For example, Acronis Backup (cloud) client appears to like to frequently connect to dl.acronis.com via TLS 1.0 with no SNI in the Client Hello. This keeps tripping rule 2028304 “ET JA3 Hash - Metasploit SSL Scanner” because it happens to match the JA3 hash in the rule. How would you recommend I tune this out since the server IPs vary (CDN) and there is no SNI to compare to? I tried to make a pass rule based on the FP-prone rule with the addition of tls.cert_subject criteria but the rule is rejected with the error “rule…mixes keywords with conflicting directions”.
Example:
pass tls $EXTERNAL_NET any -> $HOME_NET any (msg:“ET JA3 Hash - Metasploit SSL Scanner”; flow:established,to_server; ja3.hash; content:“6825b330bf9de50ccc8745553cb61b2f”; tls.cert_subject; content:“acronis”; sid:500000900; rev:1;)
It seems that ja3.hash must operate in a flow:established,to_server context while the tls.* criteria require a flow:established,from_server context. Is there any way to stop a specific JA3 rule from firing if a particular string is found in the server’s TLS cert subject?
Not all TLS clients sent SNI’s, and servers commonly are behind ever-changing IPs, so the only other thing I have to look at is the server’s TLS cert in cases like the above.
Perhaps something could be chained together using flowbits? Any suggestions would be greatly appreciated, as I’m certainly not a NIDS rule ninja.
This new “ET JA3 Hash” rule family looks promising but I’m not sure how to approach tuning out the false positives, and from what I can see there are no exclusion conditions presently in place in any of the rules of this family. I hope this does not mean that it is inherently resistant to being tuned.
Thanks,
Kevin