SSH Password Gropers Are Now Trying High Ports

badger.foo writes "You thought you had successfully avoided the tiresome password guessing bots groping at your SSH service by moving the service to a non-standard port? It seems security by obscurity has lost the game once more. We're now seeing ssh bruteforce attempts hitting other ports too, Peter Hansteen writes in his latest column." For others keeping track, have you seen many such attempts?

Comments

Low Hanging Fruit

[Nerdfest]

It's still just going after low-hanging fruit. Anyone weth any real awareness of security does now allow password-only SSH connections anyway. Key based auth and fail2ban is pretty much required these days. You can always add some port knocking to obscure it a bit if you don't like reading about failed access attempts.

Re:Low Hanging Fruit

[DaveAtFraud]

I've been using key based authentication for ssh for years. I just moved the service to a high port to get rid of all the script kiddy password guessing attempts that were clogging my log file. I also added a "throttle" in iptables:

# Block brute force attacks
# Drop repeated ssh connection attempts within 20 seconds interval
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j DROP --rcheck --seconds 20 --name THROTTLE --rsource

# Accept ssh connection if not attempted within past 20 sec.
-A INPUT -p tcp -m tcp -m state -m recent -i eth1 --dport 22222 --state NEW -j ACCEPT --set --name THROTTLE --rsource

It just cuts down on the noise. I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).

Cheers,
Dave

Re:Low Hanging Fruit

[kiddygrinder]

while it's theoretically possible it's not really worth considering, especially when you're only giving them 4 attempts an hour.

Re:Low Hanging Fruit

[DarwinSurvivor]

REJECT tells them you've detected them, the not-so-dumb ones will use this against you.

Re:Low Hanging Fruit

[SuricouRaven]

It's actually quite hard to spoof anything now. No domestic connection will forward packets that don't from from the designated IP address. You need to have access to either the LAN of a decently-sized corporation or the internal network of an ISP. Easy enough for skilled hackers to get, yes - they can compromise a device somewhere - but beyond the script kiddie.

Re:Low Hanging Fruit

[budgenator]

I'd use TARPIT instead.

Re:Low Hanging Fruit

[PlusFiveTroll]

Yes, as part of a defense in depth and not as a measure by itself.

Don't rely on security-though-obscurity

[Gaygirlie]

You're being naive and just waiting for a disaster to happen if all you rely on is changing the default port. I, myself, use this application called Denyhosts that bans the IP-addresses that try brute-forcing passwords, and I've set it up to just ban access to any services, not only SSH, after 5 failed attempts. These days I've got thousands of IP-addresses on my hosts.deny - file and it just keeps on growing. That said, use Denyhosts or something similar if you need password authentication or just disable password auth altogether.

SSHGuard FTW

[water-and-sewer]

I'll probably have to go learn about key-based security. But meanwhile, I'm really happy with sshguard. It defends against brute force attacks by monitoring logs and aplying increasingly (exponentially) tougher time-outs as attacks from IP addresses continue. It's reduced my log from 100s of entries per day to about 15. http://www.rferl.org/content/world-press-photo-winners/24903576.html
    They've got it in FreeBSD ports, which makes it easy to install into an existing firewall.

iptables

[markdavis]

If you want to end almost any possibility of brute force, load this with iptables:

/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "sshd_brute_force_block "
/sbin/iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

Those three lines will slow the amount of connections by the same ipaddress to sshd. When the attacker reaches 4 hit counts it will be blocked for 60 seconds before resetting. If the attacker keeps attacking before the 60 seconds are up it will reset the the time limit to another 60 seconds. Have been using it for years and it is extremely effective. Even a botnet attack (which is unlikely) would be futile because there just aren't enough attempts.

Seriously, this type of thing should be built directly into ssh. If not this sophisticated, then at least it should include attempt and restart delays which would not be as effective but beat the hell out of the default behavior.

Re:The length of the VPN's password

[PlusFiveTroll]

So your saying a 32 char password is better then a 16 char password, whoda thunk it.

Or, to rephrase that, all you've done is make it 500 trillion times harder to crack your ssh (if you're using good passwords), if you are using keyfiles for both then there pretty much needs to be a remote exploit in both the listeners.

Re:Don't rely ONLY on security-though-obscurity

[Anonymous Coward]

There, I fixed the title for you.

I use both a nonstandard port as well as Denyhosts. My block file only numbers in the hundreds, yours in the many thousands. Why? Because every random scan that hits my system flags my IP as "not likely" and moves on, when it hits your IP you get flagged as "valid target" and then you get hit with focused attacks.

If you're going to pretend to understand security, then at least get the saying right. Yes, it's never a good idea to only use obscurity, but there's rarely any valid reason to NOT use it as part of a layered model.

Better than that...

[IBitOBear]

The below will create a dynamic blacklist. Any IP address that connects more than three times in five hours (pass or fail) will go into a blacklit that will persist until they stop trying for at least a day.

This will recodr your bad actors _and_ it will "expire" in case you invalidate a system by accident (e.g. over-use).

iptables --new-chain SSHTHROTTLE
iptables --append SSHTHROTTLE --match recent --name bad_actors --update --seconds 86400 --jump DROP
iptables --append SSHTHROTTLE --match hashlimit --hashlimit-name ssh_throttle --hashlimit-upto 5/hour --hashlimit-mode srcip --hashlimit-burst 2 --jump ACCEPT
iptables --append SSHTHROTTLE --match recent --name bad_actors --set --jump DROP
iptables --append INPUT --in-interface ext+ --proto tcp --match conntrack --ctstate NEW --dport 22 --syn --jump SSHTHROTTLE