[Snort-users] snort and packet sniffing
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
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