4 ms·
1. You're wrong, see rfc793. TCP flow control acknowledges streamed bytes, not packets. 2. I just tell you what works in real life. Blocking 500 supernodes (ou
by jsn 17y ago
1. You're wrong, see rfc793. TCP flow control acknowledges streamed bytes, not packets.
2. I just tell you what works in real life. Blocking 500 supernodes (out of 5000 machines botnet) is basically a non-issue for linux iptables on usual modern processes. Other 4500 are usually pretty tame in terms of firewall processing power.
3. You didn't propose that, it's what we do (and what works best for these attacks). Its rate of false positives is sufficiently low. Folks behind NATs don't use sustained 4 connections per user, so it's usually a non-issue either.
4. Well, you're wrong if you don't think so. Mitigating DDOS-es is one of the things i do for living [i'm in charge of web infrastructure of certain political opposition websites in Russia, if it rings any bells]. The scenarios i described is what actually happens.
- rbanffy 17y agoInteresting. Acknowledging receival on two layers (packets and butes) makes little sense. Wonder why such decision was made. About 4, are the DDoS aimed at your servers or at your office infrastructure?
- jsn 17y agoThey don't acknowledge packets, just bytes. It's pretty reasonable for a reliable streaming protocol. Their DDOS attacks target our servers. For example, Russia has some issues with Estonia, opposition sites post some independent statements and news on that. Then comes DDOS.
- rbanffy 17y agoStill, the overhead is large if it employs single byte confirmations. It turns symmetrical what could be an asymmetrical communication.
- jsn 17y agoSorry, wrong again. Stream byte acks are way more effective than packet ones. Tcp endpoint can receive several packets of data and then send just one very small ack packet (you only have to send the byte stream position after the last received packet). I'm not sure what you mean by "asymmetrical", but that's probably as asymmetrical as it gets. It's called "delayed ack" or something. Iirc, it's all described in rfc793.
- rbanffy 17y agoWhat would be then the ideal way to fix Apache?
- Locke1689 17y agoApache doesn't need "fixing" - this is the job of a firewall or IDS or some other such anti-DDoS software. That doesn't mean they couldn't incorporate some protocol patch or use asynchronous I/O or some other crap, but the reliance shouldn't be on Apache to block this. If you're running a website important enough to DDoS, you should have a heavy duty firewall and IDS and possibly reverse proxy in place as well.