Different use cases have different deployment models.
There are quite a few use cases for AWS Network Firewall, e.g VPC-to-VPC inspection, VPC-to-Onprem/VPN inspecton, VPC-to-Internet inspection. WAF (Web Application Firewall) and Shield protects frontend resources (ELB, CloudFound, API Gateway).NACL (Network Access Control List) protects subnets.Security group protects computing resources (EC2, Lambda, RDS…).
Pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.AWS Network Firewall is a high-available and scalable firewall service that provides network protections for VPC, which is a supplement to the existing security services. Pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host dotprefix content:"." endswith msg:"Allowed HTTP domain" sid:3 rev:1 ) Pass tls $HOME_NET any -> $EXTERNAL_NET 443 (tls.sni content:"" startswith nocase endswith msg:"matching TLS allowlisted FQDNs" sid:2 rev:1 ) Pass http $HOME_NET any -> $EXTERNAL_NET 80 (http.host dotprefix content:"." endswith msg:"Allowed HTTP domain" sid:892120 rev:1 ) My preference is the strict firewall type as it allows for easier mixing of protocol types when creating the required suricata flow rules.Īn example of a working strict suricata stateful rules permitting the explicit domains: I have now tried both methods for both TLS and plain HTTP traffic using the sample rules provided here: There are effectively two different ways to provision a firewall, default or strict. I started from scratch and followed the following design guide to adjust the routing setup to match best practice (I previously had the NAT gateway as next hop for the firewall subnet): With more playing around last night and this morning I'm in a better place.
0 kommentar(er)
