7 ms·
The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. This can turn into a
by herpderperator 3y ago
The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect.
This can turn into a footgun: you're away from your usual device, something happens and you desperately need to connect, but now you can't because all the devices in your vicinity don't have the ability to perform $SECURITY_FEATURE_X so that you can connect, and you're screaming at yourself for adding so much security at the expense of convenience.
This could happen as easily as restricting logins to SSH keys only, and not being able to use your SSH key on whatever host you have available at the time, wishing you'd have enabled password authentication.
- pajko 3y agohttps://github.com/CERN-CERT/pam_2fa https://github.com/CERN-CERT/pam_2fa
- herpderperator 3y agoWhat does this have to do with port knocking?
- nequo 3y agoThis is great but would this neutralize the xz backdoor? The backdoor circumvents authentication, doesn't it?
- Joel_Mckay 3y agoPort knocking with ssh over https using client certs. And port knocking is one of the few effective methods against the standard distributed brute forcing slow attacks. Note if you blanket-ban IN/RU/UK/CN/HK/TW/IR/MX/BZ/BA + tor/proxies lists, than 99.998% of your nuisance traffic issues disappear overnight. =)
- deknos 3y agocan you give an example for an implementation of portnocking/ssh/over https and client certs?
- Joel_Mckay 3y agoIn general, it is a standard shore-wall firewall rule in perl, and the standard ssh protocol wrapper mod. These are very well documented tricks, and when combined with a standard port 22 and interleaved knock ports tripwire 5 day ban rules... are quite effective against scanners too. I am currently on the clock, so can't write up a detailed tutorial right now. Best regards, =)
- oarsinsync 3y ago> if you blanket-ban IN/RU/UK/CN/HK/TW/IR/MX/BZ/BA The list of countries there: India, Russia, United Kingdom, China, Hong Kong, Taiwan, Iran, Mexico, Belize, Bosnia and Herzegovina I’m amused that the UK is in that group.
- Joel_Mckay 3y agoI was too, but the past few years their government server blocks have been pen-testing servers without authorization. It is apparently a free service they offer people even when told to get stuffed. =) My spastic ban-hammer active-response list i.e. the entire block gets temporarily black-holed with a single violation: AU BG BR BZ CN ES EE FR GB HR IL IN ID IR IQ JP KG KR KP KW LV MM MX NI NL PA PE PK PL RO RU RS SE SG TW TH TR YE VN UA ZA ZZ
- dec0dedab0de 3y agoAbsolutely, everything in security is a tradeoff. I guess the real point is that there should be layers, and even though you should never rely on security through obscurity, you should still probably have a bit of obscurity in the mix.
- jolmg 3y ago> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. If that's important, one should be able to set up port knocking such that you're able to do the knocks even by changing the port in a sequence by hand on e.g. a web browser address bar.
- mr_mitm 3y agoNote that port knocking is vulnerable to replay attacks. Single Packet Authentication is better, but requires a private key (can be your SSH key). https://www.cipherdyne.org/fwknop/ https://www.cipherdyne.org/fwknop/
- jolmg 3y agoNot if you set it up such that each knocking sequence can only be used once. Port knocking is a flexible concept.
- squigz 3y agoI wonder if one could combine port knocking and TOTP in some way, so the sequence is determined by the TOTP? (Security is not my thing; don't judge me!)
- noman-land 3y agoWas just having the same thought reading this thread.
- ametrau 3y agoYeah you could but wouldn’t it defeat the purpose of being basically a secret knock before you can give the password? The password should be the ssh password.
- cesnja 3y agoThis would be just to allow you to connect to the server. If there was a vulnerable sshd on port 22, an adversary would have to know the port knocking sequence to connect to sshd and run the exploit.
- nottorp 3y agoYou just described the problem with using keys for any login, like the latest fad is? And generally with depending on a device (phone, xxxkey or whatever) for access.
- Dwedit 3y agoAt least TOTP is just a long, random, server-assigned password, where you you don't type the whole thing into during login attempts. You can write down the full TOTP secret, and make new 'TOTP keys' whenever you want. Suggested apps: Firefox Extension named "TOTP", and Android App named "Secur". You don't need the heavier apps that want you to create accounts with their company. Using a TOTP key only provides a little more protection than any other complex password, since you're not typing in the whole thing during a login attempt.
- tamimio 3y ago> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. Then you attach a device that can have port knocking to that unsupported host. Also, I remember it was called port punching not knocking.
- mlyle 3y ago> The thing about port knocking is that if you're on a host where you don't have the ability to port-knock, then you're not able to connect. You can type http://hostname:porttoknock http://hostname:porttoknock in a browser. As long as you're not behind a super restrictive gateway that doesn't let you connect to arbitrary ports, you're golden.
- webmaven 3y agoTIL another interesting browser feature. Thank you.
- bee_rider 3y agoIt seems like there’d be a pretty big overlap between those kinds of hosts.
- noman-land 3y agoI'm a bit of a noob about this. Can you explain what this means?
- shanemhansen 3y agoPort knocking involves sending a packet to certain ports on a host. It's overkill but typing http://host:port/ http://host:port/ in your browser will, as part of trying to make a TCP connection, send a packet to that port.
- codedokode 3y agoYou can as well find yourself on a host that doesn't have SSH or network that filters SSH traffic for security reasons.
- godman_8 3y agoMy solution to this has been creating a public bastion server and use Wireguard. Wireguard listens on a random UDP port (port knocking is more difficult here.) This client is set up to have a dynamic endpoint so I don't need to worry about whitelisting. The key and port information are stored in a password manager like Vaultwarden with the appropriate documentation to connect. Firewall rules are set to reject on all other ports and it doesn't respond to ICMP packets either. A lot of that is security through obscurity but I found this to be a good balance of security and practicality.
- trelane 3y agoI've seen this discussed a fair bit, and always the recommendation is to use wire guard and expose ssh only to the "local network" e.g. https://bugs.gentoo.org/928134#c38 https://bugs.gentoo.org/928134#c38 First, I don't see how this works where there's a single server (e.g. colocation). Second, doesn't that just make Wireguard the new hack target? How does this actually mitigate the risk?
- GabeIsko 3y agoI wouldn't really consider port knocking to be that effective of a way to block connections. It is really only obscure, but port knocking software is very accessible. So if you know a port needs to be knocked, it's not hard for an attacker to get to it. The main benefit of port knocking is that it allows you to present your ports as normally closed. If you have a system and you are worried about it getting port scanned for whatever reason, it makes sense to have a scheme where the ports are closed unless it receives a knock. So if someone gets access they shouldn't for whatever reason and pulls a portscan off, the information they get about your system is somewhat limited. In this scheme, it would be much better to have an access point you authenticate with and then that handles the port knocking for the other devices. So it is a kind of obscure method that is really only useful in a specific use case. As far as SSH keys go, I would argue that SSH support is so ubiquitous, and SSH access is so powerful that it is a reasonable security tradeoff. I also don't think that SSH ports should be exposed to the internet, unless it is a specific use case where that is the whole point, like GitHub. I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. I personally don't know any application where you really need supreme admin access to every device, from any device, from anywhere in the world, while at the same time it has extreme security requirements. That's a pretty big task. At that point, constructing a dedicated, hardened access point that faces the internet and grants access to other devices is probably the way to go.
- delusional 3y ago> I'm very down on connecting directly through SSH without network access. The xz situation has validated this opinion. Did it? At the point an attacker has remote code execution, couldn't they just as easily pivot into an outgoing connection to some command and control server? I don't see how some intermediary access point would have alleviated this problem. If the call is coming from inside the house, the gig is already up.
- deepbreath 3y ago> At the point an attacker has remote code execution The attacker doesn't have remote code execution in the xz case unless they can speak to your port 22. Port knocking prevents them from doing so, provided they don't know how to knock.