Project

General

Profile

Actions
Copy link

Bug #2121

closed

Packets stop passing for specific file

Added by Oliver Humpage over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Andreas Herz
Target version:
Support
Affected Versions:
Effort:
Difficulty:
Label:

Description

I run suricata 3.2.1 using netmap on FreeBSD. I’ve come across an odd issue where a particular file from an http server always stops downloading at 792MB (the file is over 900MB). I’ve narrowed it down to the emerging-current_events ruleset (i.e. disabling that ruleset lets the file download), but:

  • There is nothing in drop.log, fast.log or alert-debug.log
  • Downloading other large files from the server works fine
  • Downloading the identical file from other servers works fine (which is really odd!)

Suricata is running on the internal interface. The pcaps show that when the download hangs, incoming packets from the web server come in the external interface, but never exit the internal interface.

I've attached my suricata.yaml, pcaps of the last few seconds of transfer from ext_if (ag) and int_if (ac), and the specific ruleset that triggers this bug.

The file in question is:
http://cdn2-downloads.ableton.com/channels/9.7.2/ableton_live_lite_9.7.2_64.zip

Is there any more I can do to help diagnose what’s going on, or is that enough info? It's a production router so debug is off, but I could recompile if you really need it.

Many thanks!

Files

Download all files
suricata.yaml (12.8 KB) suricata.yaml Simplified config used Oliver Humpage, 05/30/2017 08:06 AM
emerging-current_events.rules (1020 KB) emerging-current_events.rules Only ruleset loaded Oliver Humpage, 05/30/2017 08:06 AM
ableton-ag.cap3 (993 KB) ableton-ag.cap3 External iface pcap Oliver Humpage, 05/30/2017 08:06 AM
ableton-ac.cap3 (2.48 MB) ableton-ac.cap3 Internal iface pcap Oliver Humpage, 05/30/2017 08:06 AM
Actions
Copy link
 #1

Updated by Oliver Humpage over 7 years ago

I should add, I run with emerging-current_events set to "drop" rather than "alert". If I switch back to "alert" then the download works fine. However: since there's nothing in the logs, and since the identical file downloads fine from other servers, I still think there is a bug somewhere.

Actions
Copy link
 #2

Updated by Andreas Herz over 7 years ago

  • Assignee set to Andreas Herz
  • Target version set to Support

The first thing you should try is to change the rules with "noalert" from drop to alert since they won't show any alerts but still trigger the action drop. This might even solve your issue, since it's quite certain that a drop rule does trigger and prevent traffic but doesn't show up in your logfile.

Another quick and dirty test is, after the step above, to change just some rules to drop and try to narrow it down which rule is the one that prevents the traffic when it's changed from alert to debug.

Actions
Copy link
 #3

Updated by Oliver Humpage over 7 years ago

I do apologise: I had no idea rules could have a "flowbits:noalert" flag in them. The oinkmaster examples I've seen of changing rulesets from alert -> drop don't mention that perhaps you should exclude the noalert rules :(

Turns out the culprit was SID 2018375, "TLS HeartBeat Request (Server Initiated)", which I guess you wouldn't expect to see on a plain http connection.

Please close/delete this bug, and sorry for not checking on the mailing list before reporting it.

Actions
Copy link
 #4

Updated by Victor Julien over 7 years ago

  • Status changed from New to Closed

The following option in EVE is helpful:

        #- drop:
        #    alerts: yes      # log alerts that caused drops
        #    flows: all       # start or all: 'start' logs only a single drop
        #                     # per flow direction. All logs each dropped pkt.

If you enable 'alerts', the sid of the rule causing the drop will be logged even if it's a 'noalert' rule.

https://github.com/inliniac/suricata/blob/master/suricata.yaml.in#L222

Actions
Copy link

Also available in: Atom PDF