28 ms·

Moving your SSH port isn’t security by obscurity

• ryankrage77 6y ago
  I see a lot of comments saying moving the SSH port cuts down on 'log noise' as you'll get less automated attempts going for low-hanging fruit. My VPS gets thousands of hits a day on port 22 and I have a lot of fun watching it ban them and plotting graphs/maps of the data.
• dano 6y ago
  Security is a multi-dimensional problem. Moving the port helps reduce noise, that is, you get a higher signal to noise ratio. Other dimensions include using ssh keys instead of passwords, disabling root logins, adding fail2ban, and 2fa. Using some or all of these modifications from the defaults will improve ssh security.
• dvfjsdhgfv 6y ago
  I usually hear "but it's security by obscurity" argument from people who are not involved in security in a professional way. If you need to protect a high-value target, confusing the attacker is a must. It's also reflected in various security standards and guidelines (See e.g. SP-800 171-B, 3.13.2e: Disrupt the attack surface of organizational systems and system components through unpredictability, moving target defense, or non-persistence. )
• RoryH 6y ago
  It's not more secure, but it certainly does help prevent unwanted bots spamming your SSH daemon.
• greenduck 6y ago
  On the same theme, I think that people have fixated on "security by obscurity" == bad instead of the original message which was "security by only obscurity" == bad. There are simple things you can do to keep away from scripted attacks or increase their cost. Stuff like using non-standard ports, or disabling default login IDs like root. Those are all pretty effective at keeping away the bulk of non-skilled attackers.
  • sascha_sl 6y ago
    DRM is one example in which security by obscurity is almost universally bad, and even game publishers seem to agree, considering in how many games Denuvo and/or VMProtect has been deliberately patched out of just to see massive performance improvements as soon as initial sales die down. All it does is get you the extreme fans that want something right at release, and you'll capture that audience - most of the time at least - with or without DRM. All you're doing is making their experience worse.
  • UncleMeat 6y ago
    > instead of the original message which was "security by only obscurity" == bad That isn't even the original message. The original message was Kerchoff's Principle, which states that in cryptosystems all information about the system is known except the secrets. This is very literally "security by obscurity is bad" except that it applies very narrowly to the construction of cryptosystems. The error was applying it to systems security more broadly, where it doesn't fully make sense.
  • zeepzeep 6y ago
    Using non-standard ports can actually be quite a severe security risk. Browsers block many ports, if you move your internal service to an unblocked port, you expose it to every browser in the network! (e.g. a mail server or IRC, something that can be talked to over http.)
    • tgflynn 6y ago
      Do you have a reference for "Browsers block many ports" ? I thought there are even ssh clients that run in javascript in the browser. That wouldn't work if browsers were blocking access to port 22 for outgoing packets/connections.
      • zeepzeep 6y ago
        Go to https://google.com:22 https://google.com:22 "This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."
• fabian2k 6y ago
  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.
• the8472 6y ago
  > 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? https://github.com/robertdavidgraham/masscan https://github.com/robertdavidgraham/masscan
  • megous 6y ago
    Not that costly? > "or 655,360 hours if scanning all ports" More than 70 years. Or a month with a fully loaded 8x10 gbit connection and a hardware to drive it and store results.
    • the8472 6y ago
      That's from a single machine with 100kPPS. A single cloud machine will get you more, and you can rent a bunch of those. And it's not like you need to scan all of the internet, limiting yourself to the address ranges of the big hosters will cut down the time again. But really, the question is what are you defending against? What's your threat model? There's a published SSH 0-day you didn't patch yet? Ok, maybe that'll buy you a few hours of safety, but that's assuming nobody built a database of reachable ports in advance (think shodan) that they can then rely on to execute these kinds of exploits.
      • babadaba 6y ago
        Do you see how the complexity of the attack increased though? Now the attacker has to buy multiple hosts to stage their attack from. Like anything in life, when things get hard, a percentage of people give up.
        • the8472 6y ago
          That's why I mentioned building a database, which essentially evaporates the cost for everyone except the one building the database. Unsalted password hashes are considered insecure due to rainbow tables. And even if nobody built such a database, the cost still seems trivial compared to the effort it would take to compromise SSH in the first place. That is why I asked for a threat model. What are you defending against where everything is cheap except finding the host? If your goal is to cut down on log spam, that's fine, but then just say so.
• code4tee 6y ago
  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.
• jamesmishra 6y ago
  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.
  • tracker1 6y ago
    It's pretty much one of the first things I do when setting up a system... ssh port, no password logins, ufw. Of course, when I mess one of those up, I'm doing it again... but in general, that's my getting started step. If it's a really important system I'll go a step farther and enable a port knocking sequence... but that's about the extent of it. Generally speaking, I rarely setup port knocking.
    • mercer 6y ago
      Same here. Just changing the port makes brute force attacks so rare that I feel I don't need to bother with port knocking or the like.
      • tracker1 6y ago
        65022 for the win... it's funny but many scanning scripts stop at 60000 or 65000, or only target specific known ports.
  • peterwwillis 6y ago
    > Nearly anybody that bothers to change the port is also going to follow most of the other industry-standard practices If they're following industry standard practice (I'm hoping you mean "key-based auth only") then there is absolutely zero reason to move the port, other than to avoid filling up your logs, and two IPTables rules take care of that anyway. Moving the port is like being at a bar and needing to go to the bathroom, but first leaving your cellphone on the bar, covered with a little napkin. It is literally obscuring a thing, hoping that it is secure. Honestly, if people insist on security by obscurity, they should just do it already and stop apologizing for it.
