[Oisf-users] Massive kernel drops with HTTP traffic

Michael Stone mstone at mathom.us
Mon Aug 20 14:18:03 UTC 2018

On Mon, Aug 20, 2018 at 02:53:55PM +0200, Konstantin Klinger wrote:
>@Mike: Do you have further experience in a workaround to not use libmagic?

Write rules for the traffic you're looking for. E.g., from 
you can look at file extensions:

alert http any any -> any any (msg:"FILE PDF file claimed"; fileext:"pdf"; filestore; sid:2; rev:1;)

you can also look for the magic signatures for particular file types:

alert http any any -> any any (msg:"FILE MS executable"; file_data; content:"MZ"; depth:2; filestore; sid:X; rev:1;)

That's essentially what the libmagic stuff does, but it's much more 
efficient if you're looking for only a few things to look specifically 
for those things rather than passing each file stream off to libmagic to 
check for thousands of different patterns (some of which are incredibly 
costly, like looking at the stream byte-by-byte to guess what kind of 
text file it might be). Suricata spends a lot of effort on using things 
like hyperscan to do really efficient pattern matching, then if you turn 
on magic support you basically toss all that and go back to doing 
character matches. You can look in the libmagic source to see what it's 
using for signatures. Depending on what you're trying to do, you may be 
able to accept more false positives (store possibly non-valid files) and 
use simpler signatures like the simple MZ test above without all the 
subsequent checks that filemagic does.

Adding the "noalert" keyword lets you just store the files without 
triggering alerts, which may be especially helpful if you're willing to 
accept FPs on file storage but then do more careful analysis in 

You can also try this suggestion for improving libmagic performance (I 


FYI, another feature that sounds good but scales terribly is the 
tls.fingerprint keyword.

More information about the Oisf-users mailing list