server: Add support for reading eve-log through unix socket file

[tumist]

This change makes it possible to use Suricata's unix_stream output for the eve log. Suricata acts as the client and does not create a socket file, so EveBox takes on the server role of creating a socket file in EveReader::open and then accepting a connection, if not already established, in EveReader::next_record().

It has only been tested on linux with sqlite backend, not elasticsearch.

The code change overview is:

• EveReader is now a trait that EveReaderFile (renamed from EveReader) and EveReaderSocket implement
• Processor is type-parametrized to work with either reader
• Starting a Processor for a unix socket as specified in yaml config is done by server and agent. It does not really make sense in oneshot

I am just starting to learn rust and any advice on using the language or how you would like to see this feature implemented differently is very welcome. For one, it is ugly to see the EveReader trait specify seeking functions that are only used for bookmarks when it cannot apply to sockets.

[Copilot]

Pull Request Overview

Adds support for reading Suricata’s EVE JSON log over a Unix stream socket by introducing a new EveReaderSocket implementation and wiring socket inputs through the server and agent pipelines.

• Factor EveReader into a trait with file- and socket-based implementations
• Extend CLI (main.rs, agent.rs, oneshot.rs) and watcher to accept input.sockets
• Update Processor and exports to be generic over any EveReader

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/server/main.rs	Add get_input_sockets and include sockets in input
src/eve/watcher.rs	Track and spawn socket-based readers
src/eve/reader.rs	Define EveReaderSocket and refactor EveReader
src/eve/processor.rs	Make Processor generic over the EveReader trait
src/eve/mod.rs	Export new reader types
src/cli/oneshot.rs	Use EveReaderFile instead of the old struct
src/cli/agent.rs	Add socket runner and get_eve_sockets
examples/evebox.yaml	Document input.sockets option in server example
examples/agent.yaml	Document input.sockets option in agent example

Comments suppressed due to low confidence (3)

src/server/main.rs:186

• The error message only mentions "paths" but now also checks sockets; consider updating it to something like "no paths or sockets provided".

bail!("EVE input enabled, but no paths provided");

src/eve/watcher.rs:18

• [nitpick] The field filenames is also used to track socket paths; consider renaming it to something like seen_paths or sources for clarity.

filenames: HashSet<PathBuf>,

src/eve/reader.rs:13

• This import isn’t used anywhere; it can be removed to keep dependencies minimal.

use std::os::unix::fs::FileTypeExt;

[Copilot]

[nitpick] Logic for reading sockets is duplicated from server; consider extracting a shared utility function to avoid code duplication.

[Copilot]

Panicking on a missing listener may crash the server; return a EveReaderError instead to handle the error gracefully.

[Copilot]

The EveReader trait import is unused in this file; consider removing it.

Suggested change

use crate::eve::EveReader;

[jasonish]

Thanks. Don't jump on any of the copilot stuff yet. I just find it useful for insight before looking in. Seems like a useful feature, will look more closely in the following days.

[jasonish]

I am just starting to learn rust and any advice on using the language or how you would like to see this feature implemented differently is very welcome. For one, it is ugly to see the EveReader trait specify seeking functions that are only used for bookmarks when it cannot apply to sockets.

Great. Is this a feature you would actually use? I think it does make sense to have it.

Some low hanging items to address first:

• cargo clippy
• cargo fmt
  make sure to patch those fixups into your previous commit.

While I don't think it makes sense to test/implement this on windows, you an also make sure you are clippy clean on windows. Cross (https://github.com/cross-rs/cross) can check this for you:

cross clippy --target x86_64-pc-windows-gnu

(Don't worry too much about this)

I should CI jobs for the above, but don't yet. Might be a bit before I can actually try this out though.

[tumist]

Is this a feature you would actually use? I think it does make sense to have it.

It's hardly essential feature, but it is useful if one would like to save on disk space and IO operations on the suricata machine.

make sure to patch those fixups into your previous commit.

Clippy and cargo fmt changes have been amended to the pull request commit.

While I don't think it makes sense to test/implement this on windows, you an also make sure you are clippy clean on windows. Cross (https://github.com/cross-rs/cross) can check this for you:

cross clippy --target x86_64-pc-windows-gnu

Done. Although unix sockets are available in windows, I don't know if suricata supports it and rusts' standard library functions are tagged unix only.

Regarding the panic! statement that Copilot mentioned, I would like to change the code so that an EveReaderSocket does not persist for a socket file that could not be created. It would then be EvePatternWatchers responsibility to intermittently try to re-create it.