1

Suppose I have a website and I want to make sure that a hacker isn't making my server down by utilising a DDOS attack on my website. I thought of getting IP address and revoking the access, but it seems cumbersome to implement.

Should I be worried about this? Or should I just leave it without any protection against it.

5
  • You are correct. I didn't have accurate vocabulary to describe my scenario. Its DoS. I am updating my question
    – Rockink
    Commented Aug 27, 2015 at 2:26
  • In this case, blocking by IP is the typical way to do this.
    – schroeder
    Commented Aug 27, 2015 at 2:35
  • Not only blocking IPs but if they're DDoSing via something that uses a handshake you can respond by forcing their connections to hang open. Much more expensive for the DDoSer Commented Aug 27, 2015 at 7:45
  • the kind of DoS is still not very clear
    – JOW
    Commented Aug 27, 2015 at 9:09
  • Unless you are a big company, use fail2ban.
    – sebix
    Commented Aug 29, 2015 at 10:00

3 Answers 3

5

If you're interested in understanding methods of protection on a more technical level, there are plenty of articles detailing more in depth strategies to protect yourself from a DDOS attack, such as this one from Cisco: http://www.cisco.com/c/en/us/support/docs/security-vpn/kerberos/13634-newsflash.html

That being said, you may have noticed that even some of the largest service in the world are still affected by massive scale DDOS attacks (Telegram this year, Reddit several times over the past few years). There really is no silver bullet for these kinds of things, although some strategies can include:

  • Detecting an blocking IP address ranges while the attack is in progress, as schroeder pointed out

  • Do a packet trace / capture on traffic you believe to be from a few of the offending hosts, and try to find some unique attribute you can use to block the request (i.e. similar user agents, HTTP header data)

  • Use a service like Cloudflare or Akamai as a CDN - often these services have some degree of DDOS protection built into even their free plans.

2

If you care about DDOS attacks blocking by IP address will probably not help much, because DDOS means Distributed Denial Of Service and thus is typically caused by a large number of hosts, usually some botnet. In this case there are not only lots of sources for the attack but they also often change over time, so simply blocking by source IP address does not help much and probably has also unwanted side effects like keeping out non-malicious users.

There are several kind of DOS and DDOS attacks, depending on the level where they work: The classical attacks works only at the transport level and simply consume a lot of bandwidth, thus making your site hard to reach. Often these can be filtered inside a upstream firewall just based on typical traffic pattern, like the size of the request or even the source IP address. Also CDN like Cloudflare can help in this case because they simply have larger bandwidth available and a more agile team to early detect and deter attacks. Other attacks work against the server or specifically against the application and cause the server to overload with sometimes only few requests. These kind of attacks are harder to defend. Sometimes a web application firewall (WAF) will be able to filter out such malicious HTTP requests but not always.

There is a lot of diversity in the attacks which makes it impossible to have one single solution to protect against all of these. Some examples:

  • With special tools like the low orbit ion cannon one can eat lots of bandwidth to mount a (D)DOS attack.
  • Web browsers could be instrumented for an attack like done against github. Also famous is the Slashdot effect where you can cause (inadvertently) a DOS by simply publishing a URL on some famous news site so that lots of users try to visit it.
  • By using CPU intensive tasks like the TLS handshake for https sites you can create lots of load on the server from only a few clients.
  • Some attacks are tailored specifically against some web applications, web frameworks or bugs in the web server and use complexity attacks like ReDOS or a vulnerability when parsing the range header to create a larger server load with even fewer requests.

And these are just some examples and none of these attacks requires more than a (maybe tailored) GET method and sometimes not even this. They should show you that no single protection solutions exist. Using CDN or providers specialized in DOS protection will definitely help, but they will not be able to fight all attacks. Thus if you are trying to build a business based on your web site you should be aware of the risk and plan accordingly.

0
1

As has already been said, blocking IP's will not work. DDoS attacks are very hard and sometimes impossible to protect against.

I would recommend using a service like CloudFlare. The DDoSers themselves use it to protect themselves from their fellow DDoSers. It has a free tier and a paid tier. If what you are protecting is low scale (i.e, smaller than a large enterprise) the free tier should suffice.

CloudFlare is designed to accelerate and secure any website. Our system works somewhat like a Content Delivery Network (CDN), but is designed to be much easier to setup and configure.

To explain how the system works, imagine you have a website (allen.com) and it's running a web server with the IP address of 1.1.1.1. Before CloudFlare, if someone typed your website's domain (allen.com) into their browser, the first thing that visitor's computer would do is send a query to the DNS system and get back your web server's IP address (1.1.1.1).

In order to make CloudFlare easy to set up, we take advantage of how this basic function of the Internet works. Rather than having you add hardware, install software, or change your code, we have you designate two CloudFlare nameservers as the authoritative nameservers for your domain (e.g., bob.ns.cloudflare.com and sara.ns.cloudflare.com). You make this change with the registrar from which you bought your domain (e.g., GoDaddy, Network Solutions, Register.com, etc.).

Designating CloudFlare as your authoritative nameservers doesn't change anything about your website. Your registrar remains your registrar, your hosting provider remains your hosting provider, and so on. However, because we are your authoritative nameserver, we can begin cleaning and accelerating your web traffic.

To make this happen we use a network routing technology called Anycast (and some other fancy tricks) to route initial DNS lookups for your domain to a CloudFlare data center closest to the visitor. We have data centers around the world and we’re growing every month. The data center that receives the request returns an answer in the form of an IP address (e.g., 99.99.99.99), which directs all the visitor's subsequent requests to the best data center for them.

After a visitor's browser has done the initial DNS lookup, it begins making requests to retrieve the actual content of a website. These requests are directed to the IP address that was returned from the DNS lookup. Before CloudFlare, that would have been 1.1.1.1, with CloudFlare as the authoritative nameserver that would be 99.99.99.99 (or some other address depending on what CloudFlare data center is closest to the user). CloudFlare's edge servers running on that IP address receive the request and perform analysis on it. We scan to see if the visitor appears to be a threat based a number of characteristics including the visitor's IP address, what resource they are requesting, what payload they are posting, how frequently they're making requests, etc.

To speed up the response time for a request that goes to a one of our frontline servers, CloudFlare caches parts of websites that are static in these servers. For example, we cache things like images, CSS, and JavaScript. We are very conservative with our caching because we never want to mess up dynamic content. So, for example, as a general rule we do not cache HTML. We also refresh the cache relatively frequently, so files are never more than a few hours old. Even being conservative, however, typically 50% of the resources on any given web page are cacheable.

Assuming the visitor is not a threat, the frontline checks the request against the Cached resources on our front line servers to see if the resource being requested is in CloudFlare’s local cache. If we have a local copy of the file being requested, then we can deliver it directly to the visitor from a local data center greatly increasing request response time.

If the request is for a type of resource we don't cache, or if we don't have a current copy in our cache, then we make a request from our data center (99.99.99.99) back to your origin server (1.1.1.1). Because of our scale, we can get premium routes from our data centers back to most places on the Internet. As a result, while it may seem counter-intuitive, it is sometimes the case that the number of "hops" a visitor’s request makes going through the CloudFlare network is less than the number of "hops" that they would have made going to the origin web server directly, even when we aren't able to return a result from our cache.

The combination of these systems means that we can protect sites from malicious visitors by stopping them before they even get to the origin web server, save over 60% of the bandwidth that a site would otherwise have to pay for, save over 65% of the requests that would otherwise have to be handled by a site, and cut in half average page load times. In order to make performance even better, we also do web content optimization.

CloudFlair

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .