0

I'm using this rule to skip suricata tls processing on a known SSL cert:

pass tls any any <> any any (msg:"known good mydomain cert"; tls.fingerprint:"40:.(trimmed for serverfault).:8b"; sid:1000000; rev:1)

Even with that, it's falling through to the normal tls logging.

Jan 29 19:59:38 ip-10-11-12-13 suricata[17331]: {"timestamp":"2016-01-29T19:59:38.285296+0000","flow_id":139920047174784,"in_iface":"eth0","event_type":"tls","src_ip":"10.13.13.13","src_port":49479,"dest_ip":"10.11.12.13","dest_port":8443,"proto":"TCP","tls":{"subject":"C=U...CN=*.mydomain.com","issuerdn":"C=US...","fingerprint":"40:.(trimmed for serverfault).:8b","version":"TLS 1.2"}}

I have my local.rules listed first, and I haven't changed the action-order, so pass messages should be processed first.

Is this happening because "tls:extended: yes" is set in the config? I mean, it's logging all TLS sessions so pass doesn't matter? If that's the case, how can I/should I log unknown/unmatched TLS traffic?

(I'm putting this in the snort tag because there's no suricata tag and I can't create one. I think of suricata as related to snort.)

tedder42
  • 833
  • 1
  • 9
  • 19

1 Answers1

1

The TLS logging and rules are completely independent. Pass only makes sure no other rules are evaluated for this session.

The logging is unconditional. Pass rules will not affect it.

In Suricata 3.0 however, you can also add TLS records to alert logs. To enable this, uncomment the 'tls: yes' under eve-log's alert type:

outputs:
  - eve-log:
      enabled: yes
      filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
      filename: eve.json
      types:
        - alert:
            tls: yes               # enable dumping of tls fields

Then you could have a rule that matches if the fingerprint is not what you are looking for. E.g.

alert tls any any -> any any (tls.fingerprint:!"26:ca:ea:1d:99:11:d0:14:98:ad:17:47:4a:8d:fa:94:c5:1f:53:1c"; sid:1;)

Note the ! before after tls.fingerprint.

This will get you alert records that also contain a TLS record. E.g.

{"tls":{"version":"SSLv3","fingerprint":"dc:60:87:01:82:5a:1e:5d:77:99:f1:c7:8a:d1:f2:11:37:f4:58:ad","issuerdn":"C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root","subject":"C=US, O=Akamai Technologies, Inc., CN=a248.e.akamai.net"},"alert":{"severity":3,"category":"","signature":"","rev":0,"signature_id":1,"gid":1,"action":"allowed"},"proto":"TCP","timestamp":"2009-11-14T19:28:41.698996+0100","flow_id":105716361672640,"pcap_cnt":1032789,"event_type":"alert","src_ip":"63.80.4.42","src_port":443,"dest_ip":"192.168.2.7","dest_port":1997}

You could then disable the regular TLS logging in your yaml.

One issue with this approach is that it really only works well for negating a single fingerprint.

Victor Julien
  • 26
  • 2
  • So, do you know how I can/should log unmatched TLS entries? Perhaps by putting an `alert` that matches all TLS? (since `pass` would happen before the alert) – tedder42 Jan 30 '16 at 00:07