Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2022年6月2日にBrett Wolmaransが投稿したブログ(https://sysdig.com/blog/aws-ec2-security-cloudtrail-sysdig/)を元に日本語に翻訳・再構成した内容となっております。
Elastic Compute Cloud（EC2）は、AWSの中でも最も人気のあるサービスの1つであり、Sysdigを使用すると、設定と権限のリスクを管理し、コンプライアンス要件を満たし、コンテナとホストVMの脆弱性を管理することによって、EC2を保護することができます。
攻撃者は不適切なセキュリティグループを悪用することができる
EC2やHostそのものに関しては、Sysdig Secureは複数の方法で警告を発しています。
- EC2ホスト上のOSやソフトウェアパッケージの脆弱性
- EC2ホスト上で動作するワークロードのランタイム脅威の検出
- EC2の定期的なCSPM/コンプライアンスチェック
- EC2の変更点の継続的なチェック/セキュリティ監視
EC2ホストの脆弱性
OSやソフトウェアパッケージの脆弱性に関しては、コンテナやホスト自体に現れることがあります。ホストはKubernetesクラスターのノードを指すこともあれば、コンテナのユースケースを持たずにワークロードを実行するEC2ホストを指すこともあります。
これらの保護は、EC2ホストに適用されるのと同様に、コンテナ環境にも適用されることを理解することが重要です。
Sysdig Secureは、EC2ホストだけでなく、Fargateの脆弱性もチェックすることができます。
OSの脆弱性（rpmやdpkgなど）、OS以外の脆弱性（JavaパッケージやRuby gemsなど）に関係なく、Sysdig SecureはEC2ホストとそれぞれのScan状況を簡単に確認することができます。
これらのホストの1つを掘り下げてみると、まず、Amazon Linux 2ベースのホストであることがわかります。
脆弱性のリストが表示され、最も緊急性の高い脆弱性に優先順位をつけるために、Sysdigでは、CriticalまたはHighで、修正プログラムが利用可能な脆弱性のみを表示するように選択することが可能です。
最初の脆弱性 ALAS2-2021-1722 は、Amazon Linux 2 ホストに存在するため、Sysdig Secure は、この脆弱性に関して Amazon Security Tracker データベースを使用しています。
Sysdig Secureは、この問題の詳細を示しています：
...そして、リンクから公式データベースにアクセスし、詳細を確認することができます。
EC2ホスト上のワークロードをランタイムで保護する
ランタイムセキュリティは、EC2ホストと、他の防御策を回避した脅威との間に存在する唯一のものです。ランタイム環境を継続的に監査することで、ランタイムの脅威がもたらす潜在的な影響を最小限に抑えることができます。
Sysdigは、コンテナに対する豊富なランタイムワークロード保護機能を備えており、Sysdigのポリシーは、コンテナレベルで行うのと同じようにホストレベルで作用します。
同じエンジンとルール、そしてFalco構文によって、ホストレベル、この場合は私たちのEC2ホストに対する悪意のある活動や脅威を検出することができます。
ここでは、”Delete Bash History” というアウトオブボックスのルールでテストを行なってみます。
このルールをPolicyに追加し、Hostにのみ適用されるようにPolicyの範囲を設定します。
では、EC2ホストで簡単なテストをしてみましょう。
そして、Sysdig はイベントを表示します。
そして、イベントを掘り下げると、必要なすべての「誰が」「何を」「いつ」「どこで」の詳細が表示され、行動を起こすことができます。これが、EC2ホストにおけるランタイムワークロード保護で す。
SysdigのEC2環境におけるCSPMバリデーション
EC2ホストでのワークロード保護もその一つです。しかし、EC2ホストは安全なクラウド環境全体に存在する必要があります。AWS環境が安全であることを確認する必要があるのです。
クラウド・セキュリティ・ポスチャー・マネジメント（CSPM）は、AWS環境全体を保護することを目的としたさまざまなユースケースを統合する仕組みです。CSPMは、クラウドのリソースを監査・追跡し、フレームワークに対してクラウドの静的な構成を評価します。
また、CSPMの主なユースケースの1つは、クラウドの設定が業界のコンプライアンスフレームワークで定義されたベストプラクティスに従っているかどうかをチェックすることです。
CSPMは以下のようなアラートを出すことができます：
- インターネットに直接接続されているデータストレージ
- データベースの暗号化の欠如
- 重要なシステム・アカウントで多要素認証が有効になっていないこと
ここでは、AWS環境で実行したCSPMコンプライアンスレポートの一覧を示します：
ここでは、あるCSPMスキャンの詳細が表示され、パスしたコントロールと、修正する必要があるいくつかのフェイルしたコントロールが表示されています。ここで使用したフレームワークは、AWS WAF COMPLIANCEというカスタムフレームワークです。
EC2の変更を継続的に検出
CSPMでは、ある時点のセキュリティポスチャーを把握することができます。一方、CloudTrailの監視に基づく継続的な検知は、リアルタイムにアラートを出すことができます。CSPMとCloudTrailの継続的な検知を組み合わせることで、最大限の可視性を得ることが可能となります。
CSPMのレポートに問題がなくても、何か変化があれば、できるだけリアルタイムにアラートする必要があります。そこで本稿では、AWS EC2の構成が変わると、リアルタイムでセキュリティホールが発生することを明らかにしたいと思います。
そして、このようなリスクの高い設定イベントをネイティブのツールで探し出し、Sysdig Secureがこのような状況でどのように役立っているのかを比較します。
どのAmazon EC2構成イベントが脅威を生むのか？
Sysdigは20の危険な設定イベントを特定しましたが、このリストは拡張可能です。
これらのイベントのいくつかは、1つ以上の有名なMITRE ATT&CK TTPに対応しています。https://attack.mitre.org/matrices/enterprise/cloud/iaas/、クラウドインフラの脅威マッピングに欠かせないものです。
セキュリティイベントインパクト説明Allocate New Elastic IP Address to AWS AccountHighアカウントにパブリックIPアドレスが割り当てられていることを検知します。Run Instances with Non-standard ImageHigh指定された数のインスタンスが非標準のイメージで起動したことを検知します。Run Instances in Non-approved RegionMedium非認証リージョンで指定された数のインスタンスの起動を検知します。Run InstancesMedium指定された数のインスタンスの起動を検知します。Revoke Security Group IngressHighAWS EC2のセキュリティグループから指定したイングレスルールが削除されたことを検知します。Revoke Security Group EgressHighAWS EC2のセキュリティグループから指定したegressルールの削除を検知します。Replace RouteMediumVPC内のルートテーブル内で既存のルートを置き換えることを検知します。Modify Snapshot AttributeMedium指定したEC2スナップショットの権限設定の追加・削除を検知します。Modify Image AttributeMedium指定された AMI の指定された属性が変更されたことを検知します。Make EBS Snapshot PublicHighEBSスナップショットの公開を検知します。Get Password DataHigh実行中のWindowsインスタンスの暗号化された管理者パスワードの取得を検知します。EC2 Serial Console Access EnabledHigh特定のリージョンのアカウントでAWS EC2のシリアルコンソールアクセスが有効になっていることを検知します。Disable EBS Encryption by DefaultMedium現在のリージョンにあるアカウントに対して、EBS暗号化をデフォルトで無効にすることを検知します。Describe InstancesMedium指定したAWS EC2インスタンス、またはすべてのEC2インスタンスの説明を検知します。Delete SubnetHigh指定されたサブネットの削除を検知します。Delete ClusterHigh指定したクラスタの削除を検知します。Create SnapshotMediumEBSボリュームスナップショットの作成とAmazon S3へ格納を検知します。Authorize Security Group IngressHighAWS EC2セキュリティグループへの指定されたイングレスルールの追加を検知します。Authorize Security Group EgressHighAWS EC2 のセキュリティグループに指定した egress ルールが追加されたことを検知します。Associate Elastic IP Address to AWS Network InterfaceHighパブリックIPアドレスがネットワークインターフェースに関連付けられたことを検知します。
このリストの中から、セキュリティの観点から非常に興味深い3つの危険な動きに焦点を当てます。
カスタムAMIは危険
Amazonによると、Amazon Machine Image（AMI）とは、ソフトウェア構成（例えば、OS、アプリケーションサーバ、アプリケーション）を含むテンプレートのことです。AMIからインスタンスを起動すると、クラウド上で仮想サーバとして動作するAMIのコピーとなります。
AWSアカウントでは、おそらく数種類のAMIが使用されており、OSやソフトウェアパッケージなど、それぞれの中身を把握する必要があります。これらのバージョンのOSやソフトウェアには脆弱性が含まれている可能性があり、それに対するランタイムソリューションが必要です。
しかし、それと同じくらい重要なのは、まず意識することです。つまり、見えないものは守れないので、カスタムAMIがインスタンス化されたら即座にアラートを出す必要があるのです。そうして初めて、状況のトリアージと是正措置が可能になります。
Sysdigは、組み込みの非標準イメージでインスタンスを実行するルールを使用して、このイベントのすべての発生を検出します。
Amazon EC2のワイドオープンなポート、とは？
ポート443のようなWebサーバーに使用されるポートのように、間違いなくインターネットに開放されるべきポートがあります。しかし、このように決して開いてはいけないポートもあり、もし開いていたら、それは大きな間違いか、侵入される状況です。
次の表は、一般に公開すべき／すべきでないポートをいくつか示しています：ポート目的これはインターネットに公開すべきなのか？80,8080,8008HTTP (cleartext)おそらくそうではないと思いますが、残念ながら多くのウェブサイトが平文になっています。443,4434,4443HTTPS (encrypted TLS)はい、おそらくそうでしょう。25,587SMTPクラウドプロバイダーがブロックする可能性はありますが。22,3389SSH and RDPいいえ！
これらのポートのうち、SSHのポート22を選んでみましょう。ポート22をインターネットに開放する正当な理由がないため、今回の例ではこのポートが良い候補となります。
AWSのIPスペースに22番ポートのオープンインスタンスがいくつ存在していると思いますか？
Shodanの公開検索を使って調べてみましょう。あなたは3,000,000と答えましたか？もしそうなら、あなたは賞品（無料トライアル）を獲得します。なぜなら、グローバルなAWS IPスペース内でポート22をリッスンしているインスタンスはおよそ300万個あるからです。
Amazonの主要なIPブロックの分布は以下の通りです（Shodanによる）：
犯罪の現場
AWSアカウント内で世界に公開されているすべてのセキュリティグループを手動で見つけることができますか？はい、そのためにAWS CLIを使用した簡易的な例を紹介します：
このアプローチの明らかな欠点は、かなり手作業で地味だということです。
私たちは、AWSアカウントで公開されたIPアドレスを見つけ、それらの評価を得るためにShodan APIを呼び出し、DynamoDBデータベースにすべてを格納する楽しいプロジェクトを発見しました。
Lambdaコード
まずはレポをcloneしてみましょう。Lambdaを実行すると、AWSのDynamoDBのテーブルにこのような素敵な結果が表示されます：
IPアドレスを含むDynamoDB
コードのチャンクを追加するごとに（どんなに簡単に入手できたとしても）管理負担が増えることはちょっと無視して、ここに根本的な問題があることがわかりますか？同じTOCTOUの問題だと思ったなら、その通りです。
スキャン間隔が長い場合のTOCTOU問題
このAWS Lambdaでは、実行時にしかパブリックIPアドレスを知ることができません。これを実行した後にAWSアカウントの誰かがIPを公開しても、次に実行する時までわかりません。
また、Lambdaを再実行する前に変更を元に戻されたとしても、私たちはそのことを知ることはできません。
犯罪現場を再現する
では、どのようにこれらの広いAWS EC2 Security Groupルールを1つ作成するのでしょうか？ここではAWS CLIを使って、0.0.0.0/0からのアクセスをすべて許可するセキュリティグループを作成・失効させていますが、実際には以下の3つのことを行っています。
- ネームタグを元にInstanceIDを探す
- このInstanceIDに対応するセキュリティグループIDの検索
- 0.0.0.0/32:22をこのSecurity Group IDに追加する。
AWS CLIでセキュリティグループを認可する
これら2つのAWS EC2セキュリティグループのイベントの間に、攻撃者はAmazon EC2セキュリティグループがポート22でインターネットに広く開かれている間にSSHセッションを悪用することができました。
Sysdig Secureは、Authorize Security Group Ingressルールによって、新しいセキュリティイングレスルールの発生をすべて検知します。
AWS EC2 EBSの暗号化
暗号化は一般的に、良いことです。AWS EC2のEBS暗号化も良いことであり、デフォルトで有効になっているはずです。
AWSによると、暗号化処理はEC2インスタンスをホストするサーバー上で行われ、インスタンスと接続されたEBSストレージ間の静止データと転送中のデータの両方のセキュリティを確保しています。
稀に古いインスタンスタイプでは暗号化をサポートしていない可能性もありますが、それは例外であり、ケースバイケースで処理されるはずです。
このように、誰かがAWSアカウント全体のデフォルトEBS暗号化設定を無効化した場合、セキュリティの観点からも大きな問題であり、この事象についてアラートを出す必要があります。
EBS暗号化が無効になることは、セキュリティ上の重大な問題です。
Sysdigは、Disable EBS Encryption by Defaultルールで、このリスクイベントの発生をすべて検出します。
AWS CloudTrailでリスクを掘り起こす
AWSは、私たちが行った変更を追跡せずに放置することはありません。AWS CloudTrailという偉大な監査ログがすべてを追跡します。
さらに良いことに、CloudTrailはイベントが発生したときに見るので、同じように使用時間の問題に悩まされることはなく、ある機能の頻度に依存することはありません。
ここでは、AWS EC2 Security Groupのイベントを忠実に見ることができます：
CloudTrailは正しい情報を持っているCloudTrailのログエントリーの詳細
CloudTrailはもちろん何百万ものイベントを持つことができ、これらのほぼすべてがセキュリティに全く影響を与えない良いイベントである可能性が高いです。しかし、どれがどれなのかどうやって知ることができるのでしょうか？ここでは、StackOverflowのメンバーが、興味深いイベントを見つけることがいかに難しいかを説明する質問を投稿しています。
StackOverflowの投稿
CloudTrailは本質的に何百万行もの大きさの空の巨大なログであることに加え、アラートを送ってきませんが、仮に送れたとしても、善悪の概念がないので、アラートは意味をなさないでしょう。
そこで、これを便利に使うには
- 善悪の区別がつき、アラートを送信できるツールを使う。
- AWSのネイティブツールでDIYする。
しかし、以前のブログ記事で書いたように、ネイティブツールで必要なものを得るのは非常に難しいでしょう。
そこで、Sysdig Secure for Cloudの登場です。
CloudTrailとSysdig Secureの出会い
SysdigはCloudTrailを常に監視しているので、CloudTrailが何かを知った瞬間に、Sysdigもそれを知ることになります。
しかし、CloudTrailとは異なり、Sysdigは正しいことと間違っていることの区別がつき、適切なタイミングで適切なデータをアラートし、そして何よりもSysdigはすぐに使えるのです。
Sysdigがデフォルトで検出するリスクの高いAmazon EC2イベントの幅を示すために、いくつかの例を見てみましょう。
まず、上記で見たように、トップ10のワーストプラクティスは、次のように0.0.0.0/0（世界）に対してSecurity Groupを開くことです。
AWSコンソールのセキュリティグループ
それでは、いくつかのリスクの高い事象について、Who/What/When/Where ifを調べてみましょう。
- 0.0.0.0のセキュリティグループを作成する
- EBS暗号化の無効化
どのように行うのでしょうか？ミニデモを使って、簡単なウォークスルーを行ってみましょう。
SysdigとAWS CloudTrail - より良い関係
AWS EC2は広い攻撃対象領域を提供し、その中でセキュリティグループは最上位に位置します。AWSセキュリティグループの制限は、安全でセキュアなデプロイメントの重要なコンポーネントです。
また、別のひどい設定イベントも見てみました。AWS EBSの暗号化をオフにすることです。どちらも絶対に知っておきたいイベントですね。
CloudTrailはすべてを見ますが、残念ながら善悪の区別がつかず、時には何百万ものエントリーを抱えています。CloudTrailのどこかに、リスクの高いイベントが埋蔵金のように隠れているのです。
Sysdigは、このようなダイヤモンドの原石をCloudTrailから見つけ出し、Sysdigのセキュリティポリシーに通し、「誰が、何を、いつ、どこで」発生したのかを即座に把握することができます。
Sysdig Secureは、Amazon EC2のセキュリティに穴が開き始めたことを簡単に確認し、簡単に修正することができます。
このブログではEC2のみに焦点を当てましたが、SysdigはAWSの重要なサービスのほとんど全てに対して、すぐに使えるセキュリティ機能を備えています。
また、Sysdig CloudTrailのルールは、オープンソースのFalcoプロジェクト（3000万回以上ダウンロードされている）と同じフォーマットを使用しているため、独自のカスタムルールを作成することができます。
Sysdigでリスクを一元的に把握する
Sysdig Secureを使用すると、EC2を含むクラウドとワークロード（ホスト、コンテナ、Kubernetes）における脅威を検出し、対応することができます。
EC2に関しては、クラウドの他の領域と同様に、Sysdigはいくつかの方法で保護を提供します：
- EC2ホスト上のOSおよびソフトウェアパッケージにおける脆弱性検出
- EC2ホスト上のワークロードのランタイム保護
- EC2の定期的なCSPMチェック
- EC2ホストへの変更の継続的なチェック
これらの保護がコンテナ環境にも適用されることを理解することが重要です。
設定や許可のリスクを管理し、コンプライアンス要件を満たし、コンテナとホストVMの脆弱性を管理することができます。
Sysdigは、深い可視性と豊富なコンテキストでリスクを一望できるため、問題を迅速に発見し修正することができます。
もしお時間があれば、無償トライアルで、こちらの動画と共に上記内容をお確かめいただけます。
https://youtu.be/2mbq9DxrsH4