• BLKNSLVR 6y ago
  Looking at it conversely: mustn't it be considered bad practise leaving your ssh port as default? Therefore changing it must be, at least a part of, good practise in the security task stack, no matter what label is applied to it. It's just so little effort to avoid script kiddie port scans and whatever follow ups occur when they find port 22 open.
• axegon_ 6y ago
  I've had this discussion many times with lots of people and my first argument is this: > $ telnet 10.136.3.215 22 > Trying 10.136.3.215... > Connected to 10.136.3.215. > Escape character is '^]'. > SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u7 Isn't it kind of obvious? I mean, this is what I'd get regardless of whether it's 22 or 24000.
  • elmo2you 6y ago
    It indeed is. If a port scanner does any analysis on the welcome banner, it's pretty obvious when you're dealing with an SSH server. That is, unless someone decided to run with a custom banner, which isn't something I have come across often in over two decades of experience (but I might not have recognized one if I saw one). The reality is that many (fast) scanners/script-kiddies often only scan for default ports. Changing the default port will lower your hit rate. It could be argued that this will only eliminate the less sophisticated attackers, which might hold some merit. However, good security is almost always a combination of factors that each add their own little contribution to the overall security. Even small increases can be worth it in the overall effort. Time is often an overlooked aspect within security. If you have SSH on an alternative port, you can use the detection of an inbound scan on the standard port to mitigate an subsequent scan/attack on your custom port. For instance by throwing the scanning IP address immediately in a deny ACL. Just a suggestion. Port knocking is also be an interesting concept, but a whole different discussion.
  • hatch_q 6y ago
    Do you actually run any public server with ssh on 22 and monitoring logs about it? From my experience noise on port 22 is so high that you wouldn't even notice actual targeted attempt.
    • axegon_ 6y ago
      No, I don't, but that has nothing to do with security and everything to do with routing. Noise is just as high on other ports so relying on moving a port or even a password is redundant as far as security is concerned. Personally I only have two servers which are publicly exposed to any form of ssh connections, both acting as access servers, nothing more. I've made several traps so if someone does manage to log in, I'll be immediately notified and I've also added a kill switch, so I can shut them down anytime with a click of a button.
• fooblat 6y ago
  People have a lot of misconceptions about security and I think what most people really want just doesn't exist. What we all want is to know that if we set the "correct settings" we have achieved Security. This is just not true. Security requires monitoring and maintenance. It takes ongoing attention. I'd venture that if you have a comprehensive security program in place then the port of your ssh server doesn't matter very much. Conversely, if your security program begins and ends with turning on a firewall and changing the ssh server port, I'd say you are off to a good start but you have a lot more to do if you want to get serious about security.
  • liability 6y ago
    Anybody actively monitoring their sshd logs would see clear value in changing the port. It dramatically raises the S/N of those logs.
• nmaludy 6y ago
  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.
  • ryanlol 6y ago
    It’s an useless anecdote because SSH bruteforce attempts are not a threat and cost you nothing.
    • elmo2you 6y ago
      > It’s an useless anecdote because SSH bruteforce attempts are not a threat and cost you nothing. I can say from personal experience that this anecdote is both accurate (20 years ago and up till today) and meaningful. No idea where you get this notion that brute force attack are no threat or without cost. They certainly do pose a security risk (takes only one insufficiently trained employee/intern for a potential breach) and they certainly come at a cost (way beyond dirty just logs).
      • fmajid 6y ago
        Botnets and fast networking stacks like DPDK have made port scanning the entire Internet a much more viable proposition than 20 years ago. Depending on your sshd settings you can be effectively locked out of your machine by a brute-force attack. Running on IPv6 and/or having a secondary sshd instance that only accepts connections from whitelisted IPs is cheap insurance.
• maze-le 6y ago
  Its not even obscurity: nmap --script ssh2-enum-algos target.ip -p 22-65535 -v Sure it takes a while longer, but the interesting attackers -- the ones that target a specific organization, not the ones enumerating whole ip ranges over and over again -- do have this time.
  • elmo2you 6y ago
    Obscurity doesn't mean undetectable. Also: you would still need to do a more elaborate (and therefore more "expensive") full range port scan, compared to scanning just the standard ports. That doesn't scale so well for scanning many IP address (e.g. criminals scanning the internet for potential targets).
  • rocqua 6y ago
    Getting a hit on port 22 doesn't mean much. Getting hit by a full port-scan is more of a signal of being specifically targeted though.
  • jopsen 6y ago
    I suppose your network provider (cloud provider) might have counter measures for port-scanning. (Personally, I'd prefer use port 22, just because it's less configuration)
• tastroder 6y ago
  https://news.ycombinator.com/item?id=24444497 https://news.ycombinator.com/item?id=24444497 The original, 520 comment, thread this is a reaction to.
• throwawayffffas 6y ago
  > 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. I haven't seen a single case where the new port is not 2222.
  • cedilla 6y ago
    I haven't seen a case where the port is 2222. And I've seen a few cases because I helped quite a few people with firewalld/SELinux issues related to changing the SSH port.
  • liability 6y ago
    How many cases set up by how many operators have you actually seen?
  • pwinnski 6y ago
    It's been a while, but back when I did full-time sysadmin, I used a port-knocking daemon that picked a random port > 1024 (with carve-outs for some known ports) and sent that port # to my pager. As you suggest, though, the port-knocking daemon itself ran on port 2222.
• Wowfunhappy 6y ago
  Alternate take is that it is security by obscurity, and that’s good as an extra layer of protection.
  • zeepzeep 6y ago
    From a Hacker/Pentester view: Security by obscurity will only steal my time. It won't stop me from hacking you. Moving to another port is useless, I'll do a port scan anyways. Non-standard paths and domain names are different stories, but even those will be brute forced eventually. It just costs time, makes everything more complicated and in the best case (for me) it makes it easy for you to block the wrong port.
    • Wowfunhappy 6y ago
      If you're targeting me specifically, sure. If you're not, stealing your time is all I need to do to make you move on to a different, easier target.
      • gruez 6y ago
        What's in your threat model that's simultaneously a non-targeted attack, but also sophisticated enough to get through basic security (eg. strong password or public key)?
        • cthalupa 6y ago
          Zero day exploit is the common refrain here. I commented extensively on the other thread (cliff notes: nonstandard SSH ports induce their own security risks [if on port 1024 or above], add complexity with minimal benefit, and generally indicate you should be focused your effort elsewhere - like setting up a wireguard VPN.), but they're not entirely wrong here. Just misguided. If you are guarding against OpenSSH 0 days as an attack vector, one, there are better security measures - see VPNs - to take that provide your greater protection in general, and two, port scans are trivially cheap, so once they infect all the things listening on port 22 they'll use that compute and network capacity to scan the rest of the internet to find things listening on nonstandard ports, because botnets = money, so increasing the size is a worthwhile investment. It gains you a few hours, or you could throw up Wireguard on another host where someone then needs both a Wireguard 0 day and an SSH 0 day at the same time to compromise your system.
• Zenst 6y ago
  I had an OpenBSD firewall at the start of the century and set-up my SSH with port-knocking - https://en.wikipedia.org/wiki/Port_knocking https://en.wikipedia.org/wiki/Port_knocking I used an skey https://en.wikipedia.org/wiki/S/KEY https://en.wikipedia.org/wiki/S/KEY port sequence and had a small java app that would run upon my humble Nokia and Psion Organiser to provide the port sequence for that minute in time. Not sure I have the code about still alas, due to that system getting lost along with others in a move a decade ago, but was simple enough to craft together and worked well. Even had a http/s tarpit, which is highly recommended educational wise to do and insightful. Again it is security with obscurity, just a bit more obfuscation involved in this type of set-up. Oh and dynamic DNS so home IP was known as was dynamic IP allocation via the ISP.
• NovemberWhiskey 6y ago
  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.
• R0b0t1 6y ago
  Moving the port is definitely security by obscurity, it's just that often, security by obscurity works. Tanks have armor but they still paint them camo. You are obscuring the target.
• dec0dedab0de 6y ago
  Well it would be security through obscurity if you changed the port, but didn't require any authentication on your ssh server. There was a time when people would do stuff like this, have a modem that would dial in to a corporate system without any authentication. With the idea being that they would have to guess the phone number. Then later on in the name of security making sure that you had to connect at a certain arbitrary bitrate. I understand the point of the article, I just think it's too narrow of a definition. The whole thing is just arguing semantics anyway.
  • R0b0t1 6y ago
    No, you're still getting additional security from the port move. The argument being made is nonsensical.
    • dec0dedab0de 6y ago
      You get additional security from any form of obscurity. No one has ever argued otherwise.
• teddyh 6y ago
  This post explicitly assumes that port scanning is “costly”. By all accounts, this is not true anymore.
  • __m 6y ago
    Can't you block ips after x failed attempts? That would make it costly to scan 65536 ports. In a directed attack that might not matter, but against attackers that scan millions of hosts it might give you some minor peace of mind, but if you bother to configure your sshd you probably aren't a target for those attackers anyway.
