Show HN: Ruroco – like port knocking, but better | Hacker News Reader

Show HN: Ruroco – like port knocking, but better

github.com

127 pointsmschempp102 comments

Hey there HN!

ruroco (RUn RemOte COmmand) is a tool that lets you execute commands on a server by sending UDP packets (instead of knocking on ports).

the tool consist of 3 binaries:

- client -> runs on your notebook/computer and sends the UDP packets

- server -> receives the UDP packets and makes sure that they are valid

- commander -> runs the command encoded by the data of the UDP packet if it's valid

The commands are configured on the server side, so the client does not define what is going to be executed, it only picks from existing commands.

I use this tool to open up the SSH port on my server via ufw, but only for the IP address from where I'm connecting, so the SSH port appears closed for everyone else, except me.

This is my very first "real" rust project, so any feedback is highly appreciated :)

Enjoy!

Open articleView on HN

Pretty cool. Have you seen considerations regarding port knocking by Moxie Marlinspike? I think he raises some valid points: https://github.com/moxie0/knockknock

Instead of using UDP he reads the firewall log. Also he prevents replay attacks (even though his implementation is apparently not secure in this regard). Unfortunately his code is ancient and in Python 2, so a rust implementation would be awesome.

> Instead of using UDP he reads the firewall log.

Hah! I'd never seen this before, but in a fit of pique driven by ssh scanning one day I did a similar pattern on my OpenBSD router: I added a block in log to a high port in pf.conf, wired up a little shell script that did tcpdump on pflog0 and watched for a packet to come in, then added the IP to the allow port 22 table.

I knocked on the door three times, two of which were testing, and ended up throwing it all out in favor of wireguard & making SSH no longer listen on em0, which seems infinitely less silly.

I know its very minor, but are there ergonomic improvements possible to this setup besides shell aliases/functions around pairing `wg-up host && ssh host && wg-down host`?

I agree that ultimately, with wg in the kernel, this is a much simpler setup.

From the OpenBSD perspective, I just populate /etc/hostname.wg0 on my laptop with my wg configuration ... and I can immediately `ssh router` at home or on the road :-)

IOW, why ever down the connection? Why not start your tunnel immediately when the network comes up and leave it running until the network goes down?

I was thinking about doing this to multiple different servers and thought they could all share the same vpn network address for simpler configuration but now that I think about it doing that might run into constant server-key-changed warnings from SSH.

If you need a management vlan, make one.

Wireguard interfaces are _cheap and easy_ - there's no reason not to set up an interface for normal client traffic that sshd doesn't listen on, and an interface for just sshd with different ACLs and routing logic if you want.

You don't really have to do that. Wireguard is very silent protocol. Even when you bring up the interface, unless you are sending anything to that interface, it will not redo the handshake. So you can keep it up all the time.

This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.

Well, tcpdump is explicitely not what you want to do in this case as Moxie points out, but other than that i guess, yes, it's similar.

> Well, tcpdump is explicitely not what you want to do in this case as Moxie points out

Why's that?

E: oh, if you aren't familiar with OpenBSD I might get the confusion – pflogd/the kernel (not me!) watches the actual network device and dumps to a file. So the actual "knocking" daemon I bodged together is one part running as a privsep user watching a log file and giving IPs to the other part which just adds to the pf table allowing access.

My threat model didn't include people who can fuck with pflog(4) to attack tcpdump(8) - I'm sure they're out there, and if they wanted to be they'd already be in my network (or already are).

Ah, that makes sense. I actually didn't know that about openbsd.

One of the reason why I wrote ruroco is, that I can run this from probably anywhere in the world, if I put the service on port 53, because thats DNS and that does not get blocked by any wifi whatsoever.

I used to use port knocking, but at some point found myself in a hotel where they blocked ALL ports, except TCP 80 and 443 (did not check UDP at the time).

My ssh port is on 80, so I can use all of my tools, even if the network I'm in blocks everything else.

I mean you can still use 53/udp, but the point is he doesn't start a service or sniff the interface with libpcap, because both of these increase the attack surface.

You are right, but if you are in a network that blocks every packet that is sent to any port which is not 80 or 443 your port knocking capabilities are very limited.

Ultimately reading firewall logs to do port knocking is most secure way, because - as you said - there is virtually no attack surface.

