[Snort-users] snort and packet sniffing

Martin Roesch roesch at ...1935...
Thu Aug 19 17:34:11 EDT 2004

On Aug 19, 2004, at 10:28 AM, Matt Kettler wrote:

> As an aside, it would be interesting to see which performs better 
> under load.. I suspect that tcpdump will perform better, since use of 
> text output in snort is discouraged and probably not a heavy focus of 
> developer tweaking/tuning.

The big problem would be if you enable payload dumping on either 
program, that burns up CPU (comparatively speaking).  I'd wager the 
performance of the programs is close, although we haven't done tons to 
optimize sniffer mode.

> (note: you'd have to use -n to tcpdump, since tcpdump does RDNS and 
> /etc/services lookups by default, and snort doesn't support them at 
> all. The RDNS could slow tcpdump down considerably)

Which is why Snort doesn't support them. :)

>> See nicer and more complete description of fields, in snort's case ..
> 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).

> 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.

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.

> (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...


Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Intelligent Security Monitoring
roesch at ...1935... - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org

More information about the Snort-users mailing list