-
Website
http://danielmiessler.com/ -
Original page
http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk -
Subscribe
All Comments -
Community
-
Top Commenters
-
'Dapo Osewa
3 comments · 1 points
-
Maxo
18 comments · 2 points
-
cooperati
127 comments · 2 points
-
dapxin
14 comments · 1 points
-
icepyro
3 comments · 1 points
-
-
Popular Threads
-
Free Will and Punishment
1 day ago · 1 comment
-
Broadband Speeds Around the World
3 days ago · 2 comments
-
Willpower: A Limited Resource
1 week ago · 2 comments
-
Availability Bias
5 days ago · 1 comment
-
Andrew Gelman Talks Voting Patterns and Income
5 days ago · 1 comment
-
Free Will and Punishment
I agree wholeheartedly; it's just another level of protection as part of defence in depth - although I'd use port 48351, or similar, rather than port 24!
This action would only be security through obscurity if you had no password or private key on the accounts - the non-standard port was your only protection. I'm sure that that is not the case!
A further protection is, on your firewall, to only permit connections with a source port less than 1024, then use the 'UsePrivilegedPort yes' in your ~/.ssh/config file to tell ssh to use source ports < 1024. My quick checks with nmap showed that nmap used source ports over 1024 - so even a hit on the right destination port would not result in an 'open'.
Were you monitoring the traffic to your ssh ports, if yes, were most of the source ports < 1024??
The problem with changing ports that services listen on is the loss of trust. Services that listen on ports lower than 1024 are considered "trusted" because they require root privileges. So if SSH is enabled on a very high port, I'd be worried about my personal security when I connect to that system.
Also, using service detection with tools like NMAP will quickly remove negate any extra security that is provided by running on non-standard ports.
The only upside to running on non-standard ports is that automated attacks won't occur, but honestly a good firewall ruleset or a something like deny_hosts really solves the problem while retaining the "trust" factor.
plz can you tell me how to change the port of the ssh on fedora 8
because i
ve 2 servers on the same router when so i cant login to one of them because the servers ssh have the same portplz help me , thx
What you're advocating here is not so much security improvement through obscurity, but security improvement through irregularity. You could proclaim from the mountaintops that you serve ssh on port 24—in fact, you just did—and it would still have improved your security. Heck, you could respond to attempts on 22 with a message redirecting them two ports higher, and it would improve your security, because it would still filter out all the wardialer-style scripts. It wouldn't work if everyone did the same thing, but by decreasing regularity, you make it much harder for the scripts to account for your case. None of these stop someone determined to get into your system in particular, of course, but that's why you're not relying on them.
I just run SSH on a non-standard port >1024 to keep down the size of my log files.
i used to do this, but switched to using knockd instead.
one reason i switched is that it wasn't always easy to persuade other software to use the new port. even sftp requires quite an ugly syntax to pass the parameter down to the ssh layer.
the other reason was that my isp started "traffic shaping". that means that data transfer using non-standard ports had limited bandwidth.
neither of those is a very powerful argument (and i've since changed providers - from vtr to telefonica chile - to avoid the traffic shaping) and knockd is itself a bit frustrating to use if you don't have the client handy (you can trigger it using telnet, but it's hit and miss).
even so, you might consider it... http://www.portknocking.org/</p>
ps also, of course, it can protect other protocols too.
I do this too. A while back I got really annoyed by the number of brute force attempts on my servers.
I have a HIDS system in place which alerts me to brute force attacks. On port 22 I would get at least 10 messages that it had blocked a brute force attack every day. I thought about disabling that rule, but then I realized that what I wanted to do was block out the annoying scripts, not the deliberate attacks on my systems. So I moved the SSH port to 831 (just made the number up). Now I don't get the attack messages unless someone scans my system to look at open ports and attack the services on them, something which indicates a much more dedicated attack which I might actually be worried about. I think I've gotten all of one ssh brute force alert across 10 servers.
To mitigate the inconvenience I just put the ports in my .ssh/config file along with shorthands, such as:
Host s1
HostName server1
Port 831
Really quite elegant.
This is a really, really good idea. Security through obscurity is not a replacement for other standard industry-best security practices, but it is a very helpful part.
The bottom line is it consumes server resources to deal with bogus connections. Even if you have an effective rejection system in place, a non-standard port reduces the amount of traffic you have to deal with.