I would argue that port knocking is extremely inconvenient and does not work in every scenario. So for me it's a tradeoff between "ultimate" security and convenience.

Port knocking appeals to me because of how few bytes you have to send. But a system I’ve been thinking of (and surely a bunch of people before me) goes like this:

Instead of knocking on ports, send actual HTTP requests to different paths. Over TLS or just plain HTTP.

So where you’d port knock a sequence of ports here instead you send GET requests to some different, publicly known paths

GET /index.htm

GET /about_us.htm

GET /index.htm

GET /about_us.htm

GET /products.htm

You get the idea.

And now then the challenge is that if you’re on a network that does HTTP caching, it would interfere with this.

But we already have the well known cache-busting technique for that right, so

GET /css/main.css?ver=64729929

GET /js/bundle.js?ver=947367292

GET /js/bundle.js?ver=7483939

And so on. And version is for example current Unix time and is actually ignored in terms of “knocking”. Only the path matters.

WiFi access points can redirect 53 to the DNS resolver of their choice.

btw.:

ruroco DOES prevent replay attacks, by saving the deadline (which is in ns) in a blocklist. It does not matter if the deadline has "passed", the deadline is added to the blocklist as soon as the packet reaches the server and is deemed "valid". So each packet is only valid exacly ONCE

I wonder if Moxie would now consider knockknock "cryptographically doomed"? From the README, whose commit [1] is dated 2011-09-15:

> The request is encrypted using AES in CTR mode, with an HMAC-SHA1 using the authenticate-then-encrypt paradigm.

A mere three months later, he would publish The Cryptographic Doom Principle [2] (dated 2011-12-13).

[1]: https://github.com/moxie0/knockknock/commit/e24eb33f666fc092...

[2]: https://moxie.org/2011/12/13/the-cryptographic-doom-principl...

Very unfortunate.

http://www.thoughtcrime.org/software/knockknock/ has been excluded from the Wayback Machine, and archive.is is captchawalled.

The security section fails to explain how the service prevents an attacker from intercepting a packet, then sending it again himself with a new sender IP address to whitelist SSH access his IP address.

The original (authorized) sender would then think something went wrong (packet loss), send a new packet and be none the wiser.

I agree with your observation, but this is merely put fwd as an alternative to port knocking.

Port knocking is IMHO just to keep your sshd logs clean from huge lists of failed attempts, that prevent me from actually finding interesting information in them.

I used port knocking in the description, because anyone here probably knows what port knocking is and ruroco is kind of similar to that.

Ruroco can be used for more than just keeping sshd logs clean, for example I could also enable a service other than ssh, for example a private file server that I want to get access to when I'm on my phone (although I haven't implemented an android version yet, it should be doable).

Even if that was protected against (by putting the source IP inside the payload), I'm not sure it's really much more secure. An attacker who can intercept the packet can likely also spoof the source IP, so the attacker could wait for you to open it with your IP, and then use your IP using spoofing.

Spoofing UDP is easy.

Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP, which means either you are already on the receiving path, or managed to put yourself on it e.g. through a BGP route advertisement - either way, it leaves some trail and much harder to carry out.

(And even so, the attacker still has to go through SSH authentication or an SSH vulnerability)

> Spoofing TCP is useless...

See: https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack

It's not practical but it is possible. It was more effective in the past when operating systems had more predictable initial sequence numbers. Famously this is how Kevin Mitnick (allegedly?) attacked Tsutomu Shimomura.

It’s been more than 20 years since any mainstream operating system was vulnerable.

IIRC even SYN cookies are older than 20 years at this point.

It is absolutely still a vulnerability; there's no way to protect yourself against someone who can read the sequence numbers anywhere in the middle of the network. Crypto can help you detect this but not prevent it.

RST attacks in particular are common enough to make TCP completely unsuitable for reliable long-term connections. And since TCP is also unsuitable for short-term connections, that leaves UDP the only option.

Which is exactly what I said two posts up. https://news.ycombinator.com/item?id=41329065

Now, RST attacks are still a thing, but mostly irrelevant to this port knocking alternative.

>Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP

What do you mean "original TCP"? I'm talking about an attacker creating a new TCP connection with a spoofed source address.

> which means either you are already on the receiving path

Yes, I believe that's the threat model under discussion here. Tepix mentioned an attacker who can intercept a packet, which I believe means the attacker is already on the receiving path.

Afaik it doesn't. The only useful thing there is, is a deadline on each packet so the retransmission would have to be fast, but it seems doable.

https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

The encrypted information is current time, command and random data. So the server could feasibly detect that a retransmission has occurred but that's about it.

Fair point, but all that gets you is SSH listening, they way it has to be now anyways if you want remote access.

This doesn’t feel like an unpickable lock so much as a decorative cover that makes the lock less obvious.

This is a good point. I think a simple remedy would be to include the IP the server should allow connections from as part of the authenticated payload from the client in the request.

That defeats the purpose of port knocking. If you know which IP connections comes from and you trust it - just allow connections in firewall. Port knocking is for temporary allowing certain incoming IPs.

Hi Tepix. Im the author of the tool.

Thanks for the feedback! It doesn't describe how it prevents that attack, because it doesn't prevent this attack :).

As someone else wrote, I could put the IP address of the sender into the encrypted data and validate that in the backend and drop the packet + block the IP address.

I will add that in the next release!

No that won't work because the sender doesn't know what the src ip of the packet will be by the time it arrives (NAT is everywhere!)

the client COULD use something like https://www.ipify.org/ to get the IP, which can then be used as an additional client argument.

But if an adversary uses the SAME network, then the IP address that the server sees will be the same for the client and the adversary, so it only matters if the adversary takes the packet and sends it from a different network, which the adversary won't have to do, because they still control the network where the packet was originally sent from.

If your use case is "remotely trigger execution of a very small set of fixed commands, securely" then there's Ostiary: https://openwrt.org/docs/guide-user/services/remote_control/...

Its value is in the simplicity of the crypto protocol used for this - basically "hash a password with a one time pad".

Thanks for the link. Looks interesting!

I know a guy who works as an IT consultant for a local telecom company. This is what he does: He calls up the data center and says he needs to connect to a server. The support staff there physically walks into the server room grabs an UTP cable and connects a router directly to the blade server. The router then assigns an IP with all ports wide open—no firewall, no nothing. An hour or so later, the support guy calls back to see if the work is done and then unplugs the cable. And that's their whole security protocol

From a quick skim, it sounds like you're using the current time (encrypted) to prevent replay attacks. Good, simple...but I'd note that higher up in your description. And at least think about a Plan B, for when things really go sideways, and system clocks get out of sync. Or intruders have a foothold your network infrastructure.

Thanks for the feedback! Will definitely put some thought into it.

The example shows you opening port 80 (HTTP standard port), the comment next to it mentions SSH (default port 22). That's confusing.

Also your headline claims that your system is "better", but it fails to explain why. Modern port knocking also incorporates secure cryptographic hashes.

I believe the author is comparing their method against just the naive port knocking approach

yes thats correct. Should have stated that in the headline

"The example shows you opening port 80 (HTTP standard port)"

that's because I run my ssh on port 80, but that's not standard, so I agree that it's confusing. Thanks for pointing it out. I will fix it :)

"Modern port knocking also incorporates secure cryptographic hashes."

Are you referring to fwknop? Thats not "port knocking" but Single Packet Authorization. That is very different from port knocking.

How can one incorporate secure cryptographic hashes with simple port knocking?

Nice. The deadline argument concept is smart and not in many other implementations.

It seems there are two sides of the spectrum for secure SSH access:

+ Relatively infrequent access by limited # of people to servers which are not top targets for attacks. Solutions like the one above are great for this.

+ More frequent, more users, more sensitive servers. Close all the inbound ports, permanently. Example: https://github.com/openziti-test-kitchen/zssh (or with an integrated OIDC like KeyCloak - https://youtu.be/NZJtzSoS_g0?si=Qg6p6Hdkaq1ahefg)

I agree. Instead of closing port 22 only to open a different port, it seems more secure to close all ports like the zssh example above or Tailscale SSH [1] or SSH No Ports [2].

[1] https://tailscale.com/tailscale-ssh

[2] https://atsign.com/resources/articles/close-port-22-forever-...

SSH on something other than port 22 is not more secure, but it does massively reduce the amount of log noise. Which I find invaluable since I do not have a security team monitoring my machines.

