Security → Re: XOR.DDoS malware distributed via brute force SSH attacks

 
There are some OpenSSH server config values that can be helpful when faced with brute force atatcks:

LoginGraceTime - The server disconnects after this time if the user has not successfully logged in. If the value is 0, there is no time limit. The default is 120 seconds.

MaxAuthTries - Specifies the maximum number of authentication attempts permitted per connection. Once the number of failures reaches half this value, additional failures are logged. The default is 6.

MaxSessions - Specifies the maximum number of open sessions permitted per network connection. The default is 10.

MaxStartups - Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10:30:100. Alternatively, random early drop can be enabled by specifying the three colon separated values “start:rate:full” (e.g. "10:30:60"). sshd(8) will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (60).

 

Additionally, I use the firewall to block out non-ARIN IP addresses from even accessing the ssh port of my servers.

One last item I forgot to mention: move the port that the ssh server listens on to something besides 22. After I moved ssh to a different port, the rate of ssh probes dropped to less than 1% of what they had been. The firewall block mentioned previously removed that last 1%.

Add a dash of a few IPtables rules there and you've got yourself a winner.

 
I use pf, not iptables.

But to your point, I do have firewall rules to restrict who has access to the ssh port. I only mentioned the more generic "block out non-ARIN IP addresses" rule because others may have differing firewall requirements.

One of my IPtables uses is to rate-limit requests to all my SSH daemons by x amount per specified time, run afoul & block all communications to IP indefinitely.

Yep, have pf running on my BSD boxes, much easier to configure and debug than pure IPtables.

 
Good point.

I tend to rate-limit all the open ports on my servers by default, so I didn't think to mention it.

 

For completeness in this thread, here is the place where I obtain the ARIN IP addresses to whitelist.
»www.iana.org/assignments ··· ce.xhtml

That's a URL for IPv4 addresses, as I have my ssh servers listening on IPv4 only at this point. That may change in the [near] future as IPv6 becomes more prominent.

Glad you mentioned this, port reallocation has merit particularly when facing automated default scanning attacks. Many security professionals consider port reallocation to be security through obscurity. The obscureness is just enough to throw out 90+% of generic attack traffic just like you stated.

So for all you security fledglings out there listening to security professionals/instructors jabbering that security through obscurity is a waste of time smile politely and say, "Thank you, may I have another?"

 
I look at it more as getting out of the line of fire.

Having said that, security through obscurity does have its benefits, providing, and that is a big PROVIDING, it is not your only layer of security.

I used to get SSH brute force attempts against my old linux box regularly.

I moved the port and the attacks pretty much stopped.

Since the bash vuln though, I only have key auth enabled.

 
I solved the bash vuln issue differently.

I just stopped installing bash, and removed it from the servers where I had installed it.

Yeah, that works too but some ISP like to block the non-standard ports like my former employer which is annoying.

 
Short-sighted.

If they are blocking you from increasing the security level of your system, do they also take financial responsibility for the ramifications of their decision?