5 ms·

I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made

by rsync 12y ago

I've been doing this sysadmin thing for a long, long time, and have built some large, high profile platforms,[1][2] and I can tell you that few things have made me happier than port knocking. Yes, it is a password with a tiny number of "bits". But nobody suggested using only port knocking, so that's not significant. Yes, if my attacker is sharing the exact same NAT'd IP as me then they have a window to attack ... my fully hardened server, which was no worse than what was presented to them before. Finally (and this is what makes me happiest) my sshd is not exposed to whatever new exploit might be discovered tomorrow that doesn't require user credentials. It's not exposed to being DOS'd by a buffer overflow vuln. It's not filling my logs with brute forcers all day and night. I love port knocking. [1] JohnCompanies (first VPS provider) [2] rsync.net

philjr 12y ago
just run ssh on a non-standard port and you get the same benefits
- arde 12y ago
  That is equivalent to limiting SPA to a 16-bit password.
- e40 12y ago
  just run ssh on a non-standard port and you get the same benefits philjr, that is just complete BS. I've run SSH on non-standard ports and they still get a lot of attempts. You know, there are these things called port scans that easily find the daemon on alternate ports.
peterwwillis 12y ago
Mr. Sysadmin, I have four questions: 1. When was the last time your sshd was hit with a 0day? 2. Why aren't you running grsec to prevent buffer overflows (amongst other things) ? 3. Wouldn't it be easier to DOS your host with excess traffic (like all modern DDOS attacks), rather than find a remote-code-execution buffer overflow 0day and use it solely to starve resources on a bastion host? 4. Why don't you use a VPN? If you used a udp-based VPN nobody would even know the port was open (connectionless) and you could even require a preshared key, which is the more secure equivalent of port knocking.
- arde 12y ago
  Regarding item 4, a VPN solution is considerably more complex and error prone than port knocking plus SSH. What do you do if/when your VPN service fails? I think you would usually have a VPN service AND a port knocked SSH backdoor.
  - peterwwillis 12y ago
    Yes, good security is usually more complex, though error prone I don't think is accurate. What do you do when your SSH or port knocking service fails?
    - arde 12y ago
      I meant its configuration and maintenance is more error prone. Certificates may expire without renewal, for example. I've seen port knocking work without a flaw for over ten years in a row, and the SSH configuration is shorter and almost never changes (unless it is to change the cipher or the user).
      - peterwwillis 12y ago
        A side-by-side comparison would require side-by-side configuration. And you can totally configure both SSH and a VPN the same way. Both ssh and a vpn support authenticating with public keys. Both require maintenance on security updates, or to gain new features, or to strengthen ciphers used, or allow a new user access. You mention certificates. You do not need to use certificates with either, though you can. You do not need to validate certificate expiration with either, though you can. You can also set expiration to some year well past when the technology will even be relevant. You claim that expiration of a certificate is somehow a flaw, yet it exists as a security feature. If what you want is to be more secure, you would be wise to use this feature, and not discard it as an annoying maintenance task. However, happily, you can easily ignore it with a VPN just as you do with SSH.
    - e40 12y ago
      Yes, good security is usually more complex Wow. So, in your mind software that is more complex is more secure. OK, I think I understand the origin of a lot of your comments, then. We completely and fundamentally disagree. What do you do when your SSH or port knocking service fails? That's a complete red herring. What do you do when your firewall fails??

by rsync 12y ago

philjr 12y ago

just run ssh on a non-standard port and you get the same benefits

arde 12y ago
That is equivalent to limiting SPA to a 16-bit password.
e40 12y ago
just run ssh on a non-standard port and you get the same benefits philjr, that is just complete BS. I've run SSH on non-standard ports and they still get a lot of attempts. You know, there are these things called port scans that easily find the daemon on alternate ports.

peterwwillis 12y ago

Mr. Sysadmin, I have four questions: 1. When was the last time your sshd was hit with a 0day? 2. Why aren't you running grsec to prevent buffer overflows (amongst other things) ? 3. Wouldn't it be easier to DOS your host with excess traffic (like all modern DDOS attacks), rather than find a remote-code-execution buffer overflow 0day and use it solely to starve resources on a bastion host? 4. Why don't you use a VPN? If you used a udp-based VPN nobody would even know the port was open (connectionless) and you could even require a preshared key, which is the more secure equivalent of port knocking.

arde 12y ago
Regarding item 4, a VPN solution is considerably more complex and error prone than port knocking plus SSH. What do you do if/when your VPN service fails? I think you would usually have a VPN service AND a port knocked SSH backdoor.
- peterwwillis 12y ago
  Yes, good security is usually more complex, though error prone I don't think is accurate. What do you do when your SSH or port knocking service fails?
  - arde 12y ago
    I meant its configuration and maintenance is more error prone. Certificates may expire without renewal, for example. I've seen port knocking work without a flaw for over ten years in a row, and the SSH configuration is shorter and almost never changes (unless it is to change the cipher or the user).
    - peterwwillis 12y ago
      A side-by-side comparison would require side-by-side configuration. And you can totally configure both SSH and a VPN the same way. Both ssh and a vpn support authenticating with public keys. Both require maintenance on security updates, or to gain new features, or to strengthen ciphers used, or allow a new user access. You mention certificates. You do not need to use certificates with either, though you can. You do not need to validate certificate expiration with either, though you can. You can also set expiration to some year well past when the technology will even be relevant. You claim that expiration of a certificate is somehow a flaw, yet it exists as a security feature. If what you want is to be more secure, you would be wise to use this feature, and not discard it as an annoying maintenance task. However, happily, you can easily ignore it with a VPN just as you do with SSH.
  - e40 12y ago
    Yes, good security is usually more complex Wow. So, in your mind software that is more complex is more secure. OK, I think I understand the origin of a lot of your comments, then. We completely and fundamentally disagree. What do you do when your SSH or port knocking service fails? That's a complete red herring. What do you do when your firewall fails??