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

81–90 of 108 posts

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

#81

Post by mschempp »

mr_mitm wrote: post #68
mschempp wrote: post #53

Earlier quoted context omitted.

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…

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 tradeoff between "ultimate" security and convenience.

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

#82

Post by mschempp »

saghm wrote: post #65

> 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 Super interesting! From looking at the readme, it looks like the configuration isn't specific to ssh either; I assume you could use it for any service that exposes a port.

that is correct. The configuration is not even ufw specific, you could run any command that you like. This means you could also, for example, disable or enable certain nginx configurations.

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

#83

Post by mschempp »

damezumari wrote: post #79

I think this does what ostiary does except worse. It has replay protection. Of course, that project is long abandoned although I use it. The only difference is, knocking is via tcp as it makes unique challenges instead of this repeatable udp packet.

Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it.

Kind advice from my PoV:

Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't".

I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could have.

Also keep in mind that ruroco is a very young project and is by no means finished. I was thinking about using one-time-pads or other encryption algorithms as well. I also posted this here to get feedback to improve my project.

So hopefully when I release version 1.0.0 all the issues that this project has atpit are resolved ;)

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

#84

Post by mschempp »

hiatus wrote: post #33
rmholt wrote: post #23

Seems really cool! It seems pertinent to remember however that it isn't security as much it is obfuscation.

Sending encrypted messages is obfuscation? Can you elaborate?

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 the attack surface, but imho that's very small.

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

#85

Post by 0x457 »

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

That defeats the purpose of port knocking. If you know which IP connections comes from and you trust it - just allow connections in firewall. Port knocking is for temporary allowing certain incoming IPs.

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

#86

Post by mschempp »

Tepix wrote: post #61
mschempp wrote: post #43

Earlier quoted context omitted.

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!

No that won't work because the sender doesn't know what the src ip of the packet will be by the time it arrives (NAT is everywhere!)

the client COULD use something like https://www.ipify.org/ to get the IP, which can then be used as an additional client argument.

But if an adversary uses the SAME network, then the IP address that the server sees will be the same for the client and the adversary, so it only matters if the adversary takes the packet and sends it from a different network, which the adversary won't have to do, because they still control the network where the packet was originally sent from.

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

#87

Post by praptak »

mschempp wrote: post #83
damezumari wrote: post #79

I think this does what ostiary does except worse. It has replay protection. Of course, that project is long abandoned although I use it. The only difference is, knocking is via tcp as it makes unique challenges instead of this repeatable udp packet.

Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it. Kind advice from my PoV: Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't". I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could hav…

Ostiary prevents replay by salting. Client's reply is only valid for the unique salt that the server has generated and only for a short time and obviously only once.

A replay attack can only make the server do whatever the legit client intended it to do, just up to [timeout] seconds later.

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

#88

Post by mschempp »

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

"Modern port knocking also incorporates secure cryptographic hashes."

Are you referring to fwknop? Thats not "port knocking" but Single Packet Authorization. That is very different from port knocking.

How can one incorporate secure cryptographic hashes with simple port knocking?

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

#89

Post by rmholt »

mschempp wrote: post #84
hiatus wrote: post #33

Earlier quoted context omitted.

Sending encrypted messages is obfuscation? Can you elaborate?

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

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

#90

Post by mschempp »

praptak wrote: post #87
mschempp wrote: post #83

Earlier quoted context omitted.

Thanks for the feedback and pointing out ostiary. Fixing replay attacks is on my todo list, maybe I can learn some things from how ostiary does it. Kind advice from my PoV: Your comment could be read as "your project is shit, there is ostiary which has replay protection and yours doesn't". I'm sure you didn't intend for you comment to not come across that way, and I also did not read it that way, but others could hav…

Ostiary prevents replay by salting. Client's reply is only valid for the unique salt that the server has generated and only for a short time and obviously only once. A replay attack can only make the server do whatever the legit client intended it to do, just up to [timeout] seconds later.

hmmm just validated my implementation

the deadline that is sent from the client is being added to the blocklist after the command was executed, so sending the same packet again will not work, because the deadline (which is in nanoseconds) is already on the blocklist and therefore the command will not be executed again.

This effectively means that replaying a packet is not possible, because the server will deny it.

Post reply on HN