Live data from Hacker News

Show HN: Ruroco – like port knocking, but better

github.com

31–40 of 108 posts

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

#31
post #10

Earlier quoted context omitted.

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

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

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

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

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

#34
post #13
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.

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.

[deleted]

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

#35
post #26
post #13

Earlier quoted context omitted.

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.

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

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

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

#37
post #26

Earlier quoted context omitted.

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.

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

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

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

Post reply on HN