[Oisf-users] upgrade to suricata 4.1.0 seeing false positives

Charles Dillard charlesdillard at hotmail.com
Mon Jan 7 15:57:00 UTC 2019


Hello, oisf, could use your input on problem.

In Suricata 4.1.0 we noticed that under certain conditions false positive alerts are firing that should not be.  In short rules looking for HTTP packets are firing on ICMP data.   It appears that the issue occurs on rules with http content modifiers where another rule in the ruleset uses an alert ip prefix and any content match.  The packets must include an HTTP session followed by ICMP type packets (not that the rule should not match on the http session as the pcre does not match).  I’ve also tested on suricata 4.1.2 and found that this issue is there as well.  I’m not sure when the issue was introduced.

Rules in my local.rules:

alert ip any any -> any any (msg:"IP Any With Content"; content:"blahblah"; classtype:bad-unknown; priority:102; sid:5002203; rev:10;)

alert http $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"Test Rule no http"; flow:to_server,established; content:"POST"; http_method; pcre:"/\/.+\/[a-zA_Z0-9]{4}\_confirm\.php/"; classtype:bad-unknown; priority:102; sid:9999991; rev:1;)

Test output:

#> docker run -it --rm --volume $PWD/data:/data sensor -c /data/suricata.yaml -r ./data/out.pcap
7/1/2019 -- 15:25:55 - <Notice> - This is Suricata version 4.1.0 RELEASE
7/1/2019 -- 15:25:55 - <Notice> - using flow hash instead of active packets
7/1/2019 -- 15:25:55 - <Warning> - [ERRCODE: SC_ERR_DEPRECATED_CONF(274)] - deprecated 'force-md5' option found. Please use 'force-hash: [md5]' instead
7/1/2019 -- 15:25:55 - <Warning> - [ERRCODE: SC_ERR_EVENT_ENGINE(210)] - can't suppress sid 2015985, gid 1: unknown rule
7/1/2019 -- 15:25:55 - <Notice> - all 7 packet processing threads, 4 management threads initialized, engine started.
7/1/2019 -- 15:25:55 - <Notice> - Signal Received.  Stopping engine.
7/1/2019 -- 15:25:55 - <Notice> - Pcap-file module read 1 files, 72 packets, 10078 bytes
#>  cat ./data/fast.log

01/02/2019-17:57:19.054415  [**] [1:9999991:1] Test Rule no http [**] [Classification: Potentially Bad Traffic] [Priority: 102] {ICMP} 3.20.244.244:2563 -> 10.228.203.106:0

Note that the rule which his supposed ot match on an HTTP session is alerting on an ICMP packet.

Eve.json alert also has http data for an icmp protocol:

{
  "timestamp": "2019-01-02T17:57:19.054415+0000",
  "flow_id": 1426130925450708,
  "pcap_cnt": 22,
  "event_type": "alert",
  "src_ip": "<redacted>",
  "dest_ip": "<redacted>",
  "proto": "ICMP",
  "icmp_type": 3,
  "icmp_code": 10,
  "tx_id": 0,
  "alert": {
    "action": "allowed",
    "gid": 1,
    "signature_id": 9999991,
    "rev": 1,
    "signature": "Test Rule no http",
    "category": "Potentially Bad Traffic",
    "severity": 102
  },
  "http": {
    "hostname": "<redacted>",
    "url": "/em/event",
    "http_user_agent": "Wget/1.11.4 Red Hat modified",
    "http_method": "POST",
    "protocol": "HTTP/1.0",
    "length": 0
  },
  "app_proto": "http",
  "flow": {
    "pkts_toserver": 4,
    "pkts_toclient": 0,
    "bytes_toserver": 598,
    "bytes_toclient": 0,
    "start": "2019-01-02T17:56:06.194004+0000"
  },
  "payload": "<redacted>",==",
  "payload_printable": "<redacted>",
  "stream": 0
}


This may be helpful:

suricata version:
suricata-4.1.0-ESG_1.el7.centos.x86_64
suricata-debuginfo-4.1.0-ESG_1.el7.centos.x86_64

pcre version:
pcre-devel-8.32-17.el7.x86_64
pcre-8.32-17.el7.x86_64

lua version:
lua-date-2.1.2-2.el7.centos.x86_64
lua-5.1.4-15.el7.x86_64
lua-cjson-2.1.0-1.el7.centos.x86_64


suricata alerts are written to a file /../....../json_out.txt and passed on to splunk


Thanks for your input....you're always a big help!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20190107/8bda5912/attachment.html>


More information about the Oisf-users mailing list