Hacker News Reader

Comment by bell-cot | Hacker News Reader

A few simple obscurity tricks - 22 => 2222, /admin/ => /hq/, etc. - can save your ass if there's a remote zero-day, and the bad guys are busy scanning for low-hanging fruit while the good guys learn about it then scramble to patch.

View on HN

> 22 => 2222

With a well configured SSH server, 22=> 2222 is pointless, very much the definition of obscurity providing zero security.

OpenSSH is impeccably written software, widely battle-tested and its been literally forever since there was any significant vulnerability in it despite being one of the most widely deployed servers on the planet.

Enable key/cert only authentication and you are already effectively 100% secure.

Then, to double-down:

    - Harden KexAlgorithms and Ciphers
    - PermitRootLogin no
    - Compression delayed
    - PerSourceMaxStartups
    - PerSourceNetBlockSize

Job done.

> Job done.

What part of "if there's a remote zero-day" you did not understand?

> What part of "if there's a remote zero-day" you did not understand?

What part of how about you look at CVE and see its been YEARS/DECADES since the last severe vulnerability do you not understand ?

OpenSSH zero-day my ass .... if there were any, they would have been found and exploited by now.

OpenSSH is written by the same people as OpenBSD. Those guys are OBSESSIVE about writing secure and correct code and they have the track-record to prove it.

Fact is there are millions (billions ?) of OpenSSH servers out there exposed to the internet.

OpenSSH is not the way hackers are getting in my friend.

Have you ever heard of the Titanic?

"its been YEARS/DECADES since the last severe vulnerability" therefore the probability of a new vulnerability in the next 10 years is exactly 0. /s

yet that simple change reduces bot login attempts drastically (2222 is actually quite popular, choose something else)

True & true. (I used 2222 as an example.com. Vs. giving the port used at $Job, or $PriorJob, or ...)

> With a well configured SSH server, 22=> 2222 is pointless, very much the definition of obscurity providing zero security.

This is incredibly naive. Do you remember Heartbleed? Log4J?

These were major vulns in software that is widely used, heavily reviewed, deployed by MANGAs, etc.

Heartbleed was in openssl, and Log4J in java. What does it have to do with openssh ?

One day it will be openssh.

> One day it will be openssh.

As I said mate, go look at CVE.

Its been YEARS/DECADES since the last serious vulnerability in OpenSSH.

That's despite being one of the most widely deployed pieces of software on the internet.

Have you ever been responsible for security in a professional sense? Hiding attack surfaces is standard operating procedure. No one with a triple digit IQ seriously thinks any piece of software is going to be secure to infinity.

When that day comes, a machine running sshd on a high port will have to be wiped, because how can you trust that nobody’s scanned your ports, exploited your server, and eliminated the traces?

When an OpenSSH zero‐day gets released, you can bet your bottom dollar people will be scanning full port ranges for SSH servers. And only one of them has to find you.

If that’s the scenario you’re worried about, don’t rely on obscure ports. Run your sshd behind a VPN.

> Heartbleed was in openssl... What does it have to do with openssh ?

Exactly.

I can't speak for Log4J as I have no experience, but I do know that anyone sensible agrees that OpenSSL is a pile of bloated dog poo.

OpenSSH, as I've already said, is written by the OpenBSD crew. They have a track record of having OCD about writing secure and correct software.

Okay, so are they going to live forever and keep writing impeccable software for eternity? What happens when they tire of their immortality, and decide to pass the torch?

Then we'll stop using it? On any port number?

> OpenSSH is impeccably written software, widely battle-tested and its been literally forever since there was any significant vulnerability in it despite being one of the most widely deployed servers on the planet.

I know you're lying because it's not written in Rust.

FYI, in modern ssh

  Compression delayed

is equal to

  Compression yes

which is the default already.

With regards to

  PerSourceMaxStartups
  PerSourceNetBlockSize

how do you configure it, in order to not make it a DOS vector?

> how do you configure it, in order to not make it a DOS vector?

You use it in conjunction with a third parameter that I forgot to mention, namely MaxStartups.

MaxStartups introduces a degree of randomness to the whole process, so you have MaxStartups X:Y:Z where:

     - X = Reference number of unauthenticated connections ("n")
     - Y = Percentage probability of dropping when n>X
     - Z = n=Z == all further unauthenticated connections dropped

Additional parameter that may be of interest is LoginGraceTime.

Fun fact, MaxStartups/PerSourceMaxStartups/PerSourceNetBlockSize were specifically introduced >6.1 in order to add firepower to combatting unauthenticated connection DoS attacks.

I tend to do this, if only to prevent logs being constantly spammed by bots - it results in more useful logs with much less noise.

Putting random login pages at /wp-admin/ is great for farming IP ranges to block. They don't even need to go anywhere, all you need is a form with a login button and bots will try to log in.

You should drop down a few layers on the OSI model and catch this at your reverse proxy instead of publishing login pages to catch every permutation of 'wp' in urls.

Reply on news.ycombinator.com