[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel 2.0.30 a bad choice for 1.3



jgoerzen@complete.org (John Goerzen)  wrote on 23.05.97 in <877mgphe14.fsf@glockenspiel.complete.org>:

> Sven Rudolph <sr1@os.inf.tu-dresden.de> writes:
>
> > Christoph <debian@waterf.org> writes:
> >
> > > On 21 May 1997, John Goerzen wrote:
> > >
> > > > Since we know of a number of things that have been broken in 2.0.30
> > > > (such as IP masquerading being totally hosed), why are we distributing
> > > > that version with 1.3?
> >
> > 2.0.30 has SYN_COOKIES. This is a critical feature.
>
> Agreed.  However:
>
>  * Those people that need SYN flood protection will know they need it
>    and will know how to compile their own kernel.  (There are few
>    people that really need this desperately, in my estimation.)

Why will they know they need it? A successful SYN attack just makes a  
machine deaf to the network. It usually gives NO indication what went  
wrong, except to somebody able to read traceroute output.

Why will they know how to compile their own kernels? What sort of magic  
guarantees that kernel-handling-challenged people won't be attacked that  
way?

>  * The people that will suffer due to broken networking, etc. will not
>    necessarily know what the problem is, what to do about it, etc.

On the other hand, people suffering from this problem should have a _much_  
better chance of finding out what went wrong.

> We could even include a README telling people that need SYN protection
> how to get it.

I'm sorely tempted to say that there can be no excuse to ship a kernel  
without SYN protection these days.

Oh, I give in. There really is no excuse.


MfG Kai


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: