Hacker News Reader

Comment by thatha7777 | Hacker News Reader

This is very similar to port knocking, although more complicated. Although a proper JWT token is “more secure” than a sequence of 0-65535 integers, I contend that having complicated and/or unvetted logic as your first line of defense is more problematic than secure.

View on HN

On the positive side, it's probably pretty easy to encrypt the RPC traffic. On the negative side, you've traded the fairly well known risk of running SSH with some extra set of software (whoops: s/hardware/software/) with less well known vetting, and it's own possible security problems. This is basically relying on security through obscurity because of that.

SSH is almost definitely handled by your OS package management, so any problems with SSH will be patched immediately as found, and automatically distributed to you if you opt in to that (or you will be notified there are updated to apply, and you can do so). If this system is not packaged and distributed by your OS, you're going to have to keep up to date on any security problems with it yourself. It may have less permissions by default because it's running through a container, but that doesn't always help (kernel exploits are a thing, a lot of successful hacks are first getting the ability to run unprivileged arbitrary code, then using a kernel exploit to gain privileged access.

There's something to be said for well engineered, well vetted simplicity. This is an interesting solution, but I would much rather just lock down the set of IPs it allows connections from to SSH to a very small subset of known good ones, including the IP address of a $5 DigitalOcean VM that I keep off but can turn on and connect to and use to jump to that box if at a location I can't connect from directly (and you can set a timed firewalld rules to allow access from your current IP if it's not permanent and shut of the VM again). Of use the free tier of AWS if you can get it to have a specific IP for free as well (I don't recall what you can get in the free tier other than the smallest VM).

Edit: Oh, and disable password auth. That's SSH hardening action #1, I kind of just assume everyone does that (because they should, if they can).

Yeah, I'd want to see a mention of port-knocking in the README, indicating that the author was familiar with this technique, and the known critiques of it, and why they think this method (or port-knocking in general?) withstands it. Cause it's definitely in the vicinity.

With no mention, it makes me wonder if the author is familiar with the history of this approach, which is not a good sign.

And yeah, I'm skeptical. Is this new, uncommon/unvetted, and somewhat complex "access" app just another place for potential vulnerabilities that give someone the keys to the kingdom?

> With no mention, it makes me wonder if the author is familiar with the history of this approach, which is not a good sign.

Seeing as the word “proactive” keeps reappearing in a similar fashion to “decentralized” does for people promoting their blockchain app (invariably hosted web app on google cloud or aws, using Ethereum nodes from Infura, and administered by a single permissioned smart contract) yeah, sounds like OP is excited they invented this new principle.

Technically they could be equally as secure if the port knocking converts knocked ports into a signature based authentication mechanism ;)

But at that point, you’ve potentially introduced exploitable bugs in the network stack.

Reply on news.ycombinator.com