シスコの SaaS 型監視・振る舞い検知ツールをマルチクラウド環境監視用に使ってみた

この記事はシスコの同志による Cisco Systems Japan Advent Calendar 2018 の 20 日目として投稿されました。

2017年版: https://qiita.com/advent-calendar/2017/cisco
2018年版: https://qiita.com/advent-calendar/2018/cisco

入社2年目(Advent Calendarも2回目)の今年は、個人的にシスコテクノロジー以外にパブリッククラウドやら、Kubernetesやら、色々勉強したので、1年の勉強の総復習の意味も込めて書いていきたいと思います！
そんないろんなものをまるっと復習できそうなテクノロジーがあるかなぁ、と思った時に、個人的にずっと触ってみたかった、シスコの SaaS 型監視・振る舞い検知ツール Stealthwatch Cloud を思いついたので、それをこの機会に記事にしながら触ってみようと思います。
[注] なので、本題の Stealthwatch Cloud の深いところまでたどり着かないかもしれませんので、あらかじめご承知おきください。。。

Cisco Stealthwatch Cloud とは？

Cisco Stealthwatch Cloud は、SaaS アプリケーションで、様々なテレメトリーやログ情報の解析を通じて、マルチクラウド(パブリック／プライベート) 環境のネットワーク監視、振る舞い検知、脅威検出を可能にするソリューションです。単一のクラウド内の監視に縛られず、利用するマルチクラウド環境 (AWS, Azure, GCP, Kubernetes Cluster, プライベートクラウドなど) の情報を1つのハブとして集めて、1つの GUI 上で可視化してくれるところがいいところかな、と思います。
もっと詳しい情報は、Cisco Stealthwach Cloud 公式ページ[JP] をご参照ください。(以下にて、GUI のサンプルを掲載)

Dynamic Entity Modeling

Cisco Stealthwatch Cloud について話す上で非常に重要なのが、この Dynamic Entity Modeling です。簡単に言えば、怪しいふるまいを機械学習的なロジックに基づいて検知するためのモデルです。
モデリングのプロセスとしては、まず利用開始から 36 日かけてデータ (IP meta data, Syslog, auth log, セキュリティイベント, Passive DNS, Cisco Talos Threat Intelligence など) を収集し、モデル (ベースライン) を作成します。このベースラインは、

• 平常時に、どんな振る舞いをしているか
• 平常時に、どんな他のエンティティと通信・やり取りしているか
• 平常時に、どういった時間帯にその通信・やり取りは行われているか
• ベースライン的に今後どんな振る舞いをすると考えられるか

といったものです。
このベースラインを作っている期間 (学習期間) に、全てのデバイス (エンティティ) がそのネットワーク内において、どのような「ロール」を担っているかの定義 (Android, Apple iOS, AWS リソース, WLC, スイッチ, ウェブサーバなど) や、アクセス方法 (via SSH/22, from Japan など) の「グルーピング」などが行われます。
36日かけて完全なモデルが完成すると、いよいよ Stealthwatch Cloud のアラートが本格的にアクティベートされます(これは 36 日経たないと使えないという意味でないので、わかりやすい怪しい行動、例えばポートスキャン、については、完全なモデルが完成していない状態でも検知可能です)。例えば、モデル内で学習した IP/Geo-location と異なる外部からの接続があった場合などに、そのエンティティを監視し、それが実際に外部からの侵入行為だった場合にアラートを出します。また、36日後も常時ベースラインの最適化は継続されます。
このモデルは、様々な脅威の検知をより正確に検知するために役立ちます。というのも、一般的に、10,000 台のエンドポイントがあるネットワークで、実際に脅威のアラートとされるのは 1-2 件/日と言われており、その 1-2 件の特定を大量のログやデータから識別するのは非常に困難を伴います。そこで、Stealthwatch Cloud で、マルチクラウド環境を監視し、1つのポイントで監視を行えるという点が有用なポイントかと思います。

Dynamic Entity Modeling によって作られたロールは以下のように自動で識別されます。

