Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#31228 - [snort] systemd service file

Attached to Project: Community Packages
Opened by Isaac C. Aronson (SirPenguins) - Tuesday, 21 August 2012, 20:07 GMT
Last edited by Eric Belanger (Snowman) - Saturday, 17 November 2012, 03:14 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I have written up a systemd service file for Snort (attached). This current one supports setting the sniffing interface via the @ directive (systemctl start snort@eth0.service, snort@wlan0.service, etc.) but it's trivial to put that setting back in /etc/conf.d/snort like it is for the rc service.
I've only added that one little bit because some users of snort (including myself) run different snort instances on different interfaces and it's easier to just symlink different files instead of manually editing the conf.d/snort for each interface on every reboot.
I've also added a pre-exec command that brings up the interface before starting monitoring on it. Without it, on a true "sniffing" interface, snort would fail to monitor anything and just exit. It should be harmless to run on an interface that is also used for real network data.
Other than that, this systemd service file respects everything the rc script does.

Additional info:
* package version(s) --
* should this be sent upstream? fedora has their own systemd trickery for snort and it never got upstream AFAIK
* not 100% sure if the "After=" directive should use network.service or ; right now it uses

Steps to reproduce:
This task depends upon

Closed by  Eric Belanger (Snowman)
Saturday, 17 November 2012, 03:14 GMT
Reason for closing:  Won't fix
Additional comments about closing:  snort is no longer in repo
Comment by Dave Reisner (falconindy) - Tuesday, 21 August 2012, 20:44 GMT
Some comments...

- is a given, because its always available (thanks to the journal).
- is meant to hazily signify when the network is available, but you don't really care about that (based on your ExecStartPre). I'd say you could get rid of this as well.
- Ideally this should have a BindsTo=/After= dependency on sys-subsystem-net-device-%I.device. However, this is currently broken upstream (and my bug report is quiet).
- We frown upon usage of /etc/conf.d in systemd units. If a user needs to override options, they can do so in /etc/systemd/system. Just hardcode the defaults from the conf.d file.
- Your ExecStartPre is a filthy hack. Sadly, I can sort of see uses for this (particularly wifi). It'd be nice if there were a better method of doing this (e.g. if snort would just optionally bring up the device on its own).
- If it's reasonable that snort would be running multiple instances of itself, one for each interface, then instancing the unit makes perfect sense. I would suggest aliasing this to eth0, similar to how we do in the dhcpcd unit.
Comment by Isaac C. Aronson (SirPenguins) - Tuesday, 21 August 2012, 21:24 GMT
I've removed both "After=" deps per your recommendation.

I don't know much about how the sys-subsystem-net-device stuff works, but here's why I've added the "ip link set up" command and the @ directive:
The way my sniffer at my workplace is set up is to sniff on two interfaces, eth0 and wlan0. eth0 is hooked into our main switch array into a certain port that has mirrored to it all traffic on our primary (and only) VLAN. Consequently, it's impossible to ever reach that eth0 port remotely (since Cisco port mirroring sends a copy of all Tx/Rx on a VLAN but does not include the destination port in that VLAN) and so setting a static IP is pointless, as is letting some network manager attempt to use DHCP on the interface. I leave eth0 unmanaged by netcfg.
We have another Ethernet device in there (eth1) for remote ssh/access/grabbing the sniffed data.
So, because nothing ever brings up the sniffing interface, whenever I'd try to start snort on eth0, snort would fail complaining that "eth0" doesn't exist. Manually bringing the device up with ip solved this, though I don't know if there's some other more proper way to bring the device up (udev? my network manager? rc.local?). Snort itself doesn't seem to be able to bring up the device on its own (it doesn't seem to be aware that the interface even exists until it's brought up).
I imagine that this issue would apply to anyone using snort on a solely promiscuous interface.

So yes, that ExecStartPre is a filthy hack but it's the only solution I know about right now.

As for multiple instances, yes it's very reasonable for snort to be running on multiple interfaces with multiple instances. I've seen it in plenty of production environments, including my own.
I've modified the file to include an alias to eth0.

Anything else I should change? Ideas on the interface problem?
Comment by Dave Reisner (falconindy) - Tuesday, 21 August 2012, 21:50 GMT
Hrmmmm, so without knowing much about when/where snort is used, not really. I don't know if leaving an open promiscuous interface is the common use case or an edge case. If its the latter, I'd suggest ditching it and creating your own unit along the lines of:

Description=interface %I up

ExecStart=/usr/sbin/ip l s %i up

Create an instance of this for each interface you don't plan on actively using, and it'll be brought up automatically when snort starts for that interface. It doesn't even need to be enabled.
Comment by Isaac C. Aronson (SirPenguins) - Thursday, 23 August 2012, 16:56 GMT
An open promiscuous interface is the only useful way to use snort, since if you're not mirroring traffic to your port then you're not seeing anything useful anyways. (Unless you're using ARP poisoning or something, but if it's your own network you shouldn't need that. The common case is to use it on a corporate network, the edge case is to be some wannabe hacker using ARP poisoning to try and steal some useful data).

I've been using the snort@.service file for a while now, and I've changed it to a simple service and removed the "-D" option since snort's child processes have been failing for no good reason. I find it works better in simple mode, others' mileage may vary.

I've also fixed the %i to be %I. I don't know why I made it lowercase in two places.
I've also removed the "-l /var/log/snort" bit because that screws over people who use syslog for logging. Without the -l directive, snort respects any outputs defined in /etc/snort/snort.conf which is the way it should be acting by default.