Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Ruroco – like port knocking, but better

github.com

Post reply on HN
Print view View original

41–50 of 108 posts

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

#41

Post by bigjay517 »

Tepix wrote: post #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.

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.

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

#43

Post by mschempp »

Tepix wrote: post #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.

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!

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

#45

Post by thrwaway1985882 »

bongobingo1 wrote: post #40
thrwaway1985882 wrote: post #32

Earlier quoted context omitted.

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

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?

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

#46

Post by 0cf8612b2e1e »

mrbluecoat wrote: post #36
gz5 wrote: post #30

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://git…

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.

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

#47

Post by mschempp »

cius wrote: 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.

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

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

#49

Post by mschempp »

electric_mayhem wrote: post #28

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 :) )

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

#50

Post by mschempp »

bell-cot wrote: post #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.

Thanks for the feedback! Will definitely put some thought into it.
Post reply on HN