マネジメントコンソールからデフォルト設定でEC2を作成する危険性について
はじめに
皆様こんにちは、あかいけです。
私は普段、お客様のAWS環境のセキュリティアセスメントをする機会が多いのですが、ほぼ毎回のように遭遇するリソースがあります。
それは 「マネジメントコンソールからデフォルト設定で作成され、その後放置されている可哀想なEC2インスタンス」 です…。
今回はこのあるあるの危険性をお伝えするため、実際に1台作って確かめてみます。
どこが危ないのか、そしてSecurity Hub・Amazon Inspector・Amazon GuardDutyが何を検知するのかまで、実際の検出結果とあわせて見ていきましょう。
デフォルトで作成してみる
まずはマネジメントコンソールから、デフォルト設定でインスタンスを起動していきます。
名前だけ入力して、それ以外はすべてデフォルト設定で作成します。
作成時にキーペアの選択ダイアログが出るので、今回は「キーペアなしで続行」を選択します。
こうして作成されたインスタンスの設定は以下の通りでした。
-
基本設定
- Nameタグ：management-console-ec2
- インスタンスタイプ：t3.micro
- AMI ID：ami-0967230e9fa45db6d
- AMI名：al2023-ami-2023.12.20260710.0-kernel-6.18-x86_64(Amazon Linux 2023)
- 仮想化タイプ：hvm
- アベイラビリティゾーン：ap-northeast-1a
- テナンシー：default
- 詳細モニタリング：無効
- EBS最適化：有効
- 拡張ネットワーキング(ENA)：有効
- キーペア：なし
- IAMインスタンスプロファイル：なし
-
ネットワーク設定
- VPC ID：デフォルトVPC
- サブネットID：デフォルトパブリックサブネット
- パブリックIPv4：自動割り当て
- プライベートIPv4：自動割り当て
- IPv6アドレス：なし
- 送信元/送信先チェック(SourceDestCheck)：有効
- セキュリティグループ：新規作成セキュリティグループ
-
ストレージ
- ルートデバイス名：/dev/xvda(EBS)
- ボリュームタイプ：gp3
- サイズ：8 GiB
- IOPS：3000
- スループット：125 MiB/s
- 暗号化：なし
- 終了時に削除(DeleteOnTermination)：有効
-
インスタンスメタデータ(IMDS)
- メタデータエンドポイント(HttpEndpoint)：有効(enabled)
- IMDSv2(HttpTokens)：必須(required)
- PUTレスポンスのホップ制限：2
- メタデータのタグ取得：無効(disabled)
- Nitro Enclaves：無効
- 休止(Hibernation)：無効
デンジャラスなポイント
この設定のまま放置すると何がまずいのか、特に危ないポイントを3つ挙げていきます。
インターネットから参照が可能
インスタンス作成時にVPCを指定しない場合はデフォルトVPCが利用されますが、デフォルトVPCのサブネットはパブリックIPを自動割り当てする設定がされています。
そのため今回のインスタンスにも、パブリックIPが付与されていました。
またVPC Block Public Accessという、VPC単位でインターネットとの通信を一括で遮断できる機能もありますが、この設定も明示的にオンにしない限りは有効になりません。
つまりデフォルトのままでは、インターネットから参照が可能な状態にあるということです…。
SSH用ポートが全開放されている
自動作成されるセキュリティグループは、デフォルトではSSH（WindowsならRDP）を0.0.0.0/0に開放する設定がされます。
そして前述のパブリックIPと組み合わさると、このSSH用ポートが世界中から到達可能となるわけです…。
EBSが暗号化されていない
デフォルト設定ではEBSは暗号化が無効化となります…。
またEBSの暗号化設定はリージョン単位でデフォルトで暗号化を有効にできますが、この設定は明示的にオンにしない限りは設定されません。
セキュリティサービスで起こる検知
前述のインスタンスを作成してから起動した状態で、そのまま1週間ほど放置してみました。
というわけでここからは、AWSのセキュリティサービスがこのインスタンスに対してどのような検知を出しているかを見ていきます。
AWS Security Hub CSPM
今回作成したリソース(インスタンス・セキュリティグループ・EBSボリューム)に紐づく失敗(FAILED)コントロールは、以下の5件でした。
| コントロール | 重要度 | 対象リソース | 内容 |
|---|---|---|---|
| EC2.19 | CRITICAL | セキュリティグループ | 高リスクなポートへの無制限アクセスを許可しない |
| EC2.18 | HIGH | セキュリティグループ | 許可されたポート以外への無制限アクセスを許可しない |
| EC2.9 | HIGH | インスタンス | EC2インスタンスはパブリックIPv4アドレスを持つべきではない |
| EC2.3 | MEDIUM | EBSボリューム | アタッチされたEBSボリュームは保管時に暗号化すべき |
| SSM.1 | MEDIUM | インスタンス | EC2インスタンスはSSMで管理されるべき |
前述したデンジャラスなポイントが、ほぼそのまま検出結果として並んでいますね。
各コントロールの詳細は、以下の公式ドキュメントに記載されています。
[EC2.19] Security groups should not allow unrestricted access to ports with high risk
SSH(22番)のような高リスクなポートを0.0.0.0/0に開放していることを検出しています。
セキュリティグループの全開放が、FSBPの中でも最も重い扱いになっている点は押さえておきたいところです。
[EC2.18] Security groups should only allow unrestricted incoming traffic for authorized ports
許可されていないポートを無制限に開放していることを検出するコントロールです。
EC2.19と対象リソースは同じセキュリティグループですが、切り口が異なり、SSHの全開放が2つのコントロールに同時に引っかかっています。
[EC2.9] EC2 instances should not have a public IPv4 address
インスタンスがパブリックIPv4アドレスを持っていることに対する検出です。
デフォルトサブネットの自動割り当てによってパブリックIPが付いた結果、このコントロールが失敗しています。
[EC2.3] Attached Amazon EBS volumes should be encrypted at-rest
EBSボリュームが未暗号化であることに対する検出です。
[SSM.1] Amazon EC2 instances should be managed by AWS Systems Manager
インスタンスがSystems Managerの管理下に無いことに対する検出です。
今回のインスタンスはIAMインスタンスプロファイルが未アタッチだったため、SSM Agentは動いていてもSSMからは管理できません。
Amazon Inspector
Amazon Inspectorではパッケージ脆弱性とネットワーク到達可能性の2種類の検出が発生していました。
合計で33件の検出があり、内訳はHIGHが14件、MEDIUMが19件でした。
パッケージ脆弱性
検出された32件は以下のとおりです。
Package vulnerabilityは32件で、Amazon Linux 2023の初期パッケージに含まれるkernelやvim、glib2、python3、sssd関連などのCVEが検出されていました。
(重要度・スコア順で並べています)
| CVE | 重要度 | スコア | 主な影響パッケージ |
|---|---|---|---|
| CVE-2026-14474 | HIGH | 8.8 | libsss_certmapほかsssd関連 |
| CVE-2026-6893 | HIGH | 8.8 | dracut, dracut-config-generic |
| CVE-2026-14476 | HIGH | 8.0 | libsss_certmapほかsssd関連 |
| CVE-2026-40034 | HIGH | 7.8 | rust-toolset-srpm-macros |
| CVE-2026-55693 | HIGH | 7.8 | vim-commonほかvim関連 |
| CVE-2026-57456 | HIGH | 7.8 | vim-commonほかvim関連 |
| CVE-2026-55895 | HIGH | 7.8 | vim-commonほかvim関連 |
| CVE-2026-58016 | HIGH | 7.5 | glib2 |
| CVE-2026-11972 | HIGH | 7.5 | python3, python3-libs |
| CVE-2026-11940 | HIGH | 7.5 | python3, python3-libs |
| CVE-2026-53078 | HIGH | 7.1 | kernel6.18, kernel6.18-tools |
| CVE-2026-54369 | HIGH | 7.1 | acl, libacl |
| CVE-2026-64600 | HIGH | 7.0 | kernel6.18, kernel6.18-tools |
| CVE-2026-53359 | HIGH | 7.0 | kernel6.18, kernel6.18-tools |
| CVE-2026-58012 | MEDIUM | 6.5 | glib2 |
| CVE-2026-58011 | MEDIUM | 6.5 | glib2 |
| CVE-2026-58013 | MEDIUM | 6.5 | glib2 |
| CVE-2026-57453 | MEDIUM | 6.5 | vim-commonほかvim関連 |
| CVE-2026-58010 | MEDIUM | 6.5 | glib2 |
| CVE-2026-12610 | MEDIUM | 6.4 | libsss_certmapほかsssd関連 |
| CVE-2026-54370 | MEDIUM | 6.3 | acl, libacl |
| CVE-2026-57454 | MEDIUM | 6.1 | vim-commonほかvim関連 |
| CVE-2026-9669 | MEDIUM | 5.9 | python3, python3-libs |
| CVE-2026-58015 | MEDIUM | 5.9 | glib2 |
| CVE-2026-0864 | MEDIUM | 5.5 | python3, python3-libs |
| CVE-2026-6245 | MEDIUM | 5.5 | libsss_certmapほかsssd関連 |
| CVE-2026-55892 | MEDIUM | 5.5 | vim-commonほかvim関連 |
| CVE-2026-57451 | MEDIUM | 5.3 | vim-commonほかvim関連 |
| CVE-2026-3276 | MEDIUM | 5.3 | python3, python3-libs |
| CVE-2026-58014 | MEDIUM | 5.1 | glib2 |
| CVE-2026-11850 | MEDIUM | 5.0 | krb5-libs |
| CVE-2026-57455 | MEDIUM | 4.7 | vim-commonほかvim関連 |
作りたてのインスタンスであっても、AMIの時点で既知の脆弱性を抱えているものは検出されます。
特に今回のように起動後にdnf updateをかけていない状態だとよく検知が発生します。
ネットワーク到達可能性
残りの1件はNetwork reachabilityの検出で、内容は以下のとおりでした。
| 項目 | 値 |
|---|---|
| タイトル | Port 22 is reachable from an Internet Gateway - TCP |
| 開いているネットワークパス | Internet Gateway > Network Acl > Security Group > Network Interface Instance |
インターネットゲートウェイ経由で22番ポートに到達できてしまう、という検出です。
CSPMにも同様の内容の検出はありましたが、Inspectorはも同様に外部から到達可能だと判定されたため検出されています。
Amazon GuardDuty
最後にAmazon GuardDutyです。
ここが今回もっとも 「デフォルト設定の危険性」 を実感した部分でした。
対象インスタンスに対して上がっていた検出は以下の1件でした。
UnauthorizedAccess:EC2/SSHBruteForceは、EC2インスタンスがSSHの総当たり攻撃に晒されていることを示す検出タイプであり、このインスタンスに対してSSHの総当たり攻撃が行われた疑いがあります。
Security HubやInspectorが「危ない状態である」という設定上の検出だったのに対し、GuardDutyは「実際に攻撃を受けている疑いがある」という実害の検出です。
なお、Amazon Linux 2023はデフォルトでSSHのパスワード認証が無効なので、この総当たりが即侵入につながるわけではありません。（今回の場合はキーペアも作成していないため、実質ログインは不可能）
それでもパブリックIPがついているインスタンスでSSHを全開放で晒し、放置している間に見知らぬ相手から攻撃対象にされていた、という事実は重く受け止めるべきでしょう…。
さいごに
以上、マネジメントコンソールからデフォルト設定でEC2を作成する危険性についてでした。
まとめると、マネジメントコンソールからポチポチで作れてしまうデフォルト設定は、実際には次のような危険な設定となっていました。
- パブリックIPが付与される
- SSHが全開放されている
- EBSが暗号化されていない
冒頭でお話ししたとおり、私がお客様のAWS環境のセキュリティアセスメントする際にこうしたインスタンスをほぼ毎回見かけます。
ただしこれらの対策は、SSHのソースを絞る or 接続はSession Managerにする / パブリックIPを付けない / パッケージのアップデートをするといったひと手間でできます。
とはいえ、どうしてもこういった可哀想なインスタンスはいつの間にか誰かが作成していることが多々あります…。
なので今回のようにSecurity Hub・Amazon Inspector・Amazon GuardDutyを有効にしておくと、設定上の不備から実際の攻撃まで、多層的に気付ける状態になるので、これらは有効化をおすすめします。
以上、「とりあえずデフォルトで作って放置した一台」が、思いのほか危うい入り口になり得ることを、この記事から感じ取っていただければ幸いです。
