Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Port knocking

en.wikipedia.org

Post reply on HN
Print view View original

41–50 of 185 posts

Re: Port knocking

#41

Post by rsync »

polishdude20 wrote: post #31
rsync wrote: post #24

Earlier quoted context omitted.

My default ipfw ruleset is very restrictive - no ports open. The command that gets run when the (correct) knock comes in is an ipfw command: /sbin/ipfw add 01021 allow tcp from %IP% to 10.0.0.10 22,443 setup ... so now the knocking IP can see TCP 22 and 443 (and nothing else). I then have a cron job that runs every night at midnight that deletes those rules: 0 0 * * * /sbin/ipfw delete 01021 ... so I am required to k…

So with poet knocking, if I only have an ssh port open and a couple of ports my servers server content on like an http and https server, I'm assuming id use port knocking to get inside my ssh port right? I don't need to do port knocking for my http and https ports because they're open but not as an ssh service?

Yes, that's right - you'd leave your public services open by default and the knock would simply open up tcp22 ...

Re: Port knocking

#42

Post by leeoniya »

cortesoft wrote: post #37
rsync wrote: post #5

I've been in this business for a long, long time and have come across all manner of innovations regarding network security. Port knocking (which I think I learned about first at defcon ... perhaps 18 years ago ?) stands out as one of the very few things that made my network(s) substantially safer at nearly zero cost. I love, and continue to love, both the idea and the implementation. Pay no attention to the nay-sayer…

What is your conclusion that port knocking has made your network substantially safer based on? Just curious how you measure the effectiveness of something like this.

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.

Re: Port knocking

#43

Post by dvtrn »

taliesinb wrote: post #12

I implemented a physical port-knocking daemon, once. I lived in a block of flats — you needed an expensive fob to open the outer gate, and it didn’t even work reliably. I lost my fob. So I took my intercom apart and wired a band pass filter circuit between the buzzer input and actuator output. If you pressed my buzzer with the right steady pattern, it would automatically let you in. It worked great and I didn’t buy a…

I port knocked called a friend once while traveling overseas when a second friend decided to act like an idiot and got us both some attention by the local authorities.

First friend-a local-is the type who doesn’t answer his phone from numbers he doesn’t know/isn’t saved as a contact-which I knew, so I dialed him, then dialed his wife (who also doesn’t answer unknown numbers), then dialed him again. He picked up the second time and after some explaining he chuckled and goes “yeah I figured it must be important when the same number called $wife immediately after calling me”.

He was there to pick us (including drunk mutual friend) up within the hour. And yes, he’s a network engineer heh.

Re: Port knocking

#44

Post by tptacek »

Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely.

In 2020, it's gone past "silly" and is now a design smell, in the same way that actually relying on fail2ban would be. Whatever port knocking is doing to help you is a a description of something you're doing wrong with your architecture.

We're not even comfortable with long-lived keys anymore; modern networks are built with short-lived certificates issued off 2FA from an IdP. We have good VPNs right now for the other weird cases. Our networks default to all-ports all-hosts closed. Arguably, port knocking is literally setting your security back, by making it harder for automated tooling to scream bloody murder if you've managed to expose a dev instance unexpectedly to the Internet.

Don't bother. If you've got a single system you're managing outside of a cloud provider with its own decent network firewall, just set up WireGuard and filter everything but that. If it helps, think of WireGuard as the evolution of SPA port knocking.

Re: Port knocking

#45

Post by peterwwillis »

leeoniya wrote: post #42
cortesoft wrote: post #37

Earlier quoted context omitted.

What is your conclusion that port knocking has made your network substantially safer based on? Just curious how you measure the effectiveness of something like this.

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.

Re: Port knocking

#46

Post by tptacek »

leeoniya wrote: post #42
cortesoft wrote: post #37

Earlier quoted context omitted.

What is your conclusion that port knocking has made your network substantially safer based on? Just curious how you measure the effectiveness of something like this.

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.

Wouldn't a reasonable rebuttal be that the log filtering rule that discards these failed login attempts would accomplish the same security goal, with less mechanism?

Re: Port knocking

#47

Post by WrtCdEvrydy »

leeoniya wrote: post #42
cortesoft wrote: post #37

Earlier quoted context omitted.

What is your conclusion that port knocking has made your network substantially safer based on? Just curious how you measure the effectiveness of something like this.

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...

Re: Port knocking

#48

Post by leeoniya »

tptacek wrote: post #46
leeoniya wrote: post #42

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.

Wouldn't a reasonable rebuttal be that the log filtering rule that discards these failed login attempts would accomplish the same security goal, with less mechanism?

i prefer knowing that nothing is happening rather than filtering things i dont like.

also, lots of people sing the praises of fail2ban, which needs to watch log files to operate, but you can get most of its utility by simply rate-limiting using iptables' session tracking without any additional mechanisms.

https://selivan.github.io/2018/07/07/limit-new-connections-f...

Re: Port knocking

#49

Post by fao_ »

tptacek wrote: post #44

Port knocking was somewhat silly when it was introduced ~20 years ago --- at most, on a reasonably designed network, it was saving you from your own misconfigurations, but at least in 2005 it was reasonable to imagine a highly diverse network of machines that people logged into using multiple protocols, where those misconfigurations were likely. In 2020, it's gone past "silly" and is now a design smell, in the same w…

If you're exposing a developer instance to the network and it has port knocking deployed, why does it matter? The discoverability of such a service is basically zero.

What are the chances of the cracker finding the exact combination of ports to knock on, and then the exact key to use? If they're able to do that then they are a dedicated attacker and they're mitm'ing a presumably encrypted connection on your network, so you probably have more problems than just one bad machine, they already replicated or replaced a certificate on your machine, or worse.

And if you then expose a service that isn't via the port knocking algorithm, surely that would show up?

> We're not even comfortable with long-lived keys anymore

Can you not just change the key N number of logins and factor in 2FA as well?

I'm not sure how port knocking cannot, at least theoretically, be used in conjunction with the other measures you talked about.

Re: Port knocking

#50

Post by tptacek »

leeoniya wrote: post #48
tptacek wrote: post #46

Earlier quoted context omitted.

Wouldn't a reasonable rebuttal be that the log filtering rule that discards these failed login attempts would accomplish the same security goal, with less mechanism?

i prefer knowing that nothing is happening rather than filtering things i dont like. also, lots of people sing the praises of fail2ban, which needs to watch log files to operate, but you can get most of its utility by simply rate-limiting using iptables' session tracking without any additional mechanisms. https://selivan.github.io/2018/07/07/limit-new-connections-f...

I can tell you right now what's happening and compress all those log records into a single record:

Every exposed 22/tcp on the Internet is being continuously exposed to automated SSH scanners running from thousands of points on the Internet. There is nothing you can reasonably do to prevent it (the sources are so diverse you couldn't even realistically block a determined scanner), and, if you've turned off password authentication --- which you must do anyways --- the probes aren't a meaningful threat.

Post reply on HN