Barnyard is a output system for Snort. Snort creates a special binary output format called ``unified.'' Barnyard reads this file, and then resends the data to a database backend. Unlike the database output plugin, Barnyard is aware of a failure to send the alert to the database, and it stops sending alerts. It is also aware when the database can accept connections again and will start sending the alerts again.
http://www.silicondefense.com/snortsnarf/
http://homepage.mac.com/nickzman
http://home.attbi.com/~rickzman/software/HenWen1.0.sit.bin
http://www.demarc.com/downloads/puresecure/
Feed the unified output files through Barnyard twice to separate databases, or...
You can build redundancy by using multiple output plugins. Here are some examples.
Multiple instantiations of the database plugin:
output log_database: mysql, dbname=snort host=localhost user=xyz output log_database: mysql, dbname=snort host=remote.loghost.com user=xyzRemote database and local tcpdump:
output log_database: mysql, dbname=snort host=remote.loghost.com user=xyz output log_tcpdump: /var/log/snort.tcpdumpThen you can replay the tcpdump file through snort to recreate the database.
CAVEAT: Just playing back the log packets might not trigger some of the state dependent pre-processors.
You have to use routing between two dummy devices:
modprobe -a dummy # (The dummy device has to be build by the kernel) ifconfig dummy0 192.168.0.1 ifconfig dummy0:0 192.168.0.2 telnet 192.168.0.3 12345
It's important that the second IP is on the same interface and not, e.g. dummy1 or dummy2 and that the IP you try to access is not one of those you put on the interfaces. Use snort's ability to hear in promiscious mode on an IP address range. (HOME_NET=192.168.0.0/16)
Examples: All include statements must be full paths:
WRONG: include scan-lib
CORRECT: include C:snort
scan-lib
All command line options must be full paths:
WRONG: snort.exe -l ./log
CORRECT: snort.exe -l C:snort
log
snort -i1 -lC:\( \backslash \)snort\( \backslash \)log -cC:\( \ backslash \)snort\( \backslash \)snort.confthen you should change it to be:
snort /SERVICE /INSTALL -i1 -lC:\( \backslash \)snort\( \backslash \) log -cC:\( \backslash \)snort\( \backslash \)snort.confVerify that the command line parameters were received correctly by running the command `snort /SERVICE /SHOW.'
net start snortsvcNote that versions 1.9 (build 228), 2.0 (build 50), or any versions newer than these, will add entries to the Win32 event Log if there is ever a problem starting the service. Stop the service by running the command:
net stop snortsvc
snort /SERVICE /UNINSTALL
Yes, with additional software in the contrib directory. But this can be dangerous and is not recommended unless you know what you're doing.
Guardian is a perl script which uses Snort to detect attacks, and then uses IPchains to deny any further attacks. The Guardian webpage can be found at: http://www.chaotic.org/~astevens/Guardian/index.html or you can use the mirror, http://www.cyberwizards.com/~midnite/Guardian/index.html
CHRISTOPHER CRAMER wrote:
I'm sure this has been mentioned before in similar discussions, but this feels like a _really_ bad idea. What if the bad guys realize what is going on and make use of your blocking method as a DoS attack. All one would have to do start sending a series of triggering packets with spoofed IP addresses.
Since I am no longer interested in breaking into your site, but rather making your life hell, I don't worry about the resulting data getting back to me. All I have to do is start proceeding up a list of IP addresses that I think you should no longer be able to talk to. When you come in the next morning, you find that you can no longer access the world.
Just my $0.02.
Danger Will Robinson: Conventional wisdom says that auto-blocking is inherently dangerous.
However, for those that like to live at the bleeding edge of tech (and the separate process scanning logs and processing firewall commands sounds like a good way to do this...):
Please remember to include an exclusion list and put on them important sites such as root servers, other important dns servers (yours, and important sites for your users), and in general any host you don't want to receive phone calls about being DoSed when they are spoofed - usually inconveniently like that first time you actually manage to get on vacation.... (i.e. imagine ``Crisis: the CEO can't reach his favorite redlite.org game.... you have to fly back from the Carribean ASAP....'')
snort-inline > hogwash >> SnortSAM|Guardian >> flexresp
Rerun configure with the -enable-flexresp option and rebuild/reinstall.
You can't. Such a process would slow Snort down too much to make it of any use. Instead, log to syslog and use swatch or logcheck to parse over the plaintext logfiles.
With the Logsurfer docs, this might get you on the road to doing something with Snort and Logsurfer:
JASON HAAR provided an example Swatch (3.1beta) config that emails alerts:Here are some docs on swatch:
IDS Center (see FAQ ) on Win32 will also mail alerts.
An example addition to snort.conf:
ruletype redalert { type alert output alert_syslog: LOG_LOCAL2 output database: alert, postgresql, user=user dbname=snort password=pwd }
Go into your local.rules and make sure you have something like:
redalert tcp any any -> any any (msg:"REDRUM REDRUM"; content:"redalerttest")
Then just do a telnet and type `redalerttest.' Presto, alerts to both.
Calling another program from within your main IDS loop is
generally a bad idea. Having your IDS block while waiting
for something
of dubious reliability and origin nevermind
timing while the packets are piling up is inviting packet loss.
Especially with the already oh-so-consistent ``Gee I think
I'll go away for a minute'' rock steady even cpu slicing
Windows gives you (that's sarcasm, sorry). Go with the
second approach.... process invokation is expensive on
Windows.
You want to keep that IDS task humming and munching packets as efficiently as possible with as few interruptions as possible, imho, and not be invoking the penalty of process invocation.... particularly on Windows where process invocation is much much heavier task than *nix.
Even in a secondary process... You'll probably find something that stays ``awake'' all the time will work out much more nicely than something that gets ``woken up'' on a per alert basis for the aforementioned reasons.
As a better alternative go check out swatch or logwatch. Also for those new to UNIX, logging alerts to syslog and then using ``tail -f /var/log/messages'' might be what you are looking for.
It can be done with Snort, but you might find it faster to use mailsnarf and urlsnarf from Dug Song's dsniff package. Dsniff is available from:
http://www.monkey.org/~dsong/dsniff/
You can get a win32 port of dsniff at:
http://www.datanerds.net/~mike/dsniff.html
Use the perl script snort_archdb.pl found in the contrib dir of the Snort distribution (snort_archdb-90a.tar.gz).
Also, try ``dig.''
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Firewall-HOWTO.html
http://www.insecure.org/stf/smashstack.txt
http://www.openna.com/products/books/sol/solus.php
If you are using unified logging, you can use Barnyard (see FAQ ) or the unified log to pcap converter written by Dragos:
You can then get additional decoding of the packet contents by analyzing these pcap files with either: