[Madlug] If you build it, they will come.

[Steven Cayford]

Cool. So, I went to the site, read the article, thought, "Wow, what a cool 
idea, someone should patch Linux with that technique." Then I saw the 
"Previous work in this area" reference and followed that to a discussion 
of a similar implementation 4 years ago on Linux: tcp_syncookies which you 
can enable with "echo 1 > /proc/sys/net/ipv4/tcp_syncookies"

So I checked my little 486 firewall box (running LEAF/LRP) and it was 
already enabled. Heh, heh.

Linux rocks.

-Steve


On 2001.10.28 21:56:00 -0600 Ray Ferguson wrote:
> I don't know if you hit the link yet, but near the bottom of the page he
> talks about the ecryption details.  Originally he flirted with the idea
> of
> using a small encryption cache to keep track of encrypted/decryted pairs
> so
> that they wouldn't have to encrypt and decrypt the ISN for every
> connection
> attempt, but the encryption process in his assembly implimentation was
> actually much faster than cache would be.  In fact, he added more rounds
> to
> the encryption to make it stronger because he had so much head room
> resource
> wise.  I guess it's based on RSA MD5.
> 
> On Sunday 28 October 2001 06:57 pm, you wrote:
> > I wonder how much overhead it takes to encrypt/decrypt all those packet
> > signatures?
> > -Steve
> >
> > On 2001.10.28 08:32:30 -0600 raymond wrote:
> > > I don't know about that, but this gives me a real hardon.
> www.grc.com
> > > He
> > > built it in assembly and it works well.  Look for links to nanoprobe
> > > technology off the shields up page.  Or skip to the good tech stuff:
> > >
> > > http://grc.com/r&d/nomoredos2.htm
> > >
> > > >From Gibson:
> > >
> > > Summarizing
> > >
> > >   We are immune to SYN flooding because all connection management
> > > overhead is
> > > deferred until the end of the 3-way handshake and no record that a
> SYN
> > > was
> > > received is retained.
> > >
> > >   We are immune to ACK flooding because the relationship between the
> ACK
> > > packet's apparent Source IP and the encrypted token it delivers is
> > > unknowable
> > > by any external agency. Therefore ACK packet senders are unable to
> spoof
> > > their source addresses because they have no way of producing properly
> > > matching tokens.
> > >
> > >   Upon receipt of a SYN packet, our modified "connection deferring"
> TCP
> > > protocol generates and sends an answering SYN/ACK packet in
> > > ACKnowledgement
> > > of the Client's ISN, and provides our ISN (the Encrypted Token
> matching
> > > the
> > > Client's IP). We retain no record that a SYN has been received.
> > >
> > >   The ISN we provide for our outbound SYN/ACK packet is just an
> encrypted
> > >
> > > version of the Client's apparent Source IP.
> > >
> > >   If the received SYN carried a spoofed Source IP, our SYN/ACK
> response
> > > will
> > > disappear into the Internet and that will be the end of it. But since
> we
> > > no
> > > longer allocate any connection resources upon the receipt of SYN
> packets
> > > we
> > > don't care at all if the SYN's are spoofed.
> > >
> > >   A valid Client replies to our SYN/ACK by sending an ACK packet back
> to
> > > us.
> > > It provides its current sequence number and also acknowledges the ISN
> we
> > > provided . . . which is actually its encrypted IP address.
> > >
> > >   When we receive an ACK packet for a connection that does not
> currently
> > > exist, we simply decrypt the ACKnowledged sequence number (the
> returned
> > > encrypted token) and compare it with the packet's apparent Source IP
> > > address.
> > > If they match we know that the ACK and Client are authentic.
> > >
> > > ---We must all bow in silence.  aaawwwww........
> > > _______________________________________________
> > > Madlug mailing list  -  Madlug at madisonlinux.org
> > > http://www.madisonlinux.org/mailman/listinfo/madlug
> >
> > _______________________________________________
> > Madlug mailing list  -  Madlug at madisonlinux.org
> > http://www.madisonlinux.org/mailman/listinfo/madlug
> 
> --
> Ray Ferguson
> NOC Analyst
> Berbee
> 5520 Research Park Drive; Madison WI 53711
> ferguson at berbee.com
> Direct Line: 608.298.1115 Fax: 608.288.3007
> 
> Berbee... putting the "e" in business.
> _______________________________________________
> Madlug mailing list  -  Madlug at madisonlinux.org
> http://www.madisonlinux.org/mailman/listinfo/madlug
>