3

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?

Giacomo1968
  • 3,542
  • 27
  • 38
Rick
  • 159
  • 1
  • 2
  • 7
  • 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 07 '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 07 '13 at 19:58
  • fill the pipe ether direction, peg the cpu, overflow firewall state table, there are tons of ways the DDOS can stop access to any port on a server. That is mostly the point of them. We've had a box or 2 get spider'd really hard by bots, that ignored everything.. Only way to stop them was to drop their traffic in the firewall (they were not Distributed). If the attack is truly distributed there isn't much you can do with robots.txt or rewrites (depends upon what type of attack it is) – Doon Nov 07 '13 at 20:13
  • 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. – Giacomo1968 Nov 07 '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 07 '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. – Giacomo1968 Nov 07 '13 at 21:54
  • @JakeGould Can you quantify what you mean by "getting botted"? Are we talking a hundred connection attempts per second, or a hundred thousand? Are you reaching bandwidth saturation on your connection, or do you suspect the problem is resource exhaustion on the server? The answer to your question as you posted it is "Yes, it is possible." - a *useful* answer that helps you figure out a way to mitigate the problem requires substantially more detail from you. – voretaq7 Nov 07 '13 at 23:35
  • @voretaq7 I am not the one who used the phrase, “getting botted.” That was what the origin poster said. In my experience, bandwidth saturation has very little to do with a DDoS attack on a PHP based website. In fact I have never experienced a server outage where the bandwidth saturates while the server itself is fine. As long as the server has to do work to generate content, the server will go down before bandwidth is saturated. – Giacomo1968 Nov 08 '13 at 00:17
  • @JakeGould That wasn't supposed to be a reply, but in answer to your comments I've seen outages where the pipe is saturated before the server falls over. It's especially common with cheap hosting packages that provide capped (non-burstable) bandwidth. Not every client is entitled to chew up their host's entire pipe :) – voretaq7 Nov 08 '13 at 16:51
  • Gotcha! Thankfully I don’t deal with servers like that, but good to know. – Giacomo1968 Nov 08 '13 at 16:52

4 Answers4

13

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 127.0.0.1 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 }
Giacomo1968
  • 3,542
  • 27
  • 38
0

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.

Community
  • 1
Andrew B
  • 32,588
  • 12
  • 93
  • 131
0

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]
-7

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.

user1832696
  • 1
  • 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 07 '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 07 '13 at 23:32