I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter.
There's billions of hosts on the Internet and many millions of them running an SSH service. Even attackers with huge botnets at their disposal have finite resources and time to probe for hosts and then try exploiting vulnerable ones. Every exploit attempt has some percentage chance of being against a honeypot used to help catch the attacker.
There's little point in even sniffing non-standard/uncommon ports for different services. Anyone changing a service port has a higher likelihood of having a more secure system than someone with standard ports. So even if you scan high number ports for an SSH service you're unlikely to find one on a high port that's not using a more secure than default configuration.
So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective. You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic. The more specific your allow criteria the better and more effective your block rules can be.
A "Beware of Dog" sign doesn't physically secure your house on its own. You might not even have a dog. What it does in change the calculus for a burglar. Why risk it when there's more obviously less risky targets nearby? The sign is a high pass filter.
Ports under 1024 are privileged in Linux - they require root or root delegated privileges to run. When SSH is on port 22, you have the assurance that unless the server is root compromised, it is what you think it is running on that port.
When you make that port 2222 or whatever, like so many people do, you have cut out a lot of noise... but now that compromised PHP application you had running has allowed someone to now race you every time SSH is restarted for an update or crashed or whatever to bind on that port. Let's say it wins - now you've got something listening on the SSH port. If someone using SSH ignores the fact that the host key has changed, now they're trying to login to a fake SSH server. Maybe you use password auth and you just gave them the password. Maybe they're using an OpenSSH client that is vulnerable to leaking private keys in certain situations. Maybe the fake SSH server pretends to be a real shell and they then log whatever actions you try to take when you SSH in. Because they're going to be able to figure out what port SSH is listening on - a fingerprinting port scan can be done in seconds.
You are sacrificing security when it comes to a more focused attacker for the sake of filtering out the low effort mass scans and basic brute forces. The thing is - I'm worried about the former, not the latter.
If you care enough about securing or filtering your SSH to go through any of this trouble, just set up a VPN on a separate machine and restrict SSH access via firewall to that machine. Spin up the smallest VM your cloud provider has, throw up wireguard on it, and you're good to go. It'll be plenty for a VPN that's basically just there for SSH access. Now someone has to have both an exploit for wireguard and an exploit for SSH to get into your machine that has things you care about, you've filtered out all the noise, and you haven't introduced new security risks for a more determined attacker.
Fully agree. If you want security by obscurity, modify openssh-server and jumble up the protocol a bit. XOR all the bits with some key. Send ssh packets encapsulated in Skype video frames or encoded in the fur of cat pictures over HTTP port 80.
I'm not actually joking -- the above tricks work really well for stable connections through the China firewall.
I think a useful related question is: Does running SSH on IPv6 count as security, or security through obscurity?
Because the public facing SSH services I have on IPv6 have never been probed or had bad login attempts even once in the last four years. I don't consider that a security control at all.
>I really hate the accusation that changing services to uncommon ports is security through obscurity.
If you're doing this for security reasons, then it is by definition 'security through obscurity'. The problem is that you don't like the term because it generally carries a negative connotation. What you and the author should be arguing is that 'security through obscurity' shouldn't be seen as a negative necessarily.
>So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
Thank you for this. The reason for moving ssh to a different port is not to stop a determined hacker, it is to lower the risk from script kiddies. It lowers the risk from stupid stuff, and is worth doing.
> I really hate the accusation that changing services to uncommon ports is security through obscurity. It's not a security practice, it's a high pass filter.
Well the high pass filter's purpose is to increase security. Therefore it is literally security through obscurity... Even if it's effective, that's what it is...
Haven't seen one in a while bug a steering wheel club lock had the same effect. A determined attacker could just cut the steering wheel and remove it but there were a bunch of other cars without them.
EDIT: What happens to HN? It's my second post that get downvoted for no reason in this thread. This whole post is mostly question asking for clarification, how can they deserve to be downvoted?
> So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity.
> You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective.
Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it...
> You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic.
Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?
An FBI agent from the Cyber Crimes division gave a talk while I was in college (>10 years ago). He was interested in brute force attacks against SSH daemons and created a couple hypotheses around number of logins and common passwords. To test this he setup two Honey Pot to record all of the username/passwords. The first one listened on standard SSH port 22, the other listened on a random high-numbered port. He left both of these running for ~6 months.
Results:
The honey pot listening on standard port 22 received 1,000s of login attempts (sorry, don't remember the exact number). The honey pot listening on the random high-numbered port received exactly 0.
I know this is just an anecdote and it might not necessarily be true today, but this experiment always sticks in my head. At least the guy used the scientific method: created a hypothesis, conducted the experiment, analyzed his results.
What I've found these days monitoring my own network is that there is now 2 waves -- a port scan and then the attack.
If I change a port for anything to another random port I won't get any login attempts for a few days but eventually I start getting hit again. I can repeat this over and over. I imagine what is happening is that the bad actors are scanning for open ports and they feed that periodically to another process that attempts logins.
Anecdotally, I have a machine with an exposed SSH, on a high number port. I get brute force attempts on a regular basis against it, just way less than when I run it on the standard port number. Security by obscurity is just one part of the steps I take with that machine. Using a high port number is dead simple and easily handled client side too, so I just do it.
I recently tried to change ssh port to remove log noise. Well, it certainly helped a little bit, but bots quickly found out new port and started to brute force it, so in the end it did not help, just reduced noise. And as I don't see much difference between 100000 attempts and 1000 attempts, I decided to return it back. I don't care about brute force anyway, my passwords are not "root:root".
This is my observations as well. For 20+ years I have run ssh on a high port, with exception to my sftp server. The sftp server is hit every day, all day. I have received 0 hits to my ssh port on all my other servers. Even if they hit that port, they would not see anything, as I use a poor-maps port knocking using iptables string matching, but I would still see the attempts in the iptables counters and they are always 0.
FWIW, when I chose my port, I looked at port scanning statistics back in the day, looking for the least scanned ports. It appears those stats have held true for a couple decades at least.
The entire point of everyone who rants against non standard ssh ports is that it adds more noise to the signal of "You should disable password login entirely and only use public / private key authentication."
And reading many of the responses in this thread it makes sense to me. So many people in this thread talking about how many less failed password login attempts they get when they change the port, indicating they allow password based login in the first place.
If you expect to be hit by that kind of attack (simple combination of username/password), then you should protect yourself from that kind of attack. It's never been easier nowadays to do this.
You may answer that you could still miss a few of theses simple password, that your solution would be more effective, sure, but then you use security by obscurity to protect yourself.
By the way, security by obscurity does works, it's not bad per say, just as that FBI agent just proved, it does have an effect. If it didn't, there wouldn't be so many case where it was used. The issue with security by obscurity is when you rely on that to protect from vulnerabilities and then ignore them. It only lower the likeliness of getting attack, it doesn't make attack less effective, it doesn't protect from any vulnerabilities.
Sadly, too many time, we just ignore it, hide everything and hope to avoid targeted attack which would foil that obscurity pretty quickly. This is when it get bad.
I have the same experience with non-standard port usage, and I think it's a very reasonable thing to do, while also caring for the security of the service behind that socket. SecOps will thank you for not having to wade through log spam in the endeavor of preventing attacks.
> I know this is just an anecdote and it might not necessarily be true today, but this experiment always sticks in my head. At least the guy used the scientific method: created a hypothesis, conducted the experiment, analyzed his results.
I don't need a research to see the difference in how much logging journalctl generates immediately after I disable port 22.
This article engages in quite a bit of mental gymnastics to avoid calling this tactic exactly what it is. Security by obscurity
What are you doing here? SSH generally runs on port 22. You move it to an alternate port to thwart a naive intruder's attempt to establish a connection to a service running on that port.
You are still running SSH with the same old setup. If it was insecure before it remains insecure. The only thing you've done is "obscure" how to connect to it by using an uncommonly used port.
Why all the hate on "Security by Obscurity" It's a perfectly valid thing to do. It will definitely defend against a host of intrusion attempts. Its only cast in a negative light when it's the ONLY thing you do or if you consider it sufficient in terms of security.
FWIW the key analogy is broken. Hiding a key to your house in a plant is a form of "Security by Obscurity". Anyone that finds the key can open the door. Thats not very secure. So we hide the key so no only people that know where it is can find it. If an intruder found the key they'd immediately have access to the house. We rely on the obscurity of its location to provide whatever security it has to offer.
You could achieve the same affect by having a hidden door and leaving the key out in the open or hiding both. What use is the key if the location of the door it opens is "obscure". This works because access is defined by knowing the location of the key and the door simultaneously.
Moving your SSH port isn't really about security. It's about reducing noise in your logs from annoying port scanners constantly hitting common ports. Although that does then have the benefit of making your logs more useful for detecting actual attacks. And it probably reduces some CPU cycles too as an added bonus.
I've had the SSH server for my host on a non-standard port for well over a decade now. My observations:
Back in the mid-2000's, botnets were small, the Internet was slower, and there was a lot of low-hanging fruit. Putting your SSH server on a non-standard port was a good way of reducing log clutter.
Today, though, it doesn't matter. I get as many login attempts on my non-standard ports as I see on hosts running SSH on port 22. This is because for at least the past few years, it has been feasible and indeed entirely commonplace to scan the whole IPv4 internet, 65k ports and all. Companies like Shodan and Censys sell access to detailed maps of basically everything on the routable Internet. There is no such thing as "hiding" a service on some little-used port anymore.
One can make the argument that attack surface is inversely proportional to security, so putting services on non-standard ports is in fact an increase in security. It's just that even back in the day, that increase was too small to seriously consider and today it's microscopic.
People really lose their mind over changing the SSH port. It's not an either/or choice between a non-standard port and all of the other SSH security settings. Nearly anybody that bothers to change the port is also going to follow most of the other industry-standard practices.
I don't care if it security by obscurity or not, it's not stopping a targetted attack and it's confusing the people who need to use SSH much more than the attackers.
If your woken up at 3AM because something is wrong with some random server, you want to be able to access it fairly easily. Maybe you and your team monitor servers for customers, who decide that SSH should be moved to some random port. Even with the best documentation in the world, setting the port on their SSH connection is something people will miss.
If you're able to communicate that you moved the SSH port to your team, then you're most likely also able to simply whitelist the right IPs in your firewall. Just do that instead and leave the port at 22.
We manage a ton of servers for random clients and they just need to whitelist two or three IPs depending on the team(s) that needs access. Don't expose SSH to the entire internet, unless you need random people access it and in that case moving the port just seem to be a support case waiting to happen when someone forgets to set the port.
I call this a non-issue. We use not default SSH ports and every single person in engineering, support and customer integrators are just fine with it. When 99% of all equipment are on non-default ports everyone just expect to look up port before attempting connection. And we have a lot of servers in use.
What you are talking about is when company used port 22 and then some minority of server were changed, and some don't and it wasn't communicated and caused a mess. But when done company wide on a majority of equipment it becomes just thing we do, not a problem at all.
You can do both, and in general most management teams should be at the very least using ssh configs if not full inventory management ala ansible/et al.
Whitelisting IPs may work with your corporate vpn, it most certainly does not work for hobbyists on consumer ISPs.
Moving the port deflects a lot of low effort attacks, and if the ssh server is otherwise still well secured then provides no harm and real benefit.
You could probably do something like the following in your ssh_config. Of course that's assuming that all the servers are adhering to some internal standard instead of the standard standard.
Exactly. Standards exist for a reason. The only thing you are obscuring is real authorized access. Bots don't care whether the service is on port 22 or 38692, they will just probe them all.
Yes, and that's what tools like tcp wrapper (or iptables) are there for. I use it to disallow whole networks from Brazil, China, etc so they don't even reach sshd to talk to it. Less log clutter, less to do for fail2ban if installed.
I don't think changing the SSH port is bad, at least it avoid some spam in the logs from all the automated login attempts. But for SSH there is a single, obvious security measure you should always take if at all possible, and that is to disallow passwords and use public key authentication exclusively. Weak passwords are the biggest danger for SSH, and this solved this specific problem entirely.
This discussion tends towards tediousness because people never define the security goals they're trying to achieve with their pet definitions.
Yes: moving your ssh daemon to run on a different port is "futile" if your goal is to prevent a competent attacker that is single-mindedly focused on attacking a specific host and willing to continue investing time and effort until they succeed.
Yes: having a port-knocking sequence is "futile" if your goal is to prevent an attacker that has the ability to perform full packet capture on all your traffic and is prepared to wait and observe an incoming ssh connection.
But, on the other hand:
Yes: having ssh at all is "futile" if your goal is to prevent an attacker that has the ability to identify your authorized users and then compromise them by kidnapping their families and threatening to murder them.
But even if you accept the author's distinction, the conclusion seems wrong -- moving your SSH port is security through obscurity, albeit relatively weak.
If I attempt to connect to port 22 and there's nothing there, then I don't know whether the machine has SSH or not. So the mechanism is being hidden. Therefore... security through obscurity.
(If, on the other hand, a connection to port 22 somehow failed with an error message "wrong SSH port!" then, in that case, it wouldn't be obscurity.)
The main reasons it's weak is that you can port scan to discover if it exists, and it's likely in the first place that many machines have SSH because alternatives are less common.
But it is still a first layer of security through obscurity, by definition. (Regardless of whether you think it's useful or good or not.)
You don't have to be faster than the bear, just faster than the other camper. Assuming the bear is just hungry, that is; if you messed with her cubs, she's coming for you specifically.
These are, of course, opportunistic targets and specific targets. Moving the ssh port helps with the former, but not the latter.
There is some economic cost with portscanning everything, but the bigger impact is that if you moved your ssh port you're more likely to also have turned off password auth and more likely to be running fail2ban and more likely to be running an IDS. Spammers don't want to deal with you making their livelihood more difficult. Poor spammers.
People who see brute force attacks chasing their port moves are probably specific targets. Ears up.
> It’s fine that people know you changed your SSH port. But now they have to scan all the ports and find the new one. Sure, that’s not too difficult, but many people are actually going to do that? Not many, because it’s costly in terms of time and effort.
I don't buy it. Scanning the whole IPv4 internet including all ports is not all that costly. Perhaps the effort would deter your proverbial script kiddie running a scan from home, but are those really a threat to your SSH setup?
A few useful resources:
If you don't want your SSH server being found by trivial port-scanning, apply port-knocking:
https://github.com/moxie0/knockknock
Port 2222 seems to have become the official obscured SSH port. If you want less log spam, maybe choose another one.
Also it may be a good idea to use another port <1024 - iirc it's good to keep it to the port range where an unprivileged user cannot open anything, potentially impersonating the SSH service.
Although I'm not sure how an unprivileged user would be able to stop sshd in order to take over that port.
Here's interesting thought. There's UNIX security measure that dates back to old UNIXes: only root can listen on <1024 ports. That's why all old-school services listen on <1024 ports: some random user, running software on your machine can't intercept that port.
People changing ssh port to >1024 port actually reduce security of their systems.
I wonder whether a synchronous port hopping would help security. The sshd would hop to a different listening port based on a random seed and the current time at fixed intervals. The client runs a small app to compute the current active port by using the same seed and the current time.
We maintain a sensor network which consists of multiple nodes which emulate network fingerprint and characteristics of popular services. We did multiple experiments over a period of 3 years as part of tuning our sensors one of which was changing the SSH port of one honeypot to 38651. Less than 10 hits were observed on it over a period of 6 months and 7 out of 10 were legitimate (or misguided, depends on how you look at it).
During our experiments, we learnt a lot of lessons -
1) Attackers operate on a budget and are often time-bound (they have bosses as well). They have less incentive to target esoteric ports unless they have specific intel about it.
2) It is always a better strategy to ensure you waste their resources. No one is going to do full port scans of internet. The last I heard, adding an extra port to ZMap takes around 500 MB of extra memory.
3) The advent of intel sharing models typically highlight nasty scanners like a beacon.
4) Very few ISPs provide high bandwidth pipes to their retail (or even privileged) customers do full port scans. Its always a fight between scanning via low bandwidth pipes via multiple nodes over a long period of time and have less updated data or having to pay a lot more to get a 10GB+ pipe to do it which is bad for OPSEC.
5) Corollary to previous point, even if you control a large botnet that may do it for you, you will get reported or will have scanning, co-relation or computation issues. Or all of them.
6) Pareto's principle is everywhere, 20% of security/ sanity measures will solve 80% of your problems. Simply changing network ports, running your infra over a closed VPN environment, reducing your public internet exposure, configuring dual factor authentication et al - it seriously reduced our infra monitoring/ management upkeep.
7) The internet is full of spam (and water is wet), expect mass spam all the time on your mail sensors/ email IDs. Interacting with these will eventually get elevated to targeted attempts. Even simple browsing will sometime give you a high value malware payload served via AD networks that was previously unknown.
It’s not bad, but it also shouldn’t be the basis of your security model either.
There are a lot of parallels with physical security. It’s good to do things to make yourself less of an obvious target but at the end of the day, you should still lock your doors.
[+] [-] giantrobot|5 years ago|reply
There's billions of hosts on the Internet and many millions of them running an SSH service. Even attackers with huge botnets at their disposal have finite resources and time to probe for hosts and then try exploiting vulnerable ones. Every exploit attempt has some percentage chance of being against a honeypot used to help catch the attacker.
There's little point in even sniffing non-standard/uncommon ports for different services. Anyone changing a service port has a higher likelihood of having a more secure system than someone with standard ports. So even if you scan high number ports for an SSH service you're unlikely to find one on a high port that's not using a more secure than default configuration.
So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app. You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective. You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic. The more specific your allow criteria the better and more effective your block rules can be.
A "Beware of Dog" sign doesn't physically secure your house on its own. You might not even have a dog. What it does in change the calculus for a burglar. Why risk it when there's more obviously less risky targets nearby? The sign is a high pass filter.
[+] [-] cthalupa|5 years ago|reply
Ports under 1024 are privileged in Linux - they require root or root delegated privileges to run. When SSH is on port 22, you have the assurance that unless the server is root compromised, it is what you think it is running on that port.
When you make that port 2222 or whatever, like so many people do, you have cut out a lot of noise... but now that compromised PHP application you had running has allowed someone to now race you every time SSH is restarted for an update or crashed or whatever to bind on that port. Let's say it wins - now you've got something listening on the SSH port. If someone using SSH ignores the fact that the host key has changed, now they're trying to login to a fake SSH server. Maybe you use password auth and you just gave them the password. Maybe they're using an OpenSSH client that is vulnerable to leaking private keys in certain situations. Maybe the fake SSH server pretends to be a real shell and they then log whatever actions you try to take when you SSH in. Because they're going to be able to figure out what port SSH is listening on - a fingerprinting port scan can be done in seconds.
You are sacrificing security when it comes to a more focused attacker for the sake of filtering out the low effort mass scans and basic brute forces. The thing is - I'm worried about the former, not the latter.
If you care enough about securing or filtering your SSH to go through any of this trouble, just set up a VPN on a separate machine and restrict SSH access via firewall to that machine. Spin up the smallest VM your cloud provider has, throw up wireguard on it, and you're good to go. It'll be plenty for a VPN that's basically just there for SSH access. Now someone has to have both an exploit for wireguard and an exploit for SSH to get into your machine that has things you care about, you've filtered out all the noise, and you haven't introduced new security risks for a more determined attacker.
[+] [-] dheera|5 years ago|reply
I'm not actually joking -- the above tricks work really well for stable connections through the China firewall.
[+] [-] reincarnate0x14|5 years ago|reply
Because the public facing SSH services I have on IPv6 have never been probed or had bad login attempts even once in the last four years. I don't consider that a security control at all.
[+] [-] macspoofing|5 years ago|reply
If you're doing this for security reasons, then it is by definition 'security through obscurity'. The problem is that you don't like the term because it generally carries a negative connotation. What you and the author should be arguing is that 'security through obscurity' shouldn't be seen as a negative necessarily.
>So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
How do you figure that?
[+] [-] paul_f|5 years ago|reply
[+] [-] gitgud|5 years ago|reply
Well the high pass filter's purpose is to increase security. Therefore it is literally security through obscurity... Even if it's effective, that's what it is...
[+] [-] a1369209993|5 years ago|reply
[+] [-] spullara|5 years ago|reply
[+] [-] Florin_Andrei|5 years ago|reply
[+] [-] dwild|5 years ago|reply
> So when you have SSH listening on some uncommon port and see hits in your logs you have a reasonable assurance the attacker isn't some script kiddy spamming the "attack" button on some stupid app.
Do you remove a vulnerability by doing this? Whatever you are afraid that the script kiddy may do, still can happen, thus it is security by obscurity.
> You also have reasonable assurance blocking that host/network with fail2ban or equivalent will actually be effective.
Can you explain that to me? How is it less effective to block a script kiddy or not? Block him... that's it...
> You can also set way more strict fail2ban rules since you're far less likely to ever lock out authorized traffic.
Wait, what? How will it make less likely to block authorized traffic? As long as that traffic act like authorized traffic, it should still be authorized, isn't it? You would blanked ban traffic that doesn't try too many username/password?
[+] [-] noncoml|5 years ago|reply
[+] [-] nmaludy|5 years ago|reply
Results: The honey pot listening on standard port 22 received 1,000s of login attempts (sorry, don't remember the exact number). The honey pot listening on the random high-numbered port received exactly 0.
I know this is just an anecdote and it might not necessarily be true today, but this experiment always sticks in my head. At least the guy used the scientific method: created a hypothesis, conducted the experiment, analyzed his results.
[+] [-] wvenable|5 years ago|reply
If I change a port for anything to another random port I won't get any login attempts for a few days but eventually I start getting hit again. I can repeat this over and over. I imagine what is happening is that the bad actors are scanning for open ports and they feed that periodically to another process that attempts logins.
[+] [-] Twirrim|5 years ago|reply
[+] [-] vbezhenar|5 years ago|reply
[+] [-] LinuxBender|5 years ago|reply
FWIW, when I chose my port, I looked at port scanning statistics back in the day, looking for the least scanned ports. It appears those stats have held true for a couple decades at least.
[+] [-] teilo|5 years ago|reply
[+] [-] Smar|5 years ago|reply
[+] [-] thefreeman|5 years ago|reply
And reading many of the responses in this thread it makes sense to me. So many people in this thread talking about how many less failed password login attempts they get when they change the port, indicating they allow password based login in the first place.
[+] [-] dwild|5 years ago|reply
You may answer that you could still miss a few of theses simple password, that your solution would be more effective, sure, but then you use security by obscurity to protect yourself.
By the way, security by obscurity does works, it's not bad per say, just as that FBI agent just proved, it does have an effect. If it didn't, there wouldn't be so many case where it was used. The issue with security by obscurity is when you rely on that to protect from vulnerabilities and then ignore them. It only lower the likeliness of getting attack, it doesn't make attack less effective, it doesn't protect from any vulnerabilities.
Sadly, too many time, we just ignore it, hide everything and hope to avoid targeted attack which would foil that obscurity pretty quickly. This is when it get bad.
[+] [-] beams_of_light|5 years ago|reply
[+] [-] aikinai|5 years ago|reply
[+] [-] heavenlyblue|5 years ago|reply
I don't need a research to see the difference in how much logging journalctl generates immediately after I disable port 22.
[+] [-] throwawaynothx|5 years ago|reply
[+] [-] ryanlol|5 years ago|reply
[+] [-] SassyGrapefruit|5 years ago|reply
What are you doing here? SSH generally runs on port 22. You move it to an alternate port to thwart a naive intruder's attempt to establish a connection to a service running on that port.
You are still running SSH with the same old setup. If it was insecure before it remains insecure. The only thing you've done is "obscure" how to connect to it by using an uncommonly used port.
Why all the hate on "Security by Obscurity" It's a perfectly valid thing to do. It will definitely defend against a host of intrusion attempts. Its only cast in a negative light when it's the ONLY thing you do or if you consider it sufficient in terms of security.
FWIW the key analogy is broken. Hiding a key to your house in a plant is a form of "Security by Obscurity". Anyone that finds the key can open the door. Thats not very secure. So we hide the key so no only people that know where it is can find it. If an intruder found the key they'd immediately have access to the house. We rely on the obscurity of its location to provide whatever security it has to offer.
You could achieve the same affect by having a hidden door and leaving the key out in the open or hiding both. What use is the key if the location of the door it opens is "obscure". This works because access is defined by knowing the location of the key and the door simultaneously.
Both are examples of "Security by Obscurity"
[+] [-] snowwolf|5 years ago|reply
[+] [-] bityard|5 years ago|reply
Back in the mid-2000's, botnets were small, the Internet was slower, and there was a lot of low-hanging fruit. Putting your SSH server on a non-standard port was a good way of reducing log clutter.
Today, though, it doesn't matter. I get as many login attempts on my non-standard ports as I see on hosts running SSH on port 22. This is because for at least the past few years, it has been feasible and indeed entirely commonplace to scan the whole IPv4 internet, 65k ports and all. Companies like Shodan and Censys sell access to detailed maps of basically everything on the routable Internet. There is no such thing as "hiding" a service on some little-used port anymore.
One can make the argument that attack surface is inversely proportional to security, so putting services on non-standard ports is in fact an increase in security. It's just that even back in the day, that increase was too small to seriously consider and today it's microscopic.
[+] [-] jamesmishra|5 years ago|reply
[+] [-] njharman|5 years ago|reply
The missing context; "Security by (only) obscurity". Is not good security.
Any single protection is not good security. Good security must include as many layers across as many axii as possible.
Adding obscurity to your existing security stack / layers improves your security.
[+] [-] mrweasel|5 years ago|reply
If your woken up at 3AM because something is wrong with some random server, you want to be able to access it fairly easily. Maybe you and your team monitor servers for customers, who decide that SSH should be moved to some random port. Even with the best documentation in the world, setting the port on their SSH connection is something people will miss.
If you're able to communicate that you moved the SSH port to your team, then you're most likely also able to simply whitelist the right IPs in your firewall. Just do that instead and leave the port at 22.
We manage a ton of servers for random clients and they just need to whitelist two or three IPs depending on the team(s) that needs access. Don't expose SSH to the entire internet, unless you need random people access it and in that case moving the port just seem to be a support case waiting to happen when someone forgets to set the port.
[+] [-] Yizahi|5 years ago|reply
What you are talking about is when company used port 22 and then some minority of server were changed, and some don't and it wasn't communicated and caused a mess. But when done company wide on a majority of equipment it becomes just thing we do, not a problem at all.
[+] [-] vorpalhex|5 years ago|reply
Whitelisting IPs may work with your corporate vpn, it most certainly does not work for hobbyists on consumer ISPs.
Moving the port deflects a lot of low effort attacks, and if the ssh server is otherwise still well secured then provides no harm and real benefit.
[+] [-] the8472|5 years ago|reply
[+] [-] paxys|5 years ago|reply
[+] [-] jcynix|5 years ago|reply
Yes, and that's what tools like tcp wrapper (or iptables) are there for. I use it to disallow whole networks from Brazil, China, etc so they don't even reach sshd to talk to it. Less log clutter, less to do for fail2ban if installed.
[+] [-] fabian2k|5 years ago|reply
[+] [-] NovemberWhiskey|5 years ago|reply
Yes: moving your ssh daemon to run on a different port is "futile" if your goal is to prevent a competent attacker that is single-mindedly focused on attacking a specific host and willing to continue investing time and effort until they succeed.
Yes: having a port-knocking sequence is "futile" if your goal is to prevent an attacker that has the ability to perform full packet capture on all your traffic and is prepared to wait and observe an incoming ssh connection.
But, on the other hand:
Yes: having ssh at all is "futile" if your goal is to prevent an attacker that has the ability to identify your authorized users and then compromise them by kidnapping their families and threatening to murder them.
[+] [-] crazygringo|5 years ago|reply
If I attempt to connect to port 22 and there's nothing there, then I don't know whether the machine has SSH or not. So the mechanism is being hidden. Therefore... security through obscurity.
(If, on the other hand, a connection to port 22 somehow failed with an error message "wrong SSH port!" then, in that case, it wouldn't be obscurity.)
The main reasons it's weak is that you can port scan to discover if it exists, and it's likely in the first place that many machines have SSH because alternatives are less common.
But it is still a first layer of security through obscurity, by definition. (Regardless of whether you think it's useful or good or not.)
[+] [-] Damogran6|5 years ago|reply
And it improves the quality of the logs that DO happen.
[+] [-] bill_mcgonigle|5 years ago|reply
These are, of course, opportunistic targets and specific targets. Moving the ssh port helps with the former, but not the latter.
There is some economic cost with portscanning everything, but the bigger impact is that if you moved your ssh port you're more likely to also have turned off password auth and more likely to be running fail2ban and more likely to be running an IDS. Spammers don't want to deal with you making their livelihood more difficult. Poor spammers.
People who see brute force attacks chasing their port moves are probably specific targets. Ears up.
[+] [-] the8472|5 years ago|reply
I don't buy it. Scanning the whole IPv4 internet including all ports is not all that costly. Perhaps the effort would deter your proverbial script kiddie running a scan from home, but are those really a threat to your SSH setup?
https://github.com/robertdavidgraham/masscan
[+] [-] achillean|5 years ago|reply
https://beta.shodan.io/search/facet?query=product%3Aopenssh&...
[+] [-] defend|5 years ago|reply
If you want to help secure the interwebs, host this tarpit to try to slow down network scanners: https://github.com/skeeto/endlessh
[+] [-] Netcob|5 years ago|reply
Also it may be a good idea to use another port <1024 - iirc it's good to keep it to the port range where an unprivileged user cannot open anything, potentially impersonating the SSH service.
Although I'm not sure how an unprivileged user would be able to stop sshd in order to take over that port.
[+] [-] vbezhenar|5 years ago|reply
People changing ssh port to >1024 port actually reduce security of their systems.
[+] [-] ww520|5 years ago|reply
[+] [-] rishabhd|5 years ago|reply
During our experiments, we learnt a lot of lessons -
[+] [-] code4tee|5 years ago|reply
There are a lot of parallels with physical security. It’s good to do things to make yourself less of an obvious target but at the end of the day, you should still lock your doors.