SoylentNews is people
SoylentNews
Software engineer Chris Wellons writes about tar-pitting nefarious SSH probes. Anyone with a publicly-facing SSH server knows that it is probed from the moment it is turned on. Usually, the overwhelming majority of incoming connection attempts are malevolent in nature. There are several ways to deal with these attempts, one method is to drag out the response for as long as possible.
This program opens a socket and pretends to be an SSH server. However, it actually just ties up SSH clients with false promises indefinitely — or at least until the client eventually gives up. After cloning the repository, here’s how you can try it out for yourself (default port 2222):
[...] Your SSH client will hang there and wait for at least several days before finally giving up. Like a mammoth in the La Brea Tar Pits, it got itself stuck and can’t get itself out. As I write, my Internet-facing SSH tarpit currently has 27 clients trapped in it. A few of these have been connected for weeks. In one particular spike it had 1,378 clients trapped at once, lasting about 20 hours.
(Score: 5, Interesting) by ledow on Monday March 25 2019, @07:51PM (3 children)
Rather than waste my resources responding to obviously malicious communications, I just block them.
The way I do this is looked-down-upon for reasons I can't fathom.
I don't pretend it's secure. I claim that it stops random automated spam rather than specifically-targeted attacks, which are the main category most people receive.
I use portknocks.
Unless you hit, say, ports 1234, 2345, and 3456 of my IP *IN THAT ORDER* with nothing else in-between from your IP, then you suddenly get visibility of the SSH port 22. For 30 seconds, to initiate your connection.
Simultaneously, anyone else on any other IP, or without the correct knock, or just trying sequential/random ports stands an infinitesimal chance of even activating the port-knock, let alone realising that it actually did anything (port knocks can be any length, so you'd have to scan in-between each knock attempt within 30 seconds in order to see if it opened anything), gets absolute zip. Rather than "everyone can see you have port 22 open", you can literally slide into the SSH server without any other IP even getting a valid packet to it.
And yet, when *I* want access, I have apps on my phone that will connect, knock and SSH into my machine. Hell, in a pinch, I just download a client or "tap" certain ports with any standard util that opens a connection (e.g. nc, telnet, etc.) and then connect as normal.
Replay attacks? You can combat those (by using portknocks that are cryptographically time-dependent, etc.).
Network sniffing? So my port 22 opens to me for 30 seconds. You'd have to replay it that same knock (assume it's not dependent on the IP it came from or the current time), and that would grant you access to port 22 for 30 seconds... to do what? Hit the normal layers of security that you would have without portknocks (i.e. no passwords, public-key-only, etc. etc.)
Worse-case: You get to my port 22 for 30 seconds which would have been wide-open to the net anyway.
Since I put port-knocking (with Knockd) on my SSH-running servers over ten years ago, I literally have never seen the logs let anyone open the port except me. The closest was a "Stage 1, Stage 2, Fail" (i.e. they didn't get in, because they just happened to hit the first two knock-ports but the third was wrong).
Same yourself some time rather than "security through pathetic obscurity" (moving SSH to a non-standard port that can be discovered in 60 seconds with nmap), maintaining huge blocklists and tying up resources (e.g. fail2ban, etc.) or just plain "put port 22 out in the open". Deploy your standard software, implement port-knocking (apt-get install knockd and then edit /etc/knockd.conf to do whatever you like on whatever knock you like), and watch your logs fall silent while never denying YOU access.
People really look down on it for some reason, can't fathom why, but they accept the above as "solutions"? Next best thing to literally just only opening port 22 to your known external IP's (but let's hope with that that you never have to connect over another connection in an emergency, eh?)
(Score: 2) by dwilson on Monday March 25 2019, @08:38PM (1 child)
Probably because port-knocking looks and sounds needlessly complicated, given that the usual goal isn't to prevent unauthorized login attempts, but to prevent unauthorized logins.
Myself, I lock it down by only allowing pubkey authentication and only certain users to connect, a few other changes, and then stop worrying about it. Logfiles haven't shown a break-in yet.
stribika's ssh guide [github.io] is my usual go-to when setting up a new sshd instance.
- D
(Score: 3, Interesting) by ledow on Monday April 01 2019, @10:16AM
That's all fine... I have pub-key-only too. That's where your actual security is.
But if you open port 22, you get thousands of automated attempts against it, and testing of your SSHd for vulnerabilities constantly.
It only takes one remote hole, weak key, etc. to bring that down. And I'd rather my logs weren't filled with spammed access attempts except serious ones.
Learning to ignore / not check your security logs is a very bad habit to get into.
(Score: 0) by Anonymous Coward on Monday March 25 2019, @09:02PM
As I've mentioned above in another post. I use a whitelist to limit the problem. I know which subnet the authorized logins are going to come from, no reason to let the whole world open a connection. Having limited the scope of the problem, an automated log-monitoring system for banning unauthorized access is not going to be a demanding task.
I think port knocking is pretty cool, but I haven't got a use for it yet.