6 ms·

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and

Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. 20 years ago, I was working at an ISP/Telco and one of our vendors had a permanent admin account hardcoded on their gear, you couldn't change the password and it didn't log access, or show up as an active user session. Always limit traffic to just what is necessary, does the entire internet really need to be able to SSH to your box?

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 ago
  https://github.com/CERN-CERT/pam_2fa https://github.com/CERN-CERT/pam_2fa
  - herpderperator 3y ago
    What does this have to do with port knocking?
  - nequo 3y ago
    This is great but would this neutralize the xz backdoor? The backdoor circumvents authentication, doesn't it?
- Joel_Mckay 3y ago
  Port 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 ago
    can you give an example for an implementation of portnocking/ssh/over https and client certs?
    - Joel_Mckay 3y ago
      In 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 ago
      I 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 ago
  Absolutely, 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 ago
    Note 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 ago
      Not if you set it up such that each knocking sequence can only be used once. Port knocking is a flexible concept.
      - squigz 3y ago
        I 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 ago
        Was just having the same thought reading this thread.
        ametrau 3y ago
        Yeah 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 ago
        This 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 ago
  You 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 ago
    At 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 ago
    TIL another interesting browser feature. Thank you.
    - Dwedit 3y ago
      That's just the usual way of attempting to connect to an HTTP server running on a different port. Sometimes you see websites hosted on port 8080 or something like that.
      - webmaven 3y ago
        Oh. Duh. I suppose I should have said it was a new-to-me use case for that feature.
  - bee_rider 3y ago
    It seems like there’d be a pretty big overlap between those kinds of hosts.
  - noman-land 3y ago
    I'm a bit of a noob about this. Can you explain what this means?
    - shanemhansen 3y ago
      Port 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 ago
  You 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 ago
  My 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 ago
    I'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 ago
  I 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.
nijave 3y ago
Jump host running a different SSH server implementation or SSH over VPN seems a little more reliable. There's a lot of solutions now where the host has an agent that reaches out instead of allowing incoming connections which can be useful (assuming you trust that proxy service/software). One place I worked, we ran our jumphost on GCP with Identity Aware Proxy and on AWS with SSM sessions so had to authenticate to the cloud provider API and the hosts weren't directly listening for connections from the internet. Similar setup to ZeroTier/TailScale+SSH
Terr_ 3y ago
My gut-feel is that it rides near the line between "defense in depth" versus "security through obscurity".
- mrguyorama 3y ago
  The reality is that security through obscurity works really well as a layer in an otherwise already good security model. You make sure to test it with some red teaming, and if they fail to get through, you give them all the details about your tricks so they can also test the actual security. The "obscurity" part mostly serves to limit the noise of drive by and bot'd attacks, such that each attack attempt that you end up stopping and catching is a more serious signal, and more likely to be directed. It's about short circuiting much of the "chaff" in the signal such that you are less warning fatigued and more likely to seriously respond to incidents. The obscurity is not meant to prevent targeted attacks.
- Attummm 3y ago
  While 'security through obscurity' shouldn't be your only defense, it still plays a crucial role within 'defense in depth' strategies. In the past, sensitive networks relied heavily on obscurity alone. Just dialing the right phone number could grant access to highly sensitive networks. However, there's a cautionary tale of a security researcher who took the phrase 'don't do security through obscurity' to heart and dared hackers, leading to disastrous consequences. Obscurity, when used appropriately, complements broader security measures. Take SSH, for example. Most bots target its default port. Simply changing that port removes the easy targets, forcing attackers to use more sophisticated methods, which in turn, leaves your logs with more concerning activity.
TacticalCoder 3y ago
> Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking. I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-knocking were protected while those who didn't were potentially wide open to the biggest backdoor discovered to date (even if it's wasn't yet in all the major distros). > ... does the entire internet really need to be able to SSH to your box? Nope and I never ever understood the argument saying: "Port-knocking is security theatre, it doesn't bring any added security". To me port-knocking didn't lower the security of a system. It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks).
- AlexCoventry 3y ago
  > say that port knocking is pointless and security theatre Who was saying that?
  - password4321 3y ago
    https://hn.algolia.com/?query=port%20knocking%20obscurity&type=comment https://hn.algolia.com/?query=port%20knocking%20obscurity&ty... 20200515 https://news.ycombinator.com/item?id=23187662 https://news.ycombinator.com/item?id=23187662 etc.
    - AlexCoventry 3y ago
      Thanks.
  - rdtsc 3y ago
    I've heard it many times in the form of "security through obscurity, lol! you obviously, don't know what you're doing". Yeah, it's a "straw man" pretending the person they are addressing was just planning on running telnet with port knocking.
- 3y ago
noman-land 3y ago
Got any advice to easily set up port knocking?
- AlexCoventry 3y ago
  It's old and there are probably friendlier options out there now, but https://github.com/moxie0/knockknock/blob/master/INSTALL https://github.com/moxie0/knockknock/blob/master/INSTALL
Dwedit 3y ago
Going in through the main Internet connection might not be the only way in. Someone surfing on Wifi who visits the wrong website can also become a second way into your internal network.
k8svet 3y ago
Over the weekend, I added this to a common bit included in all my NixOS systems: -networking.firewall.allowedTCPPorts = [ 22 ]; +networking.firewall.interfaces."tailscale0".allowedTCPPorts = [ 22 ]; I probably should have done this ages ago.
zoeysmithe 3y ago
Port knocking is bit like a lazy person's VPN. You might as well get off your butt and install a vpn solution and use ssh via vpn. The time and effort is almost the same nowadays anyway. The chances of both vpn and ssh being exploited like this must be zero. Worse, most corporate, public wifi, etc networks block all sorts of ports. So at home sure you can open random ports but near everywhere else its just 80 and 443. Now you can't knock. But your https vpn works fine. Also a lot of scary stuff here about identity and code checkins. If someone is some contributor, how do we know if their creds havent been stolen or they've been forced via blackmail or whatever to do this? Or how many contributors are actually intelligence agents? Then who is validating their code? This persons code went through just fine, and this was only caught because someone noticed a lag in logins, which by then, is a running binary. FOSS works on the concept of x amount of developer trust, both in code and identity. You can't verify everyone all the time (creds and certs get stolen, blackmail, etc), nor can you audit every line of code all the time. Especially if the exploit is submitted piecemeal over the years or months. That trust is now being exploited it seems. Scary times. I wonder if how FOSS works will change after this. I assume the radio silence for Theo and Linus and others means there's a lot of brainstroming to get to the root of this problem. Addressing the symptom of this one attack probably won't be enough. I imagine some very powerful people want some clarity and fixes here and this is probably going to be a big deal. I wouldn't be surprised if a big identity trust initiative comes out of this and some AI stuff to go over an entire submitter's history to spot any potentially malicious pattern like this that's hard for human beings to detect.
- codedokode 3y ago
  > nor can you audit every line of code all the time You can if you distribute this job among volunteers or hire people to do that. There are millions of developers around the world capable to do this. But reality is that nobody wants to contribute time or pay for free software.
belorn 3y ago
Rather than port knocking, I prefer IP knocking. The server has several ip addresses and once a correct sequence of connection is made, the ssh port opens. Since so few know about IP knocking, it much safer than port knocking. /s
- drpixie 3y ago
  Sounds like (another) good reason for IPv6 - your box can have many, very obscure addresses :)
teddyh 3y ago
Port knocking is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes manageable, adjust your logging levels. The security of port knocking is also woefully inadequate: • It adds very little security. How many bits are in a “secret knock”? • The security it does add is bad: It’s sent in cleartext, and easily brute-forced. • It complicates access, since it’s non-standard. 1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_principle&oldid=1214547066 https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...>
- VWWHFSfQ 3y ago
  Port knocking is definitely dumb, but "increase your password lengths, or cryptographic key sizes" does nothing if your ssh binary is compromised and anyone can send a magic packet to let themselves in. Strict firewalls, VPNs, and defense-in-depth is really the only answer here. Of course, those things all go out the window too if your TCP stack itself is also compromised. Better to just air-gap.
  - teddyh 3y ago
    Many people argue that a VPN+SSH is a reasonable solution, since it uses two separate implementations, where both are unlikely to be compromised at the same time. I would argue that the more reasonable option would be to split the SSH project in two; both of which validates the credentials of an incoming connection. This would be the same as a VPN+SSH but would not convolute the network topography, and would eliminate the need for two keys to be used by every connecting user. However, in this case, the two-layer approach would not be a protection. Sure, in this case the SSH daemon was compromised, and a VPN before SSH would have protected SSH. But what if the VPN server itself was compromised? Remember that the SSH server was altered, not to allow normal logins, but to call system() directly. What if a VPN server had been similarly altered? This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely. It is a mistake to look at this case and assume that since SSH was compromised this time, SSH must always be protected by another layer. That other layer might be the next thing to be compromised.
deleted 3y ago
[deleted]

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 ago
https://github.com/CERN-CERT/pam_2fa https://github.com/CERN-CERT/pam_2fa
- herpderperator 3y ago
  What does this have to do with port knocking?
- nequo 3y ago
  This is great but would this neutralize the xz backdoor? The backdoor circumvents authentication, doesn't it?
Joel_Mckay 3y ago
Port 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 ago
  can you give an example for an implementation of portnocking/ssh/over https and client certs?
  - Joel_Mckay 3y ago
    In 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 ago
    I 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 ago
Absolutely, 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 ago
  Note 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 ago
    Not if you set it up such that each knocking sequence can only be used once. Port knocking is a flexible concept.
    - squigz 3y ago
      I 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 ago
        Was just having the same thought reading this thread.
      - ametrau 3y ago
        Yeah 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 ago
        This 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 ago
You 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 ago
  At 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 ago
  TIL another interesting browser feature. Thank you.
  - Dwedit 3y ago
    That's just the usual way of attempting to connect to an HTTP server running on a different port. Sometimes you see websites hosted on port 8080 or something like that.
    - webmaven 3y ago
      Oh. Duh. I suppose I should have said it was a new-to-me use case for that feature.
- bee_rider 3y ago
  It seems like there’d be a pretty big overlap between those kinds of hosts.
- noman-land 3y ago
  I'm a bit of a noob about this. Can you explain what this means?
  - shanemhansen 3y ago
    Port 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 ago
You 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 ago
My 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 ago
  I'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 ago
I 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.

nijave 3y ago

Jump host running a different SSH server implementation or SSH over VPN seems a little more reliable. There's a lot of solutions now where the host has an agent that reaches out instead of allowing incoming connections which can be useful (assuming you trust that proxy service/software). One place I worked, we ran our jumphost on GCP with Identity Aware Proxy and on AWS with SSM sessions so had to authenticate to the cloud provider API and the hosts weren't directly listening for connections from the internet. Similar setup to ZeroTier/TailScale+SSH

Terr_ 3y ago

My gut-feel is that it rides near the line between "defense in depth" versus "security through obscurity".

mrguyorama 3y ago
The reality is that security through obscurity works really well as a layer in an otherwise already good security model. You make sure to test it with some red teaming, and if they fail to get through, you give them all the details about your tricks so they can also test the actual security. The "obscurity" part mostly serves to limit the noise of drive by and bot'd attacks, such that each attack attempt that you end up stopping and catching is a more serious signal, and more likely to be directed. It's about short circuiting much of the "chaff" in the signal such that you are less warning fatigued and more likely to seriously respond to incidents. The obscurity is not meant to prevent targeted attacks.
Attummm 3y ago
While 'security through obscurity' shouldn't be your only defense, it still plays a crucial role within 'defense in depth' strategies. In the past, sensitive networks relied heavily on obscurity alone. Just dialing the right phone number could grant access to highly sensitive networks. However, there's a cautionary tale of a security researcher who took the phrase 'don't do security through obscurity' to heart and dared hackers, leading to disastrous consequences. Obscurity, when used appropriately, complements broader security measures. Take SSH, for example. Most bots target its default port. Simply changing that port removes the easy targets, forcing attackers to use more sophisticated methods, which in turn, leaves your logs with more concerning activity.

TacticalCoder 3y ago

> Stuff like this is why I like port knocking, and limiting access to specific client IPs/networks when possible. Indeed: I whitelist hosts/IP blocks allowed to SSH in. I don't use port-knocking but I never ever criticized those using port knocking. I do really wonder if people are still going to say that port knocking is pointless and security theatre: we now have a clear example where people who were using port-knocking were protected while those who didn't were potentially wide open to the biggest backdoor discovered to date (even if it's wasn't yet in all the major distros). > ... does the entire internet really need to be able to SSH to your box? Nope and I never ever understood the argument saying: "Port-knocking is security theatre, it doesn't bring any added security". To me port-knocking didn't lower the security of a system. It seems that we now have a clear proof that it's actually helping versus certain type of attacks (including source-code supply chain attacks).

AlexCoventry 3y ago
> say that port knocking is pointless and security theatre Who was saying that?
- password4321 3y ago
  https://hn.algolia.com/?query=port%20knocking%20obscurity&type=comment https://hn.algolia.com/?query=port%20knocking%20obscurity&ty... 20200515 https://news.ycombinator.com/item?id=23187662 https://news.ycombinator.com/item?id=23187662 etc.
  - AlexCoventry 3y ago
    Thanks.
- rdtsc 3y ago
  I've heard it many times in the form of "security through obscurity, lol! you obviously, don't know what you're doing". Yeah, it's a "straw man" pretending the person they are addressing was just planning on running telnet with port knocking.
3y ago

noman-land 3y ago

Got any advice to easily set up port knocking?

AlexCoventry 3y ago
It's old and there are probably friendlier options out there now, but https://github.com/moxie0/knockknock/blob/master/INSTALL https://github.com/moxie0/knockknock/blob/master/INSTALL

Dwedit 3y ago

Going in through the main Internet connection might not be the only way in. Someone surfing on Wifi who visits the wrong website can also become a second way into your internal network.

k8svet 3y ago

Over the weekend, I added this to a common bit included in all my NixOS systems: -networking.firewall.allowedTCPPorts = [ 22 ]; +networking.firewall.interfaces."tailscale0".allowedTCPPorts = [ 22 ]; I probably should have done this ages ago.

zoeysmithe 3y ago

Port knocking is bit like a lazy person's VPN. You might as well get off your butt and install a vpn solution and use ssh via vpn. The time and effort is almost the same nowadays anyway. The chances of both vpn and ssh being exploited like this must be zero. Worse, most corporate, public wifi, etc networks block all sorts of ports. So at home sure you can open random ports but near everywhere else its just 80 and 443. Now you can't knock. But your https vpn works fine. Also a lot of scary stuff here about identity and code checkins. If someone is some contributor, how do we know if their creds havent been stolen or they've been forced via blackmail or whatever to do this? Or how many contributors are actually intelligence agents? Then who is validating their code? This persons code went through just fine, and this was only caught because someone noticed a lag in logins, which by then, is a running binary. FOSS works on the concept of x amount of developer trust, both in code and identity. You can't verify everyone all the time (creds and certs get stolen, blackmail, etc), nor can you audit every line of code all the time. Especially if the exploit is submitted piecemeal over the years or months. That trust is now being exploited it seems. Scary times. I wonder if how FOSS works will change after this. I assume the radio silence for Theo and Linus and others means there's a lot of brainstroming to get to the root of this problem. Addressing the symptom of this one attack probably won't be enough. I imagine some very powerful people want some clarity and fixes here and this is probably going to be a big deal. I wouldn't be surprised if a big identity trust initiative comes out of this and some AI stuff to go over an entire submitter's history to spot any potentially malicious pattern like this that's hard for human beings to detect.

codedokode 3y ago
> nor can you audit every line of code all the time You can if you distribute this job among volunteers or hire people to do that. There are millions of developers around the world capable to do this. But reality is that nobody wants to contribute time or pay for free software.

belorn 3y ago

Rather than port knocking, I prefer IP knocking. The server has several ip addresses and once a correct sequence of connection is made, the ssh port opens. Since so few know about IP knocking, it much safer than port knocking. /s

drpixie 3y ago
Sounds like (another) good reason for IPv6 - your box can have many, very obscure addresses :)

teddyh 3y ago

Port knocking is stupid. It violates Kerckhoffs’s principle¹. If you want more secret bits which users need to know in order to access your system, increase your password lengths, or cryptographic key sizes. If you want to keep log sizes manageable, adjust your logging levels. The security of port knocking is also woefully inadequate: • It adds very little security. How many bits are in a “secret knock”? • The security it does add is bad: It’s sent in cleartext, and easily brute-forced. • It complicates access, since it’s non-standard. 1. <https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_principle&oldid=1214547066 https://en.wikipedia.org/w/index.php?title=Kerckhoffs%27s_pr...>

VWWHFSfQ 3y ago
Port knocking is definitely dumb, but "increase your password lengths, or cryptographic key sizes" does nothing if your ssh binary is compromised and anyone can send a magic packet to let themselves in. Strict firewalls, VPNs, and defense-in-depth is really the only answer here. Of course, those things all go out the window too if your TCP stack itself is also compromised. Better to just air-gap.
- teddyh 3y ago
  Many people argue that a VPN+SSH is a reasonable solution, since it uses two separate implementations, where both are unlikely to be compromised at the same time. I would argue that the more reasonable option would be to split the SSH project in two; both of which validates the credentials of an incoming connection. This would be the same as a VPN+SSH but would not convolute the network topography, and would eliminate the need for two keys to be used by every connecting user. However, in this case, the two-layer approach would not be a protection. Sure, in this case the SSH daemon was compromised, and a VPN before SSH would have protected SSH. But what if the VPN server itself was compromised? Remember that the SSH server was altered, not to allow normal logins, but to call system() directly. What if a VPN server had been similarly altered? This would not have protected SSH, since a direct system() call by the VPN daemon would have ignored SSH completely. It is a mistake to look at this case and assume that since SSH was compromised this time, SSH must always be protected by another layer. That other layer might be the next thing to be compromised.

deleted 3y ago

[deleted]