Project

General

Profile

Bug #2769

False positive alerts firing after upgrade suricata 3.0 -> 4.1.0

Added by Charles Dillard 9 days ago. Updated 2 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Affected Versions:
Effort:
Difficulty:

Description

Hello, oisf, could use your input on problem.

My corporate network has been running suricata 3.0. Recently upgraded to 4.1.0 then 4.1.1 and encountered issue.

Environment is CentOS release 7.4.1708 (Core) 3.10.0-862.14.4.el7.x86_64 on ~400 Dells
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-5.1.4-15.el7.x86_64

In Suricata 4.1.0 (and 4.1.1) (following recent upgrade from suricata 3.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 to 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
}

Any thoughs on how to proceed on this would help.

Talked with Andreas Herz on this via oisf forum.

issue_no_icmp-1.pcap (15.8 KB) issue_no_icmp-1.pcap pcap for Bug #2769 Charles Dillard, 01/15/2019 04:53 PM

History

#1 Updated by Victor Julien 6 days ago

  • Description updated (diff)

#2 Updated by Victor Julien 6 days ago

Do you also see this issue with 4.1.2? If so, can you share a pcap to preproduce the issue?

#3 Updated by Charles Dillard 6 days ago

Victor Julien wrote:

Do you also see this issue with 4.1.2? If so, can you share a pcap to preproduce the issue?

Issue is seen with 4.1.2 (in a lab here). Working out details of sending you a pcap file, since information is sensitive. Let you know. Thanks.

#4 Updated by Charles Dillard 5 days ago

Victor Julien wrote:

Do you also see this issue with 4.1.2? If so, can you share a pcap to preproduce the issue?

Here is pcap file for issue described. Thanks.

#5 Updated by Victor Julien 3 days ago

  • Assignee set to Victor Julien

I can't seem to reproduce this with 4.1.2. Are you sure it's still an issue? The timestamps of the alert record posted above is a lot older than the actual run output, so maybe its a old alert?

#6 Updated by Charles Dillard 2 days ago

Victor Julien wrote:

I can't seem to reproduce this with 4.1.2. Are you sure it's still an issue? The timestamps of the alert record posted above is a lot older than the actual run output, so maybe its a old alert?

Will check with my team, let you know Tuesday.

Also available in: Atom PDF