• vbezhenar 6y ago
  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.
  • yrro 6y ago
    At least an attacker (who doesn't have root) can't read a systems' SSH host keys.
    • vbezhenar 6y ago
      Yes, client will notice that server fingerprint changed. So the question is, how many people will ignore that notice and still enter their password? SSH is a good software in that regard, as it allows clients to notice that server changed, but still it's an attack vector, one you should not just dismiss.
• Vivtek 6y ago
  One note on the article, though - if you're camouflaged in the dessert, that's pretty obscure.
  • jkingsbery 6y ago
    They'd expect a tank to be sand colored. The metal thing in an over-sized ice cream dish with a cherry on top of it would catch them by surprise.
• rdtsc 6y ago
  For me it was about the log noise. It was annoying to have to log those drive-by brute force scripts and scanners so moved it a different port. Still got some but it was 100x less. However, I imagine once this becomes a popular enough technique, and I see it discussed on HN periodically, scanner scripts will start scanning other ports for SSH. So over time it might be less useful.
• njharman 6y ago
  The mantra "security by obscurity (is bad)" has been so oft repeated without context that the contextless "interpretation" become a false truism. 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.
  • iso1631 6y ago
    > Adding obscurity to your existing security stack / layers improves your security. In theory yes. In practice you are increasing the chance of someone else thinking "Oh this is secure I don't need to do that". I saw this very recently in several broadcasters all over the world - they have a broadcast server which comes with a well known default admin password for the webserver on port 80. Several of these blocked port 80 externally, but allowed another port (7071), as it said to do so in the manual. They then didn't bother changing the password because "port 80 is blocked". Had port 80 not been blocked they would have been more likely to think "Ooh I must change the password". Now it's not good they didn't change it anyway, but your flat statement that "Adding obscurity to your existing security stack / layers improves your security" only applies if nothing else in your security stack changes. I check port 22 on my public IP addresses to ensure that any servers are uptodate. Occasionally I'll find an out of date and yell at the department to fix it. That's far better than blocking port 22, as they then listen on port 2222 or similar, and never update their ssh servers, and then when someone does stumble across it, nobody has a clue it's happened. Never underestimate the ability for people to work around your "improved security" by introducing worse security problems
  • okennedy 6y ago
    I mentioned this in another response, but I'll refine my argument here. Security by obscurity's negative connotation comes from the ratio of effort on the part of the system implementer to the effort on the part of the attacker. While it may take time to break into an "obscured" system, it also takes a lot of effort to build the system in the first place. Worse, if the security is broken, you have to re-implement from scratch. Better approaches decouple the implementation/methods for enforcing security from the random components of the system that need to be kept secret. Whether or not this increases the effort for the attacker, it drastically reduces the effort for the defender. If an RSA key is cracked, a new one can be generated in less than a second, and once deployed the attacker is back to square one. Having SSH on a different port adds the cost of a full port-scan to any attempt to break in, vs the cost of changing one line in a config file. That all being said, there is a major difference between changing your port number and changing your RSA key: The attacker/defender effort ratio scales linearly (vs exponentially). Every time you change your port number (a fixed cost), the attacker has to run another port scan (another fixed cost) to get past this layer. By contrast, the amount of effort needed to crack an RSA key is exponentially higher than the cost required to create a new one. However, adding a fixed port-scanning cost to each attack does actually correspond to a very high overhead for a non-targeted attack (their costs go up by ~2^16).
• coding123 6y ago
  If you're a big-co, shame on you for not hiding behind a VPN with time-based codes. If you're a small-co, you should absolutely move your SSH port, AND DEFINITELY disable passwords.
  • rabuse 6y ago
    I always disable passwords for every system I work on. Then use some type of PAM, like Google Auth for TOTP.
  • robertlagrant 6y ago
    > If you're a small-co, you should absolutely move your SSH port, AND DEFINITELY disable passwords Totally agree. Except you can skip the port moving.
• crazygringo 6y ago
  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.)
  • okennedy 6y ago
    This response is missing the author's point. There's a distinction between obscuring the methods and obscuring a parameter to those methods. Security by obscurity, and in particular its negative connotation refers to obscuring methods. The reason it has a negative connotation is that the amount of work it takes to implement a secure system is high relative to the amount it takes to break it. By contrast, the amount of work needed to generate an RSA key, new port number, etc... is incredibly low relative to the amount of work it takes someone to break it. Security by layers is important, but the article's point is that the ratio of effort to benefit for changing your port number is far far higher than the term "security by obscurity" generally implies.
    • crazygringo 6y ago
      > This response is missing the author's point. There's a distinction between obscuring the methods and obscuring a parameter to those methods. But that's exactly the distinction I'm saying the author is getting wrong. Moving away from the default SSH port is obscuring the method, because it's no longer a single step to check whether the server even has SSH or not. It might not at all, so the port number doesn't serve primarily as a parameter -- it serves primarily to obscure its existence in the first place. To use the article's presidential motorcade analogy, it's not like knowing there's a motorcade but not knowing which car the president it's in. Instead, it's like not knowing if there's a motorcade at all, and having to check every car in the city to see if the president is even out in public in the first place.
• maitredusoi 6y ago
  If you move it to a port lower than 1024, it is ! ;)
• achillean 6y ago
  People aren't always great at picking a "random" port number. Here's a distribution of the various ports that people run SSH on: https://beta.shodan.io/search/facet?query=product%3Aopenssh&facet=port https://beta.shodan.io/search/facet?query=product%3Aopenssh&...
