1. 目的
- AWSのセキュリティ関連サービスの復習をしている。VPCフローログについて、今さらやってみるのも…と思ったが、定期的に新機能も追加されているようなので、改めて動作確認してみる。
- ちょうど2021/3/3に、VPCフローログで取得できるフィールドが追加されたとのこと。せっかくなのでそれらを含めた確認を行う。
2. やったこと
- 検証用のVPCとインスタンスを作成する。
- VPC全体に対して、VPCフローログの取得設定を行う。
- 試験トラフィックを発生させ、VPCフローログにどのように記録されるか確認する。
3. 構成図
4. 設定手順
4.1 事前準備
- 検証用のVPCなどを作成する。(上記構成図の通り)
- VPC、パブリックサブネット、パブリックサブネット上のインスタンス(EIP付与)
- インスタンスタイプはt3.micro (Nitro世代インスタンスの場合のみ詳細に出力できるフィールドがあり、それを確認したいため)
4.2 フローログの設定
- VPC全体のフローログを取得する設定を行う。
- VPCを選択 -> アクション -> 「フローログを作成」
- 今回はAthenaでログを検索したいため、「送信先」はS3を選択する。
- ログレコード形式で「AWSのデフォルト形式」を選択すると、2021/3/3に追加されたフィールドが含まれない。そのため、「カスタム形式」を選択し、「AWSのデフォルト形式」に含まれるフィールドを全て手動で選択した上で、新しいフィールド(赤枠の4つ)を追加する。
4.3 Athena検索の設定
- S3に保存されるVPCフローログを、Athenaで検索できるようにする。
- 公式ドキュメント「Amazon VPC フローログのクエリ」に従い設定する。
- 基本的に手順通り行えばよいが、テーブル作成時に新しく追加したフィールド(4つ)を含める。
# テーブルの作成
CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs (
version int,
account string,
interfaceid string,
sourceaddress string,
destinationaddress string,
sourceport int,
destinationport int,
protocol int,
numpackets int,
numbytes bigint,
starttime int,
endtime int,
action string,
logstatus string,
pkt_src_aws_service string,
pkt_dst_aws_service string,
flow_direction string,
traffic_path int
)
PARTITIONED BY (`date` date)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ' '
LOCATION 's3://[BUCKETNAME]/AWSLogs/[ACCOUNTID]/vpcflowlogs/ap-northeast-1/'
TBLPROPERTIES ("skip.header.line.count"="1");
# パーティションの作成
ALTER TABLE vpc_flow_logs
ADD PARTITION (`date`='2021-03-10')
LOCATION 's3://[BUCKETNAME]/AWSLogs/[ACCOUNTID]/vpcflowlogs/ap-northeast-1/2021/03/10';
- フィールド名にハイフンがある(例えばtraffic-pathなど)と以下のエラーになるため、「traffic_path」などのように修正した。
# エラーメッセージ（ハイフンがある場合）
line 1:8: no viable alternative at input 'create external' (service: amazonathena; status code: 400; error code: invalidrequestexception; request id: 757d9049-a6a7-4753-b554-38df81adbecb; proxy: null)
5. 試験トラフィックの生成及びフローログの確認
- トラフィックを発生させ、それらのトラフィックがどのように記録されるかを確認する。
5.1 外部（インターネット）からのsshアクセス
- 手元の作業用PCから、VPCフローログが有効化されているVPCのインスタンスへsshアクセスする。
- インスタンス(10.0.0.188)へのssh(22/tcp)のacceptが記録されている。
5.2 インスタンスからのhttps/pingアクセス
- 検証用のインスタンスから、インターネット(例：www.yahoo.co.jp)へのhttps(curl)/pingのアクセスを行う。
- 2行目にhttpsアクセス(443/tcp)、3行目にpingアクセス(protocol 1 = icmp)が記録されている。
- その他、1行目は作業用PCからのsshアクセスへの応答、4～6行目は外部へのNTPアクセスが記録されている。
5.3 インスタンスからのS3アクセス
- 検証用のインスタンスから、VPCエンドポイントがない状態で、インターネットGW経由でS3アクセスを行う。その後、S3 VPCエンドポイント(Gatewayタイプ)を作成し、エンドポイント経由でS3アクセスを行う。通信経路の違いでログがどのように変わるかを確認する。
- 一番下の行(startime 1615437144 = 2021-03-11 13:32:24(JST)) は、VPCエンドポイントがない状態で、インスタンスで"aws s3 ls"コマンドを実行した際のログ。「traffic-path」の値が「8」(Internet Gateway経由) になっている。
- 上から3行目(starttime 1615445753 = 2021-03-11 15:55:53(JST))は、S3 VPCエンドポイントを作成した後、インスタンスで"aws s3 ls"コマンドを実行した際のログ。「traffic-path」の値が「7」(VPC Endpoint経由) になっており、経路が変わったことが確認できる。
- 上記の7と8が区別できるのは2021/3時点ではNitroインスタンスのENIのみ。
6. 所感
- 今回、やっと使い方が分かったので、トラフィックが想定通りに通らない時とかの調査に活用するようにしたい。