SYN floods - possible solution? (fwd)

With source, and reasonable knowledge of the kernel, this would be easy
enough to do on any unix. Avi's already explained what needs to be done,
and you don't need a special box.

But to protect other machines, you'd have to put a filter machine in front
of them. This sounds like a workable solution to me, for those who can cope
with the technical or financial demands (which *might* not be so high).

There's no protocol issue to prevent this. You can tag held SYNs any way
you like; you're not limited to using parts of the packet. But even if
you did, it would still be fine.

If your attacker were on a T1, and *if* his router and your can handle the
packet-forwarding load, you could see perhaps 4000 pps theoretical max.
In real life I'd be surprised to see half that many, and that would be a
*real* flood. 30sec. timeout means 60k slots in a hash table of SYNs, each
taking up 12 bytes for the data. Your total memory used is maybe 1MB if you
figure the hash just right. You might also do better if you used a tree
keyed on the source IP. For free, you can protect any number of hosts, not
just one.

But... I still don't believe that this is a good global solution. Most ISPs
can't cope with this. The clue level I've been seeing among many of the
ISP "engineers" and "systems administrators" who have called in the last
few days to ask for help ("is your problem happening to me too???") is
astonishingly low. :frowning:

I also have no clue what I'd choose to implement this on. It *could* be
done in a unix kernel but that's probably a really *bad* choice. I'm sure
plenty of people out there know some good possibilities, though.

/a

Michael Dillon writes:

But... I still don't believe that this is a good global solution. Most ISPs
can't cope with this. The clue level I've been seeing among many of the
ISP "engineers" and "systems administrators" who have called in the last
few days to ask for help ("is your problem happening to me too???") is
astonishingly low. :frowning:

Tell me about it. But if this kind of solution could be packaged up in a
single box with two ethernet interfaces then a lot of less clueful ISP's
could easily install such a thing and protect their whole network. If the
box also provided default filters on source addresses that could help
solve another problem as well. The fear of attack may well be the force
which overcomes inertia here and gets more ISP's up to speed on these
issues just like AIDS brought the issues of safe sex to the forefront.

I also have no clue what I'd choose to implement this on. It *could* be
done in a unix kernel but that's probably a really *bad* choice. I'm sure
plenty of people out there know some good possibilities, though.

Well, the advantage to using something like FreeBSD is that it is freely
available, well-documented, and eleigible for creating commercial products
as long as you check copyrights carefully. Most parts of FreeBSD have no
commercial use restrictions like GNU does.

And FreeBSD already has the basic functionality in it including support
for readily available hardware including 10baseT and 100baseTx and FDDI
interfaces. Building this kind of box would be mostly an excercise in
subtraction and it may well be possible to strip enough stuff out that it
can all be booted off a 1.44 megabyte diskette into a diskless 486 or
Pentium box with a RAMdisk.

At that point all an ISP needs to do is download a file, a disk writing
utility (RAWRITE.EXE) and assemble a box with certain standard components
like their choice of 3 types of network card as mentioned above. If the
box included ssh for the admin interface maybe it could create a precedent
for router manufacturers?

NOTE: I copied this one to freebsd-hackers

Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com