Josh Brooks wrote: > Thank you for that advice - it is very well taken. > > Obviously, my goal is to mitigate as much as possible - I have accepted > that I cannot stop all DDoS - my question is, do serious people ever > attempt to do the mitigation/load shedding with a host-based firewall (in > this case fbsd+ipfw) ? Or would all serious people interested in > mitigating attacks use an appliance, like a netscreen ?
No one seriously mitigates with a host-based system. By the time the packet has gotten to the back-end host, it has to have already been mitigated. This is basically the same reason people use SSL accelerators, if they can find them: if you do both sets of processing (serving and SSL... or in your case, serving and firewalling) on the same host, then you detract from the ability of that host to handle the load that it needs to handle. It's no mistake that only the login to HotMail is SSL, and then only if you go out of your way to ask for it. Consider that an unaccelerated host can handle - maybe - 200 SSL connections per second, at 100% CPU load. In fact, most people use a load balancer to mitigate DDOS attacks; load banacers that proxy connections usually permit you to limit the number of simultaneous connections to the back end servers; you degrade gracefully to maximum load, and then you degrade no farther. FreeBSD is really not ideal for doing this type of thing, without custom code. The FreeBSD stack, by default, has a number of issues that make it perform poorly in this situation. The fixes are mostly simple, but for whatever reason, they never make it into FreeBSD proper (my theory is that the developement focus is heavily skewed to general purpose processing, rather than network processing). For the most part, Linux has the same problems FreeBSD does, or worse, with a few obscure exceptions (e.g. QLinux). The best place to stop an attack is your router... preferrably, on your NSP's side of the link, before the packets get into your pipe, since your pipe is smaller than your NSP's pipe. > I will say this - 9/10 attacks that hurt me do not do anything interesting > - in fact they are even low bandwidth (2-3 megabits/s) but they have a > packet/second rate that just eats up all my firewall cpu and no traffic > goes through - and as soon as the attack goes away the firewall is fine. FreeBSD 4.x can handle full Gigabit pipe packet rates, though a 1GHz CPU goes to near 100%. The real issue that bites you ends up being your bus bandwidth, not anything to do with the OS -- assuming you have tuned the OS correctly. The modifications for this are, I think, relatively minor and will be obvious if you have the necessary profiling capability. FreeBSD 5.x network performance is really poor, relative to 4.x; I do not recommend using FreeBSD 5.x in a production environment. If you insist on using it, make sure it's behind something else that isn't as limited (like a FreeBSD 4.x box) that has been properly configured to do load shedding (both stack mods and tuning; the best tuning yo can do, in most cases, is to turn off SYN cookie, and crank up maxfiles, preboot, tune up the number of ports that can be used, set the KVA to 3G and the UVA to 1G, and then add RAM). > So, I am looking at putting in more sophisticated traffic shaping > (limiting packets/s from each IP I have) and skipto rules to make the > ruleset more efficient ... but this is going to be a lot of work, and I > want to know if it is all just a waste because no matter how good I get at > a freebsd firewall, a netscreen 10 will always be better ? In your position, I'd buy a Cisco CSS. Jon Mini (hi, Jon!) might recommend an F5 box, since he works for them now. Actually, in your position, I'd demo a Cisco CSS, and see if it did what I wanted (protect itself, and, by count-limiting, protects your back-end boxes). A lot of these type of boxes are based on older versions of FreeBSD, plus modifications that they may or may not have tried to get back into the mainline source tree. Load shedding is different from Netscreen or other firewalls, in that it doesn't attempt to differentiate attacks from regular traffic. You can't do that, except in the grossest way, and a cookbook attacker will just switch software, if they find that their attack is no longer effective. If you can live with a low granularity classification system, or are OK with source IP limiting (which doesn't work against a well-distributed DDOS, since you'd only get one packet from each attacker), which is mostly just a way to screw people who are behind a NAT from having a large number of connections based on actually needing a large number of connections, then a Netscreen or similar product is OK (I guess). Bottom line is that you need to limit it before it gets to the local wire, especially if it's an amplification or reflection attack against an internal host, that uses your own resources against you (e.g. "ping of death"-type attacks); I have a hard time believing that you're vulnerable to one of those, though). The easiest answer, of course, is "don't make yourself a target in the first place", but I suppose you have business reasons for needing to run IRC and IRC bots... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
