Can a DDoS attack stop me from ssh'ing into my server?

My boss says no, therefore it must be something wrong with the server. However we are getting botted by 4-5 different bots even with robots.txt and .htaccess rewrites.

My PHP guy believes its the bots and I tend to agree but is it possible for an attack to prevent me from ssh into my server myself?

  • 6
    Absolutely but the real answer is 'it depends'. The server may be under too much load to respond timely, or the NIC you're connecting over could be saturated. Indeed, so could the backbone. What do you know about the effect this DDOS is having? – Dan Nov 7 '13 at 19:52
  • for about 5 weeks now a binbot yang and AhrefsBot/5.0 among others have hit us at various times daily slowing the site if not crippling it. They are ignoring the robots.txt and the htaccess is sending them to 403 however sometimes they even get past that. – Rick Nov 7 '13 at 19:58
  • 3
    Of course they are ignoring robots.txt and can get around .htaccess. These are bots that don’t care about polite conventions like a robots.txt. If this is an Apache server highly recommend installing mod_security to help prevent attacks. It requires some configuration muscle, but well worth it. – JakeGould Nov 7 '13 at 20:16
  • 1
    but if is is only a couple of IPS that are hitting you, just drop their traffic in iptables on the floor. don't even bother handing it to apache/php way less resources intensive. – Doon Nov 7 '13 at 20:16
  • 1
    Doon, makes sense but the problem with hunting & pecking individual IPs is that nowadays it is very rare that one single IP will be the source of your traffic. It's more likely a botnet with IPs from all over will swarm a server to attack. – JakeGould Nov 7 '13 at 21:54

Absolutely yes, because a DDoS attack is designed to overwhelm server resources. Meaning your load average shoots up & your memory is maxed to the point of swapping out to disk. And it does not have to be just an attack on port 22. I have managed tons of web servers that become unreachable due to the scenario I describe above.

The best solution to an issue like that is to login via a remote console that is closer to the machine than via SSH. Like on cloud server setups where you have an option of launching a Java-based terminal. But that—of course—is based on you having access like that.

The other alternative is to painfully wait for the SSH connection to happen while your server is being DDoS'ed. Sometimes it works. But sometimes I have to open up a handful of windows and see which one gets through first.

EDIT: And if you want to proactively detect if your system is using up resources, I highly recommend using Monit. I use a script like this in Monit which does two things in addition to e-mailing me when something happens. One it detects if your web server is unreachale (aka: down) and automatically restarts it. But for you perhaps the loadavg area makes the most sense. I have it set to 7 here & it attempts to restart the server to flush out connections & attempt to get it back in control if the load average is consistently at 7 or above. Doing things like using Monit pretty much assures you have a better grip on a DDoS when it happens.

check process apache with pidfile /var/run/apache2.pid
        start "/etc/init.d/apache2 start"
        stop  "/etc/init.d/apache2 stop"
        if failed host port 80
                with timeout 15 seconds
        then restart
        if loadavg (1min) greater than 7
                for 5 cycles
        then restart
        alert username@myserver.com only on { timeout, nonexist, resource }

Yes, but there are also other causes.

I'm assuming that you've ruled out iowait first, so my next suggestion would be to do a packet capture of your DNS traffic and make sure that reverse DNS lookups are functioning correctly. In extreme scenarios, it's possible for DNS failures to cause the login process to time out even if authentication would succeed. (of course, if UseDNS no is set in sshd_config, this is completely moot)

As the others have emphasized in comments, it's important that you provide us with your research for why you think a DDoS is responsible for your lockout. There could be many potential causes for this issue, so it's important to not jump to any one conclusion.


From someone who has been on the receiving end of DDOS attacks and has worked in the hosting industry and has null routed victim IPs, yes a DDOS can bring down the entire server and any services that it provides as well as a poorly designed network and all servers on that network.

It is true that bots can also bring down the server; which is why you'll want to setup a good robots.txt with a crawl-delay to reduce how often bots crawl the site (some bots ignore the crawl-delay and just have to be blocked; Baidu for example ignores the crawl-delay eventhough it says that they do not ignore it on their site).

You can block malicious bots with RewriteRules within a .htaccess file. An example of blocking Baidu is below:

RewriteCond %{HTTP_USER_AGENT} Baiduspider/2\.0
RewriteRule ^.* - [R=404,L]

Yes, but if and only if the attacker is attacking your SSH port (by default 22) which would overload connections to that port and disallow any SSH connections until the attack stops.

  • 7
    Well, when a DDOS attack runs a machine out of system resources then it's not necessarily limited to a specific attack on the SSH port. – squillman Nov 7 '13 at 20:38
  • @user1832696 there are MANY attack vectors I can think of that do not involve directly attacking the "SSH port" -- TCP connection exhaustion (launched against ANY TCP service on the machine) is one ; the classic bandwidth saturation attack is another (you might eventually get in, but if it takes an hour to type a single character the session isn't useful) ; a fork or memory bomb is a third (if sshd can't spawn a child to handle the connection you can't log in). The list goes on, and these are attack vectors you should not be disregarding as a professional... – voretaq7 Nov 7 '13 at 23:32

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.