"+ Relatively infrequent access by limited # of people to servers which are not top targets for attacks. Solutions like the one above are great for this."

Thats exactly what I'm using it for - I'm the only one on my server :)

if you are old like me, you might remember https://en.wikipedia.org/wiki/Xinetd which did this kinda thing.

How does this distinguish itself from fwknop?

https://github.com/mrash/fwknop

And what have you got to protest against DoS attacks on your packet inspection mechanism?

Did not know fwknop, but since it came up multiple times in this thread, I'll look into it.

I have no protection against DoS attacks, but I'm working on it (there is also a WIP in the README about that :) )

Your docs say: client uses private key to encrypt -> server uses public key to decrypt.

Do you mean: client uses private key to sign -> server uses public key to verify?

My understanding is private keys decrypt/sign and public keys encrypt/verify. Either your usage, your docs, or my understanding seem to be wrong. I think I'll stick with fwknop for now.

Encrypting with the private key has the name “signing” because it’s convenient. Both are technically correct.

It sounds like my misunderstanding. So is this just a nomenclature mix up? I'll have to do more research, because I am under the impression there is something special about the private key other than the fact it was designated as such at generation time. I have many holes to fill in my knowledge around this.

The special thing about the private key is that if you have the private key you can also derive the public key from it. Meanwhile if you only have the public key you can't derive the private key.

Hence you always use the private key for decrypting or for signing. But other than switching which key to use signing and encrypting are the same thing

I think some of this is starting to come into focus. It appears the way these keys are commonly stored necessitates careful treatment after generation. For instance, if this reference is accurate, an RSA private key in PKCS#1 includes the p and q prime factors on which the whole security of the key pairs depends, so you certainly would not want to mix up the files: https://crypto.stackexchange.com/a/79606

Perhaps this helps: While fundamentally, in theory, they (keys and operations) are symmetric, many higher-level cryptographic protocols and their implementation do have differences (such as the private key also embedding the public key, or encryption being hybrid-symmetric). If the abstraction level is not obvious from context and you are still learning, this can be confusing.

Thank you, I think this helped me understand a bit more how higher level protocols impose further restrictions on use: https://crypto.stackexchange.com/a/71362

I think that's only true if you're using direct asymmetric cryptography. In the real world people use hybrid asymmetric cryptography.

Hybrid asymmetric signing is: hash the payload, then use direct asymmetric encryption/signing to encrypt/sign the hash with the private key.

Hybrid asymmetric encryption is: encrypt the payload with symmetric encryption (e.g. AES) with a random key, then encrypt the random key with direct asymmetric encryption using the public key.

As you can see, with hybrid asymmetric cryptography, there's a difference between signing and encryption besides the public vs private key difference.

RSA allows encrypting with the private key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

and decrypt with the public key, see https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

