実際にラボを実施した際の記録を載せていきます。
学習の助けになったリンクや、後に見るための学習メモ、ちょっと迷った手順を書いていきます。
あと、コマンドも忘れたくないのでログしていきます。
- 学習の助けになったリンクは、「学習に役立つリンク」にまとめて書いてあります。
- 学習メモはアイコンをつけてます。
- 迷った手順は箇条書きでつらつら書いてます。
実際の手順については、Google Cloud Skills Boostのラボの手順を参照してください。
クエスト「Security & Identity Fundamentals」の7つめのラボです。
SkillBoostの始め方は記事「GCP スキルバッジをもらおう 1Google Cloud Skill Boostをはじめよう」をどうぞ。
この記事は「GCP スキルバッジをもらおう! 〜Security & Identity Fundamentals Advent Calendar 2021」の一部として公開しています。
25日にスキルバッジが獲得できるペースで公開していきます。
##ラボの情報
ラボの名前:Google Cloud Packet Mirroring with OpenSource IDS
所要時間:1時間30分 レベル:Fundamental 必要なクレジット:5
概要:
パケットミラーリングを使用してIDSを構築する
パケットミラーリングって?
- トラブルシューティングやセキュリティ、上位レイヤのアプリケーションに基づく分析に使用するのに適している
- 選択された「ミラーリング対象のソース」からのネットワーク トラフィック(内向きと外向き)をキャプチャしてコピーし、そのコピーをコレクタに転送する
- パケット ミラーリングは各パケットのペイロード全体をキャプチャするため、帯域幅の消費量が増える
パケットミラーリングポリシー
- リージョン
- VPC ネットワーク
- ミラーリング対象のソース
- コレクタ(宛先)
- ミラーリング対象のトラフィック(フィルタ)
考慮が必要な点
- ミラーリングできるのは、TCP、UDP、ICMP トラフィックのみ
- 「ミラーリング対象のソース」と「コレクタ」は同じリージョン内にある必要がある
- ゾーンは異なっていても良い
- VPC が適切にピアリングされている限り、異なる VPC 内に存在するソースとコレクタを使用することもできる
- 特にゾーン間では、帯域幅の消費量が増えるため、追加の料金がかかる
- ミラーリングするトラフィックを制限するには、フィルタを使用できる
主要なユースケース
IDS(Intrusion Detection System: 侵入検知システム)ソリューション
-
既存のIDSでは
サービスを各VMにインストールしたり、インラインにアプライアンスを設置したりする必要がある
いずれもリソースを使うし、アプライアンスが通信のボトルネックになることがある
インライン ソリューションでは、同じ VPC にある VM 内部の「East-West」トラフィックをキャプチャできない -
パケットミラーリングでは
ソフトをインストールする必要がない。ミラーリング対象の各 VM に完全に分散される。
「コレクタ」としての IDS はトラフィック フローの外部に配置される。
内部ネットワーク ロードバランサ(ILB)を使用して「North-South」トラフィックと「East-West」トラフィックの両方を受信できる。
##学習に役立つリンク
参考URL:
Packet Mirroring による高度なネットワーク脅威検出のセットアップ
パケット ミラーリングの概要
関連SDK:
VPCネットワークの構成
https://cloud.google.com/sdk/gcloud/reference/compute/networks
https://cloud.google.com/sdk/gcloud/reference/compute/firewall-rules
https://cloud.google.com/sdk/gcloud/reference/compute/routers
仮想マシンの作成
https://cloud.google.com/sdk/gcloud/reference/compute/instance-templates
https://cloud.google.com/sdk/gcloud/reference/compute/instance-groups
内部ロードバランサの構成
https://cloud.google.com/sdk/gcloud/reference/compute/backend-services
https://cloud.google.com/sdk/gcloud/reference/compute/https-health-checks
https://cloud.google.com/sdk/gcloud/reference/compute/forwarding-rules
パケットミラーリング
https://cloud.google.com/sdk/gcloud/reference/compute/packet-mirrorings/
##ラボの実施記録
###パケット ミラーリング ラボの説明
パケット ミラーリングを IDS で使用するため、Suricata というオープンソースの IDS を使用する
ラボで構築する内容が説明されているので良く読む。
ラボで構築する最終形(ラボの説明より抜粋)
- 一つのVPC、2つのサブネット、ゾーンは跨がない
- パブリックIPを持つ2つのWebサーバ
- 「コレクタ(IDS)」として使用するパブリックIPを持つサーバ
- 必要に応じてCloud NATを構成する
環境を構築して、
IDSに必要なアラートルールやポリシーを設定して、
IDSをテストできたら終了
###ネットワーキングのフットプリントを準備する
仮想プライベート ネットワークを作成する。
gcloud compute networks create dm-stamford \
--subnet-mode=custom```
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/networks/dm-stamford].
NAME: dm-stamford
SUBNET_MODE: CUSTOM
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:
Instances on this network will not be reachable until firewall rules
are created. As an example, you can allow all internal traffic between
instances as well as SSH, RDP, and ICMP by running:
$ gcloud compute firewall-rules create <FIREWALL_NAME> --network dm-stamford --allow tcp,udp,icmp --source-ranges <IP_RANGE>
$ gcloud compute firewall-rules create <FIREWALL_NAME> --network dm-stamford --allow tcp:22,tcp:3389,icmp
us-west4 内のトラフィック ミラーリングに使用するサブネットを VPC に追加
gcloud compute networks subnets create dm-stamford-uswest4 \
--range=172.21.0.0/24 \
--network=dm-stamford \
--region=us-west4
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/regions/us-west4/subnetworks/dm-stamford-uswest4].
NAME: dm-stamford-uswest4
REGION: us-west4
NETWORK: dm-stamford
RANGE: 172.21.0.0/24
STACK_TYPE: IPV4_ONLY
IPV6_ACCESS_TYPE:
IPV6_CIDR_RANGE:
EXTERNAL_IPV6_CIDR_RANGE:
us-west4 内のコレクタに使用するサブネットを VPC に追加
gcloud compute networks subnets create dm-stamford-uswest4-ids \
--range=172.21.1.0/24 \
--network=dm-stamford \
--region=us-west4```
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/regions/us-west4/subnetworks/dm-stamford-uswest4].
NAME: dm-stamford-uswest4
REGION: us-west4
NETWORK: dm-stamford
RANGE: 172.21.0.0/24
STACK_TYPE: IPV4_ONLY
IPV6_ACCESS_TYPE:
IPV6_CIDR_RANGE:
EXTERNAL_IPV6_CIDR_RANGE:
クラウドコンソールで確認してみる
ハンバーガー>VPC Network
###ファイアウォール ルールと Cloud NAT を作成する
####全部で3つのファイアウォールルールを作る
全部で 3 つのファイアウォール ルールが必要です。
#####ルール 1
すべての送信元からのすべての VM へのトラフィックに対し、標準の HTTP ポート(TCP 80)と ICMP プロトコルを許可
gcloud compute firewall-rules create fw-dm-stamford-allow-any-web \
--direction=INGRESS \
--priority=1000 \
--network=dm-stamford \
--action=ALLOW \
--rules=tcp:80,icmp \
--source-ranges=0.0.0.0/0
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/firewalls/fw-dm-stamford-allow-any-web].
Creating firewall...done.
NAME: fw-dm-stamford-allow-any-web
NETWORK: dm-stamford
DIRECTION: INGRESS
PRIORITY: 1000
ALLOW: tcp:80,icmp
DENY:
DISABLED: False
#####ルール 2
IDS に対し、すべての送信元からの、すべてのトラフィックの受信を許可
(以降のセクションで、この IDS VM にパブリック IP を割り当てないよう注意、セキュリティ上の理由)
gcloud compute firewall-rules create fw-dm-stamford-ids-any-any \
--direction=INGRESS \
--priority=1000 \
--network=dm-stamford \
--action=ALLOW \
--rules=all \
--source-ranges=0.0.0.0/0 \
--target-tags=ids
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/firewalls/fw-dm-stamford-ids-any-any].
Creating firewall...done.
NAME: fw-dm-stamford-ids-any-any
NETWORK: dm-stamford
DIRECTION: INGRESS
PRIORITY: 1000
ALLOW: all
DENY:
DISABLED: False
#####ルール 3
すべての VM に対し、「GCP IAP プロキシ」IP 範囲を TCP ポート 22 で許可する。Cloud Console から SSH で VM に接続できるように。
gcloud compute firewall-rules create fw-dm-stamford-iapproxy \
--direction=INGRESS \
--priority=1000 \
--network=dm-stamford \
--action=ALLOW \
--rules=tcp:22,icmp \
--source-ranges=35.235.240.0/20
Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/firewalls/fw-dm-stamford-iapproxy].
Creating firewall...done.
NAME: fw-dm-stamford-iapproxy
NETWORK: dm-stamford
DIRECTION: INGRESS
PRIORITY: 1000
ALLOW: tcp:22,icmp
DENY:
DISABLED: False
クラウドコンソールで確認してみる
ハンバーガー>VPC Network>FireWall
####CloudRouterを作成する
Cloud NAT を使用するための前提条件として、まず、該当するリージョンに Cloud Router を構成する
gcloud compute routers create router-stamford-nat-west4 \
--region=us-west4 \
--network=dm-stamford
Creating router [router-stamford-nat-west4]...done.
NAME: router-stamford-nat-west4
REGION: us-west4
NETWORK: dm-stamford
####Cloud NATを構成する
パブリック IP を持たない VM にインターネットでアクセスできるようにするには、該当するリージョンに Cloud NAT を作成する
gcloud compute routers nats create nat-gw-dm-stamford-west4 \
--router=router-stamford-nat-west4 \
--router-region=us-west4 \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges
Creating NAT [nat-gw-dm-stamford-west4] in router [router-stamford-nat-west4]...done.
###仮想マシンを作成する
####ウェブサーバーのインスタンス テンプレートを作成する
このテンプレートは、us-west4 内に Ubuntu サーバーを準備して単純なウェブサービスをインストールするためのもの
gcloud compute instance-templates create template-dm-stamford-web-us-west4 \
--region=us-west4 \
--network=dm-stamford \
--subnet=dm-stamford-uswest4 \
--machine-type=g1-small \
--image=ubuntu-1604-xenial-v20200807 \
--image-project=ubuntu-os-cloud \
--tags=webserver \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/instanceTemplates/template-dm-stamford-web-us-west4].
NAME: template-dm-stamford-web-us-west4
MACHINE_TYPE: g1-small
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-12-20T01:20:43.519-08:00
####ウェブサーバーのマネージド インスタンス グループを作成する(先の手順で作ったテンプレを使用)
gcloud compute instance-groups managed create mig-dm-stamford-web-uswest4 \
--template=template-dm-stamford-web-us-west4 \
--size=2 \
--zone=us-west4-a
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/zones/us-west4-a/instanceGroupManagers/mig-dm-stamford-web-uswest4].
NAME: mig-dm-stamford-web-uswest4
LOCATION: us-west4-a
SCOPE: zone
BASE_INSTANCE_NAME: mig-dm-stamford-web-uswest4
SIZE: 0
TARGET_SIZE: 2
INSTANCE_TEMPLATE: template-dm-stamford-web-us-west4
AUTOSCALED: no
####IDS VM のインスタンス テンプレートを作成する
このテンプレートは、us-west4 内に、パブリック IP なしで Ubuntu サーバーを準備するためのもの。(「コレクタ(IDS)」構築用のVM)
gcloud compute instance-templates create template-dm-stamford-ids-us-west4 \
--region=us-west4 \
--network=dm-stamford \
--no-address \
--subnet=dm-stamford-uswest4-ids \
--image=ubuntu-1604-xenial-v20200807 \
--image-project=ubuntu-os-cloud \
--tags=ids,webserver \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" | \
tee /var/www/html/index.html
systemctl restart apache2'
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/instanceTemplates/template-dm-stamford-ids-us-west4].
NAME: template-dm-stamford-ids-us-west4
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-12-20T01:21:44.123-08:00
####IDS VM のマネージド インスタンス グループを作成する
前のステップで作成したインスタンス テンプレートを使用して、IDS として構成する 1 つの VM を作成します。
後の手順で使うので、このグループ名「mig-dm-stamford-ids-uswest4
」を覚えとく。
gcloud compute instance-groups managed create mig-dm-stamford-ids-uswest4 \
--template=template-dm-stamford-ids-us-west4 \
--size=1 \
--zone=us-west4-a
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/zones/us-west4-a/instanceGroupManagers/mig-dm-stamford-ids-uswest4].
NAME: mig-dm-stamford-ids-uswest4
LOCATION: us-west4-a
SCOPE: zone
BASE_INSTANCE_NAME: mig-dm-stamford-ids-uswest4
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: template-dm-stamford-ids-us-west4
AUTOSCALED: no
###内部ロードバランサを作成する
パケット ミラーリングでは、ミラーリングされたトラフィックをコレクタのグループに転送するために、内部ロードバランサ(ILB)を使用する。
バックエンド サービスの基本的なヘルスチェックを作成します。
gcloud compute health-checks create tcp hc-tcp-80 --port 80
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/global/healthChecks/hc-tcp-80].
NAME: hc-tcp-80
PROTOCOL: TCP
ILB として使用するバックエンド サービスのグループを作成
gcloud compute backend-services create be-dm-stamford-suricata-us-west4 \
--load-balancing-scheme=INTERNAL \
--health-checks=hc-tcp-80 \
--network=dm-stamford \
--protocol=TCP \
--region=us-west4
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/regions/us-west4/backendServices/be-dm-stamford-suricata-us-west4].
NAME: be-dm-stamford-suricata-us-west4
BACKENDS:
PROTOCOL: TCP
作成した IDS マネージド インスタンス グループを、前のステップで作成したバックエンド サービス グループに追加
gcloud compute backend-services add-backend be-dm-stamford-suricata-us-west4 \
--instance-group=mig-dm-stamford-ids-uswest4 \
--instance-group-zone=us-west4-a \
--region=us-west4
Updated [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/regions/us-west4/backendServices/be-dm-stamford-suricata-us-west4].
収集エンドポイントとして機能するフロントエンドの転送ルールを作成
実際にミラーリングするトラフィックのタイプは、パケット ミラーリング ポリシーに構成する
「--is-mirroring-collector
」フラグが設定されている点にも注意
gcloud compute forwarding-rules create ilb-dm-stamford-suricata-ilb-us-west4 \
--load-balancing-scheme=INTERNAL \
--backend-service be-dm-stamford-suricata-us-west4 \
--is-mirroring-collector \
--network=dm-stamford \
--region=us-west4 \
--subnet=dm-stamford-uswest4-ids \
--ip-protocol=TCP \
--ports=all
Created [https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-e3e4f24dc1d9/regions/us-west4/forwardingRules/ilb-dm-stamford-suricata-ilb-us-west4].
###オープンソースの IDS として Suricata をインストールする
####IDS VM に SSH で接続する
クラウドコンソールで操作。
ハンバーガー>Compute Engine>VM InstancesでVMのリストを開く。
リストから、前の手順「IDS VM のマネージド インスタンス グループを作成」で作成したインスタンスグループ名「mig-dm-stamford-ids-uswest4
」と部分一致するものを探す。その行を横にスクロールして、SSH
をクリックし、SSH接続する。
(「mig-dm-stamford-ids-uswest4
」SSHで実行)
IDS VM を更新
sudo apt-get update -y
Suricata の依存関係をインストール
sudo apt-get install libpcre3-dbg libpcre3-dev autoconf automake libtool libpcap-dev libnet1-dev libyaml-dev zlib1g-dev libcap-ng-dev libmagic-dev libjansson-dev libjansson4 -y
sudo apt-get install libnspr4-dev -y
sudo apt-get install libnss3-dev -y
sudo apt-get install liblz4-dev -y
sudo apt install rustc cargo -y
Suricata をインストール
sudo add-apt-repository ppa:oisf/suricata-stable -y
sudo apt-get update -y
sudo apt-get install suricata -y
####インストールを検証する
インストールを検証してインストールされている Suricata のバージョンを確認
suricata -V
This is Suricata version 5.0.3 RELEASE
###Suricata を構成して確認する
引き続き、「mig-dm-stamford-ids-uswest4
」SSHで実行
Suricata サービスを停止して、デフォルトの構成ファイルをバックアップ
sudo systemctl stop suricata
sudo cp /etc/suricata/suricata.yaml /etc/suricata/suricata.backup
新しい Suricata 構成ファイルと簡略版のルールをダウンロードして置き換え
新しい構成ファイルによりコレクタ インターフェースが更新されるだけでなく、my.rules ファイルと suricata.yaml ファイルで構成された、ごく一部のトラフィックに対するアラートがオンになります。デフォルトの Suricata ルールセットとアラートはかなり広範で、このラボには不要なものもあります。したがって、次のコマンドを実行してファイルをコピーしてください。
wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/suricata.yaml
wget https://storage.googleapis.com/tech-academy-enablement/GCP-Packet-Mirroring-with-OpenSource-IDS/my.rules
sudo mkdir /etc/suricata/poc-rules
sudo cp my.rules /etc/suricata/poc-rules/my.rules
sudo cp suricata.yaml /etc/suricata/surica
####Suricata サービスを起動する
再起動が必要な場合はrestartを使う
sudo systemctl start suricata
sudo systemctl restart suricata
####テスト対象の単純な Suricata ルールを確認する
このラボ用に、Suricata のルールセットは 4 つにまでトリミングされてる
注: 通常、標準のルールファイルは /etc/suricata/rules/ または /var/lib/suricata/rules に配置されています。このラボではステップ 2 で、ファイルの場所を再構成して変更しています。
cat /etc/suricata/poc-rules/my.rules
出力には全部で 4 つのルールとそれぞれの説明が示されます。
####RULES#####
#UDP ALERTS
alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;)
#HTTP ALERTS
alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;)
#ICMP ALERTS
alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;)
#TCP ALERTS
alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;)
###パケット ミラーリング ポリシーを構成する
概要で説明されていた、パケット ミラーリング ポリシー5つをそれぞれ操作する。
以下のコマンドに「ミラーリングするトラフィック」が含まれていないのは、「すべて」のトラフィックをミラーリングするようにポリシーを構成することから、フィルタは必要ないためです。このポリシーでは、上り(内向き)トラフィックと下り(外向き)トラフィックの両方をミラーリングして、コレクタ ILB の一部となっている Suricata IDS デバイスに転送します。
パケット ミラーリング ポリシーを構成する
(Cloud Shellで操作する)
gcloud compute packet-mirrorings create mirror-dm-stamford-web \
--collector-ilb=ilb-dm-stamford-suricata-ilb-us-west4 \
--network=dm-stamford \
--mirrored-subnets=dm-stamford-uswest4 \
--region=us-west4
自分のときは、このコマンドが、うまくいきませんでした。
おそらくVMにインストールされているCloudSDKが古いから?
sudo gcloud components update
を試すも、パッケージマネージャーの関係で失敗。
apt-get update google-cloud-sdk
は試しておりませんです。
ここまで来て時間制限もあるので、これ以上のトラブルシュートはせずに、クラウドコンソールから操作しました。
ハンバーガー>VPCNetword>Packet Mirroing
これで、スコアも上がったし、次の手順でのキャプチャもうまくいきました。
###パケット ミラーリングをテストする
WEB VM の外部 IP をメモしておく。
クラウドコンソールで操作。
ハンバーガー>Compute Engine>VM InstancesでVMのリストを開く。
[PUBLIC_IP_WEB1]、[PUBLIC_IP_WEB2]と表記されているVMの外部IPをコピーしておく。
Cloud Shellで操作しても同じ情報を取れる
gcloud compute instances list
####パケット ミラーリングをテストする
(「mig-dm-stamford-ids-uswest4
」SSHで実行)
次のフィルタを使用してパケット キャプチャ(tcpdump)を実行する
sudo tcpdump -i ens4 -nn -n "(icmp or port 80) and net 172.21.0.0/24"
注: 172.21.0.0/24 ネットワークはミラーリング対象のサブネットです。IDS VM はこのサブネットには属していませんが、パケット ミラーリングが正しく構成されていれば、このサブネットのミラーリングされたトラフィックを受信します。
####「ミラーリング対象」のサブネットへのトラフィックを生成する
(Cloud Shellで操作する)
WEB1 に割り当てられたパブリック アドレスに対して ping を実行します。[PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換える。
ping -c 4 [PUBLIC_IP_WEB1]
(「mig-dm-stamford-ids-uswest4
」SSHで)
ping
した内容がキャプチャされているはず。
X.X.X.X は、ICMP リクエストの送信元 IP アドレスです。
tcpdump の出力に、ウェブサーバーのプライベート IP が示されていることを確認する(Google Cloud はネットワーク変換をエッジで行う)。
00:00:45.309407 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 0, length 64
00:00:45.309736 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 0, length 64
00:00:46.309406 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 1, length 64
00:00:46.309602 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 1, length 64
00:00:47.306278 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 2, length 64
00:00:47.306406 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 2, length 64
00:00:48.314506 IP X.X.X.X > 172.21.0.3: ICMP echo request, id 25159, seq 3, length 64
00:00:48.314698 IP 172.21.0.3 > X.X.X.X: ICMP echo reply, id 25159, seq 3, length 64
(Cloud Shellで操作する)
WEB2 のパブリック アドレスに対して ping を実行する
[PUBLIC_IP_WEB2] の部分を「WEB2」のパブリック IP アドレスで置き換えます。
ping -c 4 [PUBLIC_IP_WEB2]
(「mig-dm-stamford-ids-uswest4
」SSHで)
ping
した内容がキャプチャされているはず。
00:00:46.761748 IP X.X.X.60835 > 172.21.0.2.80: Flags [S]...
00:00:46.763037 IP 172.21.0.2.80 > X.X.X.60835: Flags [S.], ... ack ...
00:00:46.816407 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
00:00:46.823624 IP X.X.X.60835 > 172.21.0.2.80: Flags [P.], ... HTTP: GET / HTTP/1.1
00:00:46.823832 IP 172.21.0.2.80 > X.X.X.60835: Flags [.], ack ...
00:00:46.824549 IP 172.21.0.2.80 > X.X.X.60835: Flags [P.], ... HTTP: HTTP/1.1 200 OK
00:00:46.879214 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
00:00:46.888477 IP X.X.X.60835 > 172.21.0.2.80: Flags [F.], ...
00:00:46.888662 IP 172.21.0.2.80 > X.X.X.60835: Flags [F.], ... ack...
00:00:46.943915 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
#####レイヤ3以外のキャプチャも試す
一方のウェブサーバーに対して標準の HTTP GET リクエストを行い、初期の TCP 3-way handshake を含む出力を生成します。
ブラウザタブを開いて、アドレスバーにhttp://[PUBLIC_IP_WEB1]/
と入力して開く。
(「mig-dm-stamford-ids-uswest4
」SSHで)
00:00:46.761748 IP X.X.X.60835 > 172.21.0.2.80: Flags [S]...
00:00:46.763037 IP 172.21.0.2.80 > X.X.X.60835: Flags [S.], ... ack ...
00:00:46.816407 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
00:00:46.823624 IP X.X.X.60835 > 172.21.0.2.80: Flags [P.], ... HTTP: GET / HTTP/1.1
00:00:46.823832 IP 172.21.0.2.80 > X.X.X.60835: Flags [.], ack ...
00:00:46.824549 IP 172.21.0.2.80 > X.X.X.60835: Flags [P.], ... HTTP: HTTP/1.1 200 OK
00:00:46.879214 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
00:00:46.888477 IP X.X.X.60835 > 172.21.0.2.80: Flags [F.], ...
00:00:46.888662 IP 172.21.0.2.80 > X.X.X.60835: Flags [F.], ... ack...
00:00:46.943915 IP X.X.X.60835 > 172.21.0.2.80: Flags [.], ack ...
WEB2でも同じようにやってみる。
SSHはまだ閉じない。
###Suricata IDS の検査とアラートをテストする
パケット ミラーリングとオープンソース IDS の Suricata との統合をテストする。
ステップ 4 でアラート対象として設定した、4 つの Suricata ルールをそれぞれ確認していく。
####RULES#####
#UDP ALERTS
alert udp $HOME_NET any -> 8.8.8.8 53 (msg:"BAD UDP DNS REQUEST"; sid:99996; rev:1;)
#HTTP ALERTS
alert http any any -> $HOME_NET 80 (msg:"BAD HTTP PHP REQUEST"; http.uri; content:"index.php"; sid:99997; rev:1;)
#ICMP ALERTS
alert icmp any any -> $HOME_NET any (msg:"BAD ICMP"; sid:99998; rev:1;)
#TCP ALERTS
alert tcp $HOME_NET any -> any 6667 (msg:"BAD TCP 6667 REQUEST"; sid:99999; rev:1;)
####テスト 1: 外向き UDP ルール / アラートをテストする
いずれかのウェブサーバーで次のコマンドを実行して、外向き DNS トラフィックを生成。
dig @8.8.8.8 example.com
IDS VM 上の Suricata イベントログ ファイルで、アラートを確認する。
*IDS VM の SSH ウィンドウ*に切り替えて次のコマンドを実行します。
egrep "BAD UDP DNS" /var/log/suricata/eve.json
次のようなログエントリが記録されていることを確認します。
@GCP: {"timestamp":"2020-08-14T01:23:14.903210+0000","flow_id":412864167987242,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":47020,"dest_ip":"8.8.8.8","dest_port":53,"proto":"UDP","alert":{"action":"allowed","gid":1,"signature_id":99996,"rev":1,"signature":"BAD UDP DNS REQUEST","category":"","severity":3},"dns":{"query":[{"type":"query","id":17268,"rrname":"EXAMPLE.COM","rrtype":"A","tx_id":0}]},"app_proto":"dns","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":82,"bytes_toclient":0,"start":"2020-08-19T18:23:14.903210+0000"}}
####テスト 2: 外向き TCP ルール / アラートをテストする
いずれかのウェブサーバーから次のコマンドを実行して、外向き TCP トラフィックを生成します。
telnet 100.64.1.1 6667
Ctrl+c キーを押して終了
IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。
IDS VM の SSH ウィンドウに切り替て次のコマンドを実行。
egrep "BAD TCP" /var/log/suricata/eve.json
次のようなログエントリが記録されていることを確認
@GCP: {"timestamp":"2020-08-14T01:27:45.058526+0000","flow_id":479376049300638,"in_iface":"ens4","event_type":"alert","src_ip":"172.21.0.2","src_port":36168,"dest_ip":"100.64.1.1","dest_port":6667,"proto":"TCP","alert":{"action":"allowed","gid":1,"signature_id":99999,"rev":1,"signature":"BAD TCP 6667 REQUEST","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":74,"bytes_toclient":0,"start":"2020-08-19T18:27:45.058526+0000"}}
####テスト 3: 内向き ICMP ルール / アラートをテストする
Cloud Shell で次のコマンドを実行して内向き ICMP トラフィックを生成します。
[PUBLIC_IP_WEB1] の部分は、「WEB1」のパブリック IP アドレスで置き換えます。
ping -c 3 [PUBLIC_IP_WEB1]
IDS VM 上の Suricata イベントログ ファイルで、アラートを確認。
egrep "BAD ICMP" /var/log/suricata/eve.json
次のようなログエントリが記録されていることを確認します。
@GCP: {"timestamp":"2020-08-14T01:24:46.065250+0000","flow_id":1114966772874978,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","dest_ip":"172.21.0.2","proto":"ICMP","icmp_type":8,"icmp_code":0,"alert":{"action":"allowed","gid":1,"signature_id":99998,"rev":1,"signature":"BAD ICMP","category":"","severity":3},"flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":98,"bytes_toclient":0,"start":"2020-08-19T18:24:46.065250+0000"}}
####テスト 4: 内向き HTTP ルール / アラートをテストする
ブラウザタブを開いて、アドレスバーにhttp://[PUBLIC_IP_WEB1]/index.php
と入力して開く。
IDS VM 上の Suricata イベントログ ファイルで、アラートを確認します。
egrep "BAD HTTP" /var/log/suricata/eve.json
次のようなログエントリが記録されていることを確認します。
@GCP: {"timestamp":"2020-08-14T01:26:36.794124+0000","flow_id":1901424684045611,"in_iface":"ens4","event_type":"alert","src_ip":"X.X.X.X","src_port":61132,"dest_ip":"172.21.0.3","dest_port":80,"proto":"TCP","tx_id":0,"alert":{"action":"allowed","gid":1,"signature_id":99997,"rev":1,"signature":"BAD HTTP PHP REQUEST","category":"","severity":3},"http":{"hostname":"PUBLIC_IP_WEB1","url":"\/index.php","http_user_agent":"curl\/7.64.1","http_content_type":"text\/html","http_method":"GET","protocol":"HTTP\/1.1","status":404,"length":275},"app_proto":"http","flow":{"pkts_toserver":7,"pkts_toclient":6,"bytes_toserver":658,"bytes_toclient":1284,"start":"2020-08-19T18:26:36.660779+0000"}}
##お疲れさまでした
これでラボの手順は終了。
右上のスコア表示が「100/100」になっていることを確認して、「ラボを終了」を押します。
今回は長かったですね・・・。