Hacker News Reader

Comment by xhrpost | Hacker News Reader

I feel an often overlooked prevention for these semi-random attacks is a change in the SSH default port. I've posted this idea elsewhere and people seem convinced that this is pointless because an attacker can just port-scan your machine. While true, this generally only happens when you are being specifically targeted by an attacker. More random attacks like the one mentioned here are likely just people scanning all the IPv4 space looking for open 22 ports and then testing known exploits. Since I don't run a super-popular site, I'm more likely to be the victim of the second kind of attack. I used to have bad-logins hitting my box on a regular basis, after switching ports for SSH, the log-in attempts went to zero.

View on HN

Just disable password authentication, problem solved. Changing the SSH port does not add security against people who are determined to break into your system, but as you said, it helps to keep the noise down so you're more likely to notice suspicious activity early.

The article makes it sound like the SSH brute-forcing requests were part of the attack, but it's unlikely - they are very common. My servers get several of these attacks a day.

I don't like changing my default SSH port, but I don't like people trying to brute-force my SSH passwords either. Instead I use iptables to drop SSH connections from any IP address that attempts to connect overly frequently. This is highly efficient (compared to scripts like fail2ban) and very simple to implement:

  # SSH daemon - tcp Port 22 - drop any more than 3 new connections from one address every 5 mins
  $IPTABLES -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --set
  $IPTABLES -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP
  $IPTABLES -A INPUT -p tcp -i eth+ --dport 22 -j ACCEPT

Enjoy!

Congrats, you have just opened yourself to a DoS for no gain whatsoever. Mind telling me the host and where you usually connect from?

You realise this only blocks connections from the abusive address, not all connections? If so, please enlighten me about how this enables a DOS.

There is no such thing as an "abusive address". There are only "abusive attackers", but what you are blocking are addresses, not attackers. Blocking attackers would require authenticating them. Which is impossible, because attackers usually won't cooperate in authenticating them. Which is why we usually authenticate legitimate users instead. Which is what the sshd would do if you just let it do its job. What you do instead is to offer a service which anyone without any authentication can use to block any address they like from accessing your ssh server by sending three packets where they put the address they wish to block into the source address field, with different source ports so as to make netfilter consider them NEW flows. Such functionality that allows anyone to reduce the availability of a service, especially when it takes as little effort as three packets, is what is commonly called a Denial of Service vulnerability.

Thanks for the explanation - I see your point and it would wise to consider this possibility when looking at this technique.

For my use case though, this reduces load on my server (and prevents clogging my auth log files) by stopping incessant password brute-forcing attempts. I must admit to quickly adding an over-riding ALLOW for the handful of IP addresses that should have access, though!

Because source IPs really aren't easy to spoof, right? </s>

I don't think changing your SSH port will prevent a web server exploit (which is what the article is talking about).

Well, these hits on your ssh port target only the most low-hanging of the low-hanging fruit - i.e. common username/password combinations. Nobody's brute-forcing you anything, they're just trying some common user/pass pairs at random. Disable remote login by password in lieu of key authentication and you can sleep tightly while listening to the soothing hum of failed login attempts crashing upon your airtight SSH configuration.

In the long run, I've found that years pass and connections configs get lost and you forget which fancy port you used for your SSH connection on that server. Maybe YOU have an ironclad convention, but your co-worker had another one, and you can't remember what port he used. And he's left the company or died or joined a cult.

Kids, leave your SSH ports alone. A config is just a config. But keys are forever.

Eh, seems just as likely you'd lose your keys if you lose your config. At least, I keep both in ~/.ssh

You can just let nmap run over it if you don't know the port anymore...

I stick with iptables IP whitelists. We're talking /31 or /32 whitelists. I really don't need SSH access 24/7, so it's fine having just a couple chairs permitted. I don't need to SSH from the airport.

That's naturally not the only layer of security, but I figure it's a nicer option than non-default port.

I have four VPSs, mostly on different hosting companies. 99% of ssh attacks come from China, the rest are eastern Europe (mainly Romania or Ukraine) or Brazil.

The Chinese attacks use a group of about 15 IP addresses, then, every so often, they all change the addresses to new ones at once. This has just happened, last week, in fact. So now I have dozens of attackers all coming from a group of about 15 IP addresses, which are different to the 15 or so IP addresses they used a couple of weeks ago. (No kidding, the regularity that this happens, it would not surprise me if their military is training a new class of crackers and has been assigned a different set of addresses to use this term.)

When I get a new IP address in the log, I do a whois and rewrite the "inetnum:|NetRange:" field to a class A|B|C address and then DROP it in iptables. Fuck 'em. The whole darn network class gets dropped. Not that I'm likely to be logging in from China any time soon anyway.

I now have a list of network classes with about 35 address ranges that get dropped, if anyone is interested in the list.

But I often DO need to ssh from the airport!

That's what I use. Since I access my VPS from just two places (home, work), I have only those two address allowed. Rest everything is dropped.

This was my first though as well, although the attack this time wasn't really SSH-based. It really does greatly reduce the frequency of attacks.

I connect to many SSH servers that aren't under my control. It's pretty annoying to remember an arbitrary SSH port for my own.

Binding to IPv6-only is more effective at reducing log spam: IP scanning 2^128 addresses is impractical, and scanners often cannot connect because of misconfiguration/incompatibility or lack of a routable IPv6 host address.

> scanners often cannot connect because of misconfiguration/incompatibility or lack of a routable IPv6 host address

Isn't this likely to keep you out of your own system too, at some point (accessing from unusual location without IPv6)?

Yeah. It could be problematic. Then again, 6to4/6in4 tunneling is fairly straightforward: https://en.wikipedia.org/wiki/List_of_IPv6_tunnelbrokers. Binding to a backup IPv4 port is another option.

I agree, and I've always thought that the people opposed to it are getting the 'security by obscurity' thing all wrong and taking it to ridiculous levels. Denying information to your attacker is virtually always a good idea. The only exception is widely-used, core stuff like encryption algorithms, web browsers, server framework, etc.

So sure, change the port and all, just as long as you're aware of what it does and doesn't do. I don't think anyone believes that you can allow root login with a password of 12345 if only you change the port, but it can be a good layer in a well-designed system.

The port change is a cosmetic difference that does not alter the security of your box one iota. All it currently does is reduce the number of unauthorized attempted logins.

If your box is more vulnerable on port 22 than port 22221 then your problems run orders of magnitude deeper than which port your ssh server runs on.

Reply on news.ycombinator.com