using RSA, one can easily derive the public key from its private key (see https://security.stackexchange.com/questions/172274/can-i-ge...), that's why the private key is kept safely on the client

Also for SSH the public key is also stored on the server, while the private key is kept safely on the client, see https://www.ssh.com/academy/ssh/public-key-authentication#ke...

SSH can also be used with RSA: https://www.ssh.com/academy/ssh/keygen#creating-an-ssh-key-p...

I documented the snippets I needed when setting up Caddy + fastcgi to run shell scripts remotely with self-signed HTTPS Basic Auth on an internal server a couple years ago: https://hn-notes.pages.dev/20221128

Although far more heavyweight and barely relevant to this discussion since it's not hidden, sometimes it's useful to be able to do things remotely in an emergency without a private key.

> The commands are configured on the server side, so the client does not define what is going to be executed, it only picks from existing commands

Super interesting! From looking at the readme, it looks like the configuration isn't specific to ssh either; I assume you could use it for any service that exposes a port.

that is correct. The configuration is not even ufw specific, you could run any command that you like. This means you could also, for example, disable or enable certain nginx configurations.

Seems really cool! It seems pertinent to remember however that it isn't security as much it is obfuscation.

Sending encrypted messages is obfuscation? Can you elaborate?

I think what rmholt means is that ruroco does not improve security in the sense, that it has stronger and safer encryption/algorithms/... but that it merely "hides" existing services.

I would argue that it does improve security in the way that it reduces the attack surface of potential vulnerable services, because they are simply not accessible for adversaries.

On the other hand, having another tool running increases the attack surface, but imho that's very small.

Yup that's what I meant! And I am worried that a replay attack would be able to bypass ruroco. Thus ruruco is not a replacement for good SSH security, which you have to do anyway.

But like I wanna stress that I like ruroco and I might end up using it to decrease the internet noise on my home lab, but I'm just worried that someone might end up relying on ruroco instead of proper SSH security

a replay attack won't work, because every UDP packet data has deadline in nanoseconds.

Once this UDP packet reaches the server the deadline will be added to the blocklist.

If an attacker sends the same packet again, the server will check its blocklist for the deadline. It does not matter if the deadline has been reached or not. once the packet reaches the server, the deadline of that packet will be added to the blocklist.

I see i see good to know, thanks!

I think this does what ostiary does except worse. It has replay protection. Of course, that project is long abandoned although I use it.

The only difference is, knocking is via tcp as it makes unique challenges instead of this repeatable udp packet.

Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it.

Kind advice from my PoV:

Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't".

I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could have.

Also keep in mind that ruroco is a very young project and is by no means finished. I was thinking about using one-time-pads or other encryption algorithms as well. I also posted this here to get feedback to improve my project.

So hopefully when I release version 1.0.0 all the issues that this project has atpit are resolved ;)

Ostiary prevents replay by salting. Client's reply is only valid for the unique salt that the server has generated and only for a short time and obviously only once.

A replay attack can only make the server do whatever the legit client intended it to do, just up to [timeout] seconds later.

hmmm just validated my implementation

the deadline that is sent from the client is being added to the blocklist after the command was executed, so sending the same packet again will not work, because the deadline (which is in nanoseconds) is already on the blocklist and therefore the command will not be executed again.

This effectively means that replaying a packet is not possible, because the server will deny it.

super complicated github description! hn desc. is rather better. great work tho :)

I'm not good at describing things easily. I will put the hn description on top of the git repo :)

Thanks for the feedback!

What would be the reasons to choose this over fwknop?

While I wish that fwknop would have displaced the whole idea of port knocking by now, this adds the element of triggering command execution based on the packet, instead of the single fixed action of just opening a port.

Very useful! I think it is a great idea !

Ugh, I need to enable port knocking on my mikrotik one day.

Is is pronounced "Ruh-Roh" like Scooby Doo?

Funny. Haven't thought of that, probably because I'm german.

The way I pronounce it is with long vowels.

So in an extreme way it would be ruuurooocooo :)

What type of encryption is used?

RSA

How does this compare to just running WireGuard?

IMHO Wireguard + SSH is a better (more robust, widely supported and more secure) approach. Maybe the OP simply hasn't yet heard about or used Wireguard.

"Maybe the OP simply hasn't yet heard about or used Wireguard."

I have, but I do not want to run a VPN solution on my private sever, for which I barely have any need. Also Wireguard, although VERY secure is still not "simple" software.

In addition there are usecases where Wireguard would not help, for example when I want to open up an http service for the current network that Im in.

WireGuard is honestly very easy to set up. All of the commands feel very straightforward: https://www.procustodibus.com/blog/2020/11/wireguard-point-t...

You can definitely run an HTTP server behind WireGuard. WireGuard just adds a network interface that your server can listen on (e.g. your server would listen on a private address like 10.0.0.1).

OP's example was a great one. For example, let's say you visit your friends and you want to watch some content together that is accessible on your server. Using this approach you can open access to that without setting up Wireguard on friend's smart TV.

And Wireguard does use quite a bit of CPU if you are using a lot of network bandwidth. Small servers don't have that much compute power, so utilizing the port knocking somewhat removes that issue.

I don't know that you're right about the WireGuard CPU expense thing.

My router (with Wireguard) can't handle more than 45Mbit/s through Wireguard because the CPU starts throttling.

I suspect that RaspberryPi or old Intel NUC also would not be able to handle speeds anywhere near gigabit.

My NUC easily pegs the network. I'm not sure you're right about this. Either way: you can just use WireGuard as a control channel, the same way this software does.

