こんにちは、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はウェブサーバに向かう通信を、そのサーバ証明書を用いて復号化し、検査した後に再びサーバ証明書を用いて暗号化して、何食わぬ顔でウェブサーバに転送します。
検査したい対象サーバのサーバ証明書を入手しなければ検査ができないので、必然的に自身の管理下にあるサーバのみが検査対象になります。
本稿でも、前の記事と同様、Network Firewallの基本的な設定については扱いません。Network Firewallのデプロイ、ファイアウォールポリシーの作成、ルールグループの作成などの基本的な設定手順については以下の記事などを参考にしてください。
アウトバウンド(Egress) TLSインスペクション
アウトバウンド(AWSのドキュメントではEgressと呼ばれる)方向、つまり、自分たちの管理下にあるクライアントPCが、自分たちの管理下にないSSLサーバ証明書をインストールした外部のサーバと通信するときに通信内容を検査する機能です。こちらの機能の検証記事は下記をご覧ください。
Ingress TLSインスペクション設定の流れ
Ingress TLSインスペクション機能検証のために実施した設定は以下の通りです。
- ACMでサーバ証明書を作成する
- Network FirewallのTLS検査設定を作成する
- Network Firewallのファイアウォールポリシーを作成する
- Network Firewallをデプロイしてファイアウォールポリシーを関連付ける
なお、既に作成済みのファイアウォールポリシーにTLS検査設定を追加することはできません。Network Firewallデプロイ時の流れで空のファイアウォールポリシーを作成することができますが、空のファイアウォールポリシーに後からTLS検査設定は追加できないので注意が必要です。
動作確認の流れ
Ingress TLSインスペクションの動作確認で実施した内容は以下の通りです。
- Network Firewallのルールグループに検証用のルールを追加する
- クライアントPCからHTTPSアクセスして挙動を確認する
- Network FirewallのAlertログを確認する
Ingress TLSインスペクション設定
ACMでサーバ証明書を作成する
まず、ACMで証明書を作成します。Network Firewallのドキュメントによると、インポートでもACMからリクエストするのでもどちらでも問題ありませんが、自己署名証明書はサポートされていません。
証明書の作成手順については、AWSの公式ドキュメントやインターネット上の各種記事をご参照ください。
なお、今回は、ACMでリクエストして証明書を作成しました。
Network FirewallのTLS検査設定を作成する
AWSマネジメントコンソール、ネットワークファイアウォールのTLS検査設定から「TLS検査設定を作成」をクリックします。
「インバウンド SSL/TLS 検査用のサーバー証明書」で、作成した証明書を選択します。証明書は複数追加できるようなので、今回は、複数のサイトをインスペクションできることを確認するために、ACMで作成した証明書をふたつ選択しました。
「TLS 検査設定の詳細」を埋めた後、「スコープ設定」で検査対象とする送信元/送信先IPとポートを指定します。なお、ここで指定した範囲に含まれるTLS通信が上で選択した証明書を使用していない場合、正常な通信ができなくなってしまうようなので、検査に必要な最小限の範囲を指定するようにしましょう。
以降の設定項目も適切に入力して、TLS検査設定を作成します。
Network Firewallのファイアウォールポリシーを作成する
ファイアウォールポリシー作成時にTLS検査設定を指定します。
作成途中で「TLS検査設定を追加」というステップがありますので、先ほど作成したTLS検査設定を指定します。それ以外は通常のファイアウォールポリシー作成と同様の手順で、ファイアウォールポリシーの作成を完了させます。
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にアクセスしてみます。想定通り、コンテンツは表示されません。
次に、/scsk.htmlにアクセスしてみます。こちらも想定通り、問題なくコンテンツを表示できました。TLSインスペクションが働き、HTTPをチェックするルールが適用されていることが確認できました。
念のため証明書を確認してみます。アウトバウンドTLSインスペクションの時とは違い、発行者(Issued By)がAmazonになっている、ACMでリクエストした何の変哲もない証明書です。
今回、TLS検査設定でふたつ証明書を指定しているので、もうひとつの証明書に対応したFQDNでも同じことを試しましたが、同様の結果になりました。複数の証明書を設定しても問題なく動作するようです。
Network FirewallのAlertログを確認する
Network Firewallのアラートログを確認したところ、以下のログが出力されていました。意図通りにHTTPの内容をチェックし、URIに基づいて通信を制御できていることがログからも分かりました。
また、同じサーバ証明書をインストールした別の(IPアドレスが異なる)ウェブサーバにアクセスしたところ、以下のログが出力されました。スコープ設定で検査対象に含まれていない通信はNetwork Firewallで復号されずにTLSプロトコルと認識されて通過していったことが分かります。
まとめ
Network FirewallのIngress TLS Inspectionについて、簡単な検証の結果をまとめてみました。
AWSのマネージドサービスを使って高度なネットワークセキュリティを確保したいというニーズはわりとあるのではないかと感じているので、今後もNetwork Firewallのノウハウを蓄積して記事にしていきたいと考えています。