SYN City

"Turn the right flag in SYN City, and you can crash anything..."

There's a nasty little denial of service technique out there called SYN flooding, which exploits a fundamental process of establishing a TCP/IP connection.

Here's how it works:

1. Send a SYN packet to a target server.
2. The target server will reply with a SYN+ACK packet.
3. You are, at this point, supposed to reply with an ACK packet to ensure both hosts can reach each other. Instead, ignore sending the ACK. Better still, spoof the source IP address so the target server sends its SYN+ACK off into the ether and you never have to deal with it.
4. The target server, in order to maintain connectivity during periods of high congestion or latency, will wait for an ACK response that it will never receive.
5. Repeat this process a few hundred thousand times.

SYN flooding is the Internet equivalent of ringing someone's doorbell and then running away, and there are steps to avoid it. Linux and FreeBSD support SYN cookies, which is simply a method of constructing a SYN+ACK packet in such a way that a server doesn't have to wait for an ACK to complete the connection. Instead, it encodes secret values into its SYN+ACK packets, then simply studies the ACKs it receives to see if they match any recent SYN+ACK packets that the server may have sent.

SYN+ACK cookies are nice for Linux and FreeBSD, but what about OpenBSD? OpenBSD does things just a little differently: it uses SYN proxying, a feature of the PF packet filter since version 3.4. SYN proxying is a slightly different solution to the problem. Instead of running a webserver with an OS that supports SYN cookies, you can run a webserver of any variety and protect it from SYN floods on the OpenBSD firewall you've placed in front of it.

Your OpenBSD firewall will be configured with the "synproxy" flag, which ensures that only fully completed connections that have responded with an ACK will be passed through it to that webserver:

pass in on $ext_if proto tcp from any to $www_server port 80 \
flags S/SA synproxy state

Caveat: SYN proxies don't work on bridges for obvious reasons.