Web アプリケーションを攻撃から守る方法を調べてみた

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

zenn に引っ越しました。引っ越す前のブログはこちらです。

Web アプリケーションを悪意ある攻撃から守る方法を調べてみました。
やみくもに調べるのも一つの手ではありますが、今回は体系だったつもりになりたかったので MITRE ATT&CK® Exploit Public-Facing Application を参考にします。
MITRE ATT&CK は以前から興味があったのですが、ドキュメントを深く読み込んだことはなく、また、どのような使い方をすればいいのか理解してはいませんでした。いい機会なので自分がやろうとしている対策の評価に使ってみたいと思います。

テクニック

検索したらヒットした MITRE ATT&CK® Exploit Public-Facing Application を開きます。
MITRE ATT&CK は大きく3つの分野 (Enterprise、Mobile、ICS) に分けて資料を展開しているようです。今回は Enterprise に分類されています。

説明

ページを開くとまず説明があります。
悪用される例として、Web サーバーだけではなくデータベース、SMB、SSH、SNMP などインターネットに面している可能性があるサービスにも攻撃対象に含まれる可能性があるそうです。
アプリケーションがクラウドでホストされていると、そこから侵害されて API アクセスを許したりなどの悪用をされる可能性があります。

手順例

手順例では、過去に発生した攻撃事案を公開記事付きで紹介しています。
ここを読むと、攻撃手法と対策がかなり理解できそうです。

緩和策

攻撃を緩和するための手法が紹介されています。
機械翻訳したリストを記述しておきます。具体的な対策は後ほど。

• アプリケーションの分離とサンドボックス化
• エクスプロイト保護
• ネットワークのセグメンテーション
• 特権アカウントの管理
• ソフトウェアを更新する
• 脆弱性スキャン

検出

攻撃の検出方法が紹介されています。
こちらも機械翻訳したリストを記述します。

• アプリケーションログ
• ネットワークトラフィック

対策

担当エンジニアが MITRE ATT&CK のテクニック記事をどのように読んで活用するかを自分なりにシュミレーションしてみました。

手順例を読む

過去に発生したインシデントの手口がリンクされています。対策を行ううえで貴重な情報です。公開してくれた企業・団体のみなさまありがとうございます。
侵入に使用されたツールや攻撃対象のプロセスやファイル、盗まれるデータ、想定される被害などが記述されています。これらを理解することで自身が管理しているシステムへの防御に役立てます。

例えば、「Operation CuckooBees During Operation CuckooBees, the threat actors exploited multiple vulnerabilities in externally facing servers.」をいう列があります。
ここに注釈が付いています。(執筆日時点では 49 です) 注釈のリンクを開くと攻撃の詳細が説明されたサイトへ飛ばされます。自身が類似のサイトを管理している場合にはかなり役に立つ情報になるはずです。

緩和策

AWS 上にシステムが構築されている前提で緩和策を考えてみます。

アプリケーションの分離とサンドボックス化

アプリケーションをホストから分離する対策を行います。

アプリケーションがコンテナで動作しているのであれば、非 root で稼働します。特権(Privileged)と呼ばれることもあります。
root または特権モードでコンテナを動かしてしまうと、ホストのリソースへアクセスできてしまう可能性があります。特定のアプリケーションだけではなくシステム全体に攻撃を仕掛けられる可能性があります。
root または特権モードの危険性については Dockerコンテナを特権モードで実行することが危険な理由 が参考になると思います。
ECS ではタスク定義で明示的に特権を false にします。
EKS では1.23以降はデフォルトで特権が制限されています。

コンテナの場合は、readOnlyRootFilesystem を true にします。
アプリケーションでどうしてもファイルシステムへの書き込みが必要なケースでは、そこのディレクトリだけ別のボリュームでマウントしそこだけ書き込み可能なように構成します。
ロートファイルシステムを ReadOnly にすることでアプリケーションの改ざんやマルウェアの侵入を防ぎます。

仮想サーバーを利用している場合では不要なミドルウェア・ソフトウェアがインストールされていないこと、不要なサービスを無効にしていること、重要なファイルのパーミッションが正しく設定されていること、OS 設定変更イベントがロギングされていることなどを実施し堅牢なホストを構築します。
AWS だと、EC2 Image Builder を使ってハードニングした AMI を作成することができます。また、マーケットプレイスで CIS が公開している AMI も存在します。これらの活用を検討します。
Deploying CIS Level 1 hardened AMIs with Amazon EC2 Image Builder
aws marketplace Center for Internet Security

エクスプロイト保護

エクスプロイト保護は様々な観点があるとは思いますが、ここでは WAF を考えてみます。
外部からの攻撃がアプリケーションまで到達するのを防ぐために WAF 導入は効果的です。

AWS WAF ではマネージドルールが複数用意されています。
AWS Managed Rules rule groups list から機械翻訳で紹介します。

• ベースラインルールグループ
  • コア ルール セット (CRS) 管理ルール グループ
  • 管理者保護管理ルール グループ
  • 既知の不正な入力管理ルール グループ
• ユースケース固有のルールグループ
  • SQL データベース管理ルール グループ
  • Linux オペレーティング システムで管理されるルール グループ
  • POSIX オペレーティング システムが管理するルール グループ
  • Windows オペレーティング システムで管理されるルール グループ
  • PHP アプリケーション管理ルール グループ
  • WordPress アプリケーション管理ルール グループ
• IP レピュテーション ルール グループ
  • Amazon IP レピュテーション リスト管理対象ルール グループ
  • 匿名 IP リスト管理ルール グループ
