はじめに
AWS Network Firewall では、ネットワークトラフィックをきめ細かく制御するファイアウォールルールを定義できます。AWS のウェブサイトでは以下のユースケースが紹介されています。
- VPC 間のトラフィックを検査
- アウトバウンドトラフィックをフィルタリング
- インバウンドのインターネットトラフィックの侵入を防ぐ
- AWS Direct Connect と VPN のトラフィックを保護する
アウトバウンドトラフィックの HTTP/HTTPS 通信を、特定のドメインのみ許可して、他のドメインを禁止ができます。事前に確認した安全なドメインのみ HTTP/HTTPS アクセスを許可することで、セキュリティレベルの向上が期待できます。
この記事では「特定のドメインを許可するホワイトリスト方式」の設定方法を紹介します。
構成図
Network Firewall の構成図を先に紹介します。Network Firewall を構成するときに、どの経路を検査するかをコントロールするために各 Subnet で Route Table の適切な設定が必要です。この記事で扱う構成図を、以下の Workshop から引用します。AWS からインターネットへのアウトバウンド通信や、逆方向のインバウンド通信が、すべて Network Firewall の Endpoint を経由するのが注目ポイントですね。
それでは設定を進めていきます。
Firewall Policy の作成
まず、Network Firewall の Firewall Policy の作成をしていきます。Create Firewall Policy を押します。
適当に名前を指定して Next を押します。
rule group は空っぽのままにしておきます。
ここは重要な設定です。 Firewall Policy の Rule order (ルールの評価順) をどうするか指定する項目です。Rule order の Default or Strict は一度設定すると、後から変更ができません。 もし変更したいときには削除と再作成が必要となり、Route Table の設定変更も含めて、全体的な設定変更が必要となります。
個人的な感想ですが、ここの設定は Strict の方が柔軟に運用が出来ると思います。以下の 2 点が理由です。
- ファイアウォールのルールの評価順を厳密に指定可能
- ルールに何もマッチしなかったときのデフォルトアクションを、許可 or 拒否で設定可能
ということで、以下の設定を入れます
- Strict
- Drop established : デフォルト拒否の設定。HTTP(S) のドメインを検査するときには、Drop established が設定しやすい。Drop All では、HTTP(S) の通信手前の ハンドシェイク部分も Drop してしまうため、下位の TCP レベルで許可設定を入れないと動作しない。Drop established では、ハンドシェイク部分は許可してくれるので、直感的に設定が出来る
- Alert all : ログの指定
- Alert established : ログの指定
Next を押します。
デフォルトのまま Next を押します。
Tag は無しで Next を押します。
Create firewall policy を押します。
Firewall Policy が 作成されました。
Network Firewall の作成
次に、Firewall を作成します。各 Subnet に Network Firewall の Endpoint が作成されます。
VPC のサービス画面に Network Firewall があり、Create Firewall を押します。
Firewall をデプロイする VPC と Subnet を指定します。Network Firewall 専用の Subnet を選択します。Routing Table でルートをコントロールするため、専用の Subnet を用意するとシンプルに構成できます。
また、指定した Subnet ごとに Network Firewall Endpoint が作成されるので、料金に影響が有る部分となっています。
前の手順で作成した Firewall Policy を紐づけます。
Create Firewall を押します。
Firewall が作成され、Provisioning になっています。
一定時間後に Ready になりました。
Firewall Endpoint が 2 個作成されています。
Route Table の設定
構成図通りに設定をします。重要そうな設定のみ抜粋して紹介します。
Firewall Route Table
Firewall Endpoint が動作する Subnet に紐づく Route Table です。
Internet Gateway を経由して、インターネットに出るための経路を設定します。
こんな感じの設定です。
Public Route Table
NAT Gateway を配置する Public Subnet です。
これが重要なポイントですね。0.0.0.0/0 の経路に対して、Internet Gateway の代わりに、Network Firewall の Endpoint を指定 します。これを指定することで、インターネットへ出る経路に Network Firewall を中継させることができます。
Edit routes を押します。
0.0.0.0/0 の宛先に対して、Gateway Load Balancer Endpoint を指定します。Network Firewall と表示されないのが、ちょっとややこしいですね。
2 つの選択肢が表示されているのが、Network Firewall の Endpoint です。AZ が同じものを選択して、Save を押します。
別の Route Table も同様に設定します。
Ingress Route Table の作成
Internet Gateway に紐づける、Ingress Route Table です。
インターネット側から入ってくる通信に、Network Firewall を経由するルートを設定していきます。ポイントは、NAT Gateway が稼働している Public Subnet 宛の通信を、Network Firewall の Endpoint に指定 している点です。ここは間違えやすいポイントなので注意しましょう。
また、Ingress Route Table そのものについて気になる方は、Classmethod さんのとてもわかりやすいブログを見てみてください。(ありがとうございます！)
https://dev.classmethod.jp/articles/what-is-vpc-ingress-routing/
それでは、Ingress Route Table を作成していきます。作成するモノ自体は、通常の Route Table と同じです。
適当に名前を付与して、Create を押します。
作成された Route Table を選択して、Edit edge associations を選択します。Edit subnet associations ではなく、edge の方を選択することで、Ingress Route Table になります。
Internet Gateway を選択して、Save changes を押します。
紐づけが出来ました。
Route を編集します。
ルートを追加します。インターネットから Public Subnetへの通信を、Network Firewall を経由するように設定します。これによって、インターネットから返ってくる通信を、Network Firewall で中継できるので、セキュリティ設定に応じた通信遮断などが出来るようになります。
設定されました。
Network Firewall の Log の有効化
Network Firewall のデフォルトでは、Log 出力が無効化になっています。遮断したときのログを確認したいので、有効化していきます。Firewall の詳細画面を開きます。
Firewall details を選択します。
Log の設定で Edit を押します。
出力対象のログを全て選択します。
今回はログの出力先を S3 にします。Bucket 名などを指定します。
設定されました。
アウントバウンドトラフィックをドメインで制御
AWS から外のインターネットへ通信するアウトバウンドトラフィックで、特定のドメインだけの通信を許可するホワイトリスト形式を試してみましょう。
Rule Group の作成
特定のドメインを許可するために、Role Group を作成します。
Network Firewall rule group で、独自のルールを作成していきます。
Stateful Rule Group を選択し、Domain List を指定します。
Capacity は、いくらか小さめに 100 と指定します。ここで指定する Capacity は後で変更が出来ないので、今後のドメイン追加の余地を考慮して、ある程度余裕をもって設定すると良いです。
ちょっと辛いところが、Capacity 消費の計算式は公開されていないので、事前に検証しながら進めていく必要があります。それなら大き目の Capacity を指定すればいいんじゃないかと思いますが、それも難しいです。Rule Group に紐づけられる Rule の Capacity 上限は 30000 となっています。なので、Capacity を大きくしすぎるのもデメリットがあります。
Stateful Rule order を Strict にします。Firewall Policy を Strict で作成したので、こちらも Strict にする必要があります。(Default で作ると、紐づけるときにエラーになる)
指定したドメインの通信を許可します。AWS のサービスが EC2 インスタンスと通信することもあるので、amazon 系のドメインを許可します。
.amazon.com
.amazonaws.com
Create を押します。
作成されました。
Firewall に Rule Group を紐づける
Firewall を選択します。
Add unmanaged stateful rule groups を押します。
さきほど作成した Rule Group を選択して Add を押します。
Firewall に Rule Group が紐づけられました。Capacity 30000 の上限から、紐づけた 100 分が消費されていることがわかります。
動作確認 : 通信遮断
Private Subnet に配置した EC2 インスタンスから、禁止されている (許可されていない) ドメインへ通信をしてみます。遮断されることが期待値です。
Google の検索エンジンにアクセスしますが、レスポンスが返ってきません。期待通りですね。
[ec2-user@ip-10-1-0-143 ~]$ curl -v https://www.google.com/
* Trying 142.251.42.132:443...
* Connected to www.google.com (142.251.42.132) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
^C
[ec2-user@ip-10-1-0-143 ~]$ date
Sat Jan 14 12:44:06 UTC 2023
このときの Alert ログは、こんな感じに出力されています。
- Block されている点がログでわかる
- 送信元と送信先 IP がわかる
- sni に、リクエストヘッダーに含まれるドメインが記録されている
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673700244",
"event": {
"timestamp": "2023-01-14T12:44:04.278827+0000",
"flow_id": 419526559929285,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 8485,
"dest_ip": "142.251.42.132",
"dest_port": 443,
"proto": "TCP",
"alert": {
"action": "blocked",
"signature_id": 5,
"rev": 0,
"signature": "aws:alert_established action",
"category": "",
"severity": 3
},
"tls": {
"sni": "www.google.com",
"version": "UNDETERMINED",
"ja3": {},
"ja3s": {}
},
"app_proto": "tls"
}
}
このときの Flow ログは、こんな感じに出力されています。
- Block されていでも、Flow ログには出力されている
- Flow ログだけでは、Block されているのか、通信が許可されているのかはわからない (と思う)
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673700521",
"event": {
"timestamp": "2023-01-14T12:48:41.460387+0000",
"flow_id": 419526559929285,
"event_type": "netflow",
"src_ip": "10.1.1.102",
"src_port": 8485,
"dest_ip": "142.251.42.132",
"dest_port": 443,
"proto": "TCP",
"app_proto": "tls",
"netflow": {
"pkts": 23,
"bytes": 6482,
"start": "2023-01-14T12:44:04.267205+0000",
"end": "2023-01-14T12:45:07.655326+0000",
"age": 63,
"min_ttl": 253,
"max_ttl": 253
},
"tcp": {
"tcp_flags": "1b",
"syn": true,
"fin": true,
"psh": true,
"ack": true
}
}
}
許可ドメインを追加
www.google.com のドメインを Block 出来たことがわかったので、これを許可する設定もやってみます。
該当の Rule Group を開きます。
Add domains を押します。
以下のドメインを追加して、Save を押します。
.google.com
動作確認 : 通信許可
curl で通信が出来ました。
[ec2-user@ip-10-1-0-143 ~]$ curl -v https://www.google.com/
* Trying 142.250.196.132:443...
* Connected to www.google.com (142.250.196.132) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.google.com
* start date: Dec 12 08:19:43 2022 GMT
* expire date: Mar 6 08:19:42 2023 GMT
* subjectAltName: host "www.google.com" matched cert's "www.google.com"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x1edb770)
> GET / HTTP/2
> Host: www.google.com
> user-agent: curl/7.79.1
> accept: */*
>
< HTTP/2 200
< date: Sat, 14 Jan 2023 14:05:51 GMT
< expires: -1
< cache-control: private, max-age=0
< content-type: text/html; charset=ISO-8859-1
< cross-origin-opener-policy-report-only: same-origin-allow-popups; report-to="gws"
< report-to: {"group":"gws","max_age":2592000,"endpoints":[{"url":"https://csp.withgoogle.com/csp/report-to/gws/other"}]}
< p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
< server: gws
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< set-cookie: 1P_JAR=2023-01-14-14; expires=Mon, 13-Feb-2023 14:05:51 GMT; path=/; domain=.google.com; Secure
< set-cookie: AEC=ARSKqsJnvdRVKWp9FLX-MNF4uHPDtkkQttjNyvTqgmosDvY2JKJe4Tsy1dk; expires=Thu, 13-Jul-2023 14:05:51 GMT; path=/; domain=.google.com; Secure; HttpOnly; SameSite=lax
< set-cookie: NID=511=UES9AYD9DVc9WFQlUfGuFh1K4VjvHE8HsjE6L7c2T9zIKxfbfcs6zam9CjIPKxQib7G5feVTwHMSM9tNy3CZ5AaNS8Z-YPUj34fG5u89pc978Kc8x1VarTSvLtNs5_OKkbnA89aqYTJewc8ZBYBu0Ezzk96PWhMQYMNrPh3gjCg; expires=Sun, 16-Jul-2023 14:05:51 GMT; path=/; domain=.google.com; HttpOnly
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
< accept-ranges: none
< vary: Accept-Encoding
<
<!doctype html><html itemscope="" itemtype="http://schema.org/WebPage" lang="ja"><head><meta content="世界中のあらゆる情報を検索するためのツールを提供しています。さまざまな検索機能を活用して、お探しの情報を見つけてください。" name="description"><meta content="noodp" name="robots"><meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
省略
[ec2-user@ip-10-1-0-143 ~]$ date
Sat Jan 14 14:05:55 UTC 2023
このときの Alert ログは、こんな感じに出力されています。
- action が allowed となっている
- 送信先のドメインは記録されていない
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673705151",
"event": {
"timestamp": "2023-01-14T14:05:51.670926+0000",
"flow_id": 1641110069783548,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 50749,
"dest_ip": "142.250.196.132",
"dest_port": 443,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 2,
"rev": 0,
"signature": "aws:alert_strict action",
"category": "",
"severity": 3
}
}
}
このときの Flow ログは、こんな感じに出力されています。
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673705245",
"event": {
"timestamp": "2023-01-14T14:07:25.116483+0000",
"flow_id": 1641110069783548,
"event_type": "netflow",
"src_ip": "10.1.1.102",
"src_port": 50749,
"dest_ip": "142.250.196.132",
"dest_port": 443,
"proto": "TCP",
"app_proto": "tls",
"netflow": {
"pkts": 25,
"bytes": 2240,
"start": "2023-01-14T14:05:51.666620+0000",
"end": "2023-01-14T14:05:51.810241+0000",
"age": 0,
"min_ttl": 253,
"max_ttl": 253
},
"tcp": {
"tcp_flags": "1b",
"syn": true,
"fin": true,
"psh": true,
"ack": true
}
}
}
想定通りに、特定のドメインの許可設定を入れることで、それ以外のドメインの HTTT/HTTPS 通信が禁止されることがわかりました。
検証を通じてわかったこと
-
特定のドメインに限定したホワイトリスト形式が構成できる。
- 通信プロトコルは HTTP/HTTPS が対応している。
- HTTP/HTTPS プロトコル以外の TCP/UDP では、ドメイン許可はサポートされていない。ただ、ルールに合致しないものはデフォルトで禁止しているので、悪意のある通信が許可されるわけではない。そのため、TCP/UDP などは、ドメインの代わりに、IP アドレスの許可設定を入れることで柔軟にコントロールが出来る。
-
ドメイン制限は、Stateful Rule Group で設定が可能。Stateless Rule Group には無い。
-
独自に設定するルールに加えて、AWS 側で管理されているマネージドグループがある。以下の Document に一覧と説明が書かれている。
- いろいろ便利なルールがあるので、これも使っていくのが良さそう。
- https://docs.aws.amazon.com/network-firewall/latest/developerguide/aws-managed-rule-groups-list.html
-
Firewall に Rule Groups を紐づけるときに消費する Capacity という概念がある。1 Firewall あたり、30,000 Capacity を超えて紐づけが出来ない。
-
Network Firewall のネットワークトラフィックをログに出力可能。出力先は、S3, CloudWatch Logs, Kinesis Data Firehose の 3 つから選択可能。
-
ログに出力するときに、Log type を Alert と Flow の 2 つから選択可能
- Alert : ルールの中で Action を
AlertかDropを選択したものがログに出される。この記事の構成では、通信をブロックしたものと許可したものの両方が Alert に表示される。 - Flow (netflow) : 通信が許可されたものがログに表示される (はず)。
drop establishedで設定している場合は、禁止しているドメインについても、TCP の 3 ウェイハンドシェイクの部分だけは通信が許可されるのでログに出力される。そのため混乱しないようにしたい。
- Alert : ルールの中で Action を
-
出力されるログのフォーマットが、以下の Document で記載されている。ログに出力されるなかで、
event_typeがログの種別を表している -
ログは、リアルタイムに出力されるわけではなく、出力されるまで時間が必要。
- CloudWatch Logs, Kinesis Data Firehose : 平均 3 ~ 6 分
- S3 : 平均 8 ~ 12 分
- https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-logging.html
-
netflow で通信が許可されたもの、1 回のリクエストにつき、行きの経路と帰りの経路の 2 個が記録される
-
Firewall Policy の Rule Order に関する設定は、
DefaultとStrictの 2 種類の中から 1 つを選ぶ。個人的には、Strictの方が設定が楽だと思う。Strictでは、ルールに該当しなかったときのデフォルトアクションを指定できるので、柔軟なコントロールが出来る。- 一度作った後に設定変更が出来ない。やろうとおもったら、削除と再作成が必要。
-
Stateful Rule で
Strictにしたときに、何もルールに合致しなかったときのデフォルトドロップアクションを指定できる。-
drop establishedとdrop allの2種類が選択が出来るが、デフォルト拒否のルールを設定するためには、drop establishedの方がより直感的に設定が出来た。以下引用 -
drop establishedを選択すると、Network Firewall は接続が確立されている状態のパケットのみをドロップします。これにより、上位層の接続に必要なレイヤー 3 と 4 の接続確立用のパケットは許可し、既に接続が確立されているパケットについてはドロップします。このため、下位層のプロトコルで実施するハンドシェーク部分を許可する追加のルールを記述する必要なく、デフォルト拒否の設定においてアプリケーション層の pass ルールを記述することができます。
-
-
ログに出力される送信元 IP は、実際に通信する EC2 instance ではなく 、NAT Gateway となった。
- この記事の構成では、Firewall Gateway の手前に NAT Gateway が存在しているので、このような構成になる。
- 記事を作った後に気が付いたのだが、Subnet の Routing 構成を工夫することで送信元 IP を実際のインスタンスにできる
- https://d1.awsstatic.com/webinars/jp/pdf/services/202110_AWS_Black_Belt_Network_Firewall_advanced01.pdf
- P.8 : Amazon VPCの新機能 More specific routing(MSR)
付録1 : S3にログ出力
こんな感じで、S3 にログが出力される。
付録2 : Flowlog
Network Firewall で通信が許可されたときのログを次に記載します。EC2 インスタンスから、Google の検索エンジンに Curl したときのログです。
curl -v https://www.google.com/
Network Firewall が出力するログは 1 回のリクエストで 2 個分出力される。
行きのログ
{
"firewall_name": "network-firewal-test01",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673625629",
"event": {
"timestamp": "2023-01-13T16:00:29.530458+0000",
"flow_id": 237681334242370,
"event_type": "netflow",
"src_ip": "10.1.1.102",
"src_port": 55057,
"dest_ip": "142.251.42.196",
"dest_port": 443,
"proto": "TCP",
"app_proto": "tls",
"netflow": {
"pkts": 24,
"bytes": 2188,
"start": "2023-01-13T15:57:51.478274+0000",
"end": "2023-01-13T15:57:51.628997+0000",
"age": 0,
"min_ttl": 253,
"max_ttl": 253
},
"tcp": {
"tcp_flags": "1b",
"syn": true,
"fin": true,
"psh": true,
"ack": true
}
}
}
帰りのログ
{
"firewall_name": "network-firewal-test01",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673625629",
"event": {
"timestamp": "2023-01-13T16:00:29.530489+0000",
"flow_id": 237681334242370,
"event_type": "netflow",
"src_ip": "142.251.42.196",
"src_port": 443,
"dest_ip": "10.1.1.102",
"dest_port": 55057,
"proto": "TCP",
"app_proto": "tls",
"netflow": {
"pkts": 28,
"bytes": 22399,
"start": "2023-01-13T15:57:51.478274+0000",
"end": "2023-01-13T15:57:51.628997+0000",
"age": 0,
"min_ttl": 44,
"max_ttl": 44
},
"tcp": {
"tcp_flags": "1b",
"syn": true,
"fin": true,
"psh": true,
"ack": true
}
}
}
付録3 : Alertlog
ブロックされたときのログ
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673698029",
"event": {
"timestamp": "2023-01-14T12:07:09.638080+0000",
"flow_id": 814109353713397,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 60573,
"dest_ip": "142.250.196.132",
"dest_port": 443,
"proto": "TCP",
"alert": {
"action": "blocked",
"signature_id": 4,
"rev": 0,
"signature": "aws:alert_established action",
"category": "",
"severity": 3
},
"tls": {
"sni": "www.google.com",
"version": "UNDETERMINED",
"ja3": {},
"ja3s": {}
},
"app_proto": "tls"
}
}
通信許可されたときのログ
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673705151",
"event": {
"timestamp": "2023-01-14T14:05:51.670926+0000",
"flow_id": 1641110069783548,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 50749,
"dest_ip": "142.250.196.132",
"dest_port": 443,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 2,
"rev": 0,
"signature": "aws:alert_strict action",
"category": "",
"severity": 3
}
}
}
付録4 : 特定の IP アドレスへのアウトバウンドを許可する
ドメイン以外にも、特定の IP アドレスに限定した接続を許可させてみます。
rule group の作成
名前を適当に指定します。
通信許可をさせたい宛先の IP アドレスと Port と Protocol を指定します。
Create します。
作成されました。
作成した Rule Group を、Firewall Policy に紐づけます。
紐づけします。
これで、特定の IP アドレスと Port に対して通信が出来たことを確認できました。
許可されていない (禁止されている) IPアドレスのときの通信ログは次にようになっています。
SSH は、この記事では TCP Port 22 を使っているのでなので、TCP の 3 ウェイハンドシェイクの通信が走ります。この記事の構成では drop established を設定しているため、3 ウェイハンドシェイクの部分は、禁止されている IP アドレスでも許可されたログが出ます。混乱しないようにしましょう。
Alert ログの 3 ウェイハンドシェイク部分 : SYN
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673764392",
"event": {
"timestamp": "2023-01-15T06:33:12.737152+0000",
"flow_id": 1655536452400602,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 4647,
"dest_ip": "xx.xx.xx.xx",
"dest_port": 22,
"proto": "TCP",
"alert": {
"action": "blocked",
"signature_id": 5,
"rev": 0,
"signature": "aws:alert_established action",
"category": "",
"severity": 3
},
"ssh": {
"client": {
"proto_version": "2.0",
"software_version": "OpenSSH_7.4"
},
"server": {
"proto_version": "2.0",
"software_version": "OpenSSH_7.4"
}
},
"app_proto": "ssh"
}
}
Alert ログの 3 ウェイハンドシェイク部分 : SYN + ACK
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673764392",
"event": {
"timestamp": "2023-01-15T06:33:12.491950+0000",
"flow_id": 1655536452400602,
"event_type": "alert",
"src_ip": "xx.xx.xx.xx",
"src_port": 22,
"dest_ip": "10.1.1.102",
"dest_port": 4647,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 2,
"rev": 0,
"signature": "aws:alert_strict action",
"category": "",
"severity": 3
}
}
}
Alert ログの 3 ウェイハンドシェイク部分 : ACK
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673764392",
"event": {
"timestamp": "2023-01-15T06:33:12.493100+0000",
"flow_id": 1655536452400602,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 4647,
"dest_ip": "xx.xx.xx.xx",
"dest_port": 22,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 2,
"rev": 0,
"signature": "aws:alert_strict action",
"category": "",
"severity": 3
}
}
}
3 ウェイハンドシェイクのあとに、実際に Block されているログ
{
"firewall_name": "network-firewall-test02",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1673764392",
"event": {
"timestamp": "2023-01-15T06:33:12.737152+0000",
"flow_id": 1655536452400602,
"event_type": "alert",
"src_ip": "10.1.1.102",
"src_port": 4647,
"dest_ip": "xx.xx.xx.xx",
"dest_port": 22,
"proto": "TCP",
"alert": {
"action": "blocked",
"signature_id": 5,
"rev": 0,
"signature": "aws:alert_established action",
"category": "",
"severity": 3
},
"ssh": {
"client": {
"proto_version": "2.0",
"software_version": "OpenSSH_7.4"
},
"server": {
"proto_version": "2.0",
"software_version": "OpenSSH_7.4"
}
},
"app_proto": "ssh"
}
}
参考 URL
Workshop
https://catalog.workshops.aws/networkfirewall/en-US
Black Belt
https://d1.awsstatic.com/webinars/jp/pdf/services/BlackBelt202106_AWS_Network_Firewall_Basic.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/202110_AWS_Black_Belt_Network_Firewall_advanced01.pdf
AWS再入門ブログリレー2022 Network Firewall 編
https://dev.classmethod.jp/articles/re-introduction-2022-network-firewall/
AWS NETWORK FIREWALLのログ
https://mikunet.biz/tech/cc/aws-network-firewall-log/
S3に格納したNetwork FirewallのログをAthenaで抽出してみた
https://dev.classmethod.jp/articles/aws-nfw-alertlog-athena/
評価の流れが AWS Document で説明されている
https://docs.aws.amazon.com/ja_jp/network-firewall/latest/developerguide/firewall-rules-engines.html
AWS Network Firewall のルールグループと評価の流れを詳細に理解する ※ハマりポイントも解説しています
https://blog.serverworks.co.jp/network_firewall_rule
re:Post の Questions : Suricate 形式で特定のドメインを許可する設定が共有されている。
https://repost.aws/questions/QU1rEZzGniSdCxMJCaKweWnQ/state-full-domain-list
Network Firewall のいくつかの構成パターン
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall-with-vpc-routing-enhancements/
ルールの評価順序の Strict 方式についてのわかりやすい Blog
https://aws.amazon.com/jp/blogs/news/hands-on-walkthrough-of-the-aws-network-firewall-flexible-rules-engine-part-2/
Network Firewall の Rule Group の設定例
https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-examples.html