• ramtatatam 6y ago
  I stopped changing my ssh port once I learned low ports can only be taken be processes started as root. And then I realized I won't expose ssh port or any other management port except my vpn port...
  • acdha 6y ago
    Note that the root restriction isn’t strictly true any more: for example, on Linux you could grant the CAP_NET_BIND_SERVICE capability to a process and run it as a non-root user. If you have network services running as root just to be able to bind a low port, you could avoid that. In the case of sshd, of course, it would also need permission to start sessions as another user.
    • ramtatatam 6y ago
      I only do this for nginx serving content on http(s) ports, but of course technically if my host got compromised an attacker could do the same for ssh port. But at this point (having root) he/she would not have to do this (I don't use passwords) and I would be already doomed :)
• bibelo 6y ago
  Thank you Sir
• ogre_codes 6y ago
  I imagine if you set up a host with hundreds of ssh tarpits and just one slow SSH port, bots trying to crawl your site to figure out the SSH port would be minimal. https://nullprogram.com/blog/2019/03/22/ https://nullprogram.com/blog/2019/03/22/
• arendtio 6y ago
  Sometimes I wonder why everybody tries to get out of line, when instead it might be more useful, to keep some service on port 22 just to increase the cost for the botnet operators. Does someone know it there is something like a super slow and super save sshd implementation which doesn't allow anybody to actually login?
  • isbvhodnvemrwvn 6y ago
    Services like that are typically called tarpits, for SSH you can use Endlessh: https://github.com/skeeto/endlessh https://github.com/skeeto/endlessh
    • arendtio 6y ago
      Thanks, sounds exactly like what I have been looking for and Arch Linux seems to have an AUR for it :-)
      • jl6 6y ago
        I'd be wary of doing something that causes your server to be singled out in the attacker's reports, as might be the case if it causes their scanner to hang.
  • rovr138 6y ago
    This was posted a couple days ago, https://news.ycombinator.com/item?id=19465967 https://news.ycombinator.com/item?id=19465967
  • belak 6y ago
    I've seen endlessh[0] referenced in the past. Here's an article that talks about this and other SSH tarpits[1]. [0]: https://github.com/skeeto/endlessh https://github.com/skeeto/endlessh [1]: https://nullprogram.com/blog/2019/03/22/ https://nullprogram.com/blog/2019/03/22/
• mmis1000 6y ago
  I'd say it is a good way to get rid of port scan and password try error in logs Well, the password login isn't enabled in the first place, but the log is still full of these errors. That's annoying. The log file is far cleaner after I changed the port.
  • lucb1e 6y ago
    > the password login isn't enabled in the first place, but the log is still full of these errors Sounds like changing the port is treating the symptoms of the underlying logging problem you're having.
    • mmis1000 6y ago
      If you are open port on 22, you will have logging problem even the service on 22 isn't a ssh daemon. If you are open port on 80, someone will try /wp-admin on your server even it is a nodejs application. Whether it makes sense or not, whether it is possible to success or not do not matter. Most scanner just default to do this. The problem isn't password logging, because they can't success. The problem is log spam. If you open service on these, you are going to have log spam from random ip source.
• catern 6y ago
  Interesting analogy. You could extend the analogy to ASLR. ASLR randomizes the address just as you might randomize your SSH port. But no-one thinks of ASLR as "security by obscurity" - it's a mitigation strategy like any other. Thinking of the SSH port number as a "secret" in same way that libc addresses are "secrets" is an interesting and valuable perspective. It suggests that, like with ASLR, there should be some higher-level "linker" that gives this secret information (address of functions, SSH port number) to those who need it, and no-one else.
• Netcob 6y ago
  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.
  • kiallmacinnes 6y ago
    > Although I'm not sure how an unprivileged user would be able to stop sshd in order to take over that port. They just need to wait (or, leave their code running in wait) for an admin / system process to restart SSHD - e.g. when patching it.
    • als0 6y ago
      In theory an unprivileged user can't obtain privileged port numbers through programs because the permission would be denied.
      • kiallmacinnes 6y ago
        The post I was replying to was specifically referring to using a non-privileged port (2222).
        • als0 6y ago
          Sorry, I misread your comment.
  • als0 6y ago
    > potentially impersonating the SSH service Assuming the remote client has authenticated the host in ~/.ssh/known_hosts and assuming your unprivileged user hasn't got access to the host's private SSH keys in /etc/ssh then I'm not sure how they can really impersonate the service. On my system the private keys cannot be read by an unprivileged user. However, the trust-on-first-use model of SSH is an obvious Achilles heel.
• amadeuspagel 6y ago
  Without getting into exactly what security by obscurity means, I think what people try to warn against when warning against security by obscurity is advice that distracts from solutions that do not depend on obscurity. For example the advice to move your SSH port distracts from the advice to use a private key and disable passwords. But in the real world, there's no mechanism as secure as public key cryptography, so it makes sense to keep the mechanism secret, as added security. The author's examples of dead drops or frequency hopping offer nothing close to perfect security, and it would be a real improvement to keep them secret.
