[Snort-devel] reserved flags + spp_stream4

Jon warchild at ...1775...
Fri Mar 28 21:41:14 EST 2003

On Fri, Mar 28, 2003 at 07:29:55PM -0500, Jon wrote:
> Greetings,
> I migrated a sensor to Snort 2.x yesterday.  Its an OpenBSD -current box
> with a fairly simple snort.conf.
> I've received over 1000 alerts from 40 hosts because (for whatever reason)
> they set the two tcp reserved flags.  These packets also always have the
> SYN set, and are part of legitimate connections (well, they will be in two
> more handshakes, anyway).  
> At first I thought these were just broken machines, but a good portion of
> the alerts are coming from well-known sites like vger.kernel.org
> (linux-kernel mailing list, I think).
> My questions are:
> Is it necessary to alert on this stuff?  Since these are the ECN and CWR
> flags (I think, anyway.  I could be a bit rusty right now) and the
> existence of these flags isn't necessarily a sign of malicious intent,
> could the alerting process be re-thought or explained?  I know R0 and R1
> are often used with nmap and queso, but...
> Can this particular option to stream4 be tweaked and/or turned off? 

One thing that was suggested was that I tack a bpf filter onto my snort
startup command.  That'll certainly work, but it'll just make it so my
sensors don't see any ECN/CWR traffic, which isn't ideal.  This was
discssed a while back, and I'm of the same opinion:


I'm just not sure I see the point of alerting that ECN and CWR are set if
its a perfectly legit option and is used and may be used even more often as
time passes.  Actually, now that I (re)think about it, snort really isn't
logging the traffic because r1 and r0 are set, its just logging it as

I took a look at stream4 to see why it might be alerting on this.
Basically all it seems to be doing w/ ECN-ish traffic is seeing if some of
the reserved bits are set, and if so, checking to see if the TOS is set to
2 (maximize reliability).  If these two parameters are true, it assumes the
traffic is ECN traffic and doesn't alert.  If reserved bits *are* set but
the TOS isn't kosher, it assumes something is wrong and alerts.  This may
in fact be something interesting, but I'm not clear that its wise to do
this by default or not give the user the ability to turn it off.  Quoting
from snort.conf, "because there are a lot of crappy ip stack
implementations out there".


More information about the Snort-devel mailing list