Using a non-standard port for ssh eliminates the need for this altogether. This is almost a no-brainer, and it's the first thing I do when standing up a server.
Using a non-standard port for ssh eliminates the need for this altogether. This is almost a no-brainer, and it's the first thing I do when standing up a server.
No, it doesn't. Running a port scan and finding your "hidden" SSH port takes very little time.
Placing your SSH port behind a hosts.allow restriction ensures that you've reduced your attack surface to only the hosts (or networks) you've permitted.
Better still, set up OpenVPN, use its HMAC[1] support to stop unknown users early, and don't expose any other daemons to the internet.
The rationale for this feature is as follows. TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.
So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.
--tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake.
I don't find using hosts.allow terribly useful as the people that tend to want to ssh into servers that I control are often mobile, with IP addresses that change regularly.
The point I'm making, though, is that every instance of someone running a dictionary attack against one of my servers was a script kiddie running a tool against a range of IP addresses. Changing the port ssh runs on to something high eliminates this entirely.
The point I'm making, though, is that every instance of someone running a dictionary attack against one of my servers was a script kiddie running a tool against a range of IP addresses. Changing the port ssh runs on to something high eliminates this entirely.
Those are the attacks you see. The script kiddie with a 0-day would be much less obvious.
There are straight-forward ways to architect your infrastructure such that you solve the dictionary attack problem AND the 0-day problem, none of which require the hand-waving security (and user annoyance) of moving SSH to a non-standard port.
The security provided by a non-standard port is laughable -- it's like putting a child-proof lock on your front door.
If you're worried about dictionary attacks, turn off password authentication. If you're worried about 0-day vulnerabilities in SSH, leverage defense-in-depth (require well-secured VPN connectivity before allowing SSH access). If you're worried about user's machines being compromised and their keys stolen, leverage two-factor auth.
while denyhosts (or fail2ban just for ssh) is of extremely questionable benefit, it's not because using a non-standard port for ssh eliminates the need for it altogether.
Once the correct port is located, you're in precisely the same situation that you are if you hadn't moved ssh.
