Hacker News new | ask | show | jobs
by vbezhenar 2104 days ago
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".
4 comments

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. :)

Along similar lines, Port knocking (https://en.wikipedia.org/wiki/Port_knocking) is something out-of-band used to allow access to a host (bypassing a firewall).

I think I'd sooner implement port knocking rather than port-hopping

Ooh, yep. This is definitely a better first line of defense than port-hopping.

Maybe you'd knock to get a number, and hash the number to get the real port.

Defense in depth! :)

I came here looking forward to upvote anyone mentionning port knocking.

This is THE way to go !

You've reinvented HAVE QUICK[0]

[0]https://en.wikipedia.org/wiki/HAVE_QUICK

What is old is new! Seriously, it's cool to see something like this built, especially in the analog (EM spectrum).

I imagine the people who had to use these things locked themselves out all the time. :)

We still use it, and we still have sync issues.

So yes, it's a FANTASTIC way to lock yourself out!

Or use a TOTP with a long period (10 minutes?) and use that value mod, say, 10k with a base of something like 9000. Easy to calculate the port in your head, impossible to guess without knowing the TOTP secret (I think) and can be extended with other fun* rules like "But subtract 10* the first digit" or "Add the first and second digits multiplied".
Ah, this is a great twist! Thank you for this great contribution to the "locked myself out" idea bank.
That's a fair point - e.g. Authy is currently broken on iOS 14 which means I'd be locked out if I was doing this and using Authy (although I have a VPN to one server which can then get to my others.)
Seems like a more effective way would be to use port knocking?
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.

>And as I don't see much difference between 100000 attempts and 1000 attempts

You don't see a difference in a 2-orders-of-magnitude noise reduction when looking for attacks!?

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

> 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?