Re: snort and packet sniffing

[Matt Kettler <mkettler () evi-inc com>]

Advance note: You might want to read my conclusions first, then read the 
email in light of them, or at least be sure to read the whole message 
before reaching conclusions. (preview: snort's output is fine for it's 
purpose as an IDS, but the context of this thread is not IDS applications)

At 08:33 PM 8/19/2004, Martin Roesch wrote:
> > Ahh, yes, snort's type:0x800 is much clearer than tcpdump's ethertype:IPv4.
>
> Depends on who you ask. :)  Snort's original first job was to give me 
> output that was always predictable for debugging network apps that I was 
> building at the time.  If you're a programmer, 0x800 is clearer than IPv4 
> because I know that Snort is printing that 0x800 because that's a field 
> value from a struct in memory.  IPv4 could be coming from anywhere (table 
> lookup, hardcoded, etc).

Hmm, I am a combination low-level programmer (device drivers for Linux and 
WDM) and system admin. I can parse IP headers in my head and am pretty used 
to reading hex dumps. W.R. Stevens's TCP/IP illustrated actually has a 
permanent place on my desk surface instead of on my bookshelf.

However, ethernet formats aren't something I have memorized, as they are 
something I rarely use in such a way I'd need to examine their headers. 
Thus the 0x800 means absolutely nothing to me, because I'm not sure what 
protocol that represents. Sure I can tell you it represents 2048, but 
that's not useful either. I wouldn't know what IPX, IP, ARP, or any other 
common network protocol uses as a numeric protocol ID, but I'd easily 
recognize their names.

Let's face it, if I wanted to read the hex, I'd read the hex and ignore all 
of the decoded output.


> > I suppose it's a matter of taste, and I'd agree that some might prefer 
> one format vs another, but IMO, one of snort's weaknesses is vague and 
> cryptic packet decode.
>
> Humph, I always found tcpdump to be unnecessarily terse (esp. in 1998 when 
> I first wrote Snort) and reading its output to be a pain because it's got 
> a logic all its own.  For example, I find that grouping the TCP flags 
> together to be more clear than spreading them through the decode, I find 
> hex values to be just as readable as decimal ones (and a lot more compact) 
> while being easier to look at when trying to spot things in field-style 
> protocols.  For example, the TOS (DS) field is an appropriate place to use 
> a hexidecimal output type because it's a bit field and I can see exactly 
> what bits are set at a glance in that format.  Maybe it's because I came 
> at it with the perspective of a programmer, but Snort's sniffer mode 
> output is formatted the way it is for specific reasons.

I'd agree with those layout choices. I dislike tcpdump's tendency to spread 
out the tcp-layer flags.

 I'm certainly not hex-a-phobic Marty. And I'd certainly agree that hex is 
a more reasonable format for bitfields than decimal. I'd also agree that 
hex is as-readable as decimal. In many respects I prefer hex to decimal, if 
for no other reason than it's easier to verify against the packet contents. 
My point is that for some fields, numeric output of any form is going to 
require the reader to have special knowledge and/or resort to looking a 
value up in a book. Clearly your average system admin prefers "***A**S*" or 
"ack syn" to 0x12 or 18. Even tcpdump's spread-out-flags format is clearer 
than tcpflags:0x12. A "deep hack" type coder might find the numeric format 
clearer, but such a coder is more likely to look at the raw packet not the 
decode.

I'm also not saying tcpdump is an example of perfect output either.. both 
are pretty cryptic, and my basic argument is that snort is not 
significantly less cryptic than tcpdump. In some respects snort is 
significantly more cryptic, and others it's less cryptic. Which one is more 
readable depends a lot on the reader, but I'd suspect there are few who 
would argue strongly that one is clearer than the other by any large margin 
(notably you Marty, but you wrote the format)

Remember, the original question isn't which has perfect output, it's "Why 
would someone go to the effort of replacing tcpdump with snort, and only 
use it as a sniffer". Clearly the point of "clearer output" is a matter of 
taste, but it's hardly a decisive one where most people would agree snort 
is drastically easier to read. Even those who think snort is clearer might 
not find it worth the effort to download/compile/install snort vs using a 
precompiled copy of tcpdump off their distro CD.

> As has been noted elsewhere, I've been working on a new decoder 
> architecture for Snort lately that will have multi-mode sniffer output 
> (amongst its other features) that will allow you to be terse or very 
> verbose depending on what you need.

Very nice. I like that idea.


> > (side comment on matters of taste: I'd love to commend the genius of 
> ambiguity that created "iplen:" and "dgmlen:", which sound like they 
> should be same thing, the length of the IP datagram, but are really "ip 
> header length" and "ip datagram length". How one gets "header" from 
> "iplen" is beyond me.)
>
> Sorry about that, that's my fault.  One of the things I've tried very hard 
> to do over the years is to keep Snort's output 80-column friendly and 
> deterministic, things should always be in the same place so they're easy 
> to find.  One of the side effects of that has been some terseness and 
> "snort-ese" jargon that has gone into the system.  Iplen = length of the 
> IP header, dgmlen = length of the datagram, makes perfect sense to me. :)
>
> As I get things squared away with the new code I'll start providing 
> previews and maybe people can comment on likes and dislikes.  Hell, we 
> could even tweak Snort's existing output...


I wouldn't go so far as to say snort is in any great need of revision of 
it's output format. It's sufficient for the use of snort as an IDS. Most of 
us are using third-party interface tools anyway (Acid, squil, snortsnarf, 
etc), and resort to some tool to post-process raw packet captures when 
particular packets are of interest to us.

If snort's primary use were as a "easier to read tcpdump replacement" I'd 
be suggesting a reformat, but that's not snort's purpose. Snort's job is to 
be an IDS, generate an alert, with minimal overhead, and save the 
suspicious packet(s) for later examination with more verbose analysis 
tools. And it does that quite well.

As for the multi-mode output, I'd probably use the mode which as the least 
overhead for general snort IDS use. I might use the verbose mode for a 
sniffer, but that's a pretty rare thing for me to use snort for.



-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
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