Persistant SSH Threats? | Hacker News Reader

Persistant SSH Threats?

14 pointsdaly26 comments

For the past few months my server has seen an SSH connection attempt about once a minute. There is no reason to SSH to my server as there is nothing on it except at static website.

The SSH connections are coming from seemingly random IP addresses, rarely from the same one twice.

Is anyone else seeing such connection patterns?

View on HN

Yes, it's normal. Just people scanning for SSH ports to attack.

What I did was take the IANA IPv4 address space list[1] and add firewall rules to drop packets to port 22 coming from /8's that I would never connect from. I'm in the US, so it made sense for me to drop connections from subnets assigned to RIPE, APNIC, etc. It didn't eliminate the problem, but it reduced the connection attempts considerably.

1. https://www.iana.org/assignments/ipv4-address-space/ipv4-add...

Yeah, it's common. I hide my critical services with pyknock[1] - it's a modern successor of port-knocking implementation, based on HMAC signatures rather than on simple port sequence.

[1] - https://pypi.org/project/pyknock/

Related question that has crossed my mind: what is this risk exposure of a linux server that is accessible via the internet that has port 22 enabled, and only has users with --disabled-password set (requiring ssh connection)?

As a follow up, what is increased benefit (if any) if port 22 is only accessible by a certain IP address (e.g. my home address)?

I do something similar but added a knock daemon and changed the default ssh port 22 to something else.

So far I haven’t had any issues, fail2ban works, and it seems safe.

I do have my home IP added to the whitelist and others set to drop.

I was told in a networking class this is the second best way to protect ssh other than not running ssh.

Any thoughts on this setup as well? Maybe oversights that I’m not seeing?

It's hard to quantify that "risk" in simple terms, but --disabled-password is a basic must as it seriously mitigates popular attack vectors like brute forcing.

Filtering ssh connections at firewall level helps, and certainly reduces log entries for port scans and can halt less sophisticated attackers, but it doesn't mitigate attack vectors like a DDoS or a well funded actor.

At least this can make for very exciting wallpapers?

https://dev.to/lbonanomi/hello-worm-mapping-ssh-probes-with-...

Totally normal, make sure to use a secure mean of access like pubkeys, turn off normal password authentication, and optionally put fail2ban and totp[1]

[1]: https://www.digitalocean.com/community/tutorials/how-to-set-...

IMPORTANT: If you do setup totp, make sure your server is actually syncing its clock with NTP, because if there is a significant time-drift you might be locked out from accessing SSH remotely.

Welcome to the world of servers. There are these bots/scripts running all over the internet that are scanning for stuff like this and always trying to brute force into servers they can find and get in. The good news is that this is not only targeted at you. The bad news is that you cannot do much about them except ensuring that your servers are hardened and have the right security setup. There are tools like fail2ban etc. that can block those IP addresses but again, you cannot really stop them as you will get these hits from random IPs all over the world.

Yes, for decades. Move SSH off of port 22 and you’ll see far fewer attempts.

No idea why you are being downvoted, this is a solid advice. Masscan [1] claims to scan whole IPv4 Internet for a single port in 5 minutes. Moving to a random high port would increase scan time 64000-fold, to 7 months.

You'd still be advised to disable password-based auth and/or configure fail2ban, though.

[1] https://github.com/robertdavidgraham/masscan

It's a bad idea, privileged ports are a thing for a reason.

https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....

https://adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-ano...

You have a point there, but it's far, far from being so clear-cut.

Privileged ports is a measure to guarantee that daemon listening there was started with root privileges. Which is a useful guarantee on a shared server, less so on a single-purpose or personal server.

Plus, if you have an sshd started at boot, and already listening on a pre-defined high port, there is very little chance another program could bind to the same port, save crashing and racing the daemon.

Finally, in ssh protocol, server authenticates itself to the client, so even if by some trickery a bogus ssh server would bind to the same port, it will either need to access /etc/ssh/ssh_host_*_key, which are enforced to be root-readable only, or risk being trivially detected by a client comparing presented public key to that saved from last login in the ~/.ssh/known_hosts.

There are also some DPI firewalls, or just port-based firewall that can block ssh traffic on a non-standard port, but assuming we are talking about your own server, that should be easy to rectify too.

You understand the risks, but it's also a bad idea because it's effectively security-by-obscurity. I can port scan your host and find your SSH port in just a few minutes. Port knocking is better but still not foolproof unless you're doing some crazy 12-port sequence... And not having hordes of chinese bots hammering on our SSH port makes us slip up and do silly things like leaving password auth enabled.

There's no harm in having connection attempts on your ssh port. Changing your port will not make you more secure against a dedicated attacker, and you just make things harder for yourself (and marginally less secure, for the reasons you mentioned) with no real benefit.

And like I mentioned in the other comment, just use SSH keys and disable password auth. It's not hard, and it's all it takes to thwart every bot that hits you on port 22. If you want to be more hardcore you can run fail2ban or firewall the port down to your country or whatever.

It's the equivalent of "I connect to my host via IP address instead of having DNS records because it'll be harder for them to find!".

Obscurity is just one more security tactic. Security by obscurity as the only defense is bad. As an additional layer to many defenses it is a sound choice.

You still paint camoflage on a tank.

There's no harm in those attempts, but they are annoying. Even with fail2ban there is extra stuff running, unnecessary connections, junk in your logs. The benefits of moving SSH off 22 for your personal, internet facing servers outweigh the negatives.

SSH is less secure on an unprivileged port, this is a bad move. Use ssh keys and fail2ban, and filter your logs if you care about the attempts that much. This is like complaining that you're seeing web scrapers in your http access log: it's just background noise, it doesn't matter.

I did not suggest changing it to an unprivileged port, just a non default. Also you can change the Linux privileged port range with sysctl.

>you can change the Linux privileged port range with sysctl

I'm pretty sure you can't without recompiling the kernel, it's defined in the source in include/net/sock.h here: https://github.com/torvalds/linux/blob/master/include/net/so...

Newer kernels have the sysctl: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Oh very cool, thanks for the link! Learn something new every day

That's normal, it's often referred to as background noise: https://en.wikipedia.org/wiki/Internet_background_noise

It stems from automated port scans sweeping IP ranges looking for vulnerable/exploitable systems.

A simple way to address it is to use something like fail2ban to ban repeat offenders. Blacklist services like abuseipdb.com may help further, but ban with caution.

Blacklistd (available natively on FreeBSD and NetBSD) are a good defense against these attacks. If you're using Linux you'll have to use fail2ban or something that scans log files for a similar. Using public key authentication and disabling password authentication is also a good idea.

Yes, this is normal.

Any server exposed on the internet will be probed constantly by botnets.

I notice the same thing: connections from random combinations of IPs/usernames.

Sadly, that comes with having a public accessible server: people wanting to hack their way in.

I have SSH disabled.

Are you Telnet or RDP person?

Reply on news.ycombinator.com