ちょっと余談ですが、シスコがどんな風に機械学習をセキュリティソリューションに活用しているか、について気になる方は、Cisco Security Analytics のホワイトペーパーをご参照ください。また、ライトに知りたい方は、この Cisco Blog のポストが参考になるかもしれません。他にも、このポストも非常に面白いです。

本題: 実際にトライアルを触ってみよう！

前置きが少し長くなりましたが、ここから実際に AWS と GCP 環境の監視を Cisco Stealthwatch Cloud 60 日間フリートライアルを使って、特にこれと考えずに触ってみたいと思います！
＊つい最近、Azureでもサポートされたのですが、時間の都合上、割愛させていただきます。

早速ですが、aws marketplaceに行ってみると、

ちゃんとありました！Subscribeを押してみると、

もう始まりました！
セットアップガイドを書きたいわけでないので、ここからのステップはサラッと。

この後のステップ

1. アカウントがアクティベートされるまで待つ (長くて12時間くらい)
2. アクティベートの通知メールのURLに飛び、パスワード設定
3. AWS側での設定

• 監視する VPC 用の Flow Log の作成
• VPC Flow Logs 用の IAM ロールの作成
• Stealthwatch Cloud との連携を許可する IAM ポリシー/ロールの作成

1. GCP側での設定

• VPC サブネット内で VPC Flow Log を有効化
• サービスアカウントの作成

1. GKE側での設定

• Kubernetes Secret の作成
• サービスアカウントの作成
• Kubernetes DeamonSet Config の作成

1. Stealthwatch Cloud 側で、AWS/GCP/GKE と連携させて、準備完了。

うまくいくと、下のようになります。

デモ

簡単なデモを考えてやってみたいと思います。
まず、Stealthwatch Cloud には、4 つの情報を常時食わせ、監視対象とします。

1. Amazon CloudWatch
2. VPC Flow Logs (from AWS)
3. VPC Flow Logs (from GCP)
4. GKE
   次に、Kali Linux を使い、GCP内に作った環境を攻撃します (AWS 環境は、ペネトレーションテストの事前申請が間に合わなそうなので割愛)。
   最後に、検知した脅威アラートを、Webex Teams の Stealthwatch Cloud Alert というスペースに通知させます。
   
   [注] この記事を書き始めたのが投稿される 36 日以上前では全然なかったため、エンティティモデルが完成した状態のものがお見せ出来ませんでした。ごめんなさい。

事前準備 (AWS環境)

GUIでポチポチして作っただけなので割愛いたします。

事前準備 (GCP/GKE環境)

ここは復習になったので、AWS に比べ触った経験も少なかったし、備忘録程度に記載いたします。

$ gcloud --version
Google Cloud SDK 228.0.0
bq 2.0.39
core 2018.12.07
gsutil 4.34

SSH 関連のコマンド

$ ssh-keygen -t rsa -f ~/.ssh/<任意の鍵ファイル名> -C <任意のユーザ名>     # SSHの秘密鍵・公開鍵のセットを生成
$ chmod 400 ~/.ssh/<任意の鍵ファイル名>     # 鍵ファイルに対するアクセス権限の変更
$ cat ~/.ssh/my-ssh-key-4-advent.pub     # 公開鍵の確認。GCP Consoleに戻り、Compute Engine＞VMインスタンス＞<任意のインスタンス>を選択し、編集＞SSHの欄に公開鍵をコピペ

NATゲートウェイの設定

GKEの設定

GUIでGKEクラスターを作成したら、まず shell 上で、肝心の kubectl コマンドを使えるようにします。連携に入る前の確認作業も行います。

$ sudo apt-get update
$ sudo apt-get install -y apt-transport-https
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ echo "deb https:/apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get install -y kubectl

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.7", GitCommit:"0c38c362511b20a098d7cd855f1314dad92c2780", GitTreeState:"clean", BuildDate:"2018-08-20T10:09:03Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10+", GitVersion:"v1.10.9-gke.5", GitCommit:"d776b4deeb3655fa4b8f4e8e7e4651d00c5f4a98", GitTreeState:"clean", BuildDate:"2018-11-08T20:33:00Z", GoVersion:"go1.9.3b4", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl get nodes
NAME                                           STATUS     ROLES     AGE       VERSION
gke-gke-cluster-1-default-pool-<#>             Ready   <none>    3h        v1.10.9-gke.5
gke-gke-cluster-1-default-pool-<#>             Ready   <none>    5h        v1.10.9-gke.5
gke-gke-cluster-1-default-pool-<#>             Ready   <none>    42m       v1.10.9-gke.5

