3 ms·

This works fine when there are tens or even a few hundred source IPs. However, malicious DDoS attacks are often orchestrated using zombie machines (maybe your p

by mpk 18y ago

This works fine when there are tens or even a few hundred source IPs. However, malicious DDoS attacks are often orchestrated using zombie machines (maybe your parent's unpatched Windows box, for example). This way the perpetrators remain out of reach and you end up swamped with thousands upon thousands of source IPs, none (or few) of which share a net block. This is really not a problem you can solve down at the firewall-before-webserver level.

lsc 18y ago
the response to my post was saying I was wrong (and is right in saying I was wrong) because the attacker is spoofing the source address. This makes it a harder problem to solve than zombied PCs (the case of zombied PCs sending unwanted traffic can be blocked by a firewall or other means, you just need an automated method of identifying the boxes you want to block.)
- disambiguated 18y ago
  Firewalls aren't DDoS mitigation devices, they're staeful policy-enforcement devices. DDoS attacks are attacks against capacity and/or state - firewalls must be protected from DDoS just like hosts (even more so, in fact). Implement iACLs, uRPF, and S/RTBH at your edges, and work with your SP on a reaponse plan. And take your server out from behind the firewall. Stateful inspection makes no sense at all on a front-end server, where every connection is by definition unsolicited. Harden the OS, harden the apps/services, run a chrooted jail, use tcpwrappers and mod_security and mod_evasive, and use stateless ACLs in an ASIC-based router to enforce access policies. By placing the server behind the firewall, you increase its vulnerability due to the potential for exhaustion of the connection table by an attacker. You can use firewalls between the tiers of a multi-tier setup, where you can control the number and types of inbound connections on a bidirectional basis, but no one who operates high-volume publicly-accessible servers puts the the front-end behind a firewall, because it does nothing to increase the security posture, and can actually be harmful.

by mpk 18y ago

lsc 18y ago

the response to my post was saying I was wrong (and is right in saying I was wrong) because the attacker is spoofing the source address. This makes it a harder problem to solve than zombied PCs (the case of zombied PCs sending unwanted traffic can be blocked by a firewall or other means, you just need an automated method of identifying the boxes you want to block.)

disambiguated 18y ago
Firewalls aren't DDoS mitigation devices, they're staeful policy-enforcement devices. DDoS attacks are attacks against capacity and/or state - firewalls must be protected from DDoS just like hosts (even more so, in fact). Implement iACLs, uRPF, and S/RTBH at your edges, and work with your SP on a reaponse plan. And take your server out from behind the firewall. Stateful inspection makes no sense at all on a front-end server, where every connection is by definition unsolicited. Harden the OS, harden the apps/services, run a chrooted jail, use tcpwrappers and mod_security and mod_evasive, and use stateless ACLs in an ASIC-based router to enforce access policies. By placing the server behind the firewall, you increase its vulnerability due to the potential for exhaustion of the connection table by an attacker. You can use firewalls between the tiers of a multi-tier setup, where you can control the number and types of inbound connections on a bidirectional basis, but no one who operates high-volume publicly-accessible servers puts the the front-end behind a firewall, because it does nothing to increase the security posture, and can actually be harmful.