• forty 6y ago
  (Sorry if my question is stupid) why expose SSH on the internet rather than having it behind a VPN?
  • drdebug 6y ago
    I think SSH security is similar to that of a VPN (except for large installations where key management/revokation may be better handled by VPN tools), so for many people there's no need to use a VPN.
    • forty 6y ago
      Well it avoids cluttering the auth logs of all the machines with failed ssh attempts, which is, from what I understand, the main benefit of moving the ssh port to a non standard one. As a side benefit, it also adds a real layer of security (ie you would have to find a vuln in both openssh and openvpn for example). Key management for SSH can actually be pretty good, you can do pretty cool short lived certificate authentication with ssh using Hashicorp Vault for example. I would still not have my VMs have public IPs, feels like asking for troubles, for no real benefits.
• omgwtfbyobbq 6y ago
  Would SSH over Tor Onion Service be security by obscurity?
• MaxBarraclough 6y ago
  > I just came across another post on Hacker News talking about why you shouldn’t move your SSH port off of 22 because it’s Security by Obscurity. As greenduck already said, anyone making such an argument doesn't understand the issue of security by obscurity: it's not a problem when it's used as an additional layer of security, but it's a huge problem when it's used as the only layer of security. Personally I favour IP whitelisting, but I realise this has issues with scalability.
• Damogran6 6y ago
  Moving off 22 reduces logging...which reduces disk churn...which reduces power consumption... And it improves the quality of the logs that DO happen.
• deleted 6y ago
  [deleted]
• rishabhd 6y ago
  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.
• defend 6y ago
  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 https://github.com/moxie0/knockknock If you want to help secure the interwebs, host this tarpit to try to slow down network scanners: https://github.com/skeeto/endlessh https://github.com/skeeto/endlessh
• ppierald 6y ago
  I've always advocated it (whether you call it security by obscurity or not) simply because most of the scanners will not choose to pick any other port but 22, then systems like DenyHosts will provide higher fidelity about threats and less volume to pour over. Of course, whether you are on 22, 24, 2222, or whatever, you need to properly harden your sshd with certificates, ciphers, removing the unneeded/unsafe configuration parameters, etc., otherwise it just won't matter what port you are on.
  • outworlder 6y ago
    Be aware of potential security issues if you use ports greater than 1024, as those are unprivileged and any app can bind to them. If this is a single machine that only you have access to it may be fine. If that's not true (and it won't be if it is a machine owned by a company), then you are better sticking with privileged ports.
    • ppierald 6y ago
      Of course... just using the common ports that people often quote in the obscurity arguments. Harden first, obsecure second.
• kempbellt 6y ago
  Except it is. Moving your SSH port does nothing to change your SSH based vulnerability if an attacker knows the new port, but it makes it a lot less likely for you to be swept up in passive crawls. This is like arguing, "If your hide-a-key is under the backdoor doormat, you are no less secure than if you put it under the front doormat". It's easy for someone to say "I was dropping off a package" for a reason to be at your front door. Much more difficult to explain why you are in someone's backyard. Most attackers are opportunistic, take minimal risk, and want to keep costs low. Doing a full port scan on one IP is expensive in time and computation, and also has some risk. Unless they know for sure that it is worth the pay off, doing a quick "Tried turning the door knob" test is about all they will do.
  • ori_b 6y ago
    It's not a security measure, it's a noise reduction measure. It reduces the number of people jiggling the handle on your door, but if all it takes to get in is jiggling the handle, you have bigger problems.
    • kempbellt 6y ago
      Which is exactly what security by obscurity means... You are not wrong about having bigger problems if that's all it takes, but making access to a thing less obvious, even if it is super simple, is a form of security. This is like saying, keeping your cash in your front pocket instead of your wallet doesn't make your cash safer from pickpockets. Except, that's exactly what it does. If someone knows that your cash is in your front pocket, then sure, they could target that. But if you are trying to protect yourself from casual pickpockets that aim for wallets, then you have created a small buffer for yourself. Which is a form of security. It's not great security, but it is a layer of protection.
• snowwolf 6y ago
  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.
  • bityard 6y ago
    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.
    • sumedh 6y ago
      > Today, though, it doesn't matter. I get as many login attempts on my non-standard ports That is weird, I dont see any login attempts on my non standard ports on my multiple servers.
• trishankdatadog 6y ago
  Reupping my comment [1] from the last discussion: > Agreed: adding port-knocking and fail2ban in addition to passwordless should not be and are not silly ideas. [1] https://news.ycombinator.com/item?id=24446577 https://news.ycombinator.com/item?id=24446577
• SassyGrapefruit 6y ago
  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. Both are examples of "Security by Obscurity"
  • kristopolous 6y ago
    The parent changed his message so this is no longer in direct response but it's probably still valuable: By that logic so are passwords and the key itself, You simply have an "obscured" notch configuration on the grooves of the key. My ssh private key is also just a very uncommon sequence of bytes! It's all encompassing. So either your interpretation needs works, keys and passwords are insecure, or obscurity is actually totally fine.
    • opless 6y ago
      That's incredibly tenuous. Also I don't think you know much about asymmetric encryption or the SSH protocol either.
      • deleted 6y ago
• strictfp 6y ago
  In a sense, all security is by obscurity. Security-wise, your PIN is in fact pretty much equivalent to a random port.
