I’m working on creating some info alerts for internal use, to alert on TLS when the CN matches. I have created the following rule, which is valid (rule is loaded), however fails to detect (despite confirming TLS event traffic is properly picked up).
Am I missing something here? Running Suricata 5.0.6 on Debian. Other custom TCP and IP rules work fine.
alert tls [1.1.1.1/23,2.2.2.2] any -> 192.168.1.1 any (msg:"Company Info - TLS Traffic from A to B"; tls.cert_subject; content:"CN=the.company.com"; isdataat:!1,relative; sid:900456; rev:1;)
Thank you for testing, I’m running scirius probes, so not really an option to upgrade Uses Debian, and stuck in 5.x land with the issues preventing 6.x working on Debian unfortunately.
I tried the legacy keyword as well, with no luck either. I’ll probably have to wait for the probes to get updated to 6.x.
Hey, just want to say that the keyword is working on 5.0.6 as expected. Have you tried making your test as simple as possible? Have you checked the Suricata TLS logs to ensure that the request is logged as expected.
I recommend the new startswith and endswith keywords as well
$ cat fast.log
06/18/2021-20:31:51.173358 [**] [1:1:0] test [**] [Classification: (null)] [Priority: 3] {TCP} 151.101.237.164:443 -> 192.168.1.118:60224
$ cat ../test.rules
alert tls any any <> any any (msg:"test"; tls.cert_subject; content:"nytimes.com"; endswith; sid:1;)
$ suricata -V
This is Suricata version 5.0.6 RELEASE
Thank you, it does pick up as a TLS event. The only atypical thing about the traffic is that it is FTPS, not HTTPS - however suricata is picking up the events as TLS (including CN being parsed out properly), so I wouldn’t think that would matter?
I’ll see where it goes with opening up direction and also setting source net to any. Originally I had the rule set to a destination port range, which didn’t seem to make a difference. I’ll follow up with the findings.
Uses Debian, and stuck in 5.x land with the issues preventing 6.x working on Debian unfortunately.