Live data from Hacker News

Port knocking

en.wikipedia.org

131–140 of 185 posts

Re: Port knocking

#131
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…

For me changing the default port for SSH achieved much of the same result at an even lower cost IMO. That is, unless you're high profile enough that attackers might want to target your server specifically and you're not just randomly scanned by botnets which won't generally bother looking beyond port 22.

Re: Port knocking

#133
post #112

Earlier quoted context omitted.

Back in the day of payphones and expensive long-distance calls, hitchhikers had a protocol for calling their parents/friends for free: they ring them up but don't say anything. The callee reads a list of expected answers (like the towns where the caller would stay), and the caller hangs up on the right answer, then dials again. Not sure how payment worked and why you could listen for free—I'm only familiar with the m…

Sounds like 1800 reverse where you could send a short 2-3 second message that’s supposed to be your name. The other person would get an option to receive a call from for $5, but usually is the name or code of a location to be picked up. I must have done this 100 times as a kid. Once an angry man clued onto it, switched my line across and told me off. This is back in the days where mobile calls were expensive and very…

I think that's just good old Mr. Bob Itsaboy: https://www.youtube.com/watch?v=9JxhTnWrKYs

Re: Port knocking

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

Turn on logging for failed connection to port 22 and you have just recreated the same log file, assuming you trust the underlying security in your sshd configuration. You just moved the "nothing happened" event from the sshd to the firewall, and the firewall by default do not log such events.

The best argument in favor of knockd that I can think of is the same of fail2ban, which is that ssh connection is actually a finite resource. You can only have so many simultaneous TCP connections. Rejecting packages in the firewall has no limits, and I have had servers which has received service disruption in the past because swarms of ssh bots used up the available tcp connections that the web server could handle. fail2ban in my case was a less intrusive change to our work flow so we use that rather than knockd to solve the problem.

I will add as a small note that the default of not logging firewall events has come to bite us once in a while. Just like keeping the default in ssh to log, keeping the default to not log is a trade off between resource usage and keeping logs of events.

Re: Port knocking

#135
Port knocking is pointless. Just use a password over UDP and stop feeling yourself with your cloak and dagger pretend spy nonsense.

Re: Port knocking

#136
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…

I've been wanting to implement knockd on something for years but people always push back. I don't actually think it's incredibly useful but I love the cool factor. Good for you for actually doing it.

Re: Port knocking

#138
post #52
post #49

Earlier quoted context omitted.

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,…

The premise of your comment is that you're deploying dev instances on routable IP addresses on networks without default-closed filtering, in a configuration where it's theoretically possible that people could directly get a remote shell into that machine. Don't do that. In AWS (for example), have a dev VPC, and a WireGuard forwarder on it (or, if you're doing things 2010-style, an SSH bastion). If the machine needs t…

You're telling people not to do a simple thing, instead telling them to do a far more complex thing.

You do not give a single argument on why the complex thing is meaningfully safer in practice.

If security is equal for all practical purposes in either case, this would be the wrong thing to do, because it is easier to fuck up complex things and it's more expensive to manage them.

https://xkcd.com/538/

Re: Port knocking

#139
I agree with other comments that portknocking is stupid.

It's not stupid to have a tiny tiny service to unlock your bigger attack surfaces. It IS stupid to implement "IP-over-SYNpackets" (actually "password over SYN packets") when we already have a perfectly good way to send packets of information that doesn't expose even the complexities of TCP (e.g. slowlaris, SYN flood, etc…). And it's called UDP. Just send your plaintext password in a UDP packet.

It's not exactly hard to safely receive a UDP packet. In fact it's orders of magnitude easier to make a UDP server secure than a raw packet sniffer.

But also I would argue that TCP MD5 (RFC 2385) is vastly underused. It doesn't work through NAT, so maybe now that IPv6 is becoming more and more common it'll gain more traction. It's been used in production with BGP since forever (at least since the 90s), but there's nothing stopping it being used for SSH too. (in fact I run a patched OpenSSH that uses TCP MD5, see my blog post)

TCP MD5 also prevents your connection from being reset on a TCP level, once it's up and running, even by someone who can inject spoofed packets and sniff your encrypted connection.

More on this: https://blog.habets.se/2019/11/TCP-MD5.html

Re: Port knocking

#140
post #131
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…

For me changing the default port for SSH achieved much of the same result at an even lower cost IMO. That is, unless you're high profile enough that attackers might want to target your server specifically and you're not just randomly scanned by botnets which won't generally bother looking beyond port 22.

Put ssh on port 80 and http on port 22 - perfect security ;)
Post reply on HN