4

Vulnerabilities are discovered everyday. The recent Heart bleed attack caught many people off guard. I was wondering if a serious flaw was to be discovered that allows unfettered access to SSH, how should I defend myself and minimize my exposure to such an attack in order to have sufficient time to patch the server?

5

Setup a port knock daemon which opens the firewall for some time when specific ports are "touched" in some specific order. See for more information Port knocking

| improve this answer | |
1

Setup IP filters on your firewall or server, so that SSH connections are only accepted from a specific static IP. That will at least force an attacker to compromise your client or your network infrastructure, before they can use a 0-day attack against your SSH server.

| improve this answer | |
  • I have thought about that too, but it doesn't work for my case as I don't have a fixed IP address. – Question Overflow Aug 3 '14 at 10:11
  • 1
    It may be a very "patchy" thing, but you could allow a particular netblock (like: 1.1.0.0/16), sure, you allow 65k addresses, (or 16M, if you allow /8) - but you block the others. – ndrix Aug 3 '14 at 12:59
  • Not feasible because my ISP has many IP blocks that are scattered around the full spectrum. – Question Overflow Aug 3 '14 at 16:57
  • Setup dynamic DNS on your SSH clients and whitelist them. I have a script that resolves my clients' IPs every few minutes and updates my firewall rules. – Michael May 26 at 0:38
0

OpenSSH provides a very good initial security, because it uses privilege separation and sandboxing. This way the small network listen and authentication part is separated from the rest, that is, it runs as a different non-privileged user and with sandboxing it also can do only limited system calls.

The major problem then is brute-force password probing. The easiest way to limit your attack surface here is to disallow password authentication, i.e. only allow public-key authentication or at least limit password authentication to few users with known hard-to-guess passwords. Because, once the attacker has access as a local user it is often easy to use a privilege escalation exploit to get full system access.

Also, limiting the amount of SSH connection attempts limits the attack surface as does moving to a non-standard port. Examples from my sshd_config:

 Port 22                               # port 22 gets rate limit with iptables
 Port 22922                            # use an uncommon port where nobody probes for unlimited access
 AllowUsers user1 user2 trusted_user   # limit users which might connect
 PasswordAuthentication no             # no password authentication by default
 # allow password authentication only for users which care about their password
 Match User trusted_user
 PasswordAuthentication yes

And the iptables rules I use to limit connection rate for SSH.

 iptables -N SSH_CHECK
 # limit ssh on default port from same IP to 3/40 sec
 iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
 iptables -A SSH_CHECK -m recent --set --name SSH
 iptables -A SSH_CHECK -m recent --update --seconds 40 --hitcount 3 --name SSH -j DROP

And if you think that these methods combined don't give you enough time to react in case of a major security problem you can set up a multi-staged system. For example you could run the externally visible SSH daemon in some kind of sandbox (chroot, container, virtual or real machine) and make the user log in there. After the first successful login the user then must continue to log into the next stage of your system etc.

| improve this answer | |
  • Those are actually the basic things to do. I am talking about the discovery of a major security flaw in SSH implementation that allows user to gain a root shell even without a key or password. – Question Overflow Aug 3 '14 at 16:55
  • For more security you could setup a multi-staged system. See edit. – Steffen Ullrich Aug 3 '14 at 17:26
0

I honestly can't believe any of the previous posters have told you the obvious answer.

Both of the above answers are WRONG.... you don't need port knocking, you don't need to change your port, you don't need to set up IP filters.... unless you really want to do "belt and braces".

All you need to do is do what most people are too lazy to do ....

(a) Setup public key authentication and disable all other forms of authentication

PasswordAuthentication no
ChallengeResponseAuthentication no
PermitRootLogin no

(b) Keep your system patched and up to date

Really, its that simple. There's no need to go all OTT.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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