4 ms·

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 addres

• cies 2y ago
  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.
  • mschempp 2y ago
    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).
• Thorrez 2y ago
  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.
  • beagle3 2y ago
    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)
    • EvanAnderson 2y ago
      > Spoofing TCP is useless... See: https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack 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.
      • beagle3 2y ago
        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.
        • o11c 2y ago
          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.
          • beagle3 2y ago
            Which is exactly what I said two posts up. https://news.ycombinator.com/item?id=41329065 https://news.ycombinator.com/item?id=41329065 Now, RST attacks are still a thing, but mostly irrelevant to this port knocking alternative.
    • Thorrez 2y ago
      >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.
  • deleted 2y ago
    [deleted]
• rmholt 2y ago
  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/ce766751b51c8ff6246a2be02a0d028e8e880bcb/src/server.rs#L174 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.
• brookst 2y ago
  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.
• bigjay517 2y ago
  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.
  • 0x457 2y ago
    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.
• mschempp 2y ago
  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!
  • Tepix 2y ago
    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!)
    • mschempp 2y ago
      the client COULD use something like https://www.ipify.org/ 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.