Hacker News Reader

Comment by acl777 | Hacker News Reader

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 learn more about how you have used knockd.

View on HN

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

The following is a little lame, but I want to see who has knocked so far today (should just be me and my own IPs) so I do this every minute:

  * * * * * /sbin/ipfw show|/usr/bin/grep ^01021 | awk '{print $7}' > /tmp/.knock_list

... and then cat that list to myself every time I log in ...

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?

> So with poet knocking

Knocking a poet is bound to get you into trouble. Poets fight back, and hard. Just don't do it.

But they're just so damn eloquent all the time. It drives me nuts.

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

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

This is freaking genius!

Personally I avoid knockd and instead use something like fwknop https://github.com/mrash/fwknop. You get the advantage of port kocking while protecting yourself from re-play attacks. The main dis-advantage is it is a more complicated procedure so it may limit you a bit.

How I set it up specifically: https://peekread.info/tech/20190513-fwknop/

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

I think "attacker has a private key" is an unreasonable threat model to protect against, not least because the key is so much harder to crack than port knocking. The benefit to port knocking is against information disclosure ("this server is running Apache httpd version x.y and sshd version z"), brute force, noisy logs, and pre-auth vulnerabilities (things like heartbleed and shellshock). While in theory I suppose wireguard could be affected by pre-auth vulnerabilities and maybe a completely blind bruteforce attack, it's a listening UDP port that doesn't respond until it sees valid credentials, so it's completely invisible to an attacker.

Reply on news.ycombinator.com