---
I receive more than a few emails from end users who are having difficultly determining if snort version 2.9.x is running on their server, though the quickest way to see if it is running is by using the commands 'ps' and 'grep'.
However, in many cases, there could be an issue with the 'snort.conf' file which can be found using the '-T' option to snort (run manually) to determine which line in snort.conf is causing difficulty.
On my system when snort is NOT running, the command below returns the following:
[bill@moocow ~]$ ps auxww | grep -i "snort"
bill 1025 0.0 0.2 116388 2164 pts/0 S+ 09:01 0:00 grep --color=auto -i snort
If I use systemctl to check the status of snort, I get:
[root@moocow init.d]# systemctl status snort.service
Loaded: loaded (/usr/lib/systemd/system/snort.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Jan 23 09:10:55 moocow systemd[1]: Stopped Snort NIDS Daemon.
Which shows that snort isn't currently running on my server.
However, when snort is running, the same command produces a slightly
different output:
[bill@moocow ~]$ ps auxww | grep -i "snort"
snort 1071 41.6 39.7 748988 404492 ? Ssl 09:11 0:37 /usr/local/bin/snort -A fast -b -d -i enp0s8 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort
bill 1090 0.0 0.2 116388 2204 pts/0 S+ 09:13 0:00 grep --color=auto -i snort
Here is the output when systemctl is used instead of ps auxww | grep -i "snort":
When I start snort 2.9.8.x on Fedora 22, the output below is a partial
listing of the output that snort sends to /var/log/messages:
[root@moocow init.d]# systemctl status snort.service
* snort.service - Snort NIDS Daemon
Loaded: loaded (/usr/lib/systemd/system/snort.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2016-01-10 10:02:38 PST; 1min 33s ago
Main PID: 1070 (snort)
CGroup: /system.slice/snort.service
`-1070 /usr/local/bin/snort -A fast -b -d -i enp0s8 -u snort -g sn...
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_IMAP Version 1...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SSLPP Version ...4>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DNP3 Version 1...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SSH Version 1....3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DNS Version 1....4>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_DCERPC2 Versio...3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_REPUTATION Ver...1>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_FTPTELNET Vers...3>
Jan 10 10:03:26 moocow snort[1070]: Preprocessor Object: SF_SIP Version 1....1>
Jan 10 10:03:26 moocow snort[1070]: Commencing packet processing (pid=1070)
Hint: Some lines were ellipsized, use -l to show in full.
On newer distributions of Linux, systemd has been implmented in favor of the old style init.d startup scripts, here is the README file from the /etc/init.d directory on my Fedora 22 Server system:
You are looking for the traditional init scripts in /etc/rc.d/init.d, and they are gone?
Here's an explanation on what's going on:
You are running a systemd-based OS where traditional init scripts have been replaced by native systemd services files. Service files provide very similar functionality to init scripts. To make use of service files simply invoke "systemctl", which will output a list of all currently running services (and other units). Use "systemctl list-unit-files" to get a listing of all known unit files, including stopped, disabled and masked ones. Use "systemctl start foobar.service" and "systemctl stop foobar.service" to start or stop a service, respectively. For further details, please refer to systemctl(1).
Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.
Thank you!
Further reading:
man:systemctl(1)
man:systemd(1)
http://0pointer.de/blog/projects/systemd-for-admins-3.html
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities