Live data from Hacker News

Show HN: Ruroco – like port knocking, but better

github.com

1–10 of 108 posts

Show HN: Ruroco – like port knocking, but better

#1
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!

Show HN: Ruroco – like port knocking, but better
github.com

Re: Show HN: Ruroco – like port knocking, but better

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

Re: Show HN: Ruroco – like port knocking, but better

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

Re: Show HN: Ruroco – like port knocking, but better

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

Re: Show HN: Ruroco – like port knocking, but better

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

Re: Show HN: Ruroco – like port knocking, but better

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

Re: Show HN: Ruroco – like port knocking, but better

#9
post #6

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.

Re: Show HN: Ruroco – like port knocking, but better

#10
post #6

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.
Post reply on HN