Suricata not rejecting traffic when nothing is reading named pipe for eve logs

Hi All, i’ve just taken over a Suricata deployment at work that acts as a NAT gateway / whitelist for traffic destined for the internet.

We have suricata set up to write eve logs out to a named pipe:

mknod /var/log/suricata/eve.pipe p

  • eve-log:
    enabled: yes
    filetype: regular #regular|syslog|unix_dgram|unix_stream|redis
    filename: eve.pipe

What i’ve noticed is, if nothing is read()ing from the pipe, suricata does not send an RST packet back to the client when we have reject rules set up. Once something is reading from the pipe, i.e. cat curl requests from clients start failing as expected with ‘TCP connection reset by peer’

Any ideas what’s going on?

I’ve been able to reproduce this locally with a docker image running suricata 5.0.3 and in our production environment.

I believe if you are logging to a pipe you absolutely need something on the other end of that pipe reading from it as fast as possible, otherwise Suricata will eventually block on it waiting for something to read from it, blocking packets, etc in the process.

If you can’t ensure that something will always be reading from the pipe, a plain file is probably a better choice.

Plain file or async Redis, which is probably the fastest way to consume data from Suricata without blocking anything. We’re using this very successfully, writing to an in-memory Redis list to form a memory-constrained buffer.