$ gcloud container clusters get-credentials <GKEクラスター名> --zone <ゾーン名> --project <プロジェクト名>     # 既存の Kubernetes クラスタへの Kubectlエントリを可能にする

Kubernetes Secret とサービスアカウントの作成

＊ここからは、Stealthwatch Cloud の Integrations タブに記載されています。

$ echo -n "<サービスキー>" > obsrvbl-service-key.txt     # サービスキーを obsrvbl-service-key.txt ファイルに末尾を改行せずに入力
$ kubectl create secret generic obsrvbl --from-file=service_key=obsrvbl-service-key.txt     # obsrvbl-service-key.txt ファイルから Kubernetes Secret を作成
$ rm obsrvbl-service-key.txt     # サービスキーの入ったテキストファイルを削除
$ kubectl create serviceaccount --generator=serviceaccount/v1 obsrvbl     # サービスアカウントを作成
$ kubectl create clusterrolebinding "obsrvbl" --clusterrole="view" --serviceaccount="default:obsrvbl"     # GKEクラスター全体のデフォルトの名前空間内の obsrvbl というサービスアカウントに対して、読み取りの権限を持つクラスターロールを付与

Stealthwatch Cloud Sensor 用のポッドの作成

マスターノードとワーカーノードの両方でセンサーを起動させるための、Kubernetes の DaemonSetコンフィグをYAML形式で作成します。

$ vim obsrvbl-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: obsrvbl-ona
spec:
  selector:
    matchLabels:
      name: obsrvbl-ona
  template:
    metadata:
      labels:
        name: obsrvbl-ona
    spec:
      serviceAccountName: obsrvbl
      tolerations:
        - key: node-role.kubernetes.io/master
          effect: NoSchedule
      hostNetwork: true
      containers:
        - name: ona
          image: obsrvbl/ona:3.1
          env:
            - name: OBSRVBL_SERVICE_KEY
              valueFrom:
                secretKeyRef:
                  name: obsrvbl
                  key: service_key
            - name: OBSRVBL_KUBERNETES_WATCHER
              value: "true"
            - name: OBSRVBL_HOSTNAME_RESOLVER
              value: "false"
            - name: OBSRVBL_NOTIFICATION_PUBLISHER
              value: "false"

[Tips] 一応、Integrationタブに記載されているコンフィグ設定をそのまま貼りましたが、やってみたところ連携がうまくいきませんでした。少し修正はできたのですが、完全解決と行かなかったので引き続き考えてみる予定です。少し修正できたのは、上記ファイルの tolerations の部分を削除することで (tolerations含め、3行)、ひとまずうまくいきました。 kubectl get pods を実行して、Status の遷移を見るとフラップしているように見受けられたので、特定のノードに対するポッドのスケジュールをする・しないで起きていたのかな、と考えています。時間の許す限り、色々調べて原因究明するコードや補足するコマンド補足したいと思っています。

事前準備 (ペネトレーションテスト用 Kali Linux 環境)

Kali Linux は、OFFENSIVE SECURITY 社が提供しているペネトレーションテストで使用するツールをまとめた Debian ベースの Linux ディストリビューションです。ほんとは色々できるのですが、時間の関係上、単純に nmap のポートスキャンだけここではやることにします。
[注] クラウドベンダーによっては、ペネトレーションテストの実施前に申請を必要とするケースがあります。実施前に、必ず、各クラウドベンダーのポリシーを確認し、さらにパブリッククラウド環境の利用規定ポリシーなどの違反がないように行いましょう。

• Google Cloud Platform Console ヘルプ - クラウドのセキュリティに関するよくある質問「ペネトレーションテスト」
• AWS - 侵入テスト

VirtualBox 上で Kali Linux をいったん起動

