Live data from Hacker News

Port knocking

en.wikipedia.org

61–70 of 185 posts

Re: Port knocking

#61

Earlier quoted context omitted.

from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.

> moving ssh off of port 22 cuts your drive-by log noise I didn't know logs made me unsafe! I'm turning off all logging immediately.

The quote is not about logs making you unsafe. The quote is about ssh login and connection attempts on port 22 which clutter your log files.

Assume you move ssh to another port, say 23. In that case, anyone trying to connect to port 22 would find a closed port and the connection would fail, on a layer before login attempts get logged.

Re: Port knocking

#62

Earlier quoted context omitted.

from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.

I wonder if it would be interesting to load a ssh honeypot that would feed from the logs so it would add the logins and then just dump the ip + input to a file. Honeypot could basically run in a some sort of isolation layer (like Sandboxie or jails) and then self-destruct after the automated script is gone... and then you slam the door on that user/ip combo for good. I can't help but think this would be interesting..…

I think you're talking about something like Kippo: https://www.honeynet.org/projects/old/kippo/

Re: Port knocking

#63
Classic! I remember using Port Knocking during the Louisiana Tech CyberStorm Hacking Competition in 2015 to completely lock down open ports on our VM Host Server since trying to use the glitchy Server KVM directly on the Rack was a test in futility. Between Port Knocking, Xpra, and knowing to disconnect the VMs from the network until after I had patched them, no one stood a chance hacking our VMs. Their VMs on the other hand often didn't withstand my scripts just constantly trying to get in with the VM default passwords, change the flags to give us credit, lockdown and take over root, leaving us a way back in after, and continuously using the root account to reclaim the flag if they noticed.

Re: Port knocking

#64
post #60

Earlier quoted context omitted.

From a systems-administration standpoint, it's nice to be able to easily sift out the random bots and drive-bys from the more personal probes that maybe have a human at the other end. There are myriad bits and bobs of software and services that promise to do anomaly detection in logs, but an easier approach for now is to just move ssh off 22. It affords basically zero extra real security but makes any subsequent logi…

Let me gently challenge you: you've moved SSH to 7163/tcp. You see a pattern of login attempts. Now what, and why?

Sure. Direct answer: search logs across all services and nodes on the network for activity from that source or netrange. See if it's targeting particular usernames, especially anything that shouldn't be guessable. Treat it first as a source of information: did I screw something up somewhere? Have we had an incident I don't know about? If it looks like nothingburger, ignore it and get on with the day.

Broader answer after reading some of your other comments in this thread: in your ideal, highly secured network environment, none of this is necessary because everything's wired up tighter than a gnat's ass hole. Unfortunately I've never had the pleasure of working for one of those places.

Re: Port knocking

#65
post #27

Earlier quoted context omitted.

What if your port knocking monitor has a zero day?

Then ssh would protect you. The two having zero days at the same time is unlikely.

I guess that sort of depends on the nature of the zero day, huh?

Re: Port knocking

#66
post #27

Earlier quoted context omitted.

If your ssh sever had a 0day, port knocking would protect you.

What if your port knocking monitor has a zero day?

That's kind of the idea Moxie had with [1].

Only 15 lines of code run as root, and they basically just tail kern.log.

[1] https://moxie.org/software/knockknock/

Re: Port knocking

#67
post #57

Earlier quoted context omitted.

> the sources are so diverse you couldn't even realistically block a determined scanner thankfully, i dont have properties which attract determined scanners. and i imagine that's true for 99% of public ip addresses, too.

So then, of course, there isn't even a theoretical reason why you'd want to pay attention to SSH probes.

i mean, you're in the security industry, where targeted attacks are the default assumption. the overwhelming majority of web properties are not valuable enough to get this kind of attention.

even if security through obscurity is not real protection from targeted attacks, it is at minimum significant noise reduction, and quite possibly a reasonable barrier against drive-bys which assume default configurations. i'm sure you know how many scanners try to access some default php/wordpress admin route. how much of that would disappear if wordpress was simply installed behind a random 32-char route instead of /wp-admin? all it is is obscurity, sure. but is it not security?

Re: Port knocking

#68

Earlier quoted context omitted.

from personal experience, simply moving ssh off of port 22 cuts your drive-by log noise by 99.9%, which makes auditing clean logs much much easier. failed login attempts with ssh on 22: hundreds per week, after: 0. i imagine with knockd it would go negative.

> moving ssh off of port 22 cuts your drive-by log noise I didn't know logs made me unsafe! I'm turning off all logging immediately.

The point is that most login attempts are automated, and the automated scripts just try port 22 and move on if they fail. If you run ssh on port 22, you see in your logs all the failed attempts from the giant sea of automated scanners, and will probably miss the one or two humans who might know something about you specifically (like your username) and are trying a targeted attack.

If you put ssh on another port, all of those automated login attempts disappear from your logs. The determined human attacker probably has port-scanned you and found ssh on another port, so you'll see just that attacker and can look into it more deeply if you feel the need. On port 22, you probably never bother to look at your failed-attempt log, because there's so much noise.

Re: Port knocking

#69
post #60

Earlier quoted context omitted.

Let me gently challenge you: you've moved SSH to 7163/tcp. You see a pattern of login attempts. Now what, and why?

Sure. Direct answer: search logs across all services and nodes on the network for activity from that source or netrange. See if it's targeting particular usernames, especially anything that shouldn't be guessable. Treat it first as a source of information: did I screw something up somewhere? Have we had an incident I don't know about? If it looks like nothingburger, ignore it and get on with the day. Broader answer a…

I guess that's fair. But: if you buy into this idea, there's a much, much better thing to do: look into Canarytokens. Canarytokens, unlike port knocking, are criminally underused. Really, you should do something similar for your off-port SSH service; don't actually _run_ SSH there, just run a stateless unprivileged service that spoofs a bit of SSH protocol and generates loud alerts.

The networks I'm describing aren't "ideal" or "highly secured". I am describing table stakes. While I was at Latacora, most of the clients we engaged with were already at this level of maturity when we joined up.

Re: Port knocking

#70

I too am a fan of port knocking. I don’t use knockd, just iptables. I found the Arch Wiki most helpful. You’ll need to figure out which chain works for your setup but it’s pretty straightforward. https://wiki.archlinux.org/index.php/Port_knocking#Port_knoc... Here’s my example for a VPN running on OpenWrt. If you experience any race conditions with iptables you can pepper each rule with something like “-w 5” This ope…

FWIW I worked with a guy who insisted on doing it this way and it was extremely twitchy.

Problems included various operating systems and network tools knocking in ways that iptables hates but a knock daemon will handle (e.g. sending two requests per port); making iptables rules unnecessarily complex and hard to audit and eventually conflicting with other things that interacted with iptables; and, once, accidentally getting the knock-related rules nuked by some other software and turning a simple login into a fun little puzzle at exactly the wrong time to be solving more puzzles.

We tested both approaches early on. A working knockd implementation cost less than an hour, including getting other users set up to interact with it. The iptables implementation he switched to shortly after ended up costing dozens of hours.

Post reply on HN