AWS Network Firewall / Suricata 介紹

前言

知名開源入侵偵測系統(IDS)有兩個:Suricata、Snort,兩者都有相當不錯的效率跟彈性,而 AWS 提供的防火牆服務在有狀態規則部分是使用 GitHub 星星數較多的前者。使用者可以透過配置路由表將 EC2、ELB 等在 VPC 中的資源納入防火牆的保護。

Network Firewall 是基於 ELB 中的 Gateway Load Balancer (GWLB),將封包從一個 subnet 導向到另一個 subnet 做過濾。如果不想用 AWS 提供的 Network Firewall,也可以使用 GWLB 搭配 Market Place 中第三方廠商的封包過濾、威脅偵測服務使用。

匹配引擎

AWS 利用三種引擎來簡化配置、提升效率,其執行順序為:

Stateless Rule Groups → Stateless Default Action → Stateful Rule Groups

基本上來說 stateless 是做一些 3、4 層的封包欄位檢查,並不像 stateful 能夠過檢查資料流來定義一連串的規則,後面會舉個例子來說明。

Stateful Rule Action

有狀態模式主要分兩種,一種是 default action order,另一種是 strict evaluation order。

Stateful rule 的優先級為:

pass --> drop --> alert

規則

懶人配置

手動配置

有些比較複雜的有狀態規則必須要透過手動配置,為了方便解釋,我們直接透過範例說明:

  • 讓連向域名 *.aws.com 的連線接通
  • 讓來自 1.2.3.0/24 的連線接通
  • 其餘連線不放行

要達到第一條規則會比較複雜,因為「域名」偵測是在 HTTP 包的表頭,因此得放行 TCP 連線,但又不能讓所有 TCP 都通過,因此只放行 not_established 封包。

再來檢查 HTTP 包的 Host Header,如果沒有 *.google.com 則不放行。但是 TLS 連線是加密的怎麼辦?因為 SNI 中的域名沒加密(還沒選擇憑證當然沒加密),我們可以透過檢查 SNI 來決定是否放行。

這種方式有三個缺點:

  • 域名被污染時,aws.com 就不是真的 aws.com
  • 利用 domain fronting 可以規避這項檢查
  • 如果 HTTPS 連線沒帶 SNI,那連線會受阻
pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host ; dotprefix; content:".aws.com"; endswith; msg:"Allow aws.com HTTP requests"; sid:1; rev:1;)
pass tls $HOME_NET any <> $EXTERNAL_NET 443 (tls.sni; dotprefix; content:".aws.com"; endswith; msg:"Allow aws.com HTTPS requests"; sid:2; rev:1;)
pass tcp $HOME_NET any <> $EXTERNAL_NET 80 (flow:not_established; sid:3; rev:1;)
pass tcp $HOME_NET any <> $EXTERNAL_NET 443 (flow:not_established; sid:4; rev:1;)
pass ip 1.2.3.0/24 any <> any any (msg:"pass all traffic from/to 1.2.3.0/24"; sid:5;)
drop http $HOME_NET any <> $EXTERNAL_NET ANY (http.host ; content:!"a"; msg:"Deny HTTP domain"; sid:6; rev:1;)
drop tls $HOME_NET any <> $EXTERNAL_NET ANY (tls.sni; dotprefix; content:!"a"; msg:"Deny aws.com  HTTPS requests"; sid:7; rev:1;)

後續建議

配置完可以使用開源弱掃工具如 ZAP、OpenVAS 來檢查是否有達到該有的效果,也可以尋找弱點掃描、紅隊演練公司來協助。

常見問題

  • Connection tracking、buffer 是否有上限?
    • 基本上是沒有限制的,可以達數月、數年之久

    • 公開文件有提到 Network Firewall 會自動擴容、縮容

      AWS Network Firewall offers a Service Level Agreement with an uptime commitment of 99.99%. AWS Network Firewall enables you to automatically scale your firewall capacity up or down based on traffic load to maintain steady, predictable performance to minimize costs.

    • 雖然 Suricata 本身有 Flow time-out 設定,但 Network Firewall 基於的 GWLB timeout 時間更短,因此我們僅需關注 GWLB 的 TCP 350 秒超時即可,可以使用低於 350 秒的 TCP keepalive 來確保連線維持

  • 是否支援 HTTP/2 規則
    • 截至 2022/04 為止,尚未支援

文件重點筆記

在嗑文件時有記錄些重點,提供給大家參考。

  • Firewall log delivery
    • The timing of Network Firewall log delivery varies by location type, averaging 3-6 minutes for Amazon CloudWatch Logs and Amazon Kinesis Data Firehose and 8-12 minutes for Amazon Simple Storage Service buckets.
  • Stateful rules engine
    • The stateful rules engine might delay packet delivery in order to group packets for inspection. By default, the stateful rules engine processes your rules in the order of their action setting, with pass rules processed first, then drop, then alert
    • By default, the stateful rules engine allows traffic to pass, while the security groups default is to deny traffic.
  • Domain lists
    • Allow
      • For non-matching packets, discontinue inspection of the packet, block it from going to its intended destination, and send a message to the firewall’s alert logs if the firewall has alert logging configured.
    • Deny
      • For non-matching packets, take no action.
  • Setting rule group capacity in AWS Network Firewall
    • Each rule group must have a capacity setting that’s fixed at creation.
    • Using the consumed capacity fields in the console, you can also describe a rule group or a policy to find out how much of the rule group or policy capacity is currently in use.
  • Stateful default actions in your firewall policy
    • Note that you can provide this configuration regardless of whether you define stateful rule groups for the policy when you use strict rule order.
  • Stateful domain list rule groups in AWS Network Firewall
    • For HTTPS traffic, Network Firewall uses the Server Name Indication (SNI) extension in the TLS handshake to determine the hostname, or domain name, that the client is trying to connect to. For HTTP traffic, Network Firewall uses the HTTP host header to get the name. In both cases, Network Firewall doesn’t pause connections to do out-of-band DNS lookups. It uses the SNI or host header, not the IP addresses, when evaluating domain list rule groups.
  • Supported with caveats
    • The priority keyword is not supported for rule groups that evaluate rules using strict evaluation order.
  • Strict evaluation order
    • When you choose Strict for your rule order, you can choose one or more Default actions

comments powered by Disqus