AWS Network Firewall ドメインリストルールグループのキャパシティを測ろうの回
ドメインリストルールグループのキャパシティ計算めんどくさい
何故かステートフルルールグループのキャパシティ計算についてはドキュメントに記載がありません。しかもドメインリストルールグループはブラックボックスで、中身でどういうルールを書くのか全然わからない。ということで、測ってみましょう。
前提
ドメインリストルールグループは計算方法がちょっと複雑です。
指定プロトコルやドメイン数に応じてルールの数が変動するので、注意が必要です。
デフォルトのルール順序の場合
-
アクション許可、プロトコル HTTP のみ
ドメインの数 + 2
-
アクション許可、プロトコル HTTPS のみ
ドメインの数 + 1
-
アクション許可、プロトコル HTTP と HTTPS
((ドメインの数 + 1) * プロトコル数[HTTP と HTTPS なので 2]) + 1
突然式が複雑になりまして。HTTP に対して何か複雑なルール? が設定されているのかも?
The following Suricata rules listing shows the rules that Network Firewall creates for the above allow list specification.
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; dotprefix; content:".amazon.com"; endswith; msg:"matching HTTP allowlisted FQDNs"; priority:1; flow:to_server, established; sid:1; rev:1;)
pass http $HOME_NET any -> $EXTERNAL_NET any (http.host; content:"example.com"; startswith; endswith; msg:"matching HTTP allowlisted FQDNs"; priority:1; flow:to_server, established; sid:2; rev:1;)
drop http $HOME_NET any -> $EXTERNAL_NET any (http.header_names; content:"|0d 0a|"; startswith; msg:"not matching any HTTP allowlisted FQDNs"; priority:1; flow:to_server, established; sid:3; rev:1;)
AWS ドキュメント的なアクション許可 HTTP のみルールだと、HTTP ヘッダ名の長さをチェックするルールが多いみたい。HTTPS 用のルールには無いので、恐らくその 1 行分が多く計算をややこしくさせているのかも?
1 行目と 2 行目は対象ドメインが異なり、dotprefix のサンプルになってるだけなので合わせて 1 行としてカウントします。(なので、全部で2行)
ただ、上記には許可した http.host 以外の http.host を検知して落とすルールが欠けてますね。実際には 3 行ぐらい?
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; dotprefix; content:".amazon.com"; nocase; endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:1; rev:1;)
pass tls $HOME_NET any -> $EXTERNAL_NET any (tls.sni; content:"example.com"; startswith; nocase; endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:2; rev:1;)
drop tls $HOME_NET any -> $EXTERNAL_NET any (msg:"not matching any TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:3; rev:1;)
HTTP と同じく 3 行あるじゃん、って感じですが、2 行目は対象ドメインが違うし、dotprefix だし、ということで例外です。
-
アクション拒否、プロトコル HTTP のみ
ドメインの数 + 1
-
アクション拒否、プロトコル HTTPS のみ
ドメインの数
ここだけそのままなんだ…。
-
アクション拒否、プロトコル HTTP と HTTPS
(ドメインの数 * プロトコル数[HTTP と HTTPS なので 2]) + 1
厳格(Strict)のルール順序の場合
いつの間にかドメインリストルールグループでもルール順序で厳格が選べる話は以前しましたが、キャパシティ計算もちょっと違うんです。
-
アクション許可または拒否、プロトコル HTTP のみ
ドメインの数 + 1
-
アクション許可または拒否、プロトコル HTTPS のみ
ドメインの数
-
アクション許可または拒否、プロトコル HTTP と HTTPS
(ドメインの数 * プロトコル数[HTTP と HTTPS なので 2]) + 1
なんと突然、アクションによるキャパシティ差分が無くなっちゃいました。
何故だろう……？と思っていたのですが
Choose Strict to provide your rules in the order that you want them to be evaluated. In your firewall policy, choose the Drop established option for the drop action.
Choose this option when using strict order for your own domain list rule groups because Network Firewall requires an established connection in order to evaluate whether to pass or drop the packets for domain lists.
厳格(Strict)のルール順序なドメインリストルールグループを利用する場合、アタッチするファイアウォールポリシーのステートフルデフォルトアクションで "確立された接続のパケットをドロップ" を選択する必要がある様子。ということは、アクション許可で今まで実施していた、対象外通信をドロップする役目はデフォルトアクションが実施する…ってコト！？
そう考えると、アクション許可のルールが一つ分減っているのかな、と解釈してもおかしくなさそうですね。
終わり
ということで、ドメインリストルールグループのキャパシティ計算はこれで終わりです。
上記は私が試しただけなので、実際にこれを読んだあなたの環境でも必ず試してみてくださいね。
Discussion