Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Snort-Users
[Top] [All Lists]

Re: [Snort-users] Unified Log Format

Subject: Re: [Snort-users] Unified Log Format
Date: Tue, 28 Jun 2005 23:39:33 -0400 (EDT)

Martin,

If you want a comprehensive map of the SIDs (Snort ID's) of GID 1, you should look at the sid-msg.map file in the etc directory of your Snort distribution. SID 527 is a bad-traffic.rules detect for same source/dest IP in a packet. Typically you'll get these listening on loopback...

Ahh! The sid-msg.map, now I get it. In fact, this 527 alert is from an old log file from an early snort setup of mine. Maybe I'll get ethereal to load up this file and generate the messages from it...


[...] Typically the log data will be a standard Snort packet, but on aggregate event like a portscan you'll get our crammed packet type that we're overloading the field with.

Right. I've actually been able to (mostly) decode the sfPorstan packets. I'm thinking about teaching ethereal to understand the actual packet contents for these. It seems that these packets use the SLL ("linux cooked capture") encapsulation, but with a broken or missing SLL header? I've gotten it to work by forcing the encapsulation to ethernet -- then the normal ethereal ethernet dissector kicks in and the rest follows. But the reference date is all wacky...


GIDs 100, 117, 121 and 122 are all various portscan detectors that have been built for Snort over the years, you might just want to skip those records...

Hmm. Is there any way to get a full list of these "aggregate events" that you mention, along with details about the packet they fake up?


Thanks for the tips!  Some of these anomalies are starting to make sense.

Cheers,
mds


------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ 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

<Prev in Thread] Current Thread [Next in Thread>