[Snort-devel] RE: [Snort-users] Possible Queso Fingerprint attempt?

Ookhoi ookhoi at ...1580...
Fri Mar 16 06:41:21 EST 2001

Hi Gregor,

> > > [1] If anyone involved in that asinine decision is reading this,
> > > I'd certainly like to thank you for really buggering up a lot of
> > > firewalls and IDS's around the world.  That was a great plan,
> > > guys.  Top notch execution, too. 
> > 
> > Ecn is a good thing. The firewalls should be fixed.
> I agree that equipment broken with regards to RFC 793 should probably
> be fixed. I personally would probably not implement an experimental
> method in a production release, and certainly not enable it by
> default.

I have to correct you on this one. Ecn is not enabled by default. You
have to download the kernel yourself, untar it, set ecn from the default
No to Yes, compile it, install it and reboot your computer with it.

> And I'm still wondering how a design goal of making my "Internet
> Experience more pleasurable" (linux kernel ML FAQ,
> http://www.tux.org/lkml/#s14-2) would relate to me being blocked by a
> whole lot of routers or firewalls, or my ISP blocking me because
> people report things like the Queso Fingerprint from my systems. I
> guess it doesn't help 2.4 users that their system is sane and
> everybody else's is broken, it doesn't work for THEM. :)

The reason that we were blocked by our provider is twofold. 1, some
braindead provider installes snort, sees an alert and not being stopped
by the slightest amount of common sense, mails the logs to _our_
provider. There happens the same thing and they even multiply the total
lake of common sense. Without noticing (also) that the alert is only at
port 25 and for several days, they sent us a three-line message which
says that we did a portscan, are probably hacked and that they blocked
our server. No logs, nothing. 

You can't blame us for enabling ecn, or linux for supporting ecn. We
blame the dumbass provider which installed snort and don't know a thing
about it.

> In addition, this might make my "Internet Experience" less secure,
> because it forces vendors to provide patches for what would actually
> be a non-issue quickly, if deployment of new features would have been
> done in a proper way.

Less secure? I can't see why. And ecn was in 2.4 before it was declared
stable, so imnsho it is implemented in a proper way.


More information about the Snort-users mailing list