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.

Afaik it doesn't. The only useful thing there is, is a deadline on each packet so the retransmission would have to be fast, but it seems doable.

https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...

The encrypted information is current time, command and random data. So the server could feasibly detect that a retransmission has occurred but that's about it.

Fair point, but all that gets you is SSH listening, they way it has to be now anyways if you want remote access.

This doesn’t feel like an unpickable lock so much as a decorative cover that makes the lock less obvious.

I agree with your observation, but this is merely put fwd as an alternative to port knocking.

Port knocking is IMHO just to keep your sshd logs clean from huge lists of failed attempts, that prevent me from actually finding interesting information in them.

I used port knocking in the description, because anyone here probably knows what port knocking is and ruroco is kind of similar to that.

Ruroco can be used for more than just keeping sshd logs clean, for example I could also enable a service other than ssh, for example a private file server that I want to get access to when I'm on my phone (although I haven't implemented an android version yet, it should be doable).

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.

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

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.

>Spoofing TCP is useless - you actually need to receive all the packets sent to the original TCP

What do you mean "original TCP"? I'm talking about an attacker creating a new TCP connection with a spoofed source address.

> which means either you are already on the receiving path

Yes, I believe that's the threat model under discussion here. Tepix mentioned an attacker who can intercept a packet, which I believe means the attacker is already on the receiving path.

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.