AWS Network FirewallでインバウンドトラフィックをTLSインスペクションする

こんにちは、SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当している貝塚です。

先日、AWS Network FirewallのアウトバウンドTLSインスペクション使ってみた記事を投稿しました。 

アウトバウンド(Egress) TLS インスペクションを記事にしたのだから、以前からあるインバウンド(Ingress) TLS インスペクションも記事にしてしまおう、ということで、追加で検証してみました。

TLSインスペクションとは

SSL/TLSで暗号化された通信内容をチェックする機能です。

HTTPSなどのSSL/TLSで保護された通信は、クライアント-サーバ間で通信内容が暗号化されているため、通常、中継するネットワークデバイスで通信内容をチェックすることができません。SSLサーバ証明書をうまく使って中継デバイスで通信内容をチェックできるようにしたのがTLSインスペクションです。

インバウンド(Ingress) TLSインスペクション

インバウンド(AWSのドキュメントではIngressと呼ばれる)TLSインスペクションは、自サイトでTLSを用いて暗号化通信をしているウェブサーバ等を保護するために使用されます。たとえば自サイトでwww.example.comというサーバ証明書をインストールしたサイトを運営しているとしたら、Network Firewallにも同じwww.example.comの証明書をインストールしてやります。Network Firewallはウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。

検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバのみが検査対象になります。

nwfw_inbound_inspection

本稿でも、前の記事と同様、Network Firewallの基本的な設定については扱いません。Network Firewallのデプロイ、ファイアウォールポリシーの作成、ルールグループの作成などの基本的な設定手順については以下の記事などを参考にしてください。

アウトバウンド(Egress) TLSインスペクション

アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のサーバと通信するときに通信内容を検査する機能です。こちらの機能の検証記事は下記をご覧ください。

Ingress TLSインスペクション設定の流れ

Ingress TLSインスペクション機能検証のために実施した設定は以下の通りです。

  1. ACMでサーバ証明書を作成する
  2. Network FirewallのTLS検査設定を作成する
  3. Network Firewallのファイアウォールポリシーを作成する
  4. Network Firewallをデプロイしてファイアウォールポリシーを関連付ける

なお、既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできません。Network Firewallデプロイ時の流れで空のファイアウォールポリシーを作成することができますが、空のファイアウォールポリシーに後からTLS検査設定は追加できないので注意が必要です。

動作確認の流れ

Ingress TLSインスペクションの動作確認で実施した内容は以下の通りです。

  1. Network Firewallのルールグループに検証用のルールを追加する
  2. クライアントPCからHTTPSアクセスして挙動を確認する
  3. Network FirewallのAlertログを確認する

Ingress TLSインスペクション設定

ACMでサーバ証明書を作成する

まず、ACMで証明書を作成します。Network Firewallのドキュメントによると、インポートでもACMからリクエストするのでもどちらでも問題ありませんが、自己署名証明書はサポートされていません

証明書の作成手順については、AWSの公式ドキュメントやインターネット上の各種記事をご参照ください。

なお、今回は、ACMでリクエストして証明書を作成しました。

Network FirewallのTLS検査設定を作成する

AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。

configure_tls_inspection

「インバウンド SSL/TLS 検査用のサーバー証明書」で、作成した証明書を選択します。証明書は複数追加できるようなので、今回は、複数のサイトをインスペクションできることを確認するために、ACMで作成した証明書をふたつ選択しました。

configure_tls_inspection

「TLS 検査設定の詳細」を埋めた後、「スコープ設定」で検査対象とする送信元/送信先IPとポートを指定します。なお、ここで指定した範囲に含まれるTLS通信が上で選択した証明書を使用していない場合、正常な通信ができなくなってしまうようなので、検査に必要な最小限の範囲を指定するようにしましょう。

configure_scope_1

configure_scope_2

以降の設定項目も適切に入力して、TLS検査設定を作成します。

Network Firewallのファイアウォールポリシーを作成する

ファイアウォールポリシー作成時にTLS検査設定を指定します。

作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。

create_firewall_policy_tls_settings

Network Firewallをデプロイしてファイアウォールポリシーを関連付ける