• thrownaway954 6y ago
  hackers go after low hanging fruit 99% of the time. it's the reason why there are so many wordpress scanners out there.
• ww520 6y ago
  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.
  • lotyrin 6y ago
    If you're willing to depend on a secret, a VPN client certificate would do nicely...
• kerng 6y ago
  The author is splitting hairs, creating their own definition of the term without reference. When hair splitting, backing it up can help make a point. To my knowledge there is no official definition of the term, so both cases the author describes can be considered "obscurity". Interestingly Wikipedia states that with Security by Obscurity the main mechanism of defense is obscurity. That definition is interesting and that with that definition "obscurity" is certainly bad.
• awill 6y ago
  This only makes sense if it's the only form of security, which would be stupid. I had my personal server on p22, and got thousands of attempted attacks a day. I don't allow password authentication, only a key. I moved the default port not to reduce my risk too much, but to reduce the total number of attempts. Just by moving the default port, unsuccessful attempt dropped by 100x.
• robertlagrant 6y ago
  The problem with this is the terrible analogies. Frequency hopping is just that - hopping. Not picking a single frequency. Hiding a tank works for a while, and you'll move it pretty soon so there's no time to find it. Setting your SSH port to be something unusual, and leaving it forever, is not the same as those.
• giantrobot 6y ago
  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.
  • dheera 6y ago
    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.
  • a1369209993 6y ago
    Exactly: moving your SSH port isn't security by obscurity because it's not security in the first place.
    • geekamongus 6y ago
• rcarmo 6y ago
  I do this on the (very few) internet-accessible boxes I have for one very simple reason - it _significantly_ cuts down on the amount of junk connections and log entries, somewhere between a 1000/1 or 10000/1 ratio. All the rest (crypto, key setups, fail2ban or similar, etc.) is exactly the same as it would be on a "regular" setup, but at least I can actually _read_ the logs when I have to troubleshoot something else.
