Hacker News Reader

Comment by gxti | Hacker News Reader

> and switch sshd to a different port

Big ups for this -- since moving SSH to port 8022 I get zero bruteforce attacks. Even blacklisting tools like fail2ban can't get that kind of result. Of course it can't be the only defense, but I've always configured my SSH daemons to be key login only (no passwords). Moving SSH just cuts down on the CPU cycles burned at rejecting drone scans.

Every time I come across posts like this I consider maybe setting up a honeypot but I'm not sure what I'd do with the results other than look over them every few months for my own amusement. Are there any honeypots that can automatically forward information about the attacks to a central location?

View on HN

While it's a good idea to move ssh to a different port, if only to stop the annoying doorknob rattling in your log files, you should not pick an ssh port over 1024. Ports over 1024 are unprivileged ports, and if someone could somehow convince your ssh server to die, they could start up a counterfeit one and collect your password. A port under 1024 requires root access to be able to open it.

Of course, this only applies to linux systems where you don't trust local unprivileged users. Or software that you are running as an unprivileged user. So every system.

> Ports over 1024 are unprivileged ports

Good point, but

> they could start up a counterfeit one and collect your password.

you missed the part where I disable password logins on all of my boxes :-) The important point was that the system was already secure enough due to the key requirement, and moving the port was indeed just to stop the "doorknob rattling". If I suddenly find that a box I control is asking me for a password, I'm not going to just type my social security number in and hope for the best.

One could argue that using a port < 1024 makes it easier for the scanners to find, but frankly anything other than 22 (or a frequently scanned port) would work well enough.

gxti seems to have been mildly aware of this, but I just set up ssh at home on 2222. So thanks for pointing this out.

At which point he has user access to your machine anyway... so the point is kind of moot.

It's relevant if you've re-used the password elsewhere.

How would an unprivileged user start a counterfeit SSH server?

Did you read what he said? Unprivileged users CAN start daemons which listen on ports above 1024.

Whatever happened to that port knocking idea a few years ago, did that go anywhere?

I had my internal monitoring system on a network I managed set up with port knocking. It ended up being more hassle than I thought it was worth, as it wasn't a box that was getting attacked much anyway.

It's really pretty easy to set up with iptables in Linux.

http://www.debian-administration.org/articles/268

Lots of people seem to recommend port knocking still today, but I personally won't use it as I'd hate to get behind a firewall (e.g. hotel, airport, university) where I can't send the right sequence of knocks for whatever reason (outbound ports firewalled).

I set it up a few months ago and ended up disabling it after a few weeks due to this reason. All my SSH servers have password authentication disabled and a strict AllowUsers list, anyways.

The only thing I do externally from sshd is have a cronscript run every 15 seconds to grep my authlog file to find any IP addresses that fail authentication and put them in a global blacklist for my PF firewall. It cuts down the ssh authlog noise considerably, and rarely accidentally blacklists myself.

Don't forget `iptables -A INPUT -p tcp -m tcp --dport 22 -j TARPIT` ;)

Reply on news.ycombinator.com