That would be a 130,000 * 64 bytes ~= 63 mbit/s SYN flood. I don't have a 100 mbit/s Internet connection, so I don't have any experience in this order of magnitude. Maybe someone else does.
Just in case someone or worm using it in LAN to DoS gateway or victim in Internet. ;) I assume that if you can afford that kind of link,
you're above amateur budget for firewall hardware, too (i.e. split the traffic across multiple firewalls, based on source address, in a stateless first step).
That's great! Sounds like a load balance firewall system. Does anybody success in this?
> So is it possible to drop every first SYN packet and ask sender to > resend it just like spamd has done? How do you know which SYN is a first one and which is a second one? You'd have to remember the first ones for a little while, which means allocating memory per connection attempt.
Could synproxy using TCP sequence number or another flag as index and not create state to save memory resource? Just silly thoughts.
Then I modify the DoS tool to simply send each SYN packet twice, and you're screwed again, no?
We defend script-kids not top hacker. :) It would be great to has a parameter to turn this feature on or off.
The mechanism must work even when the attacker knows its details. I think SYN cookies[1] would be stateless, but I don't know how they hold up against 130k pps. And they have their own drawbacks (I think non-randomness of sequence numbers isn't even mentioned). > It ls worth to add some anti-DoS measure in pf now. Glad to hear that. You're welcome to do so.
Thank you! I could contribute this DoS tool for study purpose if anyone has interesting in anti-DoS research. Regards, Frank
