Live data from Hacker News

Show HN: Ruroco – like port knocking, but better

github.com

91–100 of 108 posts

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

#91
post #89

Earlier quoted context omitted.

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…

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.

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

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

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

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

#94
post #68

Earlier quoted context omitted.

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

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

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

#96
post #72

Earlier quoted context omitted.

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.

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

#97
post #96

Earlier quoted context omitted.

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.

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

#98
post #80
post #37

Earlier quoted context omitted.

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

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.

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

#99
post #89

Earlier quoted context omitted.

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

I see i see good to know, thanks!

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

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

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

WiFi access points can redirect 53 to the DNS resolver of their choice.
Post reply on HN