• shuringai 6y ago
  "Security by Obscurity is when you hide how a security measure works, not when you keep some part of it a secret." This is the net opposite of what Kerckhoff tells us. Very wrong. Let me quote Bruce Schneier on this: "If I hide $1million in a safe and hide the safe somewhere in the subway in New York, that's obscurity. If I do the same but hand you the safe right away and ask you to open it without the key, that's security". Nobody cares about whether your solution is buggy. If you assume any security based on the inability to learn something about the WORKINGS of it its broken (or more precisely just overhead because it's as good as nothing). You can only model that based on the inability to learn DATA (like a key/password).
  • danielrm26 6y ago
    If you look closely, you'll see that we're saying the exact same thing. Read Bruce's quote again. It's about hiding the mechanism.
• mrweasel 6y ago
  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.
  • paxys 6y ago
    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.
    • erdewit 6y ago
      I used to get gigabytes of logfiles from the SSH probes, but that has stopped since moving the port. That was the only reason for moving.
    • lima 6y ago
      > Bots don't care whether the service is on port 22 or 38692, they will just probe them all. Only if they really, really care about a particular host or IP range.
  • vorpalhex 6y ago
    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.
• yayr 6y ago
  the argument is very simple: - key for ssh on port 22 is only the ssh-key difficulty - key for ssh on unknown port is ssh-key difficulty + ssh-scan difficulty it is an asymmetrical solution: - for somebody with enough resources it is not much of an increase in difficulty - for somebody with insufficient resources it is a significant increase in difficulty so essentially, it is an effective way to fight of script kiddies without targeted interest. it is not effective against targeted attacks - best to not have open ssh ports at all on public servers but to put them behind vpn/firewalls with ip restrictions.
• deft 6y ago
  Instead of changing the port just secure your ssh server in general. Whitelist of login names, no password authentication and no root login at all.
  • als0 6y ago
    And Fail2ban if you want to temporarily block an IP after too many authentication attempts.
• phendrenad2 6y ago
  Security through obscurity is a free way to increase your security stochastically. It eliminates low-effort attacks, lowering noise, allowing you, the security professional, to focus on detecting high-effort attacks. Of course we shouldn't implement some security through obscurity and call it a day, but people who dismiss security through obscurity as not worth implementing at all are also foolish.
• shuntress 6y ago
  This is essentially just me shouting into the void but I really hate that for me (a common netizen) there is no realistic recourse against these constant attacks. I understand the technical issues involved but it is really disheartening to me that when it comes to malicious actors attempting to access and abuse other people's property the entire net's general response is basically "shrug can't win, don't try" By that I mean, I would not expect much to come of me submitting logs of constant penetration scans to the police.
• aritmo 6y ago
  An attacker would not bother to brute-force non-22 SSH ports. The mere fact that you bothered to chang the port is indication that you likely are not using common passwords either.
• deleted 6y ago
  [deleted]
• peter_retief 6y ago
  The other side of obscurity is to hide in plain site in fact changing ports might even attract interest. I keep port 22 because that is where I expect to find ssh and already spend too much time trying to remember things.
• mountainboy 6y ago
  First thing I do on any server is to disable ssh password logins and only allow login by public key. After that, I do not worry about ssh login attacks in the least, though I do run fail2ban to discourage such traffic.
• bill_mcgonigle 6y ago
  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.
• wanderr 6y ago
  This article was written today, in response to an article that made it onto HN 7 years ago?
• kodah 6y ago
  The author fails to mention that changing SSH to a non-privileged SSH port also has other security implications that can be exploited. The other example they gave that it's "more costly" to scan your host to find the non-standard port also barely holds water. It would be trivial to script such a scan and the relative time/compute that it occupies is minimal when you're conducting a dragnet of a pool of hosts, especially when parallelized across your own pool of hosts (which are potentially compromised, and thus coming from various host networks). I think generally when you hear people mock changing your SSH port it's because it's often done as a sort of high pass filter and then nothing else is done on top of that. That or it's done in lieu of real prevention techniques like establishing bastions with temporary credentials or OTPs. Now, I'd end with this with the usual guidance I give people in political or social realms: mocking people rarely teaches anything, it just dissuades action in the short-term. If you want people to stop being reckless with SSH then you need powerful visualizations and demonstrations of just how easy it is to find the skeletons in your closet from outside the fortress. Thank you for attending my TED talk.
• leepowers 6y ago
  Why bind a database to a local socket and not to a network port? Because it reduces the attack surface area. It doesn't mean the database is "secure": access permissions could be configured incorrectly; it could be missing security patches; etc. But closing off the port still increases security because an attacker has to compromise another system, or find a more obscure pathway to get at the database server. An attacker incurs an additional cost when trying to compromise the database. Why move SSH to a higher port? Same reason - it reduces surface area. However - does changing the SSH port _really_ add that much of a cost? For naive attackers - yes. A well configured firewall which detects and tracks SSH login failures, port scans, etc and issues IP bans is more robust. But even this only goes so far, especially for attackers who can orchestrate a large number of IP addresses.
• yk 6y ago
  It is precisely security by obscurity, it only helps against attacks one would not need to worry about in a well administered system. All the drive by traffic on port 22 is just trying to log in with absurdly simple passwords and two or three usernames, and if you have to worry about these, then you should set up public key authentication, not try to hide the port. And as a matter of fact, a nmap -A -p- target.tld will easily identify whichever port you have selected.
• donaldihunter 6y ago
  >Even if your enemy knows you’re camouflaged somewhere in the dessert I am here for this typo.
• orev 6y ago
  A lot of people don’t seem to remember (or weren’t around) when this phrase was coined. Security by/through obscurity very much referred to doing things like starting a bash shell on an obscure port so you could telnet to it and just have a shell (no login at all, and each host didn’t have a firewall either). Or naming a directory something like ‘...’ and people would overlook it in the ls listing. Or leaving a shell running on a serial/modem line assuming that no one would know the phone number to dial in to. Even a standard ssh install that allows password login on a regular port is already miles ahead of where we were a few decades ago.
• CodeWriter23 6y ago
  It’s actually defense in depth.
• euske 6y ago
  I think that "Security by obscurity is bad" is really a misstatement. The right version should be "Open design is better". The underlying assumption is that criminals are often smarter (or having more advantage) than defenders. But they probably do not outsmart the entire human intelligence, so there's a hope that an open design that actually survived can better protect us in a long run (because they're viewed and attacked by everyone). i.e. Individuals < Criminals < Collective Intelligence In this case, I don't think using an unusual SSH port is security by obscurity. Its design is already open; knowing the port number doesn't significantly change the threat model because SSH itself already provides a certain level of security.
• deleted 6y ago
  [deleted]
• ineedasername 6y ago
  I think it's important to remember that security by obscurity is not a primary line of defense, but limiting or hiding available information about your system is still a good practice. I might have the best home security system available, but that doesn't mean I'm going to make the details of that system or the contents of my house easily available information. Take all of the technical protection measures you can, but then also make it hard for attackers to gain any information as well.
• markstos 6y ago
  I tried port 2222 for a while, but scans were still quite common on that port. Plus, any unprivileged user can start a service on port 2222. Why trust connecting to that vs 22 which insures it was started by root?
• ncmncm 6y ago
  My solution is to bind SSH only to the wireguard interface, and open only UDP to the public internet. There is no way to discover which UDP ports are live.
• phloximaxi 6y ago
  This is not true. Moving the port doesn't increase security by itself. BUT. If you use it with portsentry, it IS security! - moving the port filters bots trying to connect - if an attacker tries to scan the open ports, will be immediately firewalled for that ip. This protects not only the ssh service, but all the listening services on the host! Separates the clients by behaviour. This can be bypassed only if the attacker spends a lot of time and IPs for the attack, which is a whole another level, because that is a very targeted attack and all of your security is under test.
• coverband 6y ago
  Just to make it clear: The article actually makes the argument that changing your default port is a good step with proven positives. (It seems to me that a lot of the commenters haven't really read the article and just assume the opposite based on the title.)
• WhyNotHugo 6y ago
  I like the "desert camouflage" metaphor. A person with camouflage may take an incredible amount of resources to ever find if hidden somewhere in the desert. Trying all the SSH ports is something that can be trivially scripted. It actually is, and it's relatively simple to do too.