• AWS WAF Fraud Control アカウント作成詐欺防止 (ACFP) ルールグループ
  • アカウント作成不正防止ルール一覧
• AWS WAF Fraud Control アカウント乗っ取り防止 (ATP) ルール グループ
  • アカウント乗っ取り防止ルール一覧
• AWS WAF ボット コントロール ルール グループ
  • ボット制御ルールのリスト

一般的な攻撃は網羅していると思います。AWS 提供のマネージドルールの他にセキュリティベンダーが提供しているマネージドルールも存在します。有償ということもあり機能やサポートが充実していると思います。
マネージドルール以外でもカスタムルールを作成できるのでアプリケーション固有の対策を施すことが可能です。

WAF を導入する際には以下の方針に沿って導入することをお勧めします。

• ログを有効にする
• 最初は検出モードでスタート
• ログを確認しながら過検知誤検知が無いことを確認する
• 過検知誤検知が無ければ防御モードへ変更
• 過検知誤検知があれば除外設定やカスタムルールを駆使してそれらを減らしながら防御モードへ
• ログの確認、除外設定、カスタムルールは定期的に実施する
• アプリケーション側での攻撃対策も併せて行う

ネットワークのセグメンテーション

VPC、サブネット、セキュリティグループ、NACL を駆使して論理分離をします。
ルートテーブルごとにサブネットを分割し、ポートごとにセキュリティグループを作り、CIDR 単位で通信をコントールするために NACL を使います。
サブネットの切り方は AWSサブネットの切り方を考えてみた で書いているので参考にどうぞ。

特権アカウントの管理

前述した通り、コンテナを特権モードで起動しないようにします。

仮想サーバーへのメンテナンス作業は、SSH/RDP の使用を止め Session Manager を利用します。また、RunCommand を使用して対話ログインを行わないことも手段です。
やむを得ず SSH/RDP を使う場合でも、管理者ユーザーでのログインは禁止にします。sudo には毎回パスワード入力を求めます。

マネージドサービスを使うとホストの特権アカウント管理をクラウド事業者へオフロード可能です。
DB サーバーなら RDS、ファイルサーバーなら EFS などほとんどの要求を満たすマネージドサービスが用意されているはずです。

AWS マネジメントコンソールや CLI でのアクセスも同様です。
IAM Identity Center (旧SSO) を使用してアカウントの集中管理を行います。
強い権限を持ったロールには直接ログインさせないよう工夫します。まずは ReadOnly のロールでログインし、特権ロールには時限付きでアクセスを許可します。ここに承認プロセスをはさんでも良いと思います。

ソフトウェアを更新する

OS、ミドルウェア/ソフトウェアは常にセキュリティパッチが適用された状態を保ちます。
これは勇気と工数がかかる決断ですが、攻撃されて機密情報が漏洩するよりは良い決断です。
パッチ適用手順と動作確認をする実行環境を用意し、そこでテストを行います。その後、本番環境へパッチ適用する流れです。パッチリリースから1週間程度で本番環境適用を目指します。
AWS には Patch Manager があります。Patch Manager なら一連のプロセスを半自動化し一貫したパッチ適用を実現できます。

脆弱性スキャン

公開されているアプリケーションに対して定期的に脆弱性スキャンを実施します。
外部の専門家に依頼すると信頼性のあるスキャンを実施しレポートを提出してくれると思います。

外部に依頼する前に自分たちで実施することも可能です。OWASP が Web セキュリティ テスト ガイドを公開しています。こちらは世界中のペネトレーションテスターや組織で使用されるベストプラクティスのフレームワークとなっています。
自組織でテストを実施する際に最高の教科書になると思います。
OWASP Web Security Testing Guide
OWASP wstg

MITER ATT&CK のドキュメントでの脆弱性スキャンはペネトレーションテストの文脈ですが、一方でコンテナイメージ、仮想サーバー、ソースコードへの脆弱性スキャンも必要だと考えています。
Inspector、CodeGuru セキュリティなどのマネージドサービスを使って脆弱性スキャンを実施します。Snyk のような製品を購入するのも手段です。

検出

検出の具体策を考えます。

アプリケーションログ

攻撃を受けていることをログから検出します。WAF で防御できる攻撃、アプリケーションの対策で防いでいる攻撃の検出は重要ではありませんが、それらをすり抜けてくる攻撃は検出しなければなりません。

WAF ログ、アプリケーションアクセスログは S3 または CloudWatch Logs に出力します。
S3 なら Athena、CloudWatch Logs なら Insight でクエリを準備しておき、いつでも手動検出する備えをします。
そのクエリを自動定期実行し Slack 等に通知する仕組みも構築します。
ログは可視化していたほうが人間的には優しいと思います。OpenSearch や Prometheus/Grafana、SaaS の導入を検討します。

ログから OWASP Top10 にリストされている攻撃を検出してくれるルールセットのようなものがあるといいな〜と思いつつ、ここは自分で作らないとですね。

ネットワークトラフィック

Deep Packet Inspection を導入します。

AWS Network Firewall では Exploits や WebAttack などに対応したマネージドルールグループが用意されています。これらを使うことで IPS のような動きが期待できます。
Network Firewall の導入は費用とのバランスを考慮しましょう。

まとめ

初めて MITRE ATT&CK を読んだのでこの活用方法で良いかは自信がありません。
今後も参照し続けることでもっともっと良い使い方が見つかるはずだと感じています。
セキュリティ対策は何もないところから始めても何をしていいのか分からず中途半端な対応になってしまうことが稀にあります。こういったガイドやベストプラクティスがあると助かります。