Hacker News Reader

Comment by heavenlyblue | Hacker News Reader

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

View on HN

Don’t disable port 22; just neuter it. If port 22 is disabled, the attacker will look elsewhere in your system.

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?

Obviously the next step here is a fake SSH agent that allows logins to a little sandbox.

https://github.com/cowrie/cowrie

Probably a bad idea, one vulnerable service invites people to look for more.

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.

I'd be weary of that. Sandboxes have been escaped.

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.

And the next beyond that is a sandbox that contains simulated data....

honeypots are obvious.

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.

Do you have a suggestion on how to do this?

An SSH Tarpit is a good way:

https://nullprogram.com/blog/2019/03/22/

thanks!

https://github.com/cowrie/cowrie

It depends, many people do not do a full NMAP scan. Takes to much time.

Then again, is port knocking security by obscurity enough?

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.

Sometimes I run an extra http listener on 22

Reply on news.ycombinator.com