[HN Gopher] Show HN: Ruroco - like port knocking, but better
___________________________________________________________________
Show HN: Ruroco - like port knocking, but better
Hey there HN! ruroco (RUn RemOte COmmand) is a tool that lets you
execute commands on a server by sending UDP packets (instead of
knocking on ports). the tool consist of 3 binaries: - client ->
runs on your notebook/computer and sends the UDP packets - server
-> receives the UDP packets and makes sure that they are valid -
commander -> runs the command encoded by the data of the UDP packet
if it's valid 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. I use this tool to open up the SSH
port on my server via ufw, but only for the IP address from where
I'm connecting, so the SSH port appears closed for everyone else,
except me. This is my very first "real" rust project, so any
feedback is highly appreciated :) Enjoy!
Author : mschempp
Score : 95 points
Date : 2024-08-23 10:19 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bell-cot wrote:
| From a quick skim, it sounds like you're using the current time
| (encrypted) to prevent replay attacks. Good, simple...but I'd
| note that higher up in your description. And at least think about
| a Plan B, for when things _really_ go sideways, and system clocks
| get out of sync. Or intruders have a foothold your network
| infrastructure.
| mschempp wrote:
| Thanks for the feedback! Will definitely put some thought into
| it.
| opem wrote:
| super complicated github description! hn desc. is rather better.
| great work tho :)
| mschempp wrote:
| I'm not good at describing things easily. I will put the hn
| description on top of the git repo :)
|
| Thanks for the feedback!
| Tepix wrote:
| 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.
| rmholt wrote:
| I believe the author is comparing their method against just the
| naive port knocking approach
| mschempp wrote:
| yes thats correct. Should have stated that in the headline
| mschempp wrote:
| "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 :)
| mschempp wrote:
| "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?
| Daril wrote:
| Very useful! I think it is a great idea !
| cius wrote:
| Your docs say: client uses private key to encrypt -> server uses
| public key to decrypt.
|
| Do you mean: client uses private key to sign -> server uses
| public key to verify?
|
| My understanding is private keys decrypt/sign and public keys
| encrypt/verify. Either your usage, your docs, or my understanding
| seem to be wrong. I think I'll stick with fwknop for now.
| jagged-chisel wrote:
| Encrypting with the private key has the name "signing" because
| it's convenient. Both are technically correct.
| cius wrote:
| It sounds like my misunderstanding. So is this just a
| nomenclature mix up? I'll have to do more research, because I
| am under the impression there is something special about the
| private key other than the fact it was designated as such at
| generation time. I have many holes to fill in my knowledge
| around this.
| wongarsu wrote:
| The special thing about the private key is that if you have
| the private key you can also derive the public key from it.
| Meanwhile if you only have the public key you can't derive
| the private key.
|
| Hence you always use the private key for decrypting or for
| signing. But other than switching which key to use signing
| and encrypting are the same thing
| cius wrote:
| I think some of this is starting to come into focus. It
| appears the way these keys are commonly stored
| necessitates careful treatment after generation. For
| instance, if this reference is accurate, an RSA private
| key in PKCS#1 includes the p and q prime factors on which
| the whole security of the key pairs depends, so you
| certainly would not want to mix up the files:
| https://crypto.stackexchange.com/a/79606
| 3np wrote:
| Perhaps this helps: While fundamentally, in theory, they
| (keys and operations) are symmetric, many higher-level
| cryptographic protocols and their implementation do have
| differences (such as the private key also embedding the
| public key, or encryption being hybrid-symmetric). If the
| abstraction level is not obvious from context and you are
| still learning, this can be confusing.
| cius wrote:
| Thank you, I think this helped me understand a bit more
| how higher level protocols impose further restrictions on
| use: https://crypto.stackexchange.com/a/71362
| Thorrez wrote:
| I think that's only true if you're using direct asymmetric
| cryptography. In the real world people use hybrid asymmetric
| cryptography.
|
| Hybrid asymmetric signing is: hash the payload, then use
| direct asymmetric encryption/signing to encrypt/sign the hash
| with the private key.
|
| Hybrid asymmetric encryption is: encrypt the payload with
| symmetric encryption (e.g. AES) with a random key, then
| encrypt the random key with direct asymmetric encryption
| using the public key.
|
| As you can see, with hybrid asymmetric cryptography, there's
| a difference between signing and encryption besides the
| public vs private key difference.
| mschempp wrote:
| RSA allows encrypting with the private key, see
| https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...
|
| and decrypt with the public key, see
| https://github.com/beac0n/ruroco/blob/ce766751b51c8ff6246a2b...
|
| using RSA, one can easily derive the public key from its
| private key (see
| https://security.stackexchange.com/questions/172274/can-i-
| ge...), that's why the private key is kept safely on the client
|
| Also for SSH the public key is also stored on the server, while
| the private key is kept safely on the client, see
| https://www.ssh.com/academy/ssh/public-key-authentication#ke...
|
| SSH can also be used with RSA:
| https://www.ssh.com/academy/ssh/keygen#creating-an-ssh-key-p...
| Tepix wrote:
| 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.
| cies wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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.
| beagle3 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| rmholt wrote:
| 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.
| brookst wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mr_mitm wrote:
| 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.
| thrwaway1985882 wrote:
| > 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 were testing,
| and ended up throwing it all out in favor of wireguard & making
| SSH no longer listen on em0, which seems infinitely less silly.
| bongobingo1 wrote:
| 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.
| thrwaway1985882 wrote:
| From the OpenBSD perspective, I just populate
| /etc/hostname.wg0 on my laptop with my wg configuration ...
| and I can immediately `ssh router` at home or on the road
| :-)
|
| IOW, why ever down the connection? Why not start your
| tunnel immediately when the network comes up and leave it
| running until the network goes down?
| bongobingo1 wrote:
| I was thinking about doing this to multiple different
| servers and thought they could all share the same vpn
| network address for simpler configuration but now that I
| think about it doing that might run into constant server-
| key-changed warnings from SSH.
| thrwaway1985882 wrote:
| If you need a management vlan, make one.
|
| Wireguard interfaces are _cheap and easy_ - there's no
| reason not to set up an interface for normal client
| traffic that sshd doesn't listen on, and an interface for
| just sshd with different ACLs and routing logic if you
| want.
| Jnr wrote:
| 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.
| mr_mitm wrote:
| Well, tcpdump is explicitely not what you want to do in this
| case as Moxie points out, but other than that i guess, yes,
| it's similar.
| thrwaway1985882 wrote:
| > Well, tcpdump is explicitely not what you want to do in
| this case as Moxie points out
|
| Why's that?
|
| E: oh, if you aren't familiar with OpenBSD I might get the
| confusion - pflogd/the kernel (not me!) watches the actual
| network device and dumps to a file. So the actual
| "knocking" daemon I bodged together is one part running as
| a privsep user watching a log file and giving IPs to the
| other part which just adds to the pf table allowing access.
|
| My threat model didn't include people who can fuck with
| pflog(4) to attack tcpdump(8) - I'm sure they're out there,
| and if they wanted to be they'd already be in my network
| (or already are).
| mr_mitm wrote:
| Ah, that makes sense. I actually didn't know that about
| openbsd.
| mschempp wrote:
| 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.
| mr_mitm wrote:
| 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.
| mschempp wrote:
| 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.
| codetrotter wrote:
| 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.
| mschempp wrote:
| 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
| praptak wrote:
| If 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".
| mschempp wrote:
| Thanks for the link. Looks interesting!
| jbstack wrote:
| What would be the reasons to choose this over fwknop?
| orev wrote:
| While I wish that fwknop would have displaced the whole idea of
| port knocking by now, this adds the element of triggering
| command execution based on the packet, instead of the single
| fixed action of just opening a port.
| password4321 wrote:
| I documented the snippets I needed when setting up Caddy +
| fastcgi to run shell scripts remotely with self-signed HTTPS
| Basic Auth on an internal server a couple years ago: https://hn-
| notes.pages.dev/20221128
|
| Although far more heavyweight and barely relevant to this
| discussion since it's not hidden, sometimes it's useful to be
| able to do things remotely in an emergency without a private key.
| Thorrez wrote:
| What type of encryption is used?
| mschempp wrote:
| RSA
| rmholt wrote:
| Seems really cool! It seems pertinent to remember however that it
| isn't security as much it is obfuscation.
| hiatus wrote:
| Sending encrypted messages is obfuscation? Can you elaborate?
| mschempp wrote:
| 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.
| rmholt wrote:
| 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
| mschempp wrote:
| 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.
| mariocesar wrote:
| I know a guy who works as an IT consultant for a local telecom
| company. This is what he does: He calls up the data center and
| says he needs to connect to a server. The support staff there
| physically walks into the server room grabs an UTP cable and
| connects a router directly to the blade server. The router then
| assigns an IP with all ports wide open--no firewall, no nothing.
| An hour or so later, the support guy calls back to see if the
| work is done and then unplugs the cable. And that's their whole
| security protocol
| electric_mayhem wrote:
| How does this distinguish itself from fwknop?
|
| https://github.com/mrash/fwknop
|
| And what have you got to protest against DoS attacks on your
| packet inspection mechanism?
| mschempp wrote:
| Did not know fwknop, but since it came up multiple times in
| this thread, I'll look into it.
|
| I have no protection against DoS attacks, but I'm working on it
| (there is also a WIP in the README about that :) )
| gz5 wrote:
| Nice. 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://github.com/openziti-test-kitchen/zssh (or with an
| integrated OIDC like KeyCloak -
| https://youtu.be/NZJtzSoS_g0?si=Qg6p6Hdkaq1ahefg)
| mrbluecoat wrote:
| I agree. Instead of closing port 22 only to open a different
| port, it seems more secure to close all ports like the zssh
| example above or Tailscale SSH [1] or SSH No Ports [2].
|
| [1] https://tailscale.com/tailscale-ssh
|
| [2] https://atsign.com/resources/articles/close-
| port-22-forever-...
| 0cf8612b2e1e wrote:
| SSH on something other than port 22 is not more secure, but
| it does massively reduce the amount of log noise. Which I
| find invaluable since I do not have a security team
| monitoring my machines.
| mschempp wrote:
| "+ 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 :)
| tptacek wrote:
| How does this compare to just running WireGuard?
| Jnr wrote:
| 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.
| mschempp wrote:
| "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.
| throwitaway1123 wrote:
| WireGuard is honestly very easy to set up. All of the
| commands feel very straightforward:
| https://www.procustodibus.com/blog/2020/11/wireguard-
| point-t...
|
| You can definitely run an HTTP server behind WireGuard.
| WireGuard just adds a network interface that your server
| can listen on (e.g. your server would listen on a private
| address like 10.0.0.1).
| Jnr wrote:
| OP's example was a great one. For example, let's say you
| visit your friends and you want to watch some content
| together that is accessible on your server. Using this
| approach you can open access to that without setting up
| Wireguard on friend's smart TV.
|
| And Wireguard does use quite a bit of CPU if you are
| using a lot of network bandwidth. Small servers don't
| have that much compute power, so utilizing the port
| knocking somewhat removes that issue.
| tptacek wrote:
| I don't know that you're right about the WireGuard CPU
| expense thing.
| Jnr wrote:
| My router (with Wireguard) can't handle more than
| 45Mbit/s through Wireguard because the CPU starts
| throttling.
|
| I suspect that RaspberryPi or old Intel NUC also would
| not be able to handle speeds anywhere near gigabit.
| tptacek wrote:
| My NUC easily pegs the network. I'm not sure you're right
| about this. Either way: you can just use WireGuard as a
| control channel, the same way this software does.
| throwitaway1123 wrote:
| WireGuard has apps for most devices (macOS, iOS, Android,
| Windows). For smart TVs it's a bit of a mixed bag. Some
| of them do support VPN clients, and I know Tailscale
| works on the Apple TV now (Tailscale uses WireGuard under
| the hood).
|
| If you're using the Ruroco client to proxy requests to
| the server, then you could do the same with WireGuard.
| You could have HAProxy (or something similar) proxy
| requests from your local network to the WireGuard
| interface.
| Jnr wrote:
| It is much simpler to open access to the same network
| using port knocking than setting up VPN apps and profiles
| on TV.
| throwitaway1123 wrote:
| Which smart TVs natively support port knocking?
| Jnr wrote:
| 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.
| throwitaway1123 wrote:
| 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.
| Jnr wrote:
| Wireguard doesn't require much, since it is part of Linux
| kernel.
|
| But your use-case with http server is a good one. For
| similar cases I have used custom forward-auth service, but
| that still requires to have the web server accessible,
| while your solution hides it completely.
| joshuaheard wrote:
| Is is pronounced "Ruh-Roh" like Scooby Doo?
| mschempp wrote:
| Funny. Haven't thought of that, probably because I'm german.
|
| The way I pronounce it is with long vowels.
|
| So in an extreme way it would be ruuurooocooo :)
| mannyv wrote:
| Ugh, I need to enable port knocking on my mikrotik one day.
| saghm wrote:
| > 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.
| mschempp wrote:
| 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.
| damezumari wrote:
| 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.
| mschempp wrote:
| 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 ;)
| praptak wrote:
| 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.
| mschempp wrote:
| 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.
| KaiserPro wrote:
| if you are old like me, you might remember
| https://en.wikipedia.org/wiki/Xinetd which did this kinda thing.
___________________________________________________________________
(page generated 2024-08-23 23:01 UTC)