Posted: Snort init script

Here it is!

#!/bin/sh
# Start/stop/restart snort.

# 8/30/2007 - The snort_restart function wasn't working, but an investigation ferretted out the problem: the "sleep" parameter was adjusted from "1" to "5" to give the process time to stop before starting the snort process again.

# Start snort:
snort_start() {
if [ -x /usr/local/bin/snort ]; then
echo "Starting snort daemon: /usr/local/bin/snort -devXz -c /home/snort/snort-2.6.1.1/snort.conf -i eth0"
/usr/local/bin/snort -devXz -c /home/snort/snort-2.6.1.1/snort.conf -i eth0 -D
fi
}

# Stop snort:
snort_stop() {
echo "Stopping snort daemon"
killall snort
}

# Restart snort:
snort_restart() {
snort_stop
sleep 5
snort_start
}

case "$1" in
'start')
snort_start
;;
'stop')
snort_stop
;;
'restart')
snort_restart
;;
*)
echo "usage $0 start|stop|restart"
esac

Snort Died...

It died after the creation of the new script...

The only thing I can find is the following:

Aug 27 22:34:38 starchild snort[5941]: Snort exiting

This SUCKS!

I've restarted it but I now lack visibility for the past 12+ hours. I'll watch the logs closely tonight and maybe direct any errors to a logfile.

Edited 8/30/2007:

I think I've fixed the issue (for real, this time).

There is an part of the script that would choke upon itself...the restart function:

# Restart snort:
snort_restart() {
snort_stop
sleep 5
snort_start
}

I had to change the sleep statement from "1" to "5". I believe that the script chokes because it takes a few seconds to stop the snort process. One second isn't enough time, it seems. The script was stopping the process and immediately restarting it after one second. One second after the kill command runs, the snort process is still trying to stop when the script starts the snort_start function. I've tested this by adjusting the sleep statement and running the "rc.snort restart" command...I got successful results. We'll now wait to see if the cron job croaks again (tonight).

Sophos Vulns

I saw this at an internal website (internal to my work):

Two vulnerabilities in Sophos’ anti-virus software for Microsoft Windows and Unix/Linux, will allow an attacker to remotely inject arbitrary code and also produce a Denial of Service (DoS) attack. Any version prior to 2.48.0 is affected. Please follow the links below for remediation.
http://www.heise-security.co.uk/news/94954
http://www.frsirt.com/english/advisories/2007/2972
http://www.sophos.com/support/knowledgebase/article/28407.html

This reminds me that the FAA is running Sophos AV clients on both their Windows and *nix IDSs...its stupid to even run AV on a machine that is dedicated to IDS, but I thought about them nonetheless...heh.

Edited on 8/28/2007:

I wanted to elaborate on my comments.

There's are several reasons why you shouldn't run AV on security devices:

1. The AV solution may have zero-day vulnerabilities. Sure, you can block off all attempts against the management interface of the IDS device, but why even set yourself up to a possible compromise of a critical piece of architecture?

2. AV (and firewall...yes, both installed on an IDS in the FAA's case...I'm not BSing) solutions usually demand quite a bit of system resources. IDSs usually demand major system resources also. The two will eventually bump heads, unless the IDS is seeing no traffic (which, IMO, means that the IDS is worthless or may need its sniffing interface to be placed at a more critical location).

3. Just because NIST recommends a certain security posture doesn't mean that their recommendations should be applied blindly (yes, I'm talking about the FAA). I'm also aware that the Department of Transporation (which FAA falls under) demands this ridiculous requirement. Managers should question anything that isn't apparent in guidelines from higher headquarters...to not do so is to admit that you are a follower and not a 'do-er'.

I say these comments because I worked with the FAA for awhile and certainly didn't like their way of thinking, but I worked there (as a contractor, which didn't help my situation much) and just took what was dished to me. After several years of wondering if I should've voiced my opinion more strongly before leaving their organization, I'd have maybe actually taught their management and DOT's management some things about REAL security and how their security professionals SHOULD operate. All I can say now is that I now know (and experienced) what NOT to do, especially as a security professional.

Bud, if you're reading this, know that I'm in a far better place and while I wish my friends still working there well, I do know that I will never ever be the type of person that put up with sub-par management and sub-par decision-making. I'm certainly working in a better place, but I'd like to thank you for making me a better person...you did make me better at knowing idiots when I see them. IDSs and firewalls on IDS devices...hahahaha!

Revamped rc.snort on my server

Hi all!

First, I've redone my rc.snort file. I looked at the existing rc files in /etc/rc.d/ and looked at rc.sendmail specifically. It looked very simple compared to the rc.snort I did awhile back. Remember when I mentioned that I did two of them, one for Slackware 9.0 and one for OpenBSD 3.8, with the OpenBSD one working fine but the Slackware one not working 100%? Well, instead of basing the Slackware rc.snort from Slackbuilds' thttpd rc script, I went ahead and did the following:

1. I changed the name of the existing rc.snort to rc.snort.original using the 'mv' command.

2. I executed the following: cp rc.sendmail rc.snort

3. I edited rc.snort with VIM, replacing all mentioning of sendmail with snort, also including the path of snort.

4. I then tested by manually starting, stopping and restarting a running snort process. I found that the script was choking because I forgot to add the '-D' switch to the script. I fixed this and tested successfully.

5. I lastly set a cronjob to run 5 min in the future to test that the cronjob would function using the new script. It worked!

I should've done the above AGES ago. Now I get to wait a few days to see if the cronjob fails because I haven't accounted for something else...that's what happened last time. I think I'm not going to have issues this time, though.

I'll link the revised rc.snort script a bit later.

I've also built two netcat Slackware packages, using Checkinstall. I built one for my 9.0 server and one for my v12.0 workstation. Everytime I build a package, I'll be adding it to my slackpack repository, which will have v9.0 and v12.0 directories. I've added it because I didn't find a slackpack of netcat hosted anywhere else. I've the feeling that people may want the version for 12.0. I don't think many people are using v9.0 anymore.

You are probably wondering why I'm using v9.0. Because that's what my hosting provider offers. I try to keep it up-to-date but I've noticed that Pat isn't upgrading packages that far back anymore. This means I'll have to build my own upgrade packages. This also means I'll have to be very attentive to security (like I'm not already). Additionally, this will soon force me to either upgrade to v12.0 (Linode has several howtos) or jump to another distribution for simplicity-sake. :(

Anyways, I just wanted to post since I've been doing some work with Slack.

Until next time...