The last few days I blogged about compiling Suricata in IDS and IPS mode. Today I’ll write about how to set it up for first use.
Starting with Suricata 0.9.0 the engine can run as an unprivileged user. For this create a new user called “suricata”.
useradd --no-create-home --shell /bin/false --user-group --comment “Suricata IDP account” suricata
This command will create a user and group called “suricata”. It will be unable to login as the shell is set to /bin/false.
The next thing to do is creating a configuration directory. Create /etc/suricata/ and copy the suricata.yaml example config into it. The example configuration can be found in the source archive you used to build Suricata:
mkdir /etc/suricata
cp /path/to/suricata-0.9.0/suricata.yaml /etc/suricata/
cp /path/to/suricata-0.9.0/classification.config /etc/suricata/
Next, create the log directory.
mkdir /var/log/suricata
The log directory needs to be writable for the user and group “suricata”, so change the ownership:
chown suricata:suricata /var/log/suricata
The last step I’ll be describing here is retrieving an initial ruleset. The 2 main rulesets you can use are Emerging Threats (ET) and Sourcefire’s VRT ruleset. Since putting VRT to use is a little bit more complicated I’ll be focussing on ET here.
First, download the emerging rules:
wget http://www.emergingthreats.net/rules/emerging.rules.tar.gz
Go to /etc/suricata/ and extract the rules archive:
cd /etc/suricata/
tar xzvf /path/to/emerging.rules.tar.gz
There is a lot more to rules, such as tuning and staying updated, but thats beyond the scope of this post.
Suricata is now ready to be started:
suricata -c /etc/suricata/suricata.yaml -i eth0 --user suricata --group suricata
If all is setup properly, Suricata will tell you it is now running:
[2087] 9/5/2010 — 18:17:47 – (tm-threads.c:1362)
(TmThreadWaitOnThreadInit) — all 8 packet processing threads, 3 management threads initialized, engine started.
There are 3 log files in /var/log/suricata that will be interesting to monitor:
- stats.log: displays statistics on packets, tcp sessions etc.
- fast.log: a alerts log similar to Snort’s fast log.
- http.log: displays HTTP requests in a Apache style format.
This should get you going. There is a lot more to deploying Suricata that I plan to blog on later.
Removing Trac ticket comment spam in Debian Lenny
April 23rd, 2010The Vuurmuur website runs Trac and overall I’m pretty happy with it. The only thing that Trac doesn’t do well, is dealing with spammers. Spammers target Trac a lot, so that’s a real problem.
To prevent spammers from making it through, I run Scallywhack and a number of custom ModSecurity rules. So far, spams only made it through as new tickets in the ticket tracker, so I installed the TicketDeletePlugin.
Yesterday, I saw the first spam as a comment to an existing and valid ticket. Like tickets themselves, ticket comments can not be removed by Trac by default. Luckily, upstream Trac seems to have fixed this. I’m running Debian’s version of Trac 0.11.1 however, so I decided to patch that. The patches in the Trac ticket #454 didn’t apply cleanly, so I had to patch it manually. To save others the work, it’s available here: http://www.inliniac.net/files/trac_0.11.1-debian-comment_edit.patch
To use it, make a copy of your /usr/share/pyshared/trac directory.
Next, go into the trac directory and run the command:
patch -p1 < /path/to/trac_0.11.1-debian-comment_edit.patch
After this, each comment in the comment system will have a “edit” button and you can remove the spam message content. It’s not possible to remove the entire comment, but this works for me.
Tags: comment spam, Debian, trac
Posted in Debian, ModSecurity | No Comments »