おい、最近のクラウドインフラのログ、ちゃんと見ているか？
「AWSやGCPがよしなに守ってくれているだろ」なんて甘い考えでいるなら、今すぐその思想をアップデートしてほしい。攻撃者は境界防御の隙間を縫い、誰も監視していない深夜にこっそり踏み台サーバーの探索（ポートスキャン）を始めている。
インシデント対応の現場で何度も見てきたが、最終的に会社を救うのは綺麗なアーキテクチャ図でも高価なセキュリティ製品でもない。「あの時、あの瞬間のフローログに何が記録されていたか」を正確に読み解く泥臭いフォレンジック能力だ。
今回は、VPCフローログ（VPC Flow Logs）を徹底的にしゃぶり尽くし、拒否されたパケット（REJECT）や不審なアウトバウンド通信をあぶり出す実践的な手法を解説する。さらに、SIEMを待たずにPythonとPandasで即席の解析パイプラインを回す方法まで叩き込む。しっかりついてこい。
—
1. なぜ「VPCフローログ」のデフォルト設定は使い物にならないのか
クラウド初心者がやりがちなミスが、「VPCフローログを有効化しました、これで安心です」というドヤ顔だ。大間違いと言っておこう。デフォルトのログ設定のままでは、ノイズの海から真の脅威を見つけ出すことは不可能に近い。
攻撃者は、お前のサーバーに対して次のような巧妙なステップを踏む。
1. 全ポートスキャン（TCP SYN Flood等）: どのポートで何が動いているか探る。
2. ブルートフォース攻撃: 22 (SSH) や 3389 (RDP) だけでなく、露出した 80や 443 の脆弱性を突く。
3. データ持ち出し（C2通信）: 侵入成功後、外部の不正なC2（Command and Control）サーバーへ細い帯域で通信を確立する。
これらを検知するためには、フローログのフォーマットをカスタムし、REJECT されたパケットだけでなく、「誰が・どこから・どのプロトコルで・どれだけのトラフィックを飛ばしたか」を構造化してキャプチャする必要がある。
—
2. 攻撃者の足跡を炙り出す！Pythonによるフローログ解析自動化
SIEM（SplunkやDatadogなど）のライセンス費用が高くて導入できない、あるいは「今すぐローカル環境で怪しいログを洗いたい」という場面は多い。現場で私が愛用している、VPCフローログのCSV（またはJSON）をパースし、不審な拒否パケットの傾向をスコアリングするPythonスクリプトを共有しよう。
このスクリプトは、短時間に何度も REJECT を発生させているIPアドレス（ポートスキャンの踏み台やボットネット）を特定するものだ。
import pandas as pd
from collections import Counter
import ipaddress
def analyze_vpc_flow_logs(file_path, threshold=50):
"""
VPCフローログ（CSV形式）を読み込み、短時間で大量のREJECTを発生させている
不審なIPアドレスを検出するフォレンジック用スクリプト
"""
print(f"[*] 解析対象ファイル: {file_path} の読み込みを開始...")
# AWS標準のVPCフローログの列名（適宜調整してください）
columns = [
'version', 'account-id', 'interface-id', 'srcaddr', 'dstaddr',
'srcport', 'dstport', 'protocol', 'packets', 'bytes',
'start', 'end', 'action', 'log-status'
]
try:
# 大容量ログを想定し、チャンクで読み込むかシンプルなread_csvを使用
df = pd.read_csv(file_path, names=columns, header=0, sep=r'\s+')
except Exception as e:
print(f"[-] ログの読み込みに失敗しました: {e}")
return
# 1. 拒否されたパケット (REJECT) のみに絞り込む
rejected_df = df[df['action'] == 'REJECT']
if rejected_df.empty:
print("[+] 異常なREJECTパケットは検出されませんでした。")
return
print(f"[!] 警告: 合計 {len(rejected_df)} 件の拒否されたパケットを検知しました。")
# 2. 送信元IPアドレス（srcaddr）ごとの拒否回数を集計
src_ip_counts = Counter(rejected_df['srcaddr'])
print("\n--- 【不審なスキャン・アクセス試行の検出結果】 ---")
print(f"{'送信元IPアドレス':<20} | {'拒否回数':<10} | {'判定'}")
print("-" * 50)
suspicious_ips = []
for ip, count in src_ip_counts.most_common(10):
# 内部IP（プライベートIP）か外部IPかの判定
try:
ip_obj = ipaddress.ip_address(ip)
is_private = ip_obj.is_private
except ValueError:
is_private = False
status = "要調査 (外部ボット/スキャナー)" if not is_private else "要確認 (内部ゾンビ端末?)"
if count >= threshold and not is_private:
suspicious_ips.append(ip)
print(f"{ip:<20} | {count:<10} | {status}")
print("-" * 50)
print(f"[*] 分析完了。閾値（{threshold}回）を超えた外部不審IP数: {len(suspicious_ips)}件")
return suspicious_ips
# 実行例（ローカルに配置したフローログのパスを指定）
if __name__ == "__main__":
# analyze_vpc_flow_logs('vpc_flow_sample.log', threshold=100)
passこのスクリプトを回すだけで、どの外部IPが執拗にポートを叩いているかが一目瞭然になる。もしお前の管理するサーバーのIPがここに頻出し、かつ action が ACCEPT になっているログがあれば……すでにゲームオーバー（侵入成功）の可能性が高い。今すぐそのインスタンスを切り離せ。
—
3. インシデントを自動検知するためのクラウドアーキテクチャ設計
手動でPythonスクリプトを回すだけでは、24時間365日の体制としては不十分だ。真に堅牢なインフラを目指すなら、クラウドネイティブな仕組みで「異常通信の自動検知と遮断」をループさせる必要がある。
設計のベストプラクティス
1. ログの集約: 各VPCのフローログをAmazon S3へリアルタイム出力。
2. イベント駆動の解析: S3へのログputをトリガーに、AWS Lambdaを起動。
3. 自動ブロック（Network ACL / Security Groupの動的制御）:
Lambda内で先ほどのような検知ロジックを走らせ、脅威度が高い（例: 1分間に同一IPから500回以上の不正なポートスキャン）と判定した場合、該当IPを自動的にセキュリティグループのインバウンド拒否ルール（またはNetwork ACL）に流し込む。
ここで注意してほしいのは、「何でもかんでも自動ブロックすればいいわけではない」という点だ。過剰な自動ブロックは、誤検知（False Positive）によって正規の顧客や自社の監視ツールを締め出す「DDoS（自爆攻撃）」を引き起こす。
現場のシニアエンジニアとしてアドバイスするなら、「最初はSlackやWebhooksへのアラート通知（検知の自動化）にとどめ、人間がワンクリックで遮断できるボットを作る」ことから始めるのが最も安全かつ確実だ。
—
4. セキュリティチーフからの現場の教訓
最後に、私がこれまで数々のインシデント現場を踏んできた中で痛感している鉄則を伝える。
- 「ログを取っている」と「ログを見ている・分析できる」は天と地ほどの差がある。
保存しているだけで誰も見ないS3のバケットは、ただのコストの無駄であり、インシデント後に「ログが足りなくて原因不明でした」と言い訳するための免罪符にすぎない。
- デフォルトを疑え。
OSのファイアウォール（iptables / nftables / ufw / Windows Firewall）のログも同様だ。OS側でも拒否されたパケットのカーネルログを監視できるように構成しておけ。クラウドのVPCフローログとOSのログを突き合わせることで、初めて攻撃者の全貌が浮かび上がってくる。
セキュリティは終わりなき旅だ。だが、適切なログの監視と迅速なフォレンジックの土台さえ築いておけば、攻撃者に冷や汗をかかされる側から、冷徹に脅威をいなす側へ回ることができる。
さあ、今すぐお前のインフラストラクチャのログ設定を見直しに行こう。仕事に戻れ、エンジニア！
コメント