4 ms·
Moving the SSH port is a bad idea. The article falls into a number of common pitfalls here. A connection to your SSH server does not usefully equate to someon
by jfindley 10y ago
Moving the SSH port is a bad idea. The article falls into a number of common pitfalls here.
A connection to your SSH server does not usefully equate to someone "trying to hack" your server. If I had $1 for every time I've heard this complaint, I'd be very rich, but it's total rubbish. Stop worrying about it.
The mass scanners that fill your logs with brute force attempts on port 22 are looking for trivially obvious username/password combinations. If there is any chance they could actually get in with this approach, you've screwed up so badly that moving the port will not save you. If you're using key-based authentication, no amount of scanning is ever going to compromise your server, unless the attacker learns your key.
The reason moving your port is pointless is that against an attacker sophisticated enough to have any chance of compromising your SSH server, no amount of hiding the port is going to do more than delay them a few minutes. Compromising SSHv2 is hard. You need either a key compromise (difficult to achieve, likely some sort of APT malware against your laptop), or a zero-day sshd vulnerability. Against someone motivated and able to do that, your "clever trick" of moving sshd to port 24 is totally useless.
It's a bad idea to propose, too, as it will require users to either update SELinux rules to allow sshd to bind to a different port, or disable SELinux entirely. And as many of the ports <= 1024 are used for other things, users will tend to do things like bind to ports > 1024, such as 2222. As any system user can bind to ports > 1024, you're actually reducing security, and opening up a potential priv escalation vector (user with unpriv shell access causes sshd to crash via XYZ, starts their own malicious daemon on 2222, steals your credentials, etc).
There are cases where obscurity helps. Reducing the amount of information an attacker has about the environment they are attacking is often a very valid defence, and is something any security audit should consider. Moving the sshd port is not one of these cases.
In short, make sure you're using key-based authentication (ed25519 is preferred IMO, but happy for others to debate this). Make sure password authentication is disabled. Make sure direct root ssh is disabled, and passwordless sudo is disabled. Leave the port sshd listens on well alone - it's just fine where it is.
- draw_down 10y agoIt's not meant as a defense against a sophisticated attacker.
- AstralStorm 10y agoThen what good is it? Defence against sophisticated attacker is also good against a simple one. If the service is not actually public, hide it behind a good VPN, for crying out loud. SSH servers generally do not require this measure.
- knodi123 10y ago> Defence against sophisticated attacker is also good against a simple one Sometimes there's no defense available. Like in the case of a 0-day. In this particular case, defense against unsophisticated attackers script-kiddies will save your butt.
- yummyfajitas 10y agoDid you even read the article? Let’s say that there’s a new zero day out for OpenSSH that’s owning boxes with impunity. Is anyone willing to argue that someone unleashing such an attack would be equally likely to launch it against non-standard port vs. port 22? If not, then your risk goes down by not being there, it’s that simple.
- jfindley 10y agoYes. Please don't insinuate that others haven't read the article. It might be worth reading the HN guidelines here: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Also, from the article, please note paragraphs like: "I configured my SSH daemon to listen on port 24 in addition to its regular port of 22 so I could see the difference in attempts to connect to each (the connections are usually password guessing attempts). My expected result is far fewer attempts to access SSH on port 24 than port 22, which I equate to less risk to my, or any, SSH daemon." I was pointing out that this is silly. Those "attempts to connect" are totally meaningless, as I explained.
- yummyfajitas 10y agoHe provides a very specific use case (exploiting a zero day) where they are not meaningless.
- MOARDONGZPLZ 10y agoI guess I just don't understand your complaint. The author makes it pretty clear that this is an additional layer on top of already-good security. So it only delays a sophisticated attacker for a few minutes, maybe, but maybe that's enough delay to get that attacker to move onto an easier target. In any case, I don't think this is meant specifically for sophisticated attackers targeting your machine specifically. The author also posted some data: "I configured my SSH daemon to listen on port 24 in addition to its regular port of 22 so I could see the difference in attempts to connect to each (the connections are usually password guessing attempts). My expected result is far fewer attempts to access SSH on port 24 than port 22, which I equate to less risk to my, or any, SSH daemon. [ Setup for the testing was easy: I added a Port 24 line to my sshd_config file, and then added some logging to my firewall rules for ports 22 and 24. ] I ran with this configuration for a single weekend, and received over eighteen thousand (18,000) connections to port 22, and five (5) to port 24."