- 本記事を書いた経緯
- 誰向けか
- 本記事で書かないこと
- 「トラフィックの方向」オプションとは
- 検証内容
- 検証_パターン1
- 検証_パターン2
- 検証_パターン3
- 結局、NFW導入時は「転送」「すべて」どちらを指定すれば良いのか
- 感想
技術4課改め、クラウドリライアビリティ課（略してCR課）の前田です。今回もNetwork Firewallに関するお話をさせていただきたいと思います。
今回は何かの解説というよりも、実際に動作検証してみただけという記事ですので当たり前のことしか書いておりません。
「それでもいいよ！」という方のみご覧くだされば幸いです。
本記事を書いた経緯
案件でNetwork Firewall（以降、NFWと表記）を導入することになり、NFWについて調査をしております。
NFWのステートフルルールにて「トラフィックの方向」というオプションを見かけたのですが、頭では理解できたものの実感が湧かなかったので動作確認してみました。
誰向けか
- NFWの導入を検討していて、「トラフィックの方向？何これ」となっている方
- 「トラフィックの方向」設定時の動作について頭では理解しているけど、実際に動作を確認してみたい。けど検証が面倒くさい…という方
本記事で書かないこと
「トラフィックの方向」以外のNFWの用語の説明。
特に出てくるNFWルールグループ関連の用語については弊社山本が書いた下記記事等が参考になるかと思います。
「トラフィックの方向」オプションとは
NFWでステートフルルール（以降、NFWルールと表記）を設定する際のオプションで、NFWルールの評価対象となるトラフィックの方向を指定できます。
選択肢それぞれの説明は、マネジメントコンソール記載の説明を借りると下記のようになります。
転送…指定された送信元から指定された送信先に送信されるトラフィックを検査します。
すべて…あらゆる方向からのトラフィックを検査します。（←この「あらゆる」という表現に引っかかり、今回検証するきっかけになりました。）
検証内容
検証環境について
vpc.Spoke1、vpc.Spoke2それぞれにEC2を配置してNFWを通るようにルーティングしておきます。NFWルールを検証条件に応じて変更し、EC2同士でpingを飛ばし合うことで検証します。（尚、本来は例示用IPを使用すべきですが今回は分かりやすさ重視で10.X.X.Xを使用しております。ご容赦下さい。）
NFWルール設定について
ステートフルルールのデフォルトアクションを「厳格な順序」（※1）にして全ての通信を暗黙的に拒否するようにし、特定の通信のみ許可するルールを設定するようにします。（つまり、ホワイトリスト形式を採用します。）
下記画像の「確立された接続のパケットをドロップ」が暗黙的拒否設定に該当します。「確立された接続のパケットをアラート」は、暗黙的拒否された通信にアラートログ（※2）を出すために設定しています。
※1…デフォルトアクション「厳格な順序」については下記のAWS公式ブログも参考になるかと思います。 aws.amazon.com
※2…アラートログの説明は下記ブログに記載しております。
検証_パターン1
検証内容
「トラフィックの方向」を「転送」に指定する場合の動作を確認します。
理解が合っているならば、下記のような結果になるはずです。
- 10.0.1.68/32から発信される、10.0.2.68/32を宛先とする通信はNFWルールの評価対象になって許可され、pingは通る
- 10.0.2.68/32から発信される、10.0.1.68/32を宛先とする通信はNFWルールの評価対象にならず暗黙的拒否の対象となり、pingは通らない
実際のルール設定は下記になります。
※NFWルールが許可した通信にもアラートログを出したいので、下記のような設定としています。詳細な内容については下記ブログをご覧ください。
暗黙的拒否のNetwork Firewallにおいてアラートルールのみでは拒否される。パスルールも必要！ - サーバーワークスエンジニアブログ
検証結果
10.0.1.68/32から発信される、10.0.2.68/32を宛先とするpingは通りました。
尚、ステートフルルールなので往路の通信が許可されていれば復路の通信も許可されます。
アラートログにも、設定したNFWルールによって許可されている旨が記載されています。
10.0.2.68/32から発信される、10.0.1.68/32を宛先とするpingは通りませんでした。
アラートログにも、デフォルトの拒否ルールによってブロックされている旨が記載されています。
上記のことから、「トラフィックの方向」を「転送」に指定したルールでは、「送信元に指定したCIDRから送信先に指定したCIDRへのトラフィックのみが評価される」ことが確認できました。
検証_パターン2
検証内容
「トラフィックの方向」を「すべて」に指定する場合の動作を確認します。送信元CIDR・送信先CIDRの設定はパターン1と同様です。
理解が合っているならば、下記のような結果になるはずです。
- 10.0.1.68/32から発信される、10.0.2.68/32を宛先とする通信はNFWルールの評価対象になって許可され、pingは通る
- 10.0.2.68/32から発信される、10.0.1.68/32を宛先とする通信はNFWルールの評価対象になって許可され、pingは通る
実際のルール設定は下記になります。
検証結果
10.0.1.68/32から発信される、10.0.2.68/32を宛先とするpingは通りました。
10.0.2.68/32から発信される、10.0.1.68/32を宛先とするpingも通りました。
上記のことから、「トラフィックの方向」を「すべて」に指定したルールでは、「送信元に指定したCIDR、送信先に指定したCIDRどちらが発信元になってもトラフィックは評価される」ことが確認できました。
検証_パターン3
検証内容
「トラフィックの方向」を「すべて」に指定し、送信元CIDRに2つのEC2のIPを指定し、送信先CIDRには適当な値を指定します。
「あらゆる方向からのトラフィックを検査」という説明を額面通りに受け取ると送信元CIDR/送信先CIDRのどちらかにとりあえず値が指定されていればよいのでは？と思えたので念のため実施するに至りました。
自分で発想しておいてなんですが、おそらく下記のような結果になると思います。
- 10.0.1.68/32から発信される、10.0.2.68/32を宛先とする通信はNFWルールの評価対象にならず暗黙的拒否の対象となり、pingは通らない
- 10.0.2.68/32から発信される、10.0.1.68/32を宛先とする通信はNFWルールの評価対象にならず暗黙的拒否の対象となり、pingは通らない
実際のルール設定は下記になります。
アラートルールの詳細
パスルールの詳細
検証結果
10.0.1.68/32から発信される、10.0.2.68/32を宛先とするpingは通りませんでした。
10.0.2.68/32から発信される、10.0.1.68/32を宛先とするpingも通りませんでした。
上記のことから、「トラフィックの方向」を「すべて」に指定したルールでは、「送信元に指定したCIDR、送信先に指定したCIDRどちらが発信元になっても、もう一方のCIDRへ向かうトラフィックは評価される。」ことが確認できました。
結局、NFW導入時は「転送」「すべて」どちらを指定すれば良いのか
本当に当たり前のことになってしまいますが、検査したい通信が何かによるでしょう。
クライアントがインターネット経由でWebサーバへアクセスしてくるような、どちらか一方のみが発信元になる通信を検査したいなら「転送」で良いでしょうし、
社内ネットワークのサーバ間通信のような、どちらも発信元になる通信を検査したいなら「すべて」にするのが良いでしょう。
感想
説明通りの動作になっていることを確認するだけになってしまいましたが、頭では理解していても実際に確認しないと不安…ということ、結構ありますよね。
そんな方の一助になれば幸いです。
