: Avoiding downtime after DOS and change of IP I have a small company designing, programing, and maintaining websites. I host my websites on a shared hosting plan (cpanel). I received an email
I have a small company designing, programing, and maintaining websites. I host my websites on a shared hosting plan (cpanel). I received an email 2 days ago that there was a DOS attack and the provider changed the IP address as a result. I then had to change the nameserver IP and wait for the DNS propagation. This almost took 2 -working- days during which my clients had no access to their emails or website. Also, the downtime will affect the websites in the short-term (ranking, etc.). So, I could only sit and wait not being able to do anything while my clients were furiously calling me (I don't blame them).
So my questions are:
Is it the proper response for the hosting company to change the IP when a DOS attack occurs? I switched from a company that used to shut down the servers in similar occasions (!)
What can I do to defend myself from this happening again. Although a small company, until now I had a stellar reputation. I don't want this to happen again.
Moving to a dedicated server will not change anything if their policy is to change IP at a DOS attack. Another option I found is the failover DNS which requires mirroring all the sites to a second server (double cost) and I haven't read the best things about this practice. Are there other alternatives?
More posts by @Candy875
2 Comments
Sorted by latest first Latest Oldest Best
Is it the proper response for the hosting company to change the IP when a DOS attack occurs? I switched from a company that used to shut down the servers in similar occasions
I can't see you gaining any advantage with an IP address change because 1, an IP address change causes your website to not be ready until the domain name TTL expires which may take several days. and 2, serious hackers will scan every single IP on the internet for systems that can become easy targets for attacks. Shutting down the server might be a better idea, depending on the attack.
What can I do to defend myself from this happening again. Although a small company, until now I had a stellar reputation. I don't want this to happen again.
Check your system resources and websites.
Make sure the web server software is running efficiently
Make sure your web server doesn't have a timeout setting that's too high, and make sure your scripts running on your server do not lag (for example, don't execute a script that contains an infinite loop).
In apache, there is only x number of open slots available to process scripts. Once all these slots are used up, then further connections to apache will have to wait until a slot is freed. Slots are freed the moment that either a timeout occurs or the moment the last byte of a result (HTML page or image or raw code, etc) is sent.
The value for x is important. If set too low, then guests could be waiting longer than usual for a page to be served, especially if one guest downloads a file several gigabytes in size. Remember, each resource requested uses one server slot. For a typical page, this means 3 slots could be used at once for roughly 200 milliseconds each. One slot for the HTML, one slot for the website icon (favicon.ico?) and one for an image in the page.
If x is set too high then the feeling of DOS may occur even more because then swap memory (memory from the slower storage space: the hard drive) will be required since the system will run out of actual RAM while trying to handle requests.
Maximize ports
There are only so many ports a server can have open at once.
Some servers out of the box are configured to open a very limited number of ports. Increase the range as much as possible without overlapping ports used by other system daemons. I have a server with WHM/cpanel, and I set my port range to 5000-65535.
Most Importantly
Pay attention to your scripts and watch your timimg.
When you make a page, go on webpagetest.org and run the URL through it. Choose the Native connection setting under connection speed and if the time to first byte is over 400ms from the farthest point away from your server and the remote device is not mobile, then you know you're in trouble.
Also, as I said, check all your scripts on your server. Make sure none of them run an endless loop or otherwise hog resources. Also, check server override files (such as .htaccess if you're using apache) for anything malicious.
Secure Everything
Finally, secure everything. Close ports (by dropping requests to it) that the world does not deserve. I closed off the MySQL port (just in case anyone wondered why their face went red when endlessly trying to access my MySQL server).
The only port all users should have access to is port 80, the web server port.
Only open other ports if necessary. And definitely close port 22 and 23 since hackers know those as the standard back-end shell access ports. In fact, if you need shell access, use a different port.
If it is a small/middle sized company with limited bandwidth (<1-10 Gbps) changing IP address pool is the best, cheaper and quicker option.
Only carriers, CDN providers or big companies can mitigate DoS attacks with other solutions (and the bandwidth is not a problem for them).
About DNS propagation, whois registers are the one that takes a very long time, DNS entries could be changed quickly and propagate as quick as their TTL expires.
This is a example about TTL cache:
redstar@nvidiastar:~$ dig +nocmd +noall +answer google.com www.google.com. 72 IN A 216.58.201.132
redstar@nvidiastar:~$ dig +nocmd +noall +answer google.com @216 .239.32.10 google.com. 300 IN A 74.125.206.147 google.com. 300 IN A 74.125.206.104 google.com. 300 IN A 74.125.206.103 google.com. 300 IN A 74.125.206.99 google.com. 300 IN A 74.125.206.106 google.com. 300 IN A 74.125.206.105
When I look for a DNS resolution my ISP DNS answer me a IP with a TTL of 72 seconds. To know what is the TTL you must to ask a DNS server for that domain (216.239.32.10 is one of them). In google the entries have 300 seconds TTL, so they can change their IPs and the propagation time is 5 minutes at most.
Using a backup DNS server in another network would solve the situation.
There is free secondary DNS providers that you can use. I user Twisted4Life for several years, but you can check BuddyNS too or search "free secondary dns" in any search engine.
And talking about free secondary DNS servers, you can use CloudFlare as free DNS server too as well as a CDN that caches (or not, you can disable that functionality) your static content.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.