On Mon, 2002-07-15 at 22:03, Russell Hires wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Yes. I would like to figure out how to use snort, but it's been a tough, long
> journey, and I don't feel like I've gone anywhere... :-\
>
> Eh...just a comment.
>
> Russell
> >
> > This sounds like a job for SNORT! (http://www.snort.org/)
>
SNORT is actually pretty easy to set up, it's getting anything useful
out of it that's tough.
Here's my 10-minute, $0.25 tutorial on setting up snort:
The best way of getting useful information out of snort is by building
it with some sort of database support and using ACID (heh) to pull
relevant information from the snort db.
Build your database, MySQL or PostgreSQL (Oracle is also supported but
there's no way I'm going to recommend to anyone not already a DBA that
they should set up Oracle...) according to the directions. I'm being
vague here because one person may want to just install RPMs while
another may want to build from source. Either way works as long as you
have a working database at the end.
Build snort (use either or both database options as you like):
./configure --with-mysql=[path/to/mysql]
--with-postgresql=[path/to/pgsql] --with-openssl
make
make install
If you want to have snort spit out XML (pointless but cute) then also
use the "--enable-idmef" option. If you want "flexresp" enabled (where
snort can do "active response" type things like send RST packets on
rules you specify) then use the "--enable-flexresp" option. I'd
recommend not bothering with either until you're more familiar with
snort's operations.
It will be installed in /usr/local/bin by default, with the config file
in /usr/local/etc/snort/ which you may have to copy there by hand from
the source directory - I don't recall exactly; if it's not there, put
the one from the source directory in there.
Then "mkdir /usr/local/etc/snort/rules" and from the snort source
directory, do "cp *.rules /usr/local/etc/snort/rules"
Edit the snort.conf and set:
var HOME_NET $eth0_ADDRESS
for whichever interface is the external interface on your firewall, or:
var HOME_NET [192.168.1.0/24]
where the CIDR is the address range of the network that you consider
"yours".
$HOME_NET is frequently used as a "target" address for snort rules, so
make sure that you set it to whatever range of addresses you'd like to
get snort alerts on. i.e. if you just have one external address on RR,
just use the $eth0_ADDRESS option - if you have a whole network
colocated somewhere and you want to put one snort sensor out there to
monitor everything on that network, use notation like the second
example. (And of course $eth1_ADDRESS is just as valid or $ppp_ADDRESS
- whatever your external interface.)
Then set
var EXTERNAL_NET !$HOME_NET
$EXTERNAL_NET is used as the "source" for a lot of rules to match, so
this should be anything NOT your $HOME_NET.
A lot of rules wind up looking something like:
"where source is $EXTERNAL_NET and dest is $HOME_NET ...."
so those are two of the most important settings to tweak so that you
aren't missing anything important and aren't picking up things you don't
want or need.
Then set
var RULE_PATH /usr/local/etc/snort/rules
There are some other var settings in there that should be pretty obvious
as to what they should be, or at least the default settings should be ok
if they're not so obvious. You can tweak them later if you want.
The rest of the config file, other than output options, is pretty good
by default. You shouldn't mess with anything except output settings
until you get a better idea what will happen if you change them.
The hardest part of getting any useful information out of snort is
getting any information at all out of snort. Logging to a database and
using ACID is the probably the most user-friendly and useful way, so
you'll need to scan down the config file for output plugins and find the
database methods. Configure it as appropriate for the database you've
set up by the examples given.
Note that I'm being vague here again, because there are a number of ways
you can set up the database, on the same box, on another machine behind
your firewall, with an IPSEC tunnel between widely separated boxes,
etc. So you have to make sure you have the database configured
correctly, run the appropriate creation scripts to make all the
necessary tables from the "contrib" directory under the snort sources,
and access granted to a user so that SNORT can actually connect to the
database and log its information. The actual output configuration is a
one-liner though, and I hope anyone who's gotten this far can figure it
out.
If you just want to be able to see information from snort, and don't
care about nice interfaces or being able to just see subsets of that
data, or really anything at all other than just a great big list of
alerts, then by all means use the SYSLOG output plugin, which will log
everything through syslog. I had it running like that for a little
while as I got the database stuff all worked out. I set up a nightly
CRON job that does something like "grep snort /var/log/auth.log" which
spit everything that SNORT said that day to STDOUT, which got emailed to
the user running the CRON job, usually root. So you'll either need to
set up root's .forward file to send it to you, or add yourself as an
"alias" for root in your mailer's config so you will actually see this
output.
You can also have snort log to its own files in /var/log/snort by
configuring some of the other output plugins. You may just want to turn
on *all* of the output plugins at first and see which method(s) is/are
most useful to you. It will slow snort down some to have such a huge
amount of logging to do, particularly if you have a lot of alerts, but
IMNSHO it's better to start big and narrow it down than miss something
right off the bat.
Anyway, if you've gone the database route, get that configured, then
scan to the bottom of the snort.conf and edit the rules that you want to
see.
In general, I leave *everything* turned on initially, then let it run
for a while to see which rules are generating too much noise and
one-by-one comment them out of the rules files themselves. (I still
leave all the rules file enabled in the snort.conf) You may not need
the "porn" ruleset, which I still haven't really figured out what it's
good for other than seeing who on your network is surfing porn, so you
can comment that whole ruleset out of your snort.conf unless you really
want to find all the good porn sites your users are browsing.
Once you've got that all set up, start snort:
/usr/local/bin/snort -c /usr/local/etc/snort/snort.conf -i eth0 -l
/var/log/snort -u snort -D
"-c" is "use config file...", "-i" is "listen on interface..", "-l" is
"log to this directory...", "-u" is "run as this user.." and "-D" says
"detach from tty and run in daemon mode."
So you'll have to have: a "snort" user, a /var/log/snort directory
that's writable by the snort user, and the correct interface set here.
Do a "ps" and see if snort is running. If not, tail your
/var/log/daemon.log and see if it spit out an error message. Generally
the error messages are pretty self-explanatory, so you should be able to
figure out what the problem was and fix it.
Depending on how you have logging set up, you may start to see things
appear in your database, in /var/log/auth.log and/or in files located in
/var/log/snort/. I generally have a CRON job that runs nightly that
just does a "stop/start" on the SNORT process (you can find the PID in
/var/run/snort_$iface.pid) so the logs in /var/log/snort will roll
over, otherwise they can get pretty big if you get a lot of traffic.
Grab ACID from:
http://www.cert.org/kb/aircert/
and read the instructions. It requires Apache and PHP with a few
external dependencies when you build PHP, but I don't recall what they
were now. If you can do the usual "configure; make; make install"
routine and read a couple of README files, this is by far the easiest
task in getting a good SNORT sensor running, so I'm going to blow by
this part.
Once you've got Apache and PHP up and running, you just need to copy the
ACID files over somewhere that PHP will process them and point your web
browser to the appropriate directory. It has some basic setup scripts
as part of the first couple of pages so once you have it running under
PHP, it pretty much sets itself up beyond that point.
I would *highly* recommend running an SSL-enabled Apache for your ACID
reporting, and putting a password on the subdirectory under which you
have ACID installed. Snort logs packet payloads when it finds a
fingerprint that matches, and that could contain information that could
itself be used to compromise your machine!
Now just keep an eye on it. Check it regularly to see what kinds of
alerts you're getting. Chances are, you will see a LOT of really
useless things like your machine being "PING"ed a lot or a lot of
IIS/Code Red alerts you don't care about. Find those specific rules in
the rules files (grep is your friend) and comment them out and restart
snort. After a couple of days, you should be able to get rid of most of
the noise and be left with just the "interesting" traffic.
Note that not everything you see in snort is malicious. There are a lot
of broken systems out there that do a lot of strange things. I think in
the case of nearly anyone who is not a bank, Fortune 500 company or
government system, 99% of what you see in Snort outputs is random
garbage, automated worms, or just broken systems. Which makes it hard
to sift through the gunk to find anything really important. And finding
those _really_ "interesting" reports is something you just have to learn
from experience. So keep an eye on it and start understanding what the
"normal" traffic looks like. That way you'll notice when something is
actually happening.
I will give you a hint though - the WORST thing you can see in your
snort logs is an alert that says "Successful exploit."
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
http://www.eff.org/ http://www.anti-dmca.org/
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 13:56:12 EDT