Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

"Attackers install it on Linux systems, including embedded devices such as WiFi routers and network-attached storage devices, by guessing SSH (Secure Shell) login credentials using brute-force attacks."

I'm seeing that - endless attempts to log in as root over SSH. It's apparently aimed at random IP addresses - it was hitting a newly installed server that wasn't even in DNS yet.

Here's what the attack looks like:

    Sep 30 00:06:39 s3 sshd[29144]: Failed password for root from 43.229.53.44 port 44450 ssh2
    Sep 30 00:06:42 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
    Sep 30 00:06:42 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
    Sep 30 00:06:44 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
    Sep 30 00:06:44 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
    Sep 30 00:06:46 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
    Sep 30 00:06:46 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
    Sep 30 00:06:48 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
    Sep 30 00:06:49 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2
    Sep 30 00:06:50 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
    Sep 30 00:06:51 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2
    Sep 30 00:06:52 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
    Sep 30 00:06:53 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2

I don't think I've had a box up in the last decade where I haven't seen this. The brute force attempts against ssh, and scans for vulnerable services are pretty constant. Commercial / datacenter / residential ip doesn't seem to make much of a difference. Unless you have a really bad password, its generally not an issue as the rate of the scan is pretty low. You could always run fail2ban or denyhosts to keep your logs cleaner, firewall the port off to known ips and/or set up port knocking, or change the port it listens on. (Note: Doing any of those is only a trivial increase at best security wise, its more to get rid of the log spam.)

At one point I had a script that parsed logs and added any ip with >= 10 failed attempts to an iptables chain which dropped all traffic. It would generally grow by a few hundred hosts every week.

That address is an APNIC /8 (Asia) and depending on who's whois you trust its in Japan. One of MANY defense in depth steps is to toss out all sshd traffic other than certain trusted ip ranges. Unless your server is in Japan or you live in Japan there is little reason for anyone in Japan to ever be able to ssh into your machine.

Not entirely unreasonable to only run SSH (and other things) on a VPN connection. Again, defense in depth this is hardly the only step required.

Another amusement is port knocking. No need to get all crazy and send 512 bit keys before a script temporarily opens the ssh port, remarkably little is usually enough. TCP SYN packets to SSH are only permitted for 5 minutes after a simple telnet to open TCP port ABC or whatever.

I totally agree with putting SSH on a whitelist, such a great strategy.

The VPN is a little trickier, because you're basically just exchanging your exposure from SSHD to VPN (unless you're referring to something else). I'm not sure whether that's a good idea or a bad idea, but it's something to be aware of.

I've found that white-listing SSHD (and silently dropping instead of rejecting other traffic), along with Key-Login + disabled root login has been the best I can do for preventing anything.

SSH over VPN does a couple things. First it reduces your attack surface. Surely you must have a VPN, and you must have remote SSH access, but now the internet can only poke (directly) at the VPN and no longer (directly) at the SSHd.

Assuming someone centralizes and audits and updates authorized employee lists on the VPN server, there's no way J.Random.Admin who just got fired could have some ssh keys on some random server; well, he could, but IT chopped his VPN access as he walked out the door, so they're inaccessible.

Its very difficult to set something like openvpn up such that all someone needs to know is "password123" and he's in. Fairly easy with ssh. Design to tolerate human error. You can't accidentally enable password auth instead of key auth if the system doesn't even support password auth.

Its nice to be able to document to the security guys that nothing, and I mean nothing, flows in or out of company property that doesn't go over the VPN.

Finally, although this is kinda lame, setting up SSH over VPN encourages people to do everything over VPN, hey see it wasn't so hard to put SSHd on the VPN only, so why don't you remove internet wide accessibility (insert exclamation points here) for mysql and your application admin console thingy and your VNC server and ...

If you want to mess with peoples minds, put ssh on a TOR hidden service. This freaks some people out. A bot port scanning in China doesn't know what to think of your box only being accessible via a TOR hidden service. Its not hard to set up. Have fun with connect-proxy. Although this smells of security thru obscurity, its really just one of hopefully many layers of defense.

This is fairly common, if not ubiquitous.

Use key-based authentication, disable password auth in sshd_config and install sshguard.

That's been going on for years.

Move port from 22 to somewhere else.

Install fail2ban

It's also fun to change the encryption:

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

in sshd_config. From what I've seen, the brute forcers can't work with this. (If you're sshd doesn't: upgrade)

its worth noting that essentially only openssh clients will work with these settings, and newer ones at that.

so fail2ban, disabling root logins, and key-based authentication are the answer?

A large portion of it, yes.

Limiting SSH to specific IPs or netblocks, and/or specifically excluding those you're likely to never use, would also help cut down on the attack surface. Not that hosts within your perimiter don't get compromised, but there are far fewer of them.

2FA including keyfobs is yet another option.

Port knocking can help also

Is this on a well-known cloud hosting provider? I assume so, unless "s3" indicates something else.

There have been attacks against known cloud hosting IP ranges for a long time. I'm constantly getting attempts on my personal server on common ports (i.e. 3128 for a proxy to spam through), that's on DigitalOcean.

No, it's just the third server of a set, a leased dedicated bare metal CentOS server in a large data center in Phoenix AZ. No "cloud" service is involved.

This has been going on for about three weeks now. I may configure PAM to force a login delay; the logs are getting big.

Would you consider fail2ban in this case?

"Warning: Using an IP blacklist will stop trivial attacks but it relies on an additional daemon and successful logging (the partition containing /var can become full, especially if an attacker is pounding on the server). Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server. SSH keys provide an elegant solution to the problem of brute forcing without these problems."

source: https://wiki.archlinux.org/index.php/Fail2ban

> Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server.

No they can't. That is not how TCP works.

From memory, you can spoof UDP but not TCP.

https://serverfault.com/a/153619/91708

While it doesn't give any real security, changing the ssh port will at least filter out these kinds of attacks.

I don't think it's totally random, when my server got taken over I found a list of ip addresses that the script was in turn trying to bruteforce. Someone made that list on purpose, though I don't know why or where the ip's came from.

same I saw on my servers, has been going on for more than two months. I disabled all ssh password accesses ever since. they're also testing rhosts, probably to jump from one compromised box to another, so I disabled that as well.

Reply on news.ycombinator.com