Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

How can a Linux server be protected against an attacker that tries to open a large number of SSH sessions (probably trying to brute force a password) that no ports remain to be able to legitimately login to the machine?

The server already uses only SSH key based access and does not allow root logins, so the password brute forcing is not a concern.

share|improve this question
    
Run SSH over another port such as 1010 - this will reduce a significant majority of SSH attacks. –  bolty187 Apr 10 at 16:10
1  
Studies show @Simon's comment is accurate 63.7% of the time. Or in other words, no you're really wrong. Not just wrong, but terribly-horribly-way-out-in-left-field wrong. This is dangerous thinking wrong. :) –  Steve Apr 10 at 21:33
    
Duly noted, I guess I deserved that. –  bolty187 Apr 11 at 10:26
    
The only attack that running on a different port protects against is filling up the log partition with denied login requests for admin:admin. –  Gilles Apr 11 at 11:14
    
You are correct in that it won't prevent SSH attacks, however given that the vast majority of SSH attacks are aimed solely at port 22, this will reduce the amount of SSH attacks greatly. –  bolty187 Apr 11 at 11:21

1 Answer 1

up vote 7 down vote accepted

One usually evoked solution is Fail2Ban: this is a system which uses the firewall rules (iptables) to block incoming connections from IP addresses from which some kind of exhaustive search attack is apparently in progress.

This, of course, won't work with a distributed DoS, coming from thousands of distinct IP addresses. In general, very few things resist a distributed DoS.

Fail2Ban can also be problematic in case of large-scale NAT: it has potential for locking out a whole network of normal users who just happen to share the same IP address, as seen from the outside.

It is highly recommended, when you begin to configure tools such as Fail2Ban, to also run another SSH server on another port, not covered by the Fail2Ban rules, just to allow re-entry in case a bad configuration locks you out.


Another completely different strategy is to keep a connection open at all times. E.g. you have a long-standing SSH between your server and your own desktop system; you may even multiplex other connections on it (with SSH abilities for tunnels, and/or SOCKS proxying). This avoids the allocation problem: you don't need to get a free port for your root connection since you already have one.

share|improve this answer
3  
You could also setup port knocking or single packet authorization before allowing an SSH connection. It vastly depends on how much control you have over the client, though. (See thoughtcrime.org/software/knockknock) –  Stephane Apr 10 at 15:04
    
(I wonder if I should point out that the bear didn't mention syn cokies?) –  symcbean Apr 10 at 23:00
    
SYN cookies would not help here. SYN cookies are for IP spoofing situations, where the attacker sends a SYN but never completes a TCP handshake. Here, the attackers do full TCP connections, with their true IP addresses, so SYN cookies would not help at all. –  Thomas Pornin Apr 11 at 1:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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