WireGuard has apps for most devices (macOS, iOS, Android, Windows). For smart TVs it's a bit of a mixed bag. Some of them do support VPN clients, and I know Tailscale works on the Apple TV now (Tailscale uses WireGuard under the hood).

If you're using the Ruroco client to proxy requests to the server, then you could do the same with WireGuard. You could have HAProxy (or something similar) proxy requests from your local network to the WireGuard interface.

It is much simpler to open access to the same network using port knocking than setting up VPN apps and profiles on TV.

Which smart TVs natively support port knocking?

No, the example is - you go to friends, join their Wifi, have the same external IP, send the knock from your phone/laptop to open 443 to that IP, and then you can connect from TV or their computers.

Port knocking only handles authentication (it's basically a crude password). It doesn't ensure the integrity (tamper prevention) or privacy of your connection. You would need to set up SSL certificates to handle that. You also need to get the TV to accept those certificates, which would require either a public DNS record (which exposes your server's IP via the certificate transparency log to any client that can issue a DNS request), or you would need to modify your friend's router's DNS resolver (which is even more complicated than installing a VPN, and assumes the TV uses the router's DNS server). A TV isn't going to have an /etc/hosts file that you can use to point a domain at your server's IP address.

So instead I would go to my friend's house, connect to their Wifi, and accept incoming connections from computers and TVs over the local area network and forward them through WireGuard. The TV would connect to my device via plain HTTP (which is fine since it's all happening locally), and then my device would be responsible for securely connecting to the server via WireGuard. This also has the benefit of implicitly revoking access as soon as I leave their house with my device.

You are slightly wrong.

TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate. Certificate itself has nothing to do with DNS beyond the verification step.

And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

You are both slightly wrong, and slightly misunderstanding what I'm saying.

> TLS is not mandatory in all cases, but if you want to use it, it is not an issue having a certificate.

TLS is mandatory if you want to ensure your connection isn't being eavesdropped on or tampered with.

> And even then you do not have to open any ports, even to letsencrypt verification, since you can use DNS verification method instead (for example using Cloudflare API).

Yes this is called the ACME DNS challenge. I've used it many times, but if you want to be able to type in your server's domain name on a friend's TV and have it resolve to your server's IP address, then you'll need a public DNS record.

> Certificate itself has nothing to do with DNS beyond the verification step.

Yes it does, because most certificate authorities only sign certificates for fully qualified domain names, not IP addresses [1], so it obviously does involve the domain name system (you can view the domain name associated with a certificate in your browser, it'll be listed under the field "common name"). On a desktop computer you could get around this by editing the hosts file to map any domain name to any arbitrary IP address, but you can't do that on a TV.

> And there can be a public DNS record but it doesn't say anything about ports. And the CT transparency log doesn't say anything about ports or IP addresses.

I never said anything about ports, I said a public DNS record exposes the server's IP address. The whole point of the domain name system is to convert domain names into IP addresses, so that you can actually use the internet protocol to connect to a server's IP (internet protocol) address. Try running dig from the command line on literally any domain name and watch it expose the server's IP. Malicious bots can watch the transparency log to find out about new certificates [2], then run dig or some other tool to issue a DNS request (to determine the IP address of the server), and then start hammering the server to search for vulnerabilities or even potentially to just DDOS it. If you use a wildcard certificate it's harder for attackers to figure out which subdomain to query to find your server's IP, but with WireGuard I don't need a domain name at all.

[1] https://community.letsencrypt.org/t/ssl-on-a-ip-instead-of-d...

[2] https://community.letsencrypt.org/t/suspicious-web-traffic-a...

It does not matter - all the ports are closed.

> It does not matter - all the ports are closed.

Yeah and I have a lock on my door. I still won't post my address on HN. It's all about defense in depth.

Another thing I forgot to mention is that port knocking only works if your hypothetical friend has a dedicated static IP. If your ISP decides to reassign your IP address then IP allowlists are useless. Many ISPs in the US run this racket where they make you pay for a "business account" to get a dedicated IP, even if you only want an IP6 address (which are plentiful).

Wireguard doesn't require much, since it is part of Linux kernel.

But your use-case with http server is a good one. For similar cases I have used custom forward-auth service, but that still requires to have the web server accessible, while your solution hides it completely.

Reply on news.ycombinator.com