
SYN Flood Mitigation with synsanity - alanfranzoni
http://githubengineering.com/syn-flood-mitigation-with-synsanity/
======
gue5t
tl;dr: They backported an existing kernel feature (per-cpu syn cookie
generation) to 3.x using iptables (rather than just maintaining a patchset)
because they didn't want to run a current kernel or maintain a fork.

------
DanBlake
I am curious how effective this is at larger synfloods. Obviously when
something hits near 1gbps, its game over for any server as that floods the
uplink (assuming a standard 1gbps hookup)

How many mb/s or pps can this handle on a average server while still having
the server be able to respond to legitimate requests? ( lets say a average
server is a quad core, 3.5ghz , 8gb ram)

~~~
NetStrikeForce
I believe nowadays DDoS defense has to be in depth:

\- Anycast to divide the attack among different datacenters

\- Multiple filtering devices with +10Gbps uplinks at the edge

\- Then things like SYNPROXY and this synsanity at the final servers

My point being: I don't think asking how effective is synsanity against larger
synfloods is a complete question.

~~~
jgrahamc
Agreed. For the large SYN floods (X Mpps hitting a single machine) syncookie
solutions don't work. What works is identifying the SYN flood itself and
filtering it.

~~~
scurvy
Generating SYN cookies in Linux doesn't work well at those rates without help.
That said, it's very possible. Solarflare cards are good at withstanding
several million PPS SYN floods...provided you license and then extend their IP
stack with the card.

Many hardware load balancers can do +100M SYN cookies per second (assuming a
proxy/gateway deployment instead of DSR).

So SYN cookie solutions do work; they just don't work great on stock Linux.

Edit: Add clarification about LB deployment. Won't work with DSR.

~~~
jgrahamc
_That said, it 's very possible. Solarflare cards are good at withstanding
several million PPS SYN floods...provided you license and then extend their IP
stack with the card._

Agreed. We use Solarflare cards but we don't syncookie when we get a large
flood. We identify the flood and drop it. There's little point firing back
millions of useless SYN ACKs per second.

~~~
scurvy
_Agreed. We use Solarflare cards but we don 't syncookie when we get a large
flood. We identify the flood and drop it. There's little point firing back
millions of useless SYN ACKs per second._

How do you know what to drop without SYN cookies? If the attacker isn't
advanced, sure all the SYN's will look the same. What if the attacker is smart
and the SYN's look legit and are spoofed? If you drop those SYN's, you'll run
the risk of also dropping legit traffic if you don't use cookies.

------
sargun
Why don't you guys just run the most modern stable Kernel as opposed to 3.X?

You say: While Linux 4.x has a patch to send SYN cookies under a per-CPU-core
socket lock, which does fix the problem, we wanted a solution that allowed us
to use an existing, maintained kernel with upstream security patches. We
didn’t want to roll and maintain an entire custom kernel and all related
future security patches just to mitigate this form of attack. Patching Linux
3.x to backport the socket lock change was also a similar maintenance burden
we wanted to avoid.

But, if this is the case, what's wrong with using Linux's LTS kernel, or the
stable current kernel? The kernel.org team does a great job maintaining these.
Which upstream vendor are you relying on?

Depending on your workload, and your kernel version, there are some fairly
large performance improvements. These performance improvements in my testing
primarily land in networking and I/O -- effecting many applications.

I think your work is awesome. I just think backporting, and not installing
linux-image-generic might be a lot work for not much benefit. I'd love to hear
your reasoning that leads you to believe that's a better option for security
or stability compared to using the trusty kernel.

Also, typo: `causese all` -> `causes all`.

~~~
theojulienne
Great question! A large portion of our infrastructure still runs on Ubuntu
Precise, and so the default "supported" options for the kernel on those
machines are 3.2 or 3.13. Once you're on newer releases you get 4.x support,
at the very least in backports, and at that point I would definitely agree the
upgrade is worthwhile.

~~~
sargun
Have you thought of pulling in the latest Ubuntu HWE?

------
peterwwillis
So instead of using a SYN attack, attackers can just run a full-open tcp
attack. Not as effective if all you have is one or two servers with big pipes,
but a botnet should make it feasible.

