![]() |
![]() |
|
04.05.10 How To Combat A DDoS Attack On Your Network By Dave TaylorIf you're reading this, odds are you are under attack. Your Web server is being crushed under the extraordinary load of thousands or even millions of bogus requests. How do you deal with it? Before we jump into that, a quick definition, courtesy of Wikipedia: A distributed denial of service attack (DDoS) occurs when multiple systems flood the bandwidth or resources of a targeted system, usually one or more web servers. These systems are compromised by attackers using a variety of methods, though most commonly it's due to malware or trojan attacks, either pre-scheduled or triggered by an external event. There are a number of ways to deal with a DDoS attack, but to find out best practices, I checked with a top sysadmin, who offered this advice based on a recent experience he had with a client site: As you may know, one of our ecommerce customers suffered a devastating DDoS attack which started early Friday morning and lasted until we finally contracted with a DDoS mitigation service late Saturday night. The service was implemented by pointing the "A" record for the domain to their server. The cost of the service was $350 per month plus $150 setup. The effects of the attack stopped instantly once DNS resolved to their IP. There are several of these companies around. All seem to have about the same price structure for the same services. I didn't do much research but choose the first one to respond on a Saturday. All likely had support available on the weekend but sales staff apparently get time off. Gathering the information on the attack has been somewhat difficult since during the attack our server was virtually shut down. In fact the only way we were able to get access to shell was to change the DNS to point to a different server then establish an ssh login and run "top" or something similar to keep it open when we switched it back. It is interesting to note that the attack followed DNS according to the TTL set. We had had it down to 10 seconds as we were in the process of moving the account from one server to another when the attack occurred. The attack followed the DNS within 10 seconds or less. There was very little residual attack activity after the DNS switched and that stopped within a minute or two. So here is what we think we encountered based on information from the colo support's anecdotal observations and information from the mitigation service after we blocked the attack. It is interesting to note that the mitigation service does not log activity so the information they provided is from spot observations rather than reliable metrics. 1. Incoming IPs were estimated at reaching as much as 100/sec. Each IP attempted to open between 5 to 25 connections 2. IPs were from all around the net but a sufficient number were from the US so that trying to isolate by country was useless (the customer was not regional but does business across the US). 3. At any one time the number of unique IPs was between three and four hundred. Since the software on the mitigation servers expires the IPs it blocks after 15 minutes and we did not see many instances of the same IPs recurring, the IP pool must have be in the thousands. Continue reading this article. About the Author: Dave Taylor is known as an expert on both business and technology issues. Holder of an MSEd and MBA, author of twenty books and founder of four startups, he also runs a marketing company and consults with firms seeking the best approach to working with weblogs and social networks. Dave is an award-winning speaker and frequent guest on radio and podcast programs. AskDaveTaylor.com http://www.intuitive.com/blog/ |

|
| ||
| --
NetworkNewzis an iEntry, Inc. publication -- iEntry, Inc. 2549 Richmond Rd. Lexington KY, 40509 2010 iEntry, Inc. All Rights Reserved Privacy Policy Legal archives | advertising info | news headlines | newsletters | comments/feedback | submit article |