1. Kali Linux OVA をリンクからダウンロード
2. VirtualBox 上に OVA をインポート *この時に、USBを無効にしてください
3. Kali Linux を起動 (デフォルトクレデンシャルは root/toor でした)
4. Kali Linux 上でターミナルを起動し、以下を実行し、その後Kali Linuxを停止

$ apt-get install openssh-server
$ echo /etc/ssh/sshd_config > /etc/ssh/backup_sshd_config
$ vim /etc/ssh/sshd_config
"PermitRootLogin prohibit-password" の行を検索で見つけ、"PermitRootLogin yes" に変更し、保存

$ update-rc.d -f ssh enable 2 3 4 5     # OS 起動時に sshd を起動させ、SSH でのリモートアクセスを有効化 (Kali Linux はデフォルト SSH ログイン不可)
$ echo /etc/default/grub > /etc/default/backup_grub
$ vim /etc/default/grub
...
GRUB_CMD_LINUX_DEFAULT="console=ttyS0,38400n8d"     # カーネルコマンドパラメータを変更

$ sudo update-grub

GCP用の raw ファイル(VMDK to VDI, VDI to RAW)の作成し、tar.gz形式で圧縮

C:\Users\<ユーザ名>>ver

Microsoft Windows [Version 10.0.17134.407]

C:\Users\<ユーザ名>>powershell start-process cmd -verb runas     # 管理者用のコマンドプロンプトへ移行
C\WINDOWS\system32:>cd \Program Files\Oracle\VirtualBox     # VirtualBox コマンドを使えるディレクトリへ移動
C:Program Files\Oracle\VirtualBox>VBoxManage list hdds     # VirtualBox で作成したインスタンスを表示。2つ目がマウント用に用意したインスタンス
UUID:           32761725-6a3a-4c76-a36c-e3f7e4dee9de
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       C:\Users\<ユーザ名>\VirtualBox VMs\Kali-Linux-2018.4-vbox-amd64\Kali-Linux-2018.4-vbox-amd64-disk001.vmdk
Storage format: VMDK
Capacity:       81920 MBytes
Encryption:     disabled

C:Program Files\Oracle\VirtualBox>VBoxManage clonehd "C:\Users\<ユーザ名>\VirtualBox VMs\Kali-Linux\Kali-Linux-2018.4-vbox-amd64-disk001.vmdk" "D:\tmp\kali.vdi" --format vdi     # VDI 形式に変換して、外付け HDD にクローン
C:Program Files\Oracle\VirtualBox>VBoxManage clonehd "D:\tmp\kali.vdi" "D:\tmp\disk.raw" --format raw     # VDI を RAW に変換。隠しコマンド "VBoxManage Internalcommands converttoraw" での変換も可能

[注] RAW 形式のイメージは disk.raw という名前にしないといけないようです。

また、RAW 形式にした disk.raw は tar.gz 形式で圧縮して GCP にアップロードすることが必須です。もちろんコマンドプロンプトを使ってもいいのですが、なぜか動いてくれなかったので、私は、7zip を使って圧縮しました。

Kali Linux のイメージをGCP上のバケットにアップロード

各環境での Google Cloud SDK のクイックスタートはこちら

C:\Users\<ユーザ名>\AppData\Local\Google\Cloud SDK>gsutil mb gs://<バケット名>     # GCP上に Kali Linux のイメージをアップロードするためのバケットを作成
C:\Users\<ユーザ名>\AppData\Local\Google\Cloud SDK>gsutil cp "D:\tmp\kali-linux.tar.gz" gs://<バケット名>     # 圧縮した disk.raw イメージを作成した GCP 上のバケットにコピー

Kali Linux のVMをGCP上で起動

