Project

General

Profile

Actions

Bug #2215

closed

Lost events writing to unix socket

Added by Fanny Dwargee over 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

Hi,
when using the pcap offline analysis and configured Suricata for writing eve-log events to a unix stream socket some events can be lost.

Find attached a pcap with a lot of DNS events (malware generated), first I wrote in Python a UNIX stream socket server for reading the eve log events and surprisingly some events were lost because Suricata was lot quicker writing to the socket than my code reading from it so using the "send()" primitive returned an EAGAIN error.

After that, instead of coding a C UNIX server I used the socat utility and unfortunately the same behaviour was observed.

IMHO a minimal wait would be sufficient when using a UNIX socket for eve log events.

Tested on GitHub master branch with latest commit https://github.com/inliniac/suricata/commit/499afaba4bc4624afa9e7d7e7648f9070ea5d37d

I'm going to send a PR to the GitHub repository with a new eve log option named 'unix-retry-wait' where you can set the microseconds for waiting before retry a write on a UNIX stream socket with the write queue full


Files

timeout.pcap (540 KB) timeout.pcap PCAP with a lot of DNS flows (keep care, malware generated) Fanny Dwargee, 09/20/2017 12:07 PM
Actions #1

Updated by Jason Ish over 7 years ago

I think a better fix would be to allow blocking when not running live. This would mean no lost events due to a blocking socket when using pcaps and no configuration change required between live and file reading.

I don't think any wait is acceptable in live mode, as it does hold up processing packets.

Actions #2

Updated by Andreas Herz over 7 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions #3

Updated by Fanny Dwargee over 7 years ago

I get your point and it's a really good one but I'm not totally convinced. :)

Why not let the user choose if waiting is acceptable or not?

Some will prefere to wait while others won't, in any case I think the user is the more appropriate one to decide what really needs and that's the point of the configuration option.

I think a better fix will be to take into account not being in live mode to make the wait but keep on using nonblocking sockets, IMHO it's a more balanced choice.

Actions #4

Updated by Fanny Dwargee over 7 years ago

...so that would be a mix between your idea and the initial one (I'm sorry but I don't know how to edit a post)

Actions #5

Updated by Fanny Dwargee over 7 years ago

My apologies,

I think my initial explantion lacks how I'm using Suricata, I'm controlling Suricata from a unix socket and use that for analyzing pcap files.

The command line used is:

  1. suricata -vv --unix-socket -c /usr/local/etc/suricata/suricata.yaml

...so Suricata runs in UNIX_MODE

Actions #6

Updated by Danny Browning about 7 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Danny Browning
Actions #7

Updated by Danny Browning about 7 years ago

  • Tracker changed from Optimization to Bug
Actions #8

Updated by Danny Browning about 7 years ago

Found to be a bug in not determining correctly run runmode is offline, and thus setting blocking socket for unix socket outputs.

Actions #9

Updated by Victor Julien about 7 years ago

  • Status changed from Assigned to Closed
  • Target version changed from TBD to 4.0.2/4.0.3
Actions

Also available in: Atom PDF