ローンチ直後に経験した AWS EC2 ボットネット感染2連発の分析（Security GroupからDocker隔離まで）

QAエンジニア向けのテストコード作成実践トレーニングプラットフォーム、QA Arena を少し前にローンチしました。

サービスをローンチして「GeekNews に紹介記事を一度投稿しよう」と考えていたのですが、紹介より先に AWS セキュリティ事故の振り返り（Post-Mortem）を投稿することになりました。
「バイブコーディング（Vibe Coding）」で素早く開発する過程で見落としたセキュリティ設定がどのような結果を招いたのか、そして QA の観点からどのように対応したのかを共有します。

1. Incident Timeline & Analysis

• Phase 1 (2025.12): Inbound/Outbound Policy Failure

  • 症状: インスタンスで CVE-2017-18368 など IoT エクスプロイト攻撃の兆候および異常通信を検知。
  • 原因: Security Group の Egress（出口）が All Traffic で開放されており、感染したプロセスが外部と通信可能だった。
  • 一次対応: 汚染されたインスタンスを隔離し、AWS Systems Manager (SSM) を導入して管理者アクセスを制限。

• Phase 2 (2026.01.14): Docker Container Escape

  • 症状: AWS Trust & Safety チームから "ボットネット C&C サーバーとの通信を検知" という Abuse Report を受信。 (IP: 72.62.195.44)
  • Root Cause: ユーザー投稿コードを実行する Docker コンテナに ネットワーク分離 が適用されていなかった。AI 生成コード使用時に network_mode 設定が抜けていた。**

2. Mitigation（技術的対応）**
   事故を認知した直後、QA プロセスをインフラ領域に適用し、次のように対応しました。

• Network Isolation: 悪性 IP とのすべてのアクティブ接続を遮断。
• Security Group Hardening: Outbound トラフィックを HTTPS(443) に厳格に制限。
• Code Patch: docker_service.py コード修正により、すべてのワーカーコンテナに network_mode="none" を強制適用。

3. Conclusion
AWS 側に上記の対応内容（Evidence Attached）を説明し、最終的に [Resolved] 判定を受けました。
[IMG] AWS解決証憑イメージ

今回の事故は、「QA の範囲はアプリケーションコードを超えてインフラ構成（Configuration）まで拡張されるべき」 ことを示唆しています。
厳しい洗礼を受け、セキュリティ検証まで終えた QA-Arena です。ぜひ多くのフィードバックをお願いします。

🔗 QA-Arena: https://qa-arena.qalabs.kr/

[orange]

AIを使っていて発生したセキュリティ問題をAIで解決し、その過程をAIで整理してGeekNewsに投稿

[roxie]

これはまた…。