What type of encryption is used?
RSA
Show HN: Ruroco – like port knocking, but better
51–60 of 108 posts
Re: Show HN: Ruroco – like port knocking, but better
#52Nice. 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…
"+ 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."
Thats exactly what I'm using it for - I'm the only one on my server :)
Re: Show HN: Ruroco – like port knocking, but better
#53Pretty 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 the network I'm in blocks everything else.
Re: Show HN: Ruroco – like port knocking, but better
#54The 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.
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).
Re: Show HN: Ruroco – like port knocking, but better
#55If your use case is "remotely trigger execution of a very small set of fixed commands, securely" then there's Ostiary: https://openwrt.org/docs/guide-user/services/remote_control/... Its value is in the simplicity of the crypto protocol used for this - basically "hash a password with a one time pad".
Thanks for the link. Looks interesting!
Re: Show HN: Ruroco – like port knocking, but better
#56The 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.
I believe the author is comparing their method against just the naive port knocking approach
yes thats correct. Should have stated that in the headline
Re: Show HN: Ruroco – like port knocking, but better
#57Earlier quoted context omitted.
> 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.
You don't really have to do that. Wireguard is very silent protocol. Even when you bring up the interface, unless you are sending anything to that interface, it will not redo the handshake. So you can keep it up all the time.
This is why you sometimes have to enable PersistentKeepalive on peers that are behind NAT and are calling in to the server. Without them keeping up the connection NAT would simply close it down and you wouldn't be able to connect.
Re: Show HN: Ruroco – like port knocking, but better
#58The 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.
"The example shows you opening port 80 (HTTP standard port)"
that's because I run my ssh on port 80, but that's not standard, so I agree that it's confusing. Thanks for pointing it out. I will fix it :)
Re: Show HN: Ruroco – like port knocking, but better
#59How does this compare to just running WireGuard?
IMHO Wireguard + SSH is a better (more robust, widely supported and more secure) approach. Maybe the OP simply hasn't yet heard about or used Wireguard.
Re: Show HN: Ruroco – like port knocking, but better
#60How does this compare to just running WireGuard?
IMHO Wireguard + SSH is a better (more robust, widely supported and more secure) approach. Maybe the OP simply hasn't yet heard about or used Wireguard.
"Maybe the OP simply hasn't yet heard about or used Wireguard."
I have, but I do not want to run a VPN solution on my private sever, for which I barely have any need. Also Wireguard, although VERY secure is still not "simple" software.
In addition there are usecases where Wireguard would not help, for example when I want to open up an http service for the current network that Im in.