6 ms·
Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to wast
by gsich 9y ago
Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.
- VilniusHacker 9y agoI do that. Security professionals will whine "security by obscurity is not security" but the fact is it cuts down these attempts by a huge factor.
- gregmac 9y ago(I'm primarly a developer, not sysadmin) Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me. Same goes for other non-public services such as VPN. What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?
- orev 9y agoI’m so tired of hearing people quote “security by obscurity” in relation to moving ssh ports. It is NOT security by obscurity (SBO). SBO is taking an insecure thing and trying to hide it, and relying on the hiddenness as the ONLY means of security. SSH is already highly secure, so hiding it has nothing to do with the security. You can debate whether it’s worth the inconvenience vs reducing log spam, but SBO does not come into it at all.
- xur17 9y agoI typically just pick a high numbered port. > 10k would work. I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down. Basically it boils down to 'why not?' for me.
- munin 9y agoA high numbered port (above 1024) can be bound by non root programs. Use some non 22 port below 1024 if you want to change the port. Or use some RBAC system like selinux to keep anyone from binding to 2222 or whatever.
- gsich 9y agoWhat is the problem?
- nitrogen 9y agoAnother authorized user or a non-root RCE compromise could start listening on the ssh port if sshd ever dies for some reason.
- gsich 9y agoAnd then what? /etc/ssh is still owned by root, another user can't see the hostkeys. So you'll get an error message if custom keys are used.
- dredmorbius 9y agoRemote user tries to log in. Cannot. Issues (or trojan prompts for) password. It's a game of percentages.
- gsich 9y agoSSH key verification...
- dredmorbius 9y agoServer key? Sure, but what's the accept rate on new keys? On short-lived, poorly provisioned, AWS instaances, as just one example. Again, percentages. With enough attempts, some will succeed.
- wgjordan 9y ago> it's kind of a security-by-obscurity measure This comes up as a point of confusion often, so allow me to clarify: A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.
- debaserab2 9y agoThat’s a distinction I never understood but makes a lot of sense. Thanks for the explanation.
- gsich 9y agoI am using high ports >30000 but you can chose what you want.
- h1d 9y agoReally, this sounds like a bad practice to bind on non privileged port. A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.
- wiml 9y agoIt doesn't have access to the host keys, so it can't do very much unless you intentionally bypass the "someone is intercepting your connection" error your ssh client will give you in that case.
- teddyh 9y ago> I'm not really sure what's bad about it You say it yourself: > also a (very minor) inconvenience to real users I would disagree with the “very minor” part. To paraphrase myself (https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312): As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
- tonyarkles 9y agoYou know what it does do though? Dramatically reduces the amount of log spam :). Running SSH on port 22 vs. even just 2222 significantly reduces the number of failed login attempt messages. They'd always fail anyway unless they happened to somehow get ahold of my ssh private key, but it's sure a lot less annoying when looking for something in the logs to not have to filter through all that noise.
- blattimwind 9y agoYou're looking at this the wrong way, because you seem to assume that non-standard ports adds to security the same way the key length does, which is not the case.
- CommieBobDole 9y agoIt's not security by obscurity; obscurity can be a useful component of security. Something that's well protected and hard to find is less likely to be compromised than something that's well protected and easy to find, because some percentage of attackers won't bother to look for it. "Security by obscurity" occurs when someone tries to use obscurity in place of security, by 'hiding' their insecure thing. Besides, running a service on a non-standard port offers pretty good protection against a fairly common threat scenario in which a new vulnerability is discovered in a well-known service and attackers start sweeping the internet for open ports in order to exploit it. Not that you should automatically run your services on non-standard ports; there are tradeoffs as others have mentioned. But if you've got to expose something dangerous to the internet at large (and that's an assumption that you should question frequently), then avoiding the standard ports can be a useful tool.
- simias 9y agoYears ago (actually probably more than 10 years ago now) I actually switched from port 22 to 622 on my server because I wanted to get rid of the noise of people attempting to bruteforce my SSH regularly. It worked perfectly for years but surprisingly I've had a handful of bruteforce attempts on port 622 in the past year or so. Nothing particularly targeted either, always the same typical default users (root, admin, oracle, mysql etc...). I wonder who bothers doing that. Since I disabled password logging on all accounts and my key is stored on an HSM I'm not too worried about it though.
- marcosdumay 9y ago> I wonder who bothers doing that. Somebody that added nmap to their bot script.
- gsich 9y ago622 might be too low. Scanning first 1024 ports is easier.
- dingaling 9y agoI have my perimeter sshd on port 22... Only bound to IPv6 It's a big quiet void out there in sixspace.
- MaupitiBlue 9y agoAs I sit here wasting a beautiful a Saturday afternoon trying to secure my ssh and openvpn setup, your post makes me wonder if maybe it's time ...