TCP SYN Proxy

[David Powers]

I am implementing a firewall (hopefully in OpenBSD) for a group that has become gun shy of SYN flood attacks.  One of the questions asked was whether a "syn proxy" could be implemented on the firewall to handle initial connection setup without taxing the webserver behind it.  Some Googling indicates that some of the big proprietary firewalls implement syn proxies to some significant effect (http://www.usenix.org/events/sec01/invitedtalks/oliver.pdf) but nothing about whether it has been done on OpenBSD.  Has something like this been done, and if not, do people think it would be better implemented in pf somehow or as a standalone daemon?

 

-David Powers

[Bryan Irvine]

If I understand the question correctly (and I may not),
you want the firewall to be able to dynamically start blocking DDoS
attacks without human intervention right?
This can be done using snort and PF's tables/anchors.

I've never implemented it, but I've seen plenty of doc's on it.

--Bryan

[HKS...@aol.com]

Correct me if I'm wrong, but once the connection table fills
up, doesn't obsd randomly drop half-open connections?  I
thought this was implemented a while back, as an alternative
to the SYN cookies.

Adam Wenzel

[Daniel Hartmeier]

On Tue, Apr 29, 2003 at 04:34:12PM -0400, HKS...@aol.com wrote:

> Correct me if I'm wrong, but once the connection table fills
> up, doesn't obsd randomly drop half-open connections? I
> thought this was implemented a while back, as an alternative
> to the SYN cookies.

You're right, but this only protects the daemons (if any) running on the
firewall itself. The TCP/IP stack (either IP forwarding or bridging)
does not track TCP connections that are merely forwarded.

A generic TCP proxy running on the firewall will wait for incoming
connections, then open a second connection to the real server, then
forward data between those two connections. During a SYN flood, the
incoming TCP handshakes are not completed, and the proxy doesn't see
incomplete connections, and hence doesn't hammer the real server.

There are several TCP proxies, a very simple one can be implemented with
nc(1), see the FAQ section about NAT for an example. There are others in
ports. The right choice depends on how many concurrent, fully
established connections you expect to handle. If you need several
thousands, a forking model (like the simple nc example) will create as
many processes, while a single-process proxy might be better in that
case.

Another point is that the real server will see the firewall's address as
source for all proxied connections, which might be a drawback for
logging (or, hopefully not, application level access control :).

Even without a proxy, you can limit the number of states a pf rule can
create. If you limit the number of concurrent connections to the real
server like that, a SYN flood will quickly create this number of
entries. Further connections (including legitimate ones, not part of the
flood) will get dropped until existing state entries time out. If you
use aggressive (short) timeout values for state entries that are not
fully established, those will die very quickly, leaving legitimate
clients a chance to still connect.

The question is: how many concurrent connections can the real server
handle? And how many SYN packets can you receive per second?

Daniel

[David Powers]

I am looking for some dynamic blocking of DDoS, and I may use snort dynamic
blocking as well, but the SYN proxy seems to be a very simple little item
that seriously improves the ability of a server behind a firewall to avoid
DDoS meltdown. In this case it doesn't so much dynamically block as offload
the connection creation to the firewall until it *knows* that the connection
is good. Since the webserver is generally pairing of web daemons or doing
other heavy processing for each SYN this is much more efficient and allows
the combination to withstand a much larger SYN flood.

-David

[David Powers]

I believe that this is still true, but I am talking about serving as a firewall for a webserver sitting behind, so the connection table of the firewall would never fill up (since it is only passing along the SYN packets).

 

-David

----- Original Message -----

From: HKS...@aol.com

To: p...@benzedrine.cx

Sent: Tuesday, April 29, 2003 4:34 PM

Subject: Re: TCP SYN Proxy

[Dries Schellekens]

CERT has some information on how well PF can protect you against flooding
attacks:
http://www.kb.cert.org/vuls/id/539363
http://www.kb.cert.org/vuls/id/JPLA-5AVQAP

"Maximizing Firewall Availability - Techniques on Improving Resilience to
Session Table DoS Attacks" (available at
http://www.qorbit.net/documents/maximizing-firewall-availability.pdf)
list a lot counter measurements against flooding attacks.

At first sight, PF seems to implement a number of the described
counter-attacks:
- checksum validation
- INT flow timer optimization ("set timeout")
- session table expansion ("set limit states")
- session table limiting ("keep state (max ...)")
- rate limiting (more or less possible using ALTQ)
- aggressive aging (not 100% sure, but PF has "set optimization
aggressive")
- UDP/ICMP flood protection (using timeout and max number of states)
- END session rapid removal (not 100% sure about this)

Possible improvements (according to "Maximizing Firewall Availability"):
- It would be nice to have some dynamic timeout strategy: in case the
state table is almost full, fall back to more aggressive timeouts.
- a specific SYN flood protection mechanism: TCP proxy, SYN cookies or TCP
SYN Required (somewhat resembles SYN cache in FreeBSD and NetBSD).

So OpenBSD and PF don't have a SYN flood protection mechanism, like some
of the big proprietary firewalls.
FreeBSD has SYN cookies + SYN cache and NetBSD has SYN cache, but they
aren't using in their firewall.

Cheers,

Dries
--
Dries Schellekens
email: gwyl...@ulyssis.org

[Jason Dixon]

On Tue, 2003-04-29 at 18:05, David Powers wrote:
> I am looking for some dynamic blocking of DDoS, and I may use snort dynamic
> blocking as well, but the SYN proxy seems to be a very simple little item
> that seriously improves the ability of a server behind a firewall to avoid
> DDoS meltdown. In this case it doesn't so much dynamically block as offload
> the connection creation to the firewall until it *knows* that the connection
> is good. Since the webserver is generally pairing of web daemons or doing
> other heavy processing for each SYN this is much more efficient and allows
> the combination to withstand a much larger SYN flood.

Wouldn't Squid running in httpd_accel mode work well for this? While
troubleshooting my transparent proxy, I noticed that Squid completes the
full tcp handshake prior to initiating the connection with the target
server. Sounds like what you want.

-J.

> ----- Original Message -----
> From: "Bryan Irvine" <bryan....@kingcountyjournal.com>
> To: "David Powers" <da...@grayskies.net>
> Cc: <p...@benzedrine.cx>
> Sent: Tuesday, April 29, 2003 3:53 PM
> Subject: Re: TCP SYN Proxy
>
>
> > If I understand the question correctly (and I may not),
> > you want the firewall to be able to dynamically start blocking DDoS
> > attacks without human intervention right?
> > This can be done using snort and PF's tables/anchors.
> >
> > I've never implemented it, but I've seen plenty of doc's on it.
> >
> > --Bryan
> >
> > On Tue, 2003-04-29 at 12:20, David Powers wrote:
> > > I am implementing a firewall (hopefully in OpenBSD) for a group that
> > > has become gun shy of SYN flood attacks. One of the questions asked
> > > was whether a "syn proxy" could be implemented on the firewall to
> > > handle initial connection setup without taxing the webserver behind
> > > it. Some Googling indicates that some of the big proprietary
> > > firewalls implement syn proxies to some significant effect
> > > (http://www.usenix.org/events/sec01/invitedtalks/oliver.pdf) but
> > > nothing about whether it has been done on OpenBSD. Has something like
> > > this been done, and if not, do people think it would be better
> > > implemented in pf somehow or as a standalone daemon?
> > >
> > > -David Powers
> >
> >
> >
>
>

--
Jason Dixon
DixonGroup Consulting
http://www.dixongroup.net