我正在使用这个规则来跳过suricata在一个已知的SSL证书上处理：
pass tls any any <> any any (msg:"known good mydomain cert"; tls.fingerprint:"40:.(trimmed for serverfault).:8b"; sid:1000000; rev:1) 即使如此，它正在进入正常的采伐。
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"}}
我有我的local.rules首先列出，我没有改变行动顺序，所以pass消息应该首先处理。
发生这种情况是因为在configuration中设置了“tls：extended：yes” 我的意思是，它logging所有 TLS会话，所以pass无关紧要？ 如果是这样的话，我该如何/应该logging未知/无与伦比的TLSstream量？
（我把这个放在snort标签中，因为没有suricata标签，我不能创build一个，我想与snort有关的suricata。）
TLS日志logging和规则是完全独立的。 通过只确保没有其他规则评估此会话。
logging是无条件的。 通过规则不会影响它。
然而，在Suricata 3.0中，您还可以添加TLSlogging来提醒日志。 为了实现这个function，在eve-log的alerttypes下取消注释'tls：yes'：
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
那么你可以有一个规则，匹配如果指纹不是你正在寻找。 例如
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;)
注意！ 之前之后tls.fingerprint。
这会让您提醒还包含TLSlogging的logging。 例如
{"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}
然后，您可以禁用yaml中的常规TLS日志logging。
这种方法的一个问题是，它确实只适用于否定单个指纹。