Live data from Hacker News

Port knocking

en.wikipedia.org

161–170 of 185 posts

Re: Port knocking

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

Expanding on that substantive critique, i.e. complexity. Port knocking strips you of the benefits you get from session protocols like TCP. - Fails when packet loss is high. - Fails when lags make the attempts arrive in changed order - Fails when multiple people try to execute the sequence at the same time (yes, you can track source IPs, but then it doesn't work from behind a NAT) Agreed, none of this is a problem on…

"Expanding on that substantive critique, i.e. complexity. Port knocking strips you of the benefits you get from session protocols like TCP."

This is correct and worth considering.

In actual practice (again, over 15 years, all over the world, etc.) I have found that the only place I ever run into this is on airplane (in-air) wifi. I don't know if they are specifically blocking random fragments or if they are just too laggy to make this scheme work.

A quick workaround is to ssh to some other host that you control that isn't behind a knock, but does have 'knock' installed and then jump through it.

Re: Port knocking

#162
post #147

Earlier quoted context omitted.

You already do both when you are concealing an ssh server. The cryptography part is the responsibility of the ssh server. edit: That specific scheme looks naive and susceptible to replay attacks.

The suggestion is nice though since an attacker would have to break both at once. If you conceal an SSH server, you'd first break the obscurity, then proceed with attacking the SSH server. The suggestion seems to be that you would have to break the cryptographic part to reveal the server (which is then supposedly secured by "normal" cryptographic means, such as a regular SSH server). That is, you are dealing with cry…

I'm all for defense in depth but I don't see the point of a redundant cryptographic layer. It's not trivial that it doesn't broaden the attack surface instead of narrowing it.

If the argument is that a steganographic layer that involves cryptography does a better job at concealing than a similar layer that doesn't I'm also not convinced. Cryptography helps against MITM scenarios, but at that point the existence of the service is already revealed.

Re: Port knocking

#163
post #9

And to save other folks a search, this is pretty awesome: https://linux.die.net/man/1/knockd

If someone intercepts the traffic to my server, they could see the knock sequence and re-use it. Is there any way to get knockd to use a google authenticator-like sequence of port knocks?

Yes, take a look at the manual page for knockd and search for "One_Time_Sequences". It does what you are asking by using a one-time valid sequence of port knocks, but it is like HOTP rather than TOTP.

Re: Port knocking

#164
Why is this better than an application taking open requests on one of the ports and accepting a password used to open the other port?

Re: Port knocking

#165
post #144
post #52

Earlier quoted context omitted.

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…

Re: sniffing, if I were implementing port knocking I would use the "single packet authorization" variant like in knockknock, which makes sniffing much less useful to an attacker.

At the point where you're installing network cryptography tools to authorize access to your machine, why not just use a real cryptographic tunnel?

Re: Port knocking

#166
post #145
post #122

Earlier quoted context omitted.

Can't we do both? Like, the content of the UDP packet is the output of `date -uIs | gpg --sign`.

From knockknock: > When you want to open a port from a client, you run 'knockknock', which sends a single SYN packet to the server. The packet's IP and TCP headers are encoded to represent an IND-CCA secure encrypted request to open a specified port from the source IP address. https://moxie.org/software/knockknock/

That page links to a http insecure download script, weird. (Not https, no signature)

This link: wget http://www.thoughtcrime.org/software/knockknock/knockknock-0...

Re: Port knocking

#167
post #35

A fun exercise is to integrate this with TOTP by reloading knockd with a new config every 30 sec based on the secret.

Doesn't TOTP usually allow for clock drift in either direction? This might be problematic, especially if there's some IO issue causing it to hang. What happens if the rootfs gets stuck read only?

Re: Port knocking

#168

Earlier quoted context omitted.

vpn + port knocking should be good enough but I am not sure how to implement it in an efficient way (I currently only use a VPN) https://www.howtogeek.com/105693/how-to-knock-into-your-netw...

Does this have any advantages over using plain wireguard? WG operates purely over UDP and doesn't respond unless you send it packets with an authorized key, so it's essentially the VPN and port knocking all in one.

I guess if you only have the key, you would still need to figure out how to use it

Re: Port knocking

#169
post #7

Earlier quoted context omitted.

any tips or where one would get best practice for configuring/setting up/using knockd? I wrote up how having a server on the internet is scary now ( http://redgreenrepeat.com/2020/03/20/why-you-should-secure-y... ) and how to protect it ( http://redgreenrepeat.com/2020/04/10/how-to-secure-your-serv... ) One thing I didn't get into more was port knocking/knockd as there were not many resources for it. I'd love to lear…

Moxie actually published a nice lighweight port knocking daemon that: * Does not bind to sockets * Is not written in C * Prevents replay attacks * The only code that runs as root is just tailing kern.log and is like 15 lines It probably needs to roll from SHA1 to SHA256 and Python2 to Python3, but otherwise seems sound. [1] https://moxie.org/software/knockknock/

Looks like there is a pull request to change it from authenticate-then-encrypt to encrypt-then-authenticate that hasn't been merged for over five years. Thinking this project might be abandoned, unfortunately. :-(

Edit: It appears there may be an active fork here: https://github.com/indyprime/knockknock

Still digging through to see if the encrypt-then-authenticate change made it into this version.

Edit 2: It looks like it still uses authenticate-then-encrypt. I sent an email to the maintainer of that fork, we'll see what happens. ^__^

Re: Port knocking

#170
post #145

Earlier quoted context omitted.

From knockknock: > When you want to open a port from a client, you run 'knockknock', which sends a single SYN packet to the server. The packet's IP and TCP headers are encoded to represent an IND-CCA secure encrypted request to open a specified port from the source IP address. https://moxie.org/software/knockknock/

That page links to a http insecure download script, weird. (Not https, no signature) This link: wget http://www.thoughtcrime.org/software/knockknock/knockknock-0...

Yeah, the documentation is dated. Not only does it point to an old version, but it would probably be best to get it from the GitHub page he links to. Even then, there are more active forks, so they may be worth checking out to see which would be best to get on board with.
Post reply on HN