RE: Traffic anomaly detection

["Williams Jon" <WilliamsJonathan () JohnDeere com>]

Taken a step further, there are a few rules that, while sometimes noisy, can
help detect traffic that hasn't been previously defined.  For example, worms
like CodeRed and Nimda propegate, in one form, by looking for IIS servers to
connect to.  Since we know for a fact that not every system in the world
runs IIS (sorry, Bill :-), we can presume that a system infected with one of
these worms would generate a bunch of traffic to hosts that aren't
listening.

If those hosts are somewhat RFC compliant and not listening at all on TCP
port 80, the "normal" response would be for them to send back a TCP RST
packet.  So, if we set up a snort rule such as:

        alert tcp any 80 -> any any (msg:"rejected on HTTP";flags:AR;)

we should be able to see sudden spikes in activity that would indicate the
presence of an infected machine.  Note that since we're looking at the
RESPONSE to an attack and not the attack itself, the source and destination
addresses are reversed.  The real attacker on these rules will be the
_destination_ address.

Now, as I said, this rule can get noisy, since fat fingers can trigger it,
but since what we're looking for is spikes in activity, I've accepted this.
I run my stuff into MySQL/ACID, but I combine it with a cron job that pulls
some stats on the ACID database into a RRD database so I've got line charts
showing total number of alerts, number of unique source addresses, unique
destination addresses, and unique signatures.  I can take a look at those
charts and actually see the spikes.  For example, we had some clown plug in
a Nimda-infected machine, which caused 30,000 alerts in 10 minutes.  since
the total number of alerts had been around 2k before, that spike showed up
clearly.  Also, there was a spike in the unique sources line, but the unique
destinations line stayed flat, which pointed us to one of the RST rules
rather than someplace else.

Obviously, there are other things like this that can be done, with varying
success.  In some cases, a UDP packet to an un-open port might generate an
ICMP port unreachable (itype 3, icode 3).  You can also, if you're a real
RFC jock, go through and write rules that look for out-of-spec packets, such
as ICMP types that haven't been defined.

YMMV.  I'm finding more "offenders", so to speak, with my custom written
anomaly rules than I do with the stuff I download from snort.org.  Most of
that comes from the fact that I've spent probably 100 hours over the course
of the past year or so working with people here to understand what my
network really looks like, what it really _should_ look like, and then
_carefully_ crafting rules that alert on things that I know shouldn't be
there.  This is definately *NOT* a quick fix, since every rule I turn on
usually uncovers another digital body that adds another six month project to
my list, but if you're serious about understanding your network, its a good
excersize.

Jon

-----Original Message-----
From: Erek Adams [mailto:erek () snort org]
Sent: Wednesday, February 12, 2003 7:23 AM
To: Joerg Weber
Cc: snort-users () lists sourceforge net
Subject: Re: [Snort-users] Traffic anomaly detection


On Wed, 12 Feb 2003, Joerg Weber wrote:

> we are currently using snort with quite some success (and fun, I might
> add). Now, I'm looking at SPADE and have no trouble finding traffic
> using unused IP address or dead ports, etc.
> What I'm trying to implement is the detection of 'unusual' traffic,
> generated by an unknown worm, a warez server, etc.
> I assume this is possible with SPADE, could someone confirm this?
> If so, could someone share a config file and maybe some alert entry so I
> can parse my logs/db for similar entries?

Have a read over an excellent post [0] by Frank Knobbe to the focus-ids
list.

To sum his post up, you don't need anything more than basic rules.  I'd
suggest running something like ntop [1] or Sniffer Pro (commercial) to get
a visual idea of who's on your net, what they are doing, and what "looks"
normal.  Once you've got that picture, tune your rulesets down to what is
"good" for you.  Then, since you know your websever should only accept
requests on port 80 and 22, and it should never initiate any outgoing
requests execpt for DNS you can write rules that flag any traffic other
than that.

Cheers!

-----
Erek Adams

   "When things get weird, the weird turn pro."   H.S. Thompson


[0]     http://marc.theaimsgroup.com/?l=focus-ids&m=104499996305316&w=2
[1]     http://www.ntop.org/ntop.html


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users