【Network Firewall】AWSの基礎を学ぼう 特別編
概要
「AWS エバンジェリストシリーズ AWSの基礎を学ぼう」で”AWSの基礎を学ぼう 特別編 最新サービスをみんなで触ってみる Network Firewall”というイベントに参加した感想ページです。
「AWS エバンジェリストシリーズ AWSの基礎を学ぼう」とは
以下、Connpassページより引用
Amazon Web Services (AWS)は現在200を超えるサービスを提供し、日々サービスの拡充を続けています。
このAWS エバンンジェリストシリーズでは週次でAWSのサービスをひとつづつ取り上げながらその基礎を説明していく 初心者、中級者をターゲットとした講座です。午後の仕事前にスキルアップを一緒にしませんか？
注意点 登壇者による発表内容はアマゾン ウェブ サービス ジャパンとして主催しているものではなく、コミュニティ活動の一環として勉強会の主催を行っているものです。
毎週ありがとうございます！
内容
過去にNetworkFirewallのブログは何個か記載してますので、ルールについて記載したいと思います。
Network Firewallのルール
- ステートレスに対するルールが評価される
- pass
- drop
- 上記以外の場合、ステートフルに対するルールが評価される
- ステートフルに対するルールが評価される
- pass(+ alert)
- drop(+ alert)
ステートレスは難しいので、ステートフルで以下は設定します。
キャパシティ
キャパシティってなに？
ステートフルルールグループに必要な最大処理キャパシティーを指定します。ファイアウォールポリシーからルールグループを参照する場合、このキャパシティーはポリシーのルールグループ用に予約されます。ルールグループの更新時にキャパシティーを変更または超えることはできないため、ルールグループの増加に備えて余裕を残しておきます。
ステートフルルールグループのキャパシティー要件を、追加する予定があるルールの数として見積もります。
Estimate a stateful rule group's capacity as the number of rules that you expect to have in it during its lifetime. You can't change this setting after you create the rule group.
The maximum capacity setting for a stateful rule group is 30,000.
テートフルルールグループの容量を、その存続期間中にその中にあると予想されるルールの数として見積もります。ルールグループの作成後にこの設定を変更することはできません。
ステートフルルールグループの最大容量設定は30,000です。
キャパシティ１で設定して
追加でルール追加をしようとするとエラーになります
このcapacityが単純にルール数なのか、アクセス数なのかですが、以下ループ処理を複数のターミナルから投げてみても特にhttpステータスやログに変更は無いので、単純にルール数なのかも知れません。
while true
do
curl -s http://アドレス/ -o /dev/null -w '%{http_code}\n'
date
done
5-tuple
- 送信元IPアドレス
- 送信先IPアドレス
- 送信元ポート番号
- 送信先ポート番号
- プロトコル
でルールを指定します。 セキュリティグループとかNACLでやっていることに近いので違和感は少ないかと思います。
Suricata compatible IPS rules
Rules Format
記載することは大きくは３つ
- action
対象に何を起こすか - header
ルールのプロトコル、IPアドレス、ポート、および方向を定義 - rule options
ルールの詳細を定義
例えば以下Suricataでは
drop tcp $HOME_NET any -> $EXTERNAL_NET any (msg:”ET TROJAN Likely Bot Nick in IRC (USA +..)”; flow:established,to_server; flowbits:isset,is_proto_irc; content:”NICK “; pcre:”/NICK .*USA.*[0-9]{3,}/i”; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
- action
drop - header
tcp $HOME_NET any -> $EXTERNAL_NET any - rule options
(msg:”ET TROJAN Likely Bot Nick in IRC (USA +..)”; flow:established,to_server; flowbits:isset,is_proto_irc; content:”NICK “; pcre:”/NICK .USA.[0-9]{3,}/i”; reference:url,doc.emergingthreats.net/2008124; classtype:trojan-activity; sid:2008124; rev:2;)
action
- Pass
パケットのスキャンを停止し、すべてのルールの最後にスキップします - Drop
パケットはそれ以上送信されません。欠点：受信者は何が起こっているかについてのメッセージを受信しないため、タイムアウトになります - Reject
パケットのアクティブな拒否です。受信者と送信者の両方が拒否パケットを受信します - Alert
パケットは他の脅威のないパケットと同様に扱われますが、アラートが生成されます
header - protocol
headerは細分化するとまずプロトコルに分割できます
tcp,udp,httpとかとか
header - source and destination
headerは細分化すると次に送信元先に分割できます
IPレンジをlistなどで表現可能です
header - ports
headerは細分化すると次に送信元先のportに分割できます
portをlistなどで表現可能です
header - direction
- ->
clientからserverへの一方の流れ - <>
clientとserver双方の流れ - <-
これはありません。serverからclientからへの一方の流れ
rule
ルールの残りの部分はオプションで構成されています。これらは括弧で囲まれ、セミコロンで区切られます。一部のオプションには設定（msgなど）があり、オプションのキーワード、コロン、設定の順に指定されます。その他には設定がなく、単にキーワード（nocaseなど）です。
…キーワードにヒットするかを見るのかな。詳細を記載するのは慣れが必要ですが、でもSuricataの5-tupleとは違う強みだと思います。
キーワードはログに記載されている情報とかから選択すればええのかな
{
"firewall_name": "nwfw",
"availability_zone": "ap-northeast-1a",
"event_timestamp": "1623492831",
"event": {
"timestamp": "2021-06-12T10:13:51.763325+0000",
"flow_id": 1848277047251586,
"event_type": "alert",
"src_ip": "14.8.57.96",
"src_port": 53362,
"dest_ip": "10.0.1.131",
"dest_port": 80,
"proto": "TCP",
"alert": {
"action": "allowed",
"signature_id": 1,
"rev": 0,
"signature": "",
"category": "",
"severity": 3
},
"app_proto": "http"
}
}
Discussion