Bug #2121
closed
Packets stop passing for specific file
Added by Oliver Humpage over 7 years ago.
Updated over 7 years ago.
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
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.
- 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.
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.
- 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
Also available in: Atom
PDF