The bandwidth isn't the main problem with this kind of attack. What the attackers are doing (correct me if I'm wrong) is flooding BHB's servers with bogus requests. The server itself has to deal with the requests. If the attackers are making 1,000 requests per second, and each one is only 64 bytes in size, that's a little under 100 KiloBytes of traffic (counting the "wrappers"), or about 800 kilobits, about the speed of a good cable modem or DSL line. Of course, BHB would have much more bandwidth than that. But if the server can only handle 300 requests per second, then it lags and can't process legitimate requests. Dumbed down: the attackers are targetting the machine itself, not the line to or from it. It effectively shuts the site down because the server (and/or software) isn't fast enough to handle all the requests.
The usual solution is to get or configure a router to not allow the packets to reach the server. As long as there's sufficient bandwidth to and from the site, the router simply filters (blocks) all of the bogus packets, so the server doesn't have to deal with them. Another possibility is to have the host provider (the last "hop" before the attack reaches BHB) filter the attack the same basic way. If they can't, they can go to their uplink (the core router) and have it filtered there.
If the attack involves a lot of bandwidth (as some do), then the host can go to their uplink (usually a core router, which would have a ton of bandwidth) and have it filter the packets. It's like a stream of water and a glass, a bathtub, and a storm drain. If the glass (BHB) can't handle the water stream, then they divert it to the bathtub (their host provider) which has more capacity for it. If the bathtub can't handle the water stream, then it's diverted to a storm drain (the host's uplink---the core router), which has much more capacity than the first two..
Hopefully that isn't too confusing.
[This message was edited by The Old Ballgame on December 03, 2003 at 04:04 AM.]
