Snort mailing list archives
RE: Traffic anomaly detection
From: "Williams Jon" <WilliamsJonathan () JohnDeere com>
Date: Wed, 12 Feb 2003 10:38:06 -0600
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
Current thread:
- Traffic anomaly detection Joerg Weber (Feb 12)
- Re: Traffic anomaly detection Erek Adams (Feb 12)
- Re: Traffic anomaly detection Frank Knobbe (Feb 12)
- Re: Traffic anomaly detection James Hoagland (Feb 12)
- <Possible follow-ups>
- RE: Traffic anomaly detection Bob McDowell (Feb 12)
- RE: Traffic anomaly detection Williams Jon (Feb 13)
- RE: Traffic anomaly detection Erek Adams (Feb 13)
- Re: Traffic anomaly detection Erek Adams (Feb 12)