[HN Gopher] Moving your SSH port isn't security by obscurity
___________________________________________________________________
Moving your SSH port isn't security by obscurity
Author : gempir
Score : 313 points
Date : 2020-09-21 11:33 UTC (11 hours ago)
(HTM) web link (danielmiessler.com)
(TXT) w3m dump (danielmiessler.com)
| throwawayffffas wrote:
| > 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.
| liability wrote:
| How many cases set up by how many operators have you actually
| seen?
| cedilla wrote:
| 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.
| pwinnski wrote:
| 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.
| dano wrote:
| 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.
| snowwolf wrote:
| 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 wrote:
| 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.
| leepowers wrote:
| 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.
| trishankdatadog wrote:
| 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
| SassyGrapefruit wrote:
| 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 wrote:
| 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 wrote:
| That's incredibly tenuous.
|
| Also I don't think you know much about asymmetric encryption
| or the SSH protocol either.
| kristopolous wrote:
| So if I have your private key and your hosts definition in
| your ssh config, you're still secure?
|
| Cool, send them to me and I'll show you otherwise. My email
| address is in my profile.
|
| The point was that nuance is important. Keyspace size, the
| cost and penalties of a guess, if any information leaks in
| the process, these are important.
|
| These cutesy memorable rhyming platitudes in any discipline
| are usually either meaningless or counterproductive.
|
| I could for instance, use a very long base64 url endpoint
| as effectively a shared password. If you look at the cost,
| leakage, and keyspace analysis you can tell why it works or
| it doesn't far more than the old obscurity aphorism.
|
| I think some of computer security theory could be taught
| via physical lockpicks pretty well so long as the students
| actually do the physical lockpicking act. I think the
| concepts translate well to the material reality especially
| if you have a large diversity of locks.
|
| It actually sounds like a pretty brilliant educational
| approach.
|
| Computer security through lockpicking. Requirements:
| introductory number theory, discrete mathematics, 2 or more
| programming classes
| [deleted]
| danielrm26 wrote:
| I think you're confused a bit here.
|
| The mechanism is known for a door lock. It's a lock with a key.
| What they don't have is the key.
|
| If you leave your door key, or RSA key, lying around where it's
| easy to find, well...that's a separate problem.
| rwesty wrote:
| And in this case you are putting the lock in a place that is
| not the doorknob, where an intruder will typically try to
| unlock the door.
| samdixon wrote:
| Albeit a now invisible knob that must be searched for via a
| door scan. While I don't personally switch my ssh port from
| default, I would imagine doing so would cut down on a ton of
| the noise from lowest common denominator ssh attempts.
| shiftpgdn wrote:
| My entire house nearly instantly becomes invisible to
| anyone doing a door scan. This is what an effective
| psad/fail2ban setup can do.
| wutwutwutwut wrote:
| I have changed some default ports and seeing the number of
| connection attempts drop from <many> down to close to zero
| was just nice. There are just fewer connections opened,
| fewer logs to analyze and so on. In my view, fewer
| connection attempts means less data to analyze which in my
| view is a security and cost benefit.
| garmaine wrote:
| What makes this even more ridiculous is by the most literal
| definition, most of modern cryptography is "security by
| obscurity." My TLS or SSH connection remains secure because my
| selected private key remains obscure and hard to find in a
| space of 2^128 possible keys. Only a handful of techniques
| (quantum key exchange, one-time pads) are not relying on
| obscurity for their security.
|
| Security through obscurity works perfectly well so long as you
| correctly quantify the size of the search space, the bits of
| information provided as hints, and the cost of searching--which
| basically describes what much of modern cryptography is about,
| at the primitive construction layer. By the same measure, a
| multi-million dollar cache in the American Rocky Mountains
| remained unfound for a decade despite there being a poem and
| short story filled with clues as to its location[1]. If I go
| totally off-grid for 6 months, and then come out of the
| wilderness saying that at some point during that wandering I
| cached my valuable possessions in a secret location, you're not
| going to find it.
|
| The admonition not to use security by obscurity is well-meaning
| but requires explanation. We shouldn't hide things in ad-hoc
| search spaces that haven't been adequately formalized. We
| should prefer mathematical puzzles which have well
| characterized properties. And generally that is good advice.
| But that doesn't mean we shouldn't also throw in whatever extra
| protections are convenient, even if they're ad-hoc or provide
| insufficient bits of security by themselves.
|
| [1] https://en.wikipedia.org/wiki/Fenn_treasure
| Zenbit_UX wrote:
| > 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.
|
| Yes, that was the takeaway from the article.
| craftinator wrote:
| So... Are you saying that moving your ssh port to a different
| address doesn't actually increase your security at all? In my
| practice it gets rid of ~95% of probes from people trying to
| break into my system. Whether it just signals that I know what
| I'm doing, or demands resources that the attackers aren't
| willing to give, I don't know, but it definitely has a positive
| effect on the security of my system.
| ReptileMan wrote:
| >So... Are you saying that moving your ssh port to a
| different address doesn't actually increase your security at
| all?
|
| Having a quagmire next to your castle walls don't makes your
| walls harder to breach, just buys you more time until the
| enemy gets there.
|
| It's not bad thing to have, but ... just don't build your
| walls lower and thinner next to the swamp.
| brobinson wrote:
| Building a house and putting the front door on the side or
| back of the house doesn't change the security of the door.
| Whether it has a weak lock or not doesn't depend on its
| location.
| DominoTree wrote:
| He's saying that it doesn't make your SSH configuration or
| SSH itself any more secure.
| SassyGrapefruit wrote:
| >So... Are you saying that moving your ssh port to a
| different address doesn't actually increase your security at
| all
|
| No I think if you read particularly the "Why all the hate..."
| paragraph you'll see I'm saying the opposite of that. There
| is nothing wrong with obscurity but in terms of security its
| the icing not the cake.
|
| By that I mean it will make a secure setup more secure, but
| its not enough on its own.
| enkid wrote:
| Aren't most SSH probes trying to break weak passwords? If so,
| having a strong password is much much more important than the
| port SSH is on.
| bostik wrote:
| Really, you should not be using passwords _at all_. We have
| key-based authentication for a reason.
| enkid wrote:
| Totally agree.
| worik wrote:
| Walk and chew gum.
| joking wrote:
| it doesn't increase the security at all, but is really
| convenient as you filter most of automatic attacks and have
| much less noise to filter through.
| yoz-y wrote:
| Would banning any IP that tries connecting on 22 increase
| security?
| joking wrote:
| how do you connect rightfully then? at that point is
| easier to have and access rule on the firewall and only
| accept connections from the allowed ips.
| bee_rider wrote:
| You could do something like that, but you'd have to write
| it yourself. If you want to ban IP addresses, fail2ban is
| probably an easier starting point. Plus users who
| authenticate with passwords might occasionally make typos
| and get banned, incentivizing better logon techniques.
| tasssko wrote:
| Yes the attack surface before and after is the same ergo this
| is not security at all. The difference between 22 and 2222 is a
| nominal delay on a port scan.
|
| It would be far easier and more convenient to use a ip
| whitelist and a firewall to protect access to 22.
| enkid wrote:
| The problem is when you only use security by obscurity. Just
| changing then port does not do enough to make your insecure
| application secure. For example, if you have a Windows 2000
| server on the internet, it doesn't matter what port you change
| IIS to, it's going to get hacked.
|
| To use your analogy, if your lock is broken, or can be broken,
| it doesn't matter where you hide the key.
| machello13 wrote:
| > The problem is when you only use security by obscurity.
|
| He literally says this exact thing in his comment.
| enkid wrote:
| I'm agreeing with him.
| rconti wrote:
| You're missing the point; the point is that it's only bad when
| it's used _instead_ of (say) disabling SSH if it 's not needed,
| or using the latest release, or using secure ciphers.
|
| Doing all of the above _as well as_ changing your sshd port
| will only improve your posture.
| crazygringo wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| strictfp wrote:
| In a sense, all security is by obscurity. Security-wise, your PIN
| is in fact pretty much equivalent to a random port.
| [deleted]
| aritmo wrote:
| 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.
| teddyh wrote:
| This post explicitly assumes that port scanning is "costly". By
| all accounts, this is not true anymore.
| __m wrote:
| 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.
| Wowfunhappy wrote:
| Alternate take is that it is security by obscurity, and that's
| _good_ as an extra layer of protection.
| zeepzeep wrote:
| 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 wrote:
| 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 wrote:
| 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)?
| eythian wrote:
| A bot exploiting a new SSHD vuln that my autopatching
| hasn't caught up with yet.
| cthalupa wrote:
| 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.
| pwinnski wrote:
| Sometimes, as the saying goes, I don't need to outrun the
| bear, just the other campers.
|
| If you're targeting me specifically, then yes, moving the
| port is pointless. But while I have't stopped you, I've
| avoided a half-dozen script kiddies running a script that
| takes advantage of a new 0-day.
| rocqua wrote:
| That extra time, and the effort it takes you to get through
| this obscurity, all makes it easier for the blue team to find
| you.
|
| It is not enough for a perfect defense, but it can help as
| defense in depth.
| msla wrote:
| It can be part of defense-in-depth: Move SSH to a nonstandard
| port and then completely hide it from anyone who does a port
| scan or tries SSH on the wrong port. I'm sure that's occurred
| to someone, somewhere in the world.
| greenduck wrote:
| 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.
| wnevets wrote:
| >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.
|
| This seems to be the case for a lot of things in the
| technology. Someone shares an idea, it gets popular and through
| the years of "the telephone game" the original indent is lost
| but everyone is running around treating it as gospel.
| Everything from alige to security by obscurity.
| zeepzeep wrote:
| 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 wrote:
| 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 wrote:
| Go to 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."
| tgflynn wrote:
| Hmm. There's some more information here: https://www-
| archive.mozilla.org/projects/netlib/portbanning.
|
| I'm up-voting your original comment because it does seem
| like a potentially valid concern, at least worthy of
| discussion, and shouldn't be down-voted in my opinion.
| pwinnski wrote:
| So moving my SSHD port opens me up to the wide array of
| SSHD exploits that run inside of Firefox?
|
| I'm not sure that web browsers are a popular vector for
| network exploits. Counting on anything client-side is not
| a wise approach to network security.
| tgflynn wrote:
| Any piece of javascript code on any website you visit is
| going to be running inside of Firefox on your local
| network.
|
| I don't know how widespread these kinds of attacks are
| but they are reasonably well known which is why these
| port blacklists were implemented in the first place:
|
| https://www-
| archive.mozilla.org/projects/netlib/portbanning.
| liability wrote:
| Uh, that doesn't make much sense. If you point a browser at
| an IRCd it will simply not work. Where's the security issue?
| zeepzeep wrote:
| https://en.wikipedia.org/wiki/Inter-
| protocol_exploitation#Ex...
|
| You could join and spam an IRC server via javascript in the
| past.
|
| Now if you try it you get something like
| NS_ERROR_PORT_ACCESS_NOT_ALLOWED.
|
| If you move to a non-standard port javascript can talk to
| your internal IRC again.
| liability wrote:
| If your IRCd allows an unauthenticated connection to
| start spamming like that, changing the port so a browser
| can't do it is just wallpapering over the real problem.
| Anybody that cared to could just use any other software
| to spam your IRCd.
| zeepzeep wrote:
| Yes, a public & open IRC would be another problem... but
| that's not what I'm saying. I'm talking about an internal
| server.
|
| > Anybody that cared to could just use any other software
| to spam your IRCd.
|
| No they couldn't use other software. They couldn't access
| the server, cuz they are not inside of the network.
|
| Their javascript is inside the network tho, that's why
| browsers implement this port blacklist.
|
| Moving an internal app to a non-standard port might
| expose it to malicious javascript, that's all I'm saying.
| liability wrote:
| The issue remains that your ircd is still wide open,
| waiting for somebody more creative to find another way of
| opening connections inside your LAN on arbitrary ports.
| Counting on browsers to keep your network secure is
| foolish.
| zeepzeep wrote:
| > The issue remains that your ircd is still wide open
|
| Wide open, from within the LAN... not many consider
| internal apps wide open. Besides browsers, you need
| actual hacking to reach internal services, a SSRF for
| example. Or real remote code execution and at that point,
| you have other problems.
|
| > Counting on browsers to keep your network secure is
| foolish.
|
| I think what you're saying is: treating the internal
| network as secure is foolish. That I would agree with.
|
| I never said you should rely on the browsers port
| banning. It's the other way around, people usually don't
| even know you can talk to IRC over HTTP and therefore
| don't even consider it a risk and are protected without
| even knowing.
|
| My point is not "use port banning as security measure".
| My point is just: if you move apps to a non-standard port
| you might expose it to browsers, so better use the
| standard!
| [deleted]
| sascha_sl wrote:
| 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.
| ldiracdelta wrote:
| Defense in depth. I don't care if the first level of defense is
| a speedbump. I don't absolutely depend on it, but why should I
| _not_ put the speedbump there when it is so cheap and easy.
| staticassertion wrote:
| The reason is because obscure things tend to be less well
| understood. SSH port being on another port isn't a case of
| that, but it isn't security by obscurity.
|
| Security by obscurity might be "I use a non standard PDF
| viewer, therefor I am safer". But a non-standard PDF viewer
| may also be subject to less auditing, may not have pressure
| to improve its security, etc. It's an unknown both to the
| attacker but also to you. This is where security through
| obscurity is actually a problem.
|
| It also makes it harder to threat model. Do you consider your
| obscurity as a mitigation when you consider threats to your
| system? It leads to the temptation of "well, but the attacker
| would have to _know_ that I 'm using this PDF viewer", and
| then you start to treat that as a mitigating factor. It can
| be a dangerous thing.
|
| _Secrets_ are not obscurity. _Randomness_ is not obscurity.
| People seem to make that mistake the most.
| teddyh wrote:
| Because speedbumps are annoying to everybody, and wastes
| everybody's time with unnecessary complications.
| zymhan wrote:
| It is trivial to specify the SSH port number
| thinkharderdev wrote:
| It is trivial if you actually know what the port number
| is and you are only talking to one server and the non-22
| port is static. Now imagine you have code that is
| connecting to thousands of different servers on different
| ports and they can change at any time if someone who owns
| one of those servers decides to rebuild their machine and
| changes the SSH port. Nothing is trivial at scale. That's
| not say that is always a valid consideration but
| standards and conventions exist for a reason.
| devwastaken wrote:
| There are very few people who can create proper security first,
| and then a sane level of obscurity to mitigate attack.
|
| It's the same as saying don't roll your own encryption. There's
| people out there that could, but for the other 99.9% its false
| security.
|
| Generally what happens is people will use their non programmer
| "common sense" and think "nobody will be able to figure it out
| so it's good". Obscurity is something you do because you know
| how to properly break rules.
| UncleMeat wrote:
| > 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.
| thrownaway954 wrote:
| hackers go after low hanging fruit 99% of the time. it's the
| reason why there are so many wordpress scanners out there.
| kodah wrote:
| 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.
| maitredusoi wrote:
| If you move it to a port lower than 1024, it is ! ;)
| omgwtfbyobbq wrote:
| Would SSH over Tor Onion Service be security by obscurity?
| catern wrote:
| 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.
| ww520 wrote:
| 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 wrote:
| If you're willing to depend on a secret, a VPN client
| certificate would do nicely...
| [deleted]
| rishabhd wrote:
| 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.
| mrweasel wrote:
| 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.
| the8472 wrote:
| 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. Host *.corporate.tld Port
| 38237
| mrweasel wrote:
| That's also assuming that all your servers are under one
| domain. We manage other peoples servers, so they are normally
| under that customers domain, rarely ours.
| Yizahi wrote:
| 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.
| mrweasel wrote:
| I like that. If you do move the SSH port, do it everywhere
| and randomly, then it's not unexpected. I still feel that
| other security measure should be taken first, most of which
| would make moving the port pointless.
| paxys wrote:
| 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.
| lima wrote:
| > 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.
| erdewit wrote:
| 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.
| vorpalhex wrote:
| 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.
| mrweasel wrote:
| Depending on what your tasks are, distributing ssh configs to
| 100+ people isn't that feasible, but yes, ssh configs help,
| but you're back to ensuring that the information is correctly
| distributed. Chances are that the servers and users are
| managed somehow, while laptops and workstation may or may not
| be. You could use a jump host, but then why not just
| whitelist the IP for the jump host?
|
| Just disabling password logins is just as good or better than
| moving the port. Don't want your logs to explode: logrotate!
|
| If it's just for a hobbyist on a consumer ISP then sure move
| your port, implement port knocking, use VNC, I don't care.
| For business, moving the SSH port is a weird thing to do,
| it's not that effective and you should already have other
| security measures in place that makes moving a port
| pointless.
| MaxBarraclough wrote:
| > 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.
| BLKNSLVR wrote:
| 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.
| vbezhenar wrote:
| 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 wrote:
| At least an attacker (who doesn't have root) can't read a
| systems' SSH host keys.
| vbezhenar wrote:
| 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 wrote:
| One note on the article, though - if you're camouflaged in the
| _dessert_ , that's pretty obscure.
| jkingsbery wrote:
| 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.
| achillean wrote:
| 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&...
| ramtatatam wrote:
| 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 wrote:
| 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 wrote:
| 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 :)
| peter_retief wrote:
| 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 wrote:
| 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.
| yayr wrote:
| 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.
| dvfjsdhgfv wrote:
| 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. )
| defend wrote:
| 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
|
| If you want to help secure the interwebs, host this tarpit to try
| to slow down network scanners: https://github.com/skeeto/endlessh
| axegon_ wrote:
| 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 wrote:
| 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 wrote:
| 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_ wrote:
| 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.
| hatch_q wrote:
| Noise is not high on other ports. Noise on mine (when i
| changed port from 22) went from 100+ attempted logins every
| hour to 1 per week.
| axegon_ wrote:
| Well that's you, here's mine:
|
| > alex@srv002 ~ cat /var/log/auth.log | grep
| 'Disconnected\sfrom.*\\[preauth' | wc -l
|
| > 432
|
| All of those are from today...
| awill wrote:
| 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.
| Damogran6 wrote:
| Moving off 22 reduces logging...which reduces disk churn...which
| reduces power consumption...
|
| And it improves the quality of the logs that DO happen.
| rdtsc wrote:
| 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.
| Zenst wrote:
| 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
|
| I used an skey 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.
| bill_mcgonigle wrote:
| 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.
| fabian2k wrote:
| 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.
| robertlagrant wrote:
| 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.
| bibelo wrote:
| Thank you Sir
| ppierald wrote:
| 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 wrote:
| 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 wrote:
| Of course... just using the common ports that people often
| quote in the obscurity arguments. Harden first, obsecure
| second.
| fooblat wrote:
| 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 wrote:
| Anybody actively monitoring their sshd logs would see clear
| value in changing the port. It dramatically raises the S/N of
| those logs.
| wanderr wrote:
| This article was written today, in response to an article that
| made it onto HN 7 years ago?
| Netcob wrote:
| 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 wrote:
| > 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.
| orev wrote:
| 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.
| nmaludy wrote:
| 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.
| vbezhenar wrote:
| 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".
| gen220 wrote:
| This made me think of a fun toy-idea.
|
| Let the server and client share a secret. Use that secret to
| encrypt the UTC date (2020-09-21), and sample some decimals
| from the first few bits (adding 100 or so, to avoid low-
| ports).
|
| You could use that mechanism to rotate ports every 24 hours.
| This way, the bots wouldn't be able to _learn_ the ssh port
| for more than 24 hours, without the shared secret.
|
| Sounds like fun, or an easy way to lock yourself out of a box
| by mistake, depending on your perspective. :)
| CobaltFire wrote:
| You've reinvented HAVE QUICK[0]
|
| [0]https://en.wikipedia.org/wiki/HAVE_QUICK
| SahAssar wrote:
| Seems like a more effective way would be to use port
| knocking?
| syshum wrote:
| root:root would be crazy, I would only use root:toor5 then I
| am secure for sure...
|
| /s
|
| //Side note, you should never allow login as root, and you
| should not really allow remote password login at either, only
| keys
| yjftsjthsd-h wrote:
| > root:root would be crazy, I would only use root:toor5
| then I am secure for sure...
|
| That's a minimal (read: insufficient) improvement, but if
| it were behind a real layer of security then it would
| strictly be an improvement.
|
| > Side note, you should never allow login as root, and you
| should not really allow remote password login at either,
| only keys
|
| I'm on board with keys, but why not allow root? If it's
| secured by a key, what's the harm?
| zerkten wrote:
| When you have a large base of installations in a big
| organization, this can make a difference in practice because
| your incident responders have to sift through less data. This
| makes much less of a difference when you have great log
| management and SIEM systems in place. Many places don't, and
| some hygiene can make a difference at times.
|
| When I see this in practice, the first thing I check is how
| auth is being done and the overall security of the host.
| Then, I look for how they are doing SIEM because cleaner logs
| is a common reason and they'd be better off with a more
| proactive management approach.
| LinuxBender wrote:
| 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.
| Smar wrote:
| I get thousands of tries in a day to a newly installed host
| using IPV4 nowadays.
| heavenlyblue wrote:
| > 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.
| doggydogs94 wrote:
| Don't disable port 22; just neuter it. If port 22 is
| disabled, the attacker will look elsewhere in your system.
| vlod wrote:
| Do you have a suggestion on how to do this?
| ogre_codes wrote:
| An SSH Tarpit is a good way:
|
| https://nullprogram.com/blog/2019/03/22/
| vlod wrote:
| thanks!
| giovannibajo1 wrote:
| https://github.com/cowrie/cowrie
| tensor wrote:
| This is an interesting point. Imagine if you put a fake SSH
| agent on 22, it responds just like SSH but never allows a
| login. Would it make it even less likely that someone would
| bother trying another port?
| peder wrote:
| Obviously the next step here is a fake SSH agent that
| allows logins to a little sandbox.
| Sohcahtoa82 wrote:
| I'd be weary of that. Sandboxes have been escaped.
| jrockway wrote:
| I don't think you would ever let them touch OS-level
| resources. There are plenty of third-party ssh server
| libraries where you just get a Reader and a Writer to the
| remote end. When they connect, you write "root@cool-
| computer# ". When they send bytes, you discard them, then
| print "root@cool-computer# " again.
|
| While obviously accepting a TCP connection and allocating
| resources on your computer is more risky than just
| ignoring the connection, presumably it would be fun to do
| this, which is a good reason for doing something. You can
| set a memory limit, file descriptor limit, etc. and just
| crash if they're exceeded. You can run your little fake
| ssh daemon in gvisor and protect against attacks nobody
| even knows about yet. All in all, it would be pretty low
| risk, and also pretty interesting.
| isbvhodnvemrwvn wrote:
| Probably a bad idea, one vulnerable service invites
| people to look for more.
| yjftsjthsd-h wrote:
| Depends what we mean by sandbox. I wouldn't make a chroot
| the honeypot, but I don't see an issue with a program
| that just simulates a shell but doesn't allow exec or
| real fs access, for instance.
| drtillberg wrote:
| And the next beyond that is a sandbox that contains
| simulated data....
| throwawaynothx wrote:
| honeypots are obvious.
| giovannibajo1 wrote:
| https://github.com/cowrie/cowrie
| just-juan-post wrote:
| They won't and that's the point of the OP.
|
| "They" are just a bunch of bots that try to hit 22 once and
| that's it. If it's open report it's open if not then move
| onto the next target.
|
| The only time a human is going to look for SSH on non-22
| ports is when they are actively attacking you or your
| organization.
| nickmooney wrote:
| Moving SSH to a non-standard port is helpful only to reduce
| log noise coming from untargeted attacks. If an attacker is
| looking at _your_ system, your attack surface is the same
| no matter where your SSH daemon is bound. I don 't think
| it's worthy any extra effort to "distract" attackers like
| this.
| rootsudo wrote:
| It depends, many people do not do a full NMAP scan. Takes
| to much time.
|
| Then again, is port knocking security by obscurity enough?
| teilo wrote:
| I gave up obscuring years ago, and just use fail2ban.
| mobilio wrote:
| Fail2Ban is fantastic tool.
|
| But as soon as you found that "PermitRootLogin" can be set
| with no then all brute forces become useless since they can't
| match combination of user/password.
| acdha wrote:
| fail2ban has other uses: it prevents non-root user error
| (oops, one of your contractors reused a password...), it
| significantly reduces log noise, and it protects against
| any future exploit which doesn't always work on the first 3
| tries.
| lqet wrote:
| Dito, a combination of forbidden root login, an obscure
| username, fail2ban and disabled password authentication
| worked well for me for the last 10 years. It's also quite
| simple to set up. The important part is to double and triple-
| check each step so that you don't lock yourself out (which
| has happened to me multiple times in the past, of course).
| sneak wrote:
| You don't need fail2ban if you've disabled password
| authentication. fail2ban exists to prevent password
| bruteforcing attempts.
| lqet wrote:
| True, but I _still_ prefer to completely block IPs who
| tried to log in via SSH and failed multiple times.
| TheAdamAndChe wrote:
| Sure, but enforcing best practices at all times can be
| tedious and unnecessary sometimes.
| icelancer wrote:
| You may have summoned tptacek with that.
|
| (He would argue to turn off passwords and use keys only)
| xxpor wrote:
| IMO fail2ban is still useful just to cut down on the noise.
| icelancer wrote:
| Yeah, I still support servers that have (strong)
| passwords without keys. I use fail2ban on them.
| pacija wrote:
| I use source tracking rules on pf protecting my servers and
| firewall itself:
|
| https://www.openbsd.org/faq/pf/filter.html#stateopts
| bronson wrote:
| Now that botnets are brute forcing from thousands of unique
| ips, fail2ban doesn't offer much on my servers anymore. I've
| stopped installing it.
| pnutjam wrote:
| My logs still show repeated attempts by the same IP. Lots
| of 1 and 2 tries, but multiple IP's with hundreds or
| dozens.
|
| Keep forgetting to enable fail2ban.
| jldugger wrote:
| If the attackers are using botnets to distribute the load
| across IPs, then perhaps we need to distribute the
| detection across IPs:
| https://www.abuseipdb.com/fail2ban.html
| programbreeding wrote:
| I used to manage VoIP systems and VoIPBL[0] was amazing.
|
| "VoIPBL is a distributed VoIP blacklist that is aimed to
| protects against VoIP Fraud and minimizing abuse for
| network that have publicly accessible PBX's"
|
| It's very similar to what you linked but is targeted to
| catching VoIP abuse.
|
| [0] https://voipbl.org/
| hn_acc_2 wrote:
| Just curious, what problems does fail2ban suffer with
| thousands of unique ips? (A crowded iptables I guess...)
|
| I still use it with a super oppressive jail time and few
| retries, with a few whitelisted IPs and it seems to work
| ok.
| rtkwe wrote:
| I think they're saying it doesn't stop brute force
| attacks because the botnet will just try with another IP.
| jldugger wrote:
| I think the concern is a botnet with n IPs is that
| fail2ban tracks individual IPs, so if you have any kind
| of grace period before bannination, they get a linear
| speedup of n, and if there's an expiration period, get to
| try n times harder than a single bored script kiddie.
|
| Worse, from an economic perspective, theres enough hosts
| listening on port 22 that a bot can try instead while
| they wait for timeouts, so you're not really imposing a
| cost on them. If you view running a botnet as a form of
| multi-armed bandit problem, the best you can really do is
| limit the economic value by slowing them down a tad
| versus their many, many other options.
| mobilio wrote:
| F2B support subnets:
| https://github.com/fail2ban/fail2ban/issues/2261
| Twirrim wrote:
| 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.
| cheschire wrote:
| > just one part of the steps I take with that machine.
|
| You may be interested to know this is called "Defense in
| depth".
|
| https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%.
| ..
| sllabres wrote:
| The articles summarizes
|
| > It's where you keep the mechanism secret, not the key.
|
| I think this can be, as you write, defense in depth if the
| secret of the mechanism is not the only defense.
|
| As example the block cipher for the Common Scrambling
| Algorithm
| https://en.wikipedia.org/wiki/Common_Scrambling_Algorithm
| has been secret. As it seems that has delayed the analysis
| of the system for about 8 years, but not damaged the
| procedure.
| babadaba wrote:
| Or you could say, security by obscurity is one of the
| layers of their defence in depth strategy.
|
| Edit: I believe you are implying that they used "security
| by obscurity" incorrecty, which I don't believe they did.
| If I read that wrong, my bad!
| a1369209993 wrote:
| Technically defense in depth refers to multiple _effective_
| security measures (like cryptographic login), so security
| by obscurity isn 't actually part of it.
|
| (Moving SSH port plus something like fail2ban could be
| considered defense-in-depth against the incidental DDOS-
| like issues, though.)
| huhtenberg wrote:
| Also anecdotally, I've been running SSH on the same 30xxx
| port since ~2004, including a cluster, which ran a public-
| facing service that _was_ a popular target for various forms
| of abuse.
|
| There was not a single brute force attempt. None.
| throwawaynothx wrote:
| Do you know if he ran the honey pots on the same server? if so
| that's why it received 0. the bots hit 22 and stopped.
| ryanlol wrote:
| It's an useless anecdote because SSH bruteforce attempts are
| not a threat and cost you nothing.
| selfhoster11 wrote:
| They cause some real work because of the log noise they
| create. It's easier to see targeted SSH attacks if all the
| undirected attacks are filtered away.
| lsllc wrote:
| This is absolutely true. I use fail2ban and I often find
| that it's using rather more CPU than I'd like. Sounds like
| moving my SSH port might solve that!
| gruez wrote:
| What would be indications of "targeted" ssh attacks, and
| what can you do in response?
| sascha_sl wrote:
| The fact that someone bothered to scan the entire range
| (or find your port at random) might indicate that they're
| specifically targeting you, and just being aware of that
| is an upside.
| gruez wrote:
| >and just being aware of that is an upside.
|
| but what can you realistically do with that knowledge?
| BLKNSLVR wrote:
| Infinitely more than you can do without that knowledge
| sascha_sl wrote:
| Argue for more security budget with management. If you
| can make this sound dramatic enough...
| soneil wrote:
| If you get 10,000 attempts on port 22, you're probably
| connected to the internet. If you get 10,000 attempts on
| port 63290, someone has taken a specific interest in you.
| elmo2you wrote:
| > 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 wrote:
| 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.
| elmo2you wrote:
| > Botnets and fast networking stacks like DPDK have made
| port scanning the entire Internet a much more viable
| proposition than 20 years ago
|
| True indeed, yet even today I have seen little evidence
| of scanning beyond standard ports (pretty much the same
| as in the past). Criminals are opportunistic by default
| and tend to go for low hanging fruit (standard ports,
| with standard server config). I certainly did see in
| increase on standard ports. Even while full range
| scanning has become more feasible, I have not seen much
| evidence of its use.
| mercer wrote:
| That doesn't invalidate the observation (which I share)
| that these attempts are almost 0 when using a different
| port. It reduces logspam and if I start getting lots of
| brute force attempts on my non-standard port, this is
| useful and meaningful information (someone cares enough
| to do this).
| iso1631 wrote:
| > takes only one insufficiently trained employee/intern for
| a potential breach
|
| How? If they've leaked their key, why do you assume the
| port hasn't leaked too? On the other hand if they haven't
| leaked their key how would they get in?
|
| Or are you allowing password authentication like it's 1999?
| elmo2you wrote:
| > Or are you allowing password authentication like it's
| 1999?
|
| That is assuming you have such authority or technical
| means. If you're maintaining systems for a company,
| there's a good change that the product vendor simply
| won't allow fucking around with their system like that
| (ergo: yes, in practice you are indeed stuck with your
| 1999 authentication).
|
| I'm not saying that it is good security (that's why
| layers security is often paramount), but it is situation
| I've encountered more than a few times.
|
| Great for you, if you are GOD on all the systems you work
| with. Even then, your client/employer might simply tell
| you to stuff your objections and accept the bad
| authentication policy, because to them the risks are
| simply not worth the business disruption. I totally agree
| that is a flawed argument. But decisions usually aren't
| always (if ever) called on valid arguments.
|
| Good for you, if you are in a position where you never
| had to deal with such real life situations.
| scaryclam wrote:
| Heck, some cloud providers have password logins by
| default. Since the instances are easy to setup I'd
| imagine many companies operating with a no-ops situation
| are vulnerable and don't even know it.
|
| And then there are side projects. I remember being
| educated enough to know better, but doing it anyway as
| the server was a $5 digital ocean droplet, used to run a
| tiny minecraft server for some friends. Got brute forced
| and spent the next two weeks red-faced, trying to get DO
| to allow network access again so I could at least grab a
| backup before nerfing the droplet.
|
| Now I use a basic ansible setup to automate changes to
| sshd so I don't have any excuse to be stupid again.
| deckard1 wrote:
| Not sure what you're arguing here. You either have
| control over sshd or you don't. Or are you really
| suggesting you can change the port of sshd but aren't
| allowed to disable password auth?
|
| I'm a software engineer, so if my company gets hacked via
| ssh that's really not my problem. Worrying about such
| things would make me a busybody. But if you're a system
| admin and can't properly do your job, then I would
| seriously start looking for a new place to work. They
| will get hacked and you will be the guy that gets blamed.
| elmo2you wrote:
| > Not sure what you're arguing here. You either have
| control over sshd or you don't. Or are you really
| suggesting you can change the port of sshd but aren't
| allowed to disable password auth?
|
| First, you'll have to separate two things here. One is
| the technical ability to control sshd, the second whether
| a company will allow you to tinker with the auth policy
| (whether that is password login, password login with only
| strong passwords, or rsa/ecdsa key access only).
|
| The latter has nothing to do with control and only with
| what decision makers allow you to do (that sometimes is a
| large product vendor, not allowing anything beyond what
| they ship). If you work in a place where you have full
| control over the systems you work on, great for you. I
| can ensure you that it is not the norm (unless we're
| talking about hobby projects or projects with exclusive
| personal ownership).
|
| As for the technical aspect, keep in mind that changing
| the public facing ssh port might not even be done on the
| host itself, but e.g. in port forwarding table in a
| router/firewall. This might not even always happen
| because it's technically impossible to do it on the box
| itself.
|
| I'm pretty certain that tinkering with a box is regularly
| discouraged (especially if it is managed by some
| orchestration or vendor specific control/update tool),
| while effectively the same can be done by changing a
| router/firewall. There's a lot more things to be said
| about that, but please take it from me that hacking
| around in a systems you have not build yourself isn't
| always a bright idea (and it happens to be a very common
| situation).
|
| > But if you're a system admin and can't properly do your
| job, then I would seriously start looking for a new place
| to work.
|
| That's an interesting theory, but frankly not how I think
| the real world (usually) works. As a system admin you are
| there to solve problems for a client or employer. You can
| (and should) of course always warn for potential dangers,
| but refusing work or quitting a job/assingment because
| you're not getting full control over a system .. good
| luck with that. It is simply not an acceptable position
| in many situation. You must be in really high demand if
| you want to pull stunts like those and still have any
| work after a while.
|
| Maybe it works different in software engineering land,
| but I highly doubt it. When was the last time you quit a
| job, because you preferred a different library or
| framework over the one your superiors/client dictated?
|
| Please don't get me wrong. On a personal level I'm very
| principled about what I choose to work on or with (and
| what I refuse to take part of). But at the end of the day
| we are professionals, here to solve problems. If we can
| and a client/employers is willing to accept the risks of
| an imperfect solution that fits in their requirements, it
| ultimately is their call and responsibility. All within
| reason, of course.
| icedchai wrote:
| They fill the logs with noise. That's "something." I finally
| set up fail2ban a while back... it works wonders.
| gruez wrote:
| Do people even read the logs? What value does it add
| compared to just monitoring successful logins?
| cedilla wrote:
| There's a lot of value. For example, if you see failed
| logins against random user names like "dbadmin" or "root"
| it's likely just random scanning, but what if suddenly
| lots and lots of valid user names appear?
| nkozyra wrote:
| That's a great point, but I get back to the root
| question: who's actually looking at this? If people are
| examining logs it's usually for a particular trigger or a
| problem and filtering that signal from the noise is hard.
| jldugger wrote:
| > who's actually looking at this?
|
| Well, your security team, post incident. But also
| automated systems like fail2ban.
| thelamest wrote:
| It's more typical of the servers-as-pets than servers-as-
| cattle scenario, but sometimes one is simply curious [or
| extra cautious]. SSH honeypots exist at least in part for
| this reason.
| Sohcahtoa82 wrote:
| Likely, nobody is directly looking at the logs.
|
| But they might be using software that automatically
| raises an alert when it sees repeated login attempts for
| a valid username.
|
| Isn't that one of the purposes of Splunk?
| cthalupa wrote:
| grep and zgrep will work wonders for checking for actual
| usernames in these logs even if they have significant
| amount of spam in them.
| gruez wrote:
| >but what if suddenly lots and lots of valid user names
| appear?
|
| then what are you going to do?
| cedilla wrote:
| Well that would highly depend on what I'm seeing. If it's
| a single user there might be an attack on the way against
| that user. If it's multiple users, there might have been
| a compromise of some credentials.
|
| It's definitely something you need to investigate.
| sokoloff wrote:
| At a minimum, spend some of my limited time and attention
| on this issue rather than the 100s of other things that
| might be clamoring for my time.
| wbl wrote:
| What are you going to do to solve that issue?
| elmo2you wrote:
| Did you ever had the "pleasure" of a server grinding to a
| halt because the logs filled up all the space? To where
| you had to mount the disk to another system and clean it
| up before it wants to boot from again. Can be a bitch if
| it's a machine on a remote location. Not everything is
| cloud (yet) these days.
|
| Granted, there usually is a lot more at fault when you
| run into such problems, but I find people not looking at
| logs a rather weak argument for letting them get spammed
| full with garbage. Certainly terrible hygiene, at least.
| Vvector wrote:
| Keeping the log file on the boot partition was the first
| mistake
| elmo2you wrote:
| > Keeping the log file on the boot partition was the
| first mistake
|
| Wrong assumption. With logs on a full system (but not)
| disk, your system can still grind to a halt during boot.
| Sure, if you do have access to the bootloader, you can do
| an emergency/recovery boot. But you do not always have
| that on systems build by others (especially product
| vendors).
|
| I would not be making this point if I had not run into
| situations where this was an actual problem. I can assure
| you it was never the result of my personal bad
| architecture or maintenance and almost exclusively while
| dealing with third party products.
|
| It would be valid to argue they should get their shit
| together, but the reality is that at the end of the day,
| companies buy systems like these and you still will have
| to deal with them.
| cthalupa wrote:
| >Did you ever had the "pleasure" of a server grinding to
| a halt because the logs filled up all the space?
|
| Everyone should be using logrotate, and if they actually
| read the things, shipping logs to ELK or Splunk or
| Greylog or whatever.
| elmo2you wrote:
| > Everyone should be using logrotate, and if they
| actually read the things, shipping logs to ELK or Splunk
| or Greylog or whatever.
|
| Certainly they should. That is, if they have that much
| control over the server and if it's not some legacy
| system build by some defunct organization or John Doe. I
| do not disagree with your theory, on the contrary. But
| then there is reality, where this theory isn't always
| feasible.
| gruez wrote:
| >Did you ever had the "pleasure" of a server grinding to
| a halt because the logs filled up all the space?
|
| I've never seen this issue on any systems I manage,
| mostly because they all have log rotation.
|
| >but I find people not looking at logs a rather weak
| argument for letting them get spammed full with garbage.
| Certainly terrible hygiene, at least.
|
| Why is it weak argument? If it's something that doesn't
| materially impact you, why should you expend effort into
| remediating it? Hygiene is only important for things we
| interact with on a regular basis. We as a society don't
| care about the hygiene of the sewer system, for instance.
| suprfsat wrote:
| Yep, if the sewer system occasionally spills into a
| river, you can just put up a sign and ignore it.
| [deleted]
| aikinai wrote:
| By the way, does anyone here know how to actually check sshd
| logs on MacOS?
| solarengineer wrote:
| There are a number of responses here:
| https://stackoverflow.com/questions/43382825/where-to-
| find-s...
| wvenable wrote:
| 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.
| Retr0spectrum wrote:
| The second wave is likely when public port scanning services
| such as shodan re-scan your host. (I wonder how hard it would
| be to fingerprint and subsequently blackhole shodan et al's
| scanning traffic)
| beams_of_light wrote:
| 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.
| yk wrote:
| 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.
| ogre_codes wrote:
| 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/
| CodeWriter23 wrote:
| It's actually defense in depth.
| giantrobot wrote:
| 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.
| a1369209993 wrote:
| Exactly: moving your SSH port isn't security by obscurity
| because _it 's not security in the first place_.
| geekamongus wrote:
| It is just obscurity.
| naniwaduni wrote:
| It's log filtering.
|
| Log filtering has about as much impact on security as
| having overseas contractors watch your security cameras.
| jjoonathan wrote:
| Log filtering at the expense of having one more thing to
| manage, forget, or otherwise screw-up.
|
| Ways I've seen this go wrong:
|
| - someone fails to copy the port while communicating it
|
| - the new whiz-bang AI security solution detects non-
| standard SSH ports and "quarantines" you while you try to
| figure out what happened and who to talk to
|
| - someone manually "reviews" the firewall rules and locks
| you out of your own boxes
|
| - someone builds a tool that uses SSH but doesn't allow
| non-standard ports
| a1369209993 wrote:
| > the new whiz-bang AI security solution
|
| > someone manually "reviews" the firewall rules
|
| This is a feature. Allowing Unfriendly AIs or incompetent
| morons to dictate security policy will go horribly wrong
| eventually; nonstandard SSH ports help make it painful
| for you to allow them to gain a foothold in the first
| place.
| opless wrote:
| It's not even that.
|
| I have certain hosts behind a single IP and forward SSH
| to them on arbitrarily chosen ports.
|
| Do I still get random logins on those ports?
|
| Why yes I do.
|
| Does putting SSH on a different port make any difference?
|
| No it doesn't.
|
| Putting SSH on a different port is either done for a
| specific reason, or you're just deluding yourself that
| you've somehow reduced your attack surface.
| p4bl0 wrote:
| It clearly makes a difference for me. My servers which
| have SSH listening on port 22 have countless failed login
| attempts. Those running it on another random port have
| almost none.
| opless wrote:
| Then you're clearly a statistical outlier :)
| edoceo wrote:
| Me and @p4bl0. I've got one box with ssh on 22. Logs are
| very noisy and the rules from fail2ban grow and grow.
|
| On the other 20+ boxen with ssh on port xxx22 the logs
| and f2b rules are much smaller - which means less hassle
| for the admin.
|
| And on the boxen with services behind WG there is zero
| noise.
|
| Naturally we're using keys only with all this. The
| reduced noise in the logs/rules/firewall are very handy.
| crawlcrawler wrote:
| I love Brian Regan but I have to say, even though I'm
| probably ruining one of his best jokes [0], that the
| plural form of "box" is not "boxen".
|
| [0] https://www.youtube.com/watch?v=xkrMsPiqG6M&feature=y
| outu.be...
| edoceo wrote:
| Oh, I'm aware it's "boxes". But, I got into the "boxen"
| habit in the middle 90s and now that I'm "old" I've
| chosen to become stubborn and stuck in my ways. Also, I
| think it's more fun. I've got other things to be pedantic
| about.
| dllthomas wrote:
| I'm pretty sure "Unix boxen" predates Brian Regan's
| standup.
| a1369209993 wrote:
| > Putting SSH on a different port is either done for a
| specific reason, or [...]
|
| Yes. The specific reason is "it makes log files less full
| of crap we have to sift through".
| Florin_Andrei wrote:
| Wrong.
|
| Anything that reduces the likelihood of success of any attack
| is security. Non-standard ports essentially remove you from
| the radar for a lot of dumb IP block scanners. That alone is
| worth the minimal effort involved.
| dheera wrote:
| 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.
| spullara wrote:
| 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.
| noncoml wrote:
| You mean low pass? High pass filter allows _high_ frequencies
| through. High. Pass.
| pas wrote:
| They mean filter out the low value noise (like you would
| filter out the constant hum of the PSU/grid), the scans on
| the usual ports (which all happen to be low port numbers).
| [deleted]
| cthalupa wrote:
| So here's the problem:
|
| 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.
| ses1984 wrote:
| >If someone using SSH ignores the fact that the host key has
| changed
|
| Here's the real problem.
|
| Also if you're worried you could use SELinux, AppArmor, or
| things like docker to limit the capabilities of a compromised
| PHP application.
| skrause wrote:
| Well, I've simply changed my SSH port to a different port
| <1024 (e.g. 950). That invalidates the rest of your argument.
| tyingq wrote:
| I was confused about that as well. There are plenty of
| privileged ports you can use.
| giantrobot wrote:
| What you mention makes sense if all of the wild potential
| problems exist on the system. You've already fucked up
| leaving password authentication enabled on your theoretical
| machine.
|
| It's pretty trivial to leave SSH on port 22 and just forward
| a high number port to it while blocking 22 externally. All
| the root-not-compromised assurances and still maintaining the
| high pass filter.
|
| While a VPN certainly can be a good solution to securing a
| machine, you've now got the problem of the VPN server needing
| its access protected.
|
| Public key _only_ for authentication and strict fail2ban
| rules combined with port forwarding makes for a very tight
| system. Not invulnerable but secure enough to not be worth
| the effort.
|
| As I said originally and still maintain, using non-standard
| ports is a high pass filter. It's not a security measure. It
| might be part of your security setup but it's just a filter.
| antaviana wrote:
| I guess that if you manage to take over the high number
| port by somehow crashing the high port forwarder service
| and then listening on that high port, you have taken over
| ssh on the high port.
| saltcured wrote:
| Someone setting this up well on Linux would be using
| iptables forwarding, not a user-space service listening
| and forwarding. Now, this hypothetical attack has to be
| able to manipulate the kernel's network stack and we
| might as well stop pretending the low 1024 ports have
| special significance in that case, either.
| jjav wrote:
| > If someone using SSH ignores the fact that the host key has
| changed
|
| Then it's game over regardless of anything else. That someone
| is now owned by anything and anyone who cares to MITM them.
| MayeulC wrote:
| Why not directly setup wireguard on the same machine as the
| ssh server?
|
| Wireguard doesn't answer anything during port scanning, or
| when it receive unauthenticated packets, as it doesn't need a
| handshake.
|
| Actually, I'd think that wireguard + telnet should be good
| enough, though ssh has a lot more features.
| j4ah4n wrote:
| I agree, however with any team with size > 1 you then have to
| manage access. I've seen small teams share a common
| credential and getting SSO to work OOTB with that VPN
| infrastructure in SCM is a pain. Additionally, if you end up
| having more behind that VPN (e.g., db's, monitoring, etc) its
| arguably net worse to do than the port-shift IMO.
| Florin_Andrei wrote:
| Non-standard ports greatly reduce the incidence of drive-by
| shooting attacks. That alone is worth the minimal effort
| involved.
| arendtio wrote:
| 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 wrote:
| Services like that are typically called tarpits, for SSH you
| can use Endlessh:
|
| https://github.com/skeeto/endlessh
| arendtio wrote:
| Thanks, sounds exactly like what I have been looking for and
| Arch Linux seems to have an AUR for it :-)
| jl6 wrote:
| 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 wrote:
| This was posted a couple days ago,
| https://news.ycombinator.com/item?id=19465967
| belak wrote:
| 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
|
| [1]: https://nullprogram.com/blog/2019/03/22/
| amadeuspagel wrote:
| 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.
| maze-le wrote:
| 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.
| jopsen wrote:
| 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)
| elmo2you wrote:
| 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 wrote:
| 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.
| rcarmo wrote:
| 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.
| forty wrote:
| (Sorry if my question is stupid) why expose SSH on the internet
| rather than having it behind a VPN?
| drdebug wrote:
| 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 wrote:
| 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.
| RoryH wrote:
| It's not more _secure_ , but it certainly does help prevent
| unwanted bots spamming your SSH daemon.
| kempbellt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| deft wrote:
| 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 wrote:
| And Fail2ban if you want to temporarily block an IP after too
| many authentication attempts.
| R0b0t1 wrote:
| 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.
| NovemberWhiskey wrote:
| 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.
| the8472 wrote:
| > 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
| megous wrote:
| 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.
| selfhoster11 wrote:
| Or even less, if you rent a fleet of cloud machines to do it
| for you in a distributed manner.
| robertlagrant wrote:
| What about a load of serverless functions?
| megous wrote:
| Is that not costly?
| selfhoster11 wrote:
| It could be, but you can always reuse the mapping result
| for many subsequent attacks without losing that much
| accuracy. IP addresses will drift due to reassignments
| over time, but I can easily see a map remain usable for a
| week or a month. You could also just sell/buy it from
| someone else, which costs less.
| the8472 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| babadaba wrote:
| > What are you defending against
|
| You're defending against people who wrote scripts that
| only check the default port. Based on numbers that some
| others posted, that is actually quite a sizeable number,
| as they reported numbers of attempted connections on the
| default port to be orders of magnitude higher than other
| ports.
| the8472 wrote:
| Scripts are not magic, they must be doing something. So
| what are you defending against? The last openssh preauth
| remote exploit from 2003? Weak passwords? Those are much
| better addressed by other measures.
| babadaba wrote:
| > Scripts are not magic, they must be doing something
|
| Not necessarily. Sometimes they just record potential
| targets for later manual probing. If the script doesn't
| find what it's looking for (in this example the default
| ssh port), your server is not recorded. That in itself is
| a win, even if it's small.
|
| > So what are you defending against?
|
| It limits the number of people/processes trying to gain
| access to your server. Would you rather 10 people trying
| to get in, or 1?
|
| > Those are much better addressed by other measures
|
| Well, ya. Nobody is saying obscurity is the only security
| layer. You would need to secure it assuming the port is
| known. As _an additional layer_ , only to (even slightly)
| reduce the number of potential threat actors, you change
| the port.
| megous wrote:
| Threat model is having logs flooded by run of the mill
| automated bot login attempts, and missing the targeted
| attacks in the noise.
| the8472 wrote:
| If you're monitoring your logs that does make sense. My
| issue are corporate policies that say "port 22 = bad" but
| don't monitor the logs either. I don't see what those are
| defending against.
|
| I also disagree with the general statement of the blog
| post that changing the SSH port is like hiding your
| tanks. The discrepancy between armor and camouflage vs.
| cryptography and port numbers is many orders of
| magnitude. A better explanation than that is needed in my
| opinion.
| code4tee wrote:
| 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.
| njharman wrote:
| 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.
| okennedy wrote:
| 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).
| iso1631 wrote:
| > 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
| donaldihunter wrote:
| >Even if your enemy knows you're camouflaged somewhere in the
| dessert
|
| I am here for this typo.
| jamesmishra wrote:
| 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 wrote:
| 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 wrote:
| 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.
| peterwwillis wrote:
| > 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.
| staticassertion wrote:
| A major reason to move the port is exactly so that you can
| log when someone does hit 22, especially internally.
|
| If you standardize on port 5555, for example, and all of your
| tooling understands this, now you can audit 22. Anyone
| hitting 22 is either not using your standard tooling, or is
| at least potentially an attacker. Being alerted to an
| attacker is not a small thing.
| tachyonbeam wrote:
| I'd be curious to see what happens if you setup a
| sophisticated fake SSH daemon on port 22. Give them access
| to a virtual machine connected to that port, and log every
| command they try to run.
| thinkharderdev wrote:
| There is a flip side of that as well though. You may have a
| tool that tries to look at all SSH traffic across a fleet
| of servers (maybe trying to identify compromised internal
| hosts). If every server has sshd running on a different
| random port then you can't do this (or at least it becomes
| a lot harder).
|
| More generally, I think there is in fact a trade-off
| involved in deciding to explicitly ignore standards.
| Whether it hobbles automated network analysis or just
| causes friction in the development process, it can add up
| over time. That is not to say it is always a bad idea but I
| would just caution that, just as you shouldn't blindly
| reject "security by obscurity" you shouldn't blindly accept
| "security through obscurity" even if you have layered
| defenses. There is no substitute for thinking about
| individual circumstances and weighing explicit trade-offs.
| staticassertion wrote:
| No question, it's not a 0 cost change.
| liability wrote:
| If you interpret the term literally, then yes. However that's
| not the correct approach when dealing with terms of art like
| 'security through obscurity.'
|
| Wikipedia describes the term as it's actually used (emphasis
| mine):
|
| > Security through obscurity (or security by obscurity) is
| the reliance in security engineering on design or
| implementation secrecy _as the main method_ of providing
| security to a system or component.
|
| An properly configured sshd on a non-standard port is not in
| any remote way using obscurity as it's main method of
| security.
| onion2k wrote:
| _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._
|
| This is what's known as 'putting all your eggs in one
| basket'. Relying on a strong auth mechanism is extremely
| sensible but _only_ relying on that isn 't. Exploits are
| found even in the oldest and best reviewed code. Nothing is
| 100% safe. If an exploit is discovered in the auth mechanism
| you're relying on then the obscurity of having SSH on a
| different port, with a mechanism to block port scanning,
| could at least buy you enough time to delay an attacker long
| enough for you to shut down auth until there's a fix.
| Considering the cost of switching port is so low it seems
| foolhardy not to.
| kps wrote:
| Someone attacking ssh may also attack other services (e.g.
| http) that may have vulnerabilities. fail2ban on port 22
| keeps them away.
| Karunamon wrote:
| I was going to say.. fail2ban or sshguard serve a purpose
| in ensuring that ssh skiddies don't get to talk to anything
| else on the machine either.
| petercooper wrote:
| I don't apologize for it, but I don't think yours is the only
| argument that can be made.
|
| What if a security hole is discovered in OpenSSL and
| overnight all those bots smashing port 22 are tweaked to take
| advantage of it? Let's assume a vulnerability that doesn't
| care about password auth being disabled. Sure, they might
| discover my sshd on port 17263 or whatever _eventually_ but I
| am surely going to get a significant head start on all of the
| people having their boxes hacked left right and center.
|
| Sure, it's still security by obscurity, but it's nothing like
| the napkin example. It's more like hiding your phone under a
| table that has 20 other phones on top of it. When I hear
| about phones getting stolen, I've got a while to get mine
| back.
| thinkharderdev wrote:
| That works both ways though. Imagine in your scenario you
| have thousands of servers across a large organization, many
| that may be running on auto-pilot and don't have any active
| team maintaining them. When the hypothesizes critical
| OpenSSL bug pops up, the first thing you will want to do is
| find out all the server in your network running sshd so you
| can patch them. If they are all listening on some random
| port then that task becomes much, much harder.
| cedilla wrote:
| One thing to keep in mind here is that there is no absolute
| security. There is only security against some specific
| threat.
|
| If the threat is "someone is specifically targeting you",
| then changing the port is indeed useless. However, if the
| threat is "a botnet trying to abuse a new openSSH
| vulnerability", then changing the port does help. Because no
| bot takes the time to scan tens of thousands of ports in that
| case when there are millions of other hosts around who listen
| on port 22.
|
| By the way, when I lived in a dormitory, it was actually best
| practice to hide your valuables from view if you lived in a
| ground floor apartment. Literally obscuring the thing, but
| thieves only broke into the apartment where they knew there's
| something to steal quickly. A napkin over your wallet might
| not help in a bar but it did help in this case.
| thaumasiotes wrote:
| > Literally obscuring the thing, but thieves only broke
| into the apartment where they knew there's something to
| steal quickly. A napkin over your wallet might not help in
| a bar but it did help in this case.
|
| The same approach works well for leaving stuff in cars.
| Visible bags or electronics tend to get stolen. The same
| thing under a sweatshirt doesn't.
| ryankrage77 wrote:
| 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.
| coding123 wrote:
| 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 wrote:
| I always disable passwords for every system I work on. Then use
| some type of PAM, like Google Auth for TOTP.
| robertlagrant wrote:
| > 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.
| phendrenad2 wrote:
| 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.
| kerng wrote:
| 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.
| tastroder wrote:
| https://news.ycombinator.com/item?id=24444497 The original, 520
| comment, thread this is a reaction to.
| dec0dedab0de wrote:
| 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 wrote:
| No, you're still getting additional security from the port
| move. The argument being made is nonsensical.
| dec0dedab0de wrote:
| You get additional security from any form of obscurity. No
| one has ever argued otherwise.
| shuntress wrote:
| 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.
| mmis1000 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| shuringai wrote:
| "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 wrote:
| 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.
___________________________________________________________________
(page generated 2020-09-21 23:00 UTC)