- Newest
- Most votes
- Most comments
If all of the checks in the answer above have validated, there are two main scenarios where an SNI will fail to match. Firstly, the request may not have an SNI within it. This is an unusual scenario that typically only occurs with old versions of OpenSSL. The other possibility is down to a fragmented Client Hello request. To allow Suricata to correctly detect the SNI in this event, add the keyword of ssl_state:client_hello to your "drop tls" rule and give it another test.
No, you do not need TLS inspection enabled to block HTTPS domains with Suricata rules in AWS Network Firewall.
For HTTPS traffic, AWS Network Firewall can use the Server Name Indication (SNI) extension in the TLS handshake to determine the domain name that the client is trying to connect to, without requiring TLS inspection. The tls.sni keyword in Suricata rules works without decrypting the traffic because the SNI is part of the TLS handshake and is sent in plaintext.
When TLS inspection is enabled, Network Firewall actually ends the TLS connection initiated by the client and decrypts traffic before it reaches the stateful inspection engine. In this case, most TLS-based keywords won't match except for TLS.SNI, which still works.
For your specific issue, there could be several reasons why your rule isn't matching:
-
Check that your rule syntax is correct. The example you provided looks generally correct, but ensure there are no typos.
-
Verify that the traffic is actually flowing through the Network Firewall. Check your route tables to ensure traffic is being directed to the firewall endpoints.
-
Ensure that your rule group is properly associated with your firewall policy, and that the firewall policy is associated with your firewall.
-
Check the priority of your rules. If you have other rules with higher priority that are allowing the traffic, your block rule might never be evaluated.
-
Verify that your HOME_NET and EXTERNAL_NET variables are correctly defined for your network architecture.
-
Make sure you're using the correct protocol (443) and that the traffic is actually using TLS with SNI.
If all these are correct, you might want to try using "reject" instead of "drop" to see if that makes a difference, as suggested in some troubleshooting scenarios.
Sources
Considerations when working with TLS inspection configurations in AWS Network Firewall - AWS Network Firewall
Issue with AWS Network Firewall - Suricata Rules Allowing Connections to Non-Whitelisted Public IPs | AWS re:Post
Stateful domain list rule groups in AWS Network Firewall - AWS Network Firewall
Relevant content
- asked 8 months ago
Hello, Before using the drop i start to analyze if i get the log provided by alert rule in my CW alert loggroup.
I have also enable on my firewall policy default actions Alert established Alert all Drop established
My alerting rule in suricata format are the following
Log all HTTP traffic
alert http any any -> any any (msg:"ALERT: HTTP Traffic Logged"; sid:9999995;) alert http any any -> any any (msg:"ALERT: HTTP Traffic Detected"; flow:to_server; sid:9999997;)
Log all TLS (HTTPS) traffic
alert tls any any -> any any (ssl_state:client_hello;msg:"ALERT: TLS Traffic Logged"; sid:9999996;)
My architecture is similar to this -> https://d2908q01vomqb2.cloudfront.net/5b384ce32d8cdef02bc3a139d4cac0a22bb029e8/2020/11/19/index.png
But i update the Transit Gateway Firewall Route Table to send the return traffic to the ANFW relates to this post (https://repost.aws/questions/QUuPzaGCjyQ8CHC9XjVZfk6Q/unable-to-see-http-logs-in-aws-network-firewall-cloudwatch-only-udp-logs).
So in my log actually i didn't get the trigger of my suricata rules and i have the following log due to default actions (from alert logroup):
This sounds very much like you have asymmetric routing occurring in your architecture. I would carefully validate every routing hop between your client and the firewall, not forgetting to check the return route and validate that traffic is remaining in the correct AZ.