$ gcloud compute images create kali-linux --source-uri gs://<バケット名>/disk.tar.gz
$ gcloud compute machine-types list | grep asia-northeast1-b
f1-micro         asia-northeast1-b          1     0.60
g1-small         asia-northeast1-b          1     1.70
n1-highcpu-16    asia-northeast1-b          16    14.40
n1-highcpu-2     asia-northeast1-b          2     1.80
n1-highcpu-32    asia-northeast1-b          32    28.80
n1-highcpu-4     asia-northeast1-b          4     3.60
n1-highcpu-64    asia-northeast1-b          64    57.60
n1-highcpu-8     asia-northeast1-b          8     7.20
n1-highcpu-96    asia-northeast1-b          96    86.40
n1-highmem-16    asia-northeast1-b          16    104.00
n1-highmem-2     asia-northeast1-b          2     13.00
n1-highmem-32    asia-northeast1-b          32    208.00
n1-highmem-4     asia-northeast1-b          4     26.00
n1-highmem-64    asia-northeast1-b          64    416.00
n1-highmem-8     asia-northeast1-b          8     52.00
n1-highmem-96    asia-northeast1-b          96    624.00
n1-standard-1    asia-northeast1-b          1     3.75
n1-standard-16   asia-northeast1-b          16    60.00
n1-standard-2    asia-northeast1-b          2     7.50
n1-standard-32   asia-northeast1-b          32    120.00
n1-standard-4    asia-northeast1-b          4     15.00
n1-standard-64   asia-northeast1-b          64    240.00
n1-standard-8    asia-northeast1-b          8     30.00
n1-standard-96   asia-northeast1-b          96    360.00

$ gcloud compute instances create kali-linux --image kali-linux --machine-type f1-micro --zone northeast1-b

[注] GCP 上でカスタムイメージを作る際に、Error: Could not fetch source: the tar archive is not a valid image というエラーが出ることに悩まされました。このエラーのルートコーズや対処法はいまいちわからないままでしたが、複数環境でソースイメージの作り直しやら、アップロードし直しを繰り返し、なぜかある環境でのみうまくいきました。この点については、今後同じエラーに会いたくないので引き続き確認してみたいと思います。

Kali Linux でポートスキャン攻撃を実行

$ uname -a
Linux kali 4.18.0-kali2-amd64 #1 SMP Debian 4.18.10-2kali1 (2018-10-09) x86_64 GNU/Linux

root@kali:~# nmap
Nmap 7.70 ( https://nmap.org )
Usage: nmap [Scan Type(s)] [Options] {target specification}
TARGET SPECIFICATION:
  Can pass hostnames, IP addresses, networks, etc.
  Ex: scanme.nmap.org, microsoft.com/24, 192.168.0.1; 10.0.0-255.1-254
  -iL <inputfilename>: Input from list of hosts/networks
  -iR <num hosts>: Choose random targets
  --exclude <host1[,host2][,host3],...>: Exclude hosts/networks
  --excludefile <exclude_file>: Exclude list from file
HOST DISCOVERY:
  -sL: List Scan - simply list targets to scan
  -sn: Ping Scan - disable port scan
  -Pn: Treat all hosts as online -- skip host discovery
  -PS/PA/PU/PY[portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports
  -PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
  -PO[protocol list]: IP Protocol Ping
  -n/-R: Never do DNS resolution/Always resolve [default: sometimes]
  --dns-servers <serv1[,serv2],...>: Specify custom DNS servers
  --system-dns: Use OS's DNS resolver
  --traceroute: Trace hop path to each host
SCAN TECHNIQUES:
  -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
  -sU: UDP Scan
  -sN/sF/sX: TCP Null, FIN, and Xmas scans
  --scanflags <flags>: Customize TCP scan flags
  -sI <zombie host[:probeport]>: Idle scan
  -sY/sZ: SCTP INIT/COOKIE-ECHO scans
  -sO: IP protocol scan
  -b <FTP relay host>: FTP bounce scan
PORT SPECIFICATION AND SCAN ORDER:
  -p <port ranges>: Only scan specified ports
    Ex: -p22; -p1-65535; -p U:53,111,137,T:21-25,80,139,8080,S:9
  --exclude-ports <port ranges>: Exclude the specified ports from scanning
  -F: Fast mode - Scan fewer ports than the default scan
  -r: Scan ports consecutively - don't randomize
  --top-ports <number>: Scan <number> most common ports
  --port-ratio <ratio>: Scan ports more common than <ratio>
SERVICE/VERSION DETECTION:
  -sV: Probe open ports to determine service/version info
  --version-intensity <level>: Set from 0 (light) to 9 (try all probes)
  --version-light: Limit to most likely probes (intensity 2)
  --version-all: Try every single probe (intensity 9)
  --version-trace: Show detailed version scan activity (for debugging)
SCRIPT SCAN:
  -sC: equivalent to --script=default
  --script=<Lua scripts>: <Lua scripts> is a comma separated list of
           directories, script-files or script-categories
  --script-args=<n1=v1,[n2=v2,...]>: provide arguments to scripts
  --script-args-file=filename: provide NSE script args in a file
  --script-trace: Show all data sent and received
  --script-updatedb: Update the script database.
  --script-help=<Lua scripts>: Show help about scripts.
           <Lua scripts> is a comma-separated list of script-files or
           script-categories.
OS DETECTION:
  -O: Enable OS detection
  --osscan-limit: Limit OS detection to promising targets
  --osscan-guess: Guess OS more aggressively
TIMING AND PERFORMANCE:
  Options which take <time> are in seconds, or append 'ms' (milliseconds),
  's' (seconds), 'm' (minutes), or 'h' (hours) to the value (e.g. 30m).
  -T<0-5>: Set timing template (higher is faster)
  --min-hostgroup/max-hostgroup <size>: Parallel host scan group sizes
  --min-parallelism/max-parallelism <numprobes>: Probe parallelization
  --min-rtt-timeout/max-rtt-timeout/initial-rtt-timeout <time>: Specifies
      probe round trip time.
  --max-retries <tries>: Caps number of port scan probe retransmissions.
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes
  --min-rate <number>: Send packets no slower than <number> per second
  --max-rate <number>: Send packets no faster than <number> per second
FIREWALL/IDS EVASION AND SPOOFING:
  -f; --mtu <val>: fragment packets (optionally w/given MTU)
  -D <decoy1,decoy2[,ME],...>: Cloak a scan with decoys
  -S <IP_Address>: Spoof source address
  -e <iface>: Use specified interface
  -g/--source-port <portnum>: Use given port number
  --proxies <url1,[url2],...>: Relay connections through HTTP/SOCKS4 proxies
  --data <hex string>: Append a custom payload to sent packets
  --data-string <string>: Append a custom ASCII string to sent packets
  --data-length <num>: Append random data to sent packets
  --ip-options <options>: Send packets with specified ip options
  --ttl <val>: Set IP time-to-live field
  --spoof-mac <mac address/prefix/vendor name>: Spoof your MAC address
  --badsum: Send packets with a bogus TCP/UDP/SCTP checksum
OUTPUT:
  -oN/-oX/-oS/-oG <file>: Output scan in normal, XML, s|<rIpt kIddi3,
     and Grepable format, respectively, to the given filename.
  -oA <basename>: Output in the three major formats at once
  -v: Increase verbosity level (use -vv or more for greater effect)
  -d: Increase debugging level (use -dd or more for greater effect)
  --reason: Display the reason a port is in a particular state
  --open: Only show open (or possibly open) ports
  --packet-trace: Show all packets sent and received
  --iflist: Print host interfaces and routes (for debugging)
  --append-output: Append to rather than clobber specified output files
  --resume <filename>: Resume an aborted scan
  --stylesheet <path/URL>: XSL stylesheet to transform XML output to HTML
  --webxml: Reference stylesheet from Nmap.Org for more portable XML
  --no-stylesheet: Prevent associating of XSL stylesheet w/XML output
MISC:
  -6: Enable IPv6 scanning
  -A: Enable OS detection, version detection, script scanning, and traceroute
  --datadir <dirname>: Specify custom Nmap data file location
  --send-eth/--send-ip: Send using raw ethernet frames or IP packets
  --privileged: Assume that the user is fully privileged
  --unprivileged: Assume the user lacks raw socket privileges
  -V: Print version number
  -h: Print this help summary page.
EXAMPLES:
  nmap -v -A scanme.nmap.org
  nmap -v -sn 192.168.0.0/16 10.0.0.0/8
  nmap -v -iR 10000 -Pn -p 80
SEE THE MAN PAGE (https://nmap.org/book/man.html) FOR MORE OPTIONS AND EXAMPLES

root@kali:~# nmap <ポートスキャンの対象となる IP アドレス> -sP     # ターゲットのホストが ping に応答するかを確認
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-18 10:24 EST
Nmap scan report for <ポートスキャンの対象となる IP アドレス>
Host is up (0.00096s latency).
Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

root@kali:~# nmap <ポートスキャンの対象となる IP アドレス> -sS -n     # TCP SYN スキャン (ハーフオープンスキャン・ステルススキャン) を実行し、ターゲットとなるポートから SYN/ACK を受信できるか否かを確認
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-18 10:25 EST
Nmap scan report for <ポートスキャンの対象となる IP アドレス>
Host is up (1.0s latency).
Not shown: 991 closed ports
PORT     STATE SERVICE
80/tcp   open  http
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
902/tcp  open  iss-realsecure
912/tcp  open  apex-mesh
3300/tcp open  ceph
3389/tcp open  ms-wbt-server
8081/tcp open  blackice-icecap

Nmap done: 1 IP address (1 host up) scanned in 3.46 seconds

Stealthwatch Cloud 上でのアラートを確認

• Stealthwatch Cloud Console を開く
  
  

• Stealthwatch Cloud Console の Alert タブから、ポートスキャンのアラートを生成していることを確認
  

• Port Scan の詳細情報を確認
  

[注] 上記の画像で「どのような攻撃が行われたか」が確認でき、さらに、この下に実際の観察を記録したリストが表示されます。自環境での観察だと、Kali-Linux の Scanner IP から スキャンした IP とポートレンジくらいしか見れなくて添付するには寂しいので、ここでは見栄えするサンプルを貼り付けます。

アラートを Webex Teams App に通知

自分でプログラムを頑張って作成して、カスタマイズされたアラート通知を、、、と考えていましたが、どうやらデフォルトで、Webex Teams へのアラートインテグレーションがサポートされているようなので、それを使ってみることにします！

1. Stealthwatch Cloud Console から「設定(ねじマーク)>Integrations>Services/Webhooks>Cisco Webex Teams」を選択
   

2. Cisco Webex Teams の Web アプリケーション (https://teams.webex.com) を開き、アラートを通知したいスペースを開いて、"@Stealthy" ボットをスペースに追加
   

3. Webex Teams Space のリンクから、Room Id を参照し、Stealthwatch Cloud に Room Id をコピペ
   
   

4. Webex Teams で通知が来ているかを確認
   
   デモ終了！うまくいきました！

まとめ

• Stealthwatch Cloud で、AWS, GCP, GKE を監視
• Kali-Linux を GCP 上に作成し、ペネトレーションテストを実施
• 検知されたセキュリティアラートを Webex Teams App に通知
• マルチクラウド環境を 1 つのマネジメントコンソールから監視することが可能
• 単なるアラートでなく、「どのようなことが起きているか」をセキュリティの観点から可視化することで、ルートコーズ分析にかかる時間の削減を期待できる
• 今回は触れなかったが、Stealthwatch Cloud は、VPC flow Logs, CloudWatch だけでなく、Cloud Trail, Lambda, IAM, Inspector logs, GuardDuty との連携が可能な他、プライベートネットワークの監視も行え、詳細設定を行うことで端末の自動隔離も可能

おまけ

シスコは次世代セキュリティ人材育成に向けてサイバーセキュリティスカラシップを創設しています。
学生向け、受講費用無料のこのプログラムの一部オンラインコースは学生以外の方にも広く活用いただけることになりました。詳しくはこちらをご参照ください。
私個人も2017年末に受講しましたが、セキュリティの基礎学習にもってこいのコンテンツで、全てオンラインベースの Self-paced スタイルなので進めやすくなっておりますので、ご関心のある方はぜひご活用ください。

参考URL

• Cisco.com - Cisco Stealthwatch Cloud
• Cisco Stealthwatch Cloud - Stealthwatch Cloud Free Trial Guide
• Cloud Protect Design & Deployment Guide for Cisco Stealthwatch Cloud Public & Private Network Monitoring
• A New Way to Look at AWS Security
• Monitoring Serverless Architectures in AWS
• Cisco Blogs - Security

免責事項

本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。