前回の内容を元に、今回は具体的な検証方法について記載します。
検証時のデータ処理の流れ
前回記載した通り、
「Windowsイベントログからログイン成功／失敗のログを収集・（可視化するために）集計」し、
不正アクセスの疑いを検知出来るようにするために、以下の流れでデータを処理します。
①ログ収集 ＞ 蓄積 ＞ 可視化 の各ツールはLinuxに導入します。
そのため、WindowsイベントログをLinuxへ転送します。（ログ出力：Winlogbeat）
②ログ検索・集計の高速化のため、収集したログを加工（整形）してログ蓄積ツールに渡す。
（ログ収集：Logstash）
③ログ蓄積ツールと可視化ツールを連携し、不正アクセスの疑いを可視化します。
（ログ蓄積：Elasticsearch、ログ可視化：Kibana）
上記を図示したものが、下図になります。
各コンポーネントごとに必要なツール
それぞれのコンポーネントごとのOSと導入ツールは以下の表の通りです。
| No. | 役割 | OS | 導入ツール |
|---|---|---|---|
| 1 | ログ出力 | Microsoft Windows Server 2019 Base | Winlogbeat |
| 2 | ログ収集 | Amazon Linux 2 AMI (HVM) SSD Volume Type |
Java(1.8.0_131 以上) Logstash |
| 3 | ログ蓄積 | Amazon Linux 2 AMI (HVM) SSD Volume Type |
Java(1.8.0_131 以上) Elasticsearch |
| 4 | ログ 可視化 |
Amazon Linux 2 AMI (HVM) SSD Volume Type |
Kibana |
今回は検証をAWS上で実施するため、OS名はAWS上のマシンイメージ名を記載しています。
なお、No.2～4については同じOS上で検証が可能なため、1つのOSにまとめます。
具体的には、AWS上で以下の様に環境を構築しました。
AWSインスタンス設定
| サーバ | インスタンスタイプ※1 | CPU | メモリ | VPC※2 | セキュリティグループ※3 |
|---|---|---|---|---|---|
| Windows | t2.micro | 1 | 1GB | default | research_team |
| Linux | t2.large | 2 | 8GB | default | research_team |
※1. インスタンスタイプ
今回の構成で検証を行うにあたって、
Windows側にインストールするアプリケーションと必要なスペックは以下のため、
この要件を満たす「t2.micro」を使用する。
- Winlogbeatに1GB以上のメモリが必要
Linux側にインストールするアプリケーションと必要なスペックは以下のため、
この要件を満たす「t2.large」を使用する。
- Logstashに2core以上のCPUが必要
- Logstashに2GB以上のメモリが必要
- ElasticSearchに2GB以上のメモリが必要
- Kibanaに1GB以上のメモリが必要
※2. VPCとは？
Virtual Private Cloud (VPC) は、AWS アカウント専用の仮想ネットワークです。
今回はAWSで提供するデフォルト設定を使用します。(インスタンス作成時に自動的に設定されます)
※3.セキュリティグループとは？
セキュリティグループは、インスタンスの仮想ファイアウォール機能です。
サーバ間で同じセキュリティグループ(research_team)を設定し、通信ができるようにします。
インストールしたツールとバージョン
| サーバ | 導入ツール | バージョン | インストール | リポジトリ欄 |
|---|---|---|---|---|
| Windows | Winlogbeat | 7.4.2 | 公式サイトでダウンロードして、 PowerShellでインストール※1 |
|
| Linux | Amazon Corretto8(java) | 1.8.0_232 | yumでインストール※2 | |
| Linux | ElasticSearch | 7.4.2 | yumにrepositoryを追加して、 yumでインストール |
elastic.repo※3 |
| Linux | Logstash | 7.4.2 | yumにrepositoryを追加して、 yumでインストール |
elastic.repo |
| Linux | Kibana | 7.4.2 | yumにrepositoryを追加して、 yumでインストール |
elastic.repo |
※1. Winlogbeatのダウンロードリンク
https://www.elastic.co/jp/downloads/beats/winlogbeat
インストールガイドリンク
https://www.elastic.co/guide/en/beats/winlogbeat/current/winlogbeat-installation.html
※2. ElasticSearch、Logstash、Kibanaをインストールするときに必要なので先にインストール
※3. リポジトリの追加方法は以下のリンクを参照
https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html#rpm-repo
セキュリティグループ設定
AWSではセキュリティグループの設定で、
デフォルトでは外部からの通信ができないようになっています。
今回は外部からKibanaでアクセスするために、セキュリティグループの設定を行います。
セキュリティグループの具体的な設定方法
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_SecurityGroups.html
なお、Kibana以外のサービスについては、
２台のサーバが同じVPC内に所属しているため設定は不要ですが、
理解しやすいように全ポート情報を記載しています。
| サーバ | アプリケーション | 方向※ | 通信経路 | ポート番号 | 備考 |
|---|---|---|---|---|---|
| Windows | Winlogbeat | outgoing | windows(Winlogbeat) →Linux(Logstash) |
5044 | Linux側のportを開放 |
| Linux | Logstash | incoming | Linux(Logstash) →Linux(ElasticSearch) |
9200 | |
| Linux | ElasticSearch | incoming | Linux(Kibana) →Linux(ElasticSearch) |
9200 | |
| Linux | Kibana | incoming | 外部 →Linux(Kibana) |
5601 | |
| Linux | ping | incoming | 外部 →Linux |
- | 通信確認テストのため portを開放 |
※Incoming：外部からのアクセス向けに解放しておくポート(着信)
outgoing：自分がアクセスするホストのポート(発信)
ネットワークテスト
サーバ間の通信確認として「ping」コマンドでのテストを、
各サービスのポート待ち受け確認として「ss」コマンドでの
テストを実施します。
pingによる通信確認
pingコマンドを利用して、今回の通信が行われる以下の2パターンについてテストを行います。
- WindowsサーバからLinuxサーバへ
- 外部からLinuxサーバへ
それぞれpingの応答があることを確認します。
WindowsサーバからLinuxサーバへ
C:\Users\Administrator>ping 172.31.XXX.XXX
Pinging 172.31.XXX.XXX with 32 bytes of data:
Reply from 172.31.XXX.XXX: bytes=32 time<1ms TTL=255
Reply from 172.31.XXX.XXX: bytes=32 time<1ms TTL=255
Reply from 172.31.XXX.XXX: bytes=32 time<1ms TTL=255
Reply from 172.31.XXX.XXX: bytes=32 time<1ms TTL=255
Ping statistics for 172.31.XXX.XXX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
外部からLinuxサーバへ
C:\Users\han>ping 3.112.XXX.XXX
Ping 3.112.XXX.XXX with 32 bytes of data:
Reply from 3.112.XXX.XXX: bytes=32 time=11ms TTL=236
Reply from 3.112.XXX.XXX: bytes=32 time=10ms TTL=236
Reply from 3.112.XXX.XXX: bytes=32 time=11ms TTL=236
Reply from 3.112.XXX.XXX: bytes=32 time=11ms TTL=236
Ping statistics for 3.112.XXX.XXX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 10ms, Maximum = 11ms, Average = 10ms
各サービスのポート待ち受け確認
ssコマンドを利用して、各サービスのポート待ち受けを確認します。
「セキュリティグループ設定」の項目で記載した表内のポート番号が
すべてLISTEN状態であることを確認します
[root@ip-172-31-43-233 ~]# ss -pntl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:111 0.0.0.0:* users:(("rpcbind",pid=2820,fd=8))
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=3511,fd=3))
LISTEN 0 100 127.0.0.1:25 0.0.0.0:* users:(("master",pid=3304,fd=13))
LISTEN 0 128 0.0.0.0:5601 0.0.0.0:* users:(("node",pid=3897,fd=18))
LISTEN 0 128 [::]:111 [::]:* users:(("rpcbind",pid=2820,fd=11))
LISTEN 0 128 *:9200 *:* users:(("java",pid=3348,fd=218))
LISTEN 0 128 *:5044 *:* users:(("java",pid=3831,fd=100))
LISTEN 0 128 [::ffff:127.0.0.1]:9300 *:* users:(("java",pid=3348,fd=205))
LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=3511,fd=4))
LISTEN 0 50 [::ffff:127.0.0.1]:9600 *:* users:(("java",pid=3831,fd=103))
続いてログ収集からログ可視化までの設定に取り組んでいきます。
次回アウトプットは12月25日を予定しています。