Great Circle Associates Firewalls
(November 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: "SYN" protection product leads
From: "Jesús Cea Avión" <jcea @ argo . es>
Organization: Argo Redes y Servicios Telematicos, S.A.
Date: Mon, 03 Nov 1997 15:25:51 -0100
To: Don Lewis <Don . Lewis @ tsc . tdk . com>
Cc: firewalls @ GreatCircle . COM, hacking @ argo . es
References: <199710291014 . CAA27966 @ salsa . gv . tsc . tdk . com>
Reply-to: jcea @ argo . es

Don Lewis wrote:
> } * Linux: No backlog. No memory. When a Syn arrives, a hash is
> }   calculated to generate an unique ISN. The packet is replied using
> }   that value (cookie) and silenly dropped. If the original syn was
> }   faked, nothing is done. If the syn was real, the remote computer
> }   will send us an ACK with the correct values and conection is
> }   established. The ideal solution if faking hashes is difficult
> }   (cryptography rules, of course).
> 
> This is somewhat risky if you have listening sockets in the same
> port range that is used for outgoing connections and you are
> protecting the listening sockets with something like a Cisco
> "established" filter rule.  This type of filter protects listening
> connections by blocking any initial incoming SYN packets.  If an
> outsider is able to fake the hash, he can send an initial ACK packet
> which would look like the final packet in the three way connection
> handshake.  Because the inside host doesn't keep any state until the
> connection is established, it would be fooled into thinking it had
> gotten the initial SYN and sent the reply, so it would set up the
> connection.  The packet filter would not block the
> initial incoming packet, since it would have an ACK and not have a
> SYN, making the filter think the packet was a reply to an established
> outgoing connection.

Of course, all the security, in this scheme, came from the HASH. If the
hash isn't secure or isn't implemented with care, you are **doomed**. In
fact you can reseed the hash each five minutes, for example, if you are
paranoid enough.

> You should be safe with a stateful packet filter that doesn't open the
> path for incoming packets unless it has seen an outgoing SYN packet.

Yes, you are right. Only enable incoming packet if (apart from SYN
packets):

a) You send a SYN. So it's an outgoing connection.
b) You send a SYN+ACK. It's the second step in the handshake for
   an incomming connection.

Nevertheless, my idea was to implement the SYN cookie scheme at the
firewall, in order to protect the DMZ from external SYN flooding against
bad behaved hosts (read: Windows machines :) and to avoid sequence
number prediction. An interesting addition to SPF, don't it?

What do you think?

-- 
Jesus Cea Avion                         _/_/      _/_/_/        _/_/_/
jcea @
 argo .
 es http://www.argo.es/~jcea/ _/_/    _/_/  _/_/    _/_/  _/_/
                                      _/_/    _/_/          _/_/_/_/_/
PGP Key Available at KeyServ   _/_/  _/_/    _/_/          _/_/  _/_/
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz

Indexed By Date Previous: Re: Firewall-1 on Windows NT Platform
From: Rick Romkey <pokey @ maddie . atlantic . com>
Next: RE: PPTP configuration
From: "Stackpole, Bill" <BSTACKPO @ sla . com>
Indexed By Thread Previous: RE: [NTSEC] RE: PPTP configuration
From: Leonard Miyata <leonard @ geminisecure . com>
Next: RE: SCO how secure ?
From: G2 Security Division <AFZJ-I-S @ IRWIN . ARMY . MIL>

Google
 
Search Internet Search www.greatcircle.com