Network Firewallをデプロイし、前項で作成したファイアウォールポリシーを指定します。手順はNetwork Firewallのドキュメントなどをご参照ください。

動作確認

Network Firewallのルールグループに検証用のルールを追加する

TLSインスペクションが行われることにより、HTTPSの通信はHTTP用のルールで検査できるようになっているはずです。今回の検証ではルールグループに、以下のSuricata互換ルールを追加しました。

drop http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /index.html"; http.uri; content:"index.html"; sid:1000102; rev:1;)
alert http $EXTERNAL_NET any -> $HOME_NET 443 (msg:"Detected access to tcp port 443 /scsk.html"; http.uri; content:"scsk.html"; sid:1000111; rev:1;)
pass http $EXTERNAL_NET any -> $HOME_NET 443 (http.uri; content:"scsk.html"; sid:1000112; rev:1;)
alert tls $EXTERNAL_NET any -> $HOME_NET 443 (msg:"TLS: Can't inspect this"; sid:1000121; rev:1;)
pass tls $EXTERNAL_NET any -> $HOME_NET 443 (sid:1000122; rev:1;)

1~3行目のルールで、HTTPのURIをチェックしてindex.htmlへのアクセスはドロップし、scsk.htmlへのアクセスはアラートログに出力した上で通信自体は許可するように設定しています。

4~5行目のルールは、TLSインスペクションが行われない事態を検出するために入れた念のためのルールです。HTTPS(TLS)通信だった場合にアラートログに出力した上で通信自体は許可するように設定しています。もし万が一HTTPS(TLS)通信に対してTLSインスペクションが行われなかった場合はこのルールにマッチするはずです。

クライアントPCからHTTPSアクセスして挙動を確認する

クライアントPCからウェブサーバにHTTPSアクセスします。

今回、ウェブサーバは、自前で立てたHTTPサーバの前にELBを置き、前述のTLS検査設定で指定したものと同じ証明書を用いてHTTPS化しています。

/index.htmlにアクセスしてみます。想定通り、コンテンツは表示されません。

access_index

次に、/scsk.htmlにアクセスしてみます。こちらも想定通り、問題なくコンテンツを表示できました。TLSインスペクションが働き、HTTPをチェックするルールが適用されていることが確認できました。

access_scsk

念のため証明書を確認してみます。アウトバウンドTLSインスペクションの時とは違い、発行者(Issued By)がAmazonになっている、ACMでリクエストした何の変哲もない証明書です。

cert_issued_by_amazon

今回、TLS検査設定でふたつ証明書を指定しているので、もうひとつの証明書に対応したFQDNでも同じことを試しましたが、同様の結果になりました。複数の証明書を設定しても問題なく動作するようです。

Network FirewallのAlertログを確認する

Network Firewallのアラートログを確認したところ、以下のログが出力されていました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることがログからも分かりました。

alert_log_index

alert_log_scsk

また、同じサーバ証明書をインストールした別の(IPアドレスが異なる)ウェブサーバにアクセスしたところ、以下のログが出力されました。スコープ設定で検査対象に含まれていない通信はNetwork Firewallで復号されずにTLSプロトコルと認識されて通過していったことが分かります。

alert_log_not_inspected

まとめ

Network FirewallのIngress TLS Inspectionについて、簡単な検証の結果をまとめてみました。

AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、今後もNetwork Firewallのノウハウを蓄積して記事にしていきたいと考えています。

著者について

SCSKにて、AWSの技術支援を提供するAWSテクニカルエスコートサービスの業務に従事しています。
自称ネットワークエンジニア。
CloudFormationは触っていても面白みが感じられないけれどCDKは好き。

所持資格は、
AWS Certified Solutions Architect - Professional
AWS Certified Advanced Networking - Specialty
AWS Certified Security - Specialty
AWS Certified DevOps Engineer - Professional
IPA 情報処理安全確保支援士
など。

好きなすみっコはとかげ。

貝塚広行をフォローする
クラウドに強いによるエンジニアブログです。
SCSKは専門性と豊富な実績を活かしたクラウドサービス USiZE(ユーサイズ)を提供しています。
USiZEサービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。
AWSクラウドクラウドセキュリティソリューションネットワーク
シェアする
TechHarmony
タイトルとURLをコピーしました