5 ms·

People. Port knocking. Seriously. There are very few things that have come and gone in the almost 20 years that I have been securing systems and dealing with

by rsync 13y ago

People. Port knocking. Seriously. There are very few things that have come and gone in the almost 20 years that I have been securing systems and dealing with attacks, but port knocking is a substantive, Truly Good Thing. Works for a lot of other ports too, but ssh is the obvious one.

mwcampbell 13y ago
Which port knocking implementation do you recommend?
- yareally 13y ago
  I've been using knockd[1] for the last 5 or so years. Also has prebuilt binaries (and in many repositories[2]) for almost every distro, including cygwin, native windows and android. [1] http://www.zeroflux.org/projects/knock/ http://www.zeroflux.org/projects/knock/ [2] http://packages.debian.org/wheezy/knockd http://packages.debian.org/wheezy/knockd
  - narcissus 13y ago
    Not knowing much about this stuff, are there any clients that will 'automate' the knock for you? If so, can you make any suggestions? Or is this a matter of CLI SSH will do it, but I'm just not finding it?
    - yareally 13y ago
      https://help.ubuntu.com/community/PortKnocking https://help.ubuntu.com/community/PortKnocking (also the same config basically when using Debian) It's a client/server thing, so you have to have the server running on the PC you intend to connect to (like when using ssh). Never used it in any other way than with the CLI and not with every server I admin or use as there's other best practices also mentioned in the thread that are typically good enough without throwing in port knocking like: https://news.ycombinator.com/item?id=6384313 https://news.ycombinator.com/item?id=6384313 (and the child reply) https://news.ycombinator.com/item?id=6384418 https://news.ycombinator.com/item?id=6384418 https://news.ycombinator.com/item?id=6384457 https://news.ycombinator.com/item?id=6384457 Most things you can just use knocking and connect with ssh forwarding/proxy and tunnel everything through it like DB clients, IDE connections instead of having a bunch of ports open to internet. Assuming you don't kill the connection, then you can keep reusing it as a tunnel for anything else until rebooting or losing internet connection.
- gregf 13y ago
  Also check out fwknop[1] [1] http://www.cipherdyne.org/fwknop/ http://www.cipherdyne.org/fwknop/
gcb0 13y ago
meh. it is a pain. I'm much more in favour of adding increasing delays for password abuse in ssh.
iand675 13y ago
Any other all-around good practices that you can recommend? I'm not really sure how to go about locking down a production server to a sane degree, and there's a lot of bad information out there when it comes to security.
- mburns 13y ago
  In order of least effort to most: * Disable root logins (require su/sudo) * Disable password logins (require public keys) * Run Denyhosts, to block IP addresses that have too many repeated failed login attempts. * Use Jumphosts (AKA Bastions). One (or a few) servers that listen to ssh from the open Internet and have no private keys stored on them (use key forwarding). All other servers only listen to ssh from an internal network interface the Jumphosts are also on, or from the Jumphosts IP address directly.
  - troels 13y ago
    I've always wondered what exactly is the purpose of a jumphost? Wouldn't it be equally susceptible to attacks as the actual servers are?
    - mburns 13y ago
      sshd is equally susceptible, where ever you run it, sure. With jumphosts, though, you can run denyhosts, redirect to tarpits, or other clever things, and not effect performance on your other servers. I think the motivation to use jumphosts is to minimize the surface area of your other servers as much as possible. Each daemon on each server listening for incoming connections is a liability. If an sshd exploit is found (unlikely as that is), bots that mass scan and find my ssh ports and connect won't be able to delete any production files (right away, at least) if all they gain access to is my jumphost and not one of the prod db servers.
      - troels 13y ago
        Thanks. I didn't consider that the mere act of having sshd deny attempts is a performance cost. I guess one could potentially dos a server by flooding the sshd with bogus attempts?
tptacek 13y ago
I think port knocking is really silly, for what it's worth. Disable password authentication in SSH, minimize the number of systems you expose SSH to at all, and leave it at that.
- david_shaw 13y ago
  I agree that disabling password auth--or even just using something like fail2ban to blacklist attackers--is just as effective (and significantly easier) than setting up port knocking. The substantive difference, though, is that port knocking can be used to hide the service entirely, rendering you safe (mostly) from 0day attacks, DoS against a specific service, etc. It can also be use to make things that shouldn't be on the Internet (say, an RDP route to the CEO's computer) a little safer. Still, though, it's not like VPNs are very difficult to use...
  - dspillett 13y ago
    But if you are using SSH for administrative purposes on anything important that you might be reomte from in a time of crisis you don't want to layer something else on top of SSH that might fail and not let you in, or even if the port-knocking arrnagement is OK you might not be able to access it from where you are (perhaps on a mobile/wireless network that is blocking all but the most common standard ports in an illconeived effort to block P2P traffic, which would affect people who put SSH on a non-standard port as well). OK so if it is that bad maybe everything is down/inaccessible (SSH and all), and anything that important has local hands-on support available, but it still strikes me as a bad idea to potentially lock yourself out. The worrying thing in this report though is how many hosts seems to be running ancient (now unsupported) versions such as the stock variant from Debian 4. I bet most of those hosts have no key-based auth and easily guessed passwords too...
pwg 13y ago
There is also ssh-faker: http://www.pkts.ca/ssh-faker.shtml http://www.pkts.ca/ssh-faker.shtml From the description: This program is called by /etc/hosts.deny whenever someone connects to port 22. Unless they type in a plaintext password or type the wrong password, they get an ssh-compatible error message, and a syslog message is generated. If they type in the right password, they are added to /etc/hosts.allow, and their next connection will reach the real sshd.

by rsync 13y ago

mwcampbell 13y ago

Which port knocking implementation do you recommend?

yareally 13y ago
I've been using knockd[1] for the last 5 or so years. Also has prebuilt binaries (and in many repositories[2]) for almost every distro, including cygwin, native windows and android. [1] http://www.zeroflux.org/projects/knock/ http://www.zeroflux.org/projects/knock/ [2] http://packages.debian.org/wheezy/knockd http://packages.debian.org/wheezy/knockd
- narcissus 13y ago
  Not knowing much about this stuff, are there any clients that will 'automate' the knock for you? If so, can you make any suggestions? Or is this a matter of CLI SSH will do it, but I'm just not finding it?
  - yareally 13y ago
    https://help.ubuntu.com/community/PortKnocking https://help.ubuntu.com/community/PortKnocking (also the same config basically when using Debian) It's a client/server thing, so you have to have the server running on the PC you intend to connect to (like when using ssh). Never used it in any other way than with the CLI and not with every server I admin or use as there's other best practices also mentioned in the thread that are typically good enough without throwing in port knocking like: https://news.ycombinator.com/item?id=6384313 https://news.ycombinator.com/item?id=6384313 (and the child reply) https://news.ycombinator.com/item?id=6384418 https://news.ycombinator.com/item?id=6384418 https://news.ycombinator.com/item?id=6384457 https://news.ycombinator.com/item?id=6384457 Most things you can just use knocking and connect with ssh forwarding/proxy and tunnel everything through it like DB clients, IDE connections instead of having a bunch of ports open to internet. Assuming you don't kill the connection, then you can keep reusing it as a tunnel for anything else until rebooting or losing internet connection.
gregf 13y ago
Also check out fwknop[1] [1] http://www.cipherdyne.org/fwknop/ http://www.cipherdyne.org/fwknop/

gcb0 13y ago

meh. it is a pain. I'm much more in favour of adding increasing delays for password abuse in ssh.

iand675 13y ago

Any other all-around good practices that you can recommend? I'm not really sure how to go about locking down a production server to a sane degree, and there's a lot of bad information out there when it comes to security.

mburns 13y ago
In order of least effort to most: * Disable root logins (require su/sudo) * Disable password logins (require public keys) * Run Denyhosts, to block IP addresses that have too many repeated failed login attempts. * Use Jumphosts (AKA Bastions). One (or a few) servers that listen to ssh from the open Internet and have no private keys stored on them (use key forwarding). All other servers only listen to ssh from an internal network interface the Jumphosts are also on, or from the Jumphosts IP address directly.
- troels 13y ago
  I've always wondered what exactly is the purpose of a jumphost? Wouldn't it be equally susceptible to attacks as the actual servers are?
  - mburns 13y ago
    sshd is equally susceptible, where ever you run it, sure. With jumphosts, though, you can run denyhosts, redirect to tarpits, or other clever things, and not effect performance on your other servers. I think the motivation to use jumphosts is to minimize the surface area of your other servers as much as possible. Each daemon on each server listening for incoming connections is a liability. If an sshd exploit is found (unlikely as that is), bots that mass scan and find my ssh ports and connect won't be able to delete any production files (right away, at least) if all they gain access to is my jumphost and not one of the prod db servers.
    - troels 13y ago
      Thanks. I didn't consider that the mere act of having sshd deny attempts is a performance cost. I guess one could potentially dos a server by flooding the sshd with bogus attempts?

tptacek 13y ago

I think port knocking is really silly, for what it's worth. Disable password authentication in SSH, minimize the number of systems you expose SSH to at all, and leave it at that.

david_shaw 13y ago
I agree that disabling password auth--or even just using something like fail2ban to blacklist attackers--is just as effective (and significantly easier) than setting up port knocking. The substantive difference, though, is that port knocking can be used to hide the service entirely, rendering you safe (mostly) from 0day attacks, DoS against a specific service, etc. It can also be use to make things that shouldn't be on the Internet (say, an RDP route to the CEO's computer) a little safer. Still, though, it's not like VPNs are very difficult to use...
- dspillett 13y ago
  But if you are using SSH for administrative purposes on anything important that you might be reomte from in a time of crisis you don't want to layer something else on top of SSH that might fail and not let you in, or even if the port-knocking arrnagement is OK you might not be able to access it from where you are (perhaps on a mobile/wireless network that is blocking all but the most common standard ports in an illconeived effort to block P2P traffic, which would affect people who put SSH on a non-standard port as well). OK so if it is that bad maybe everything is down/inaccessible (SSH and all), and anything that important has local hands-on support available, but it still strikes me as a bad idea to potentially lock yourself out. The worrying thing in this report though is how many hosts seems to be running ancient (now unsupported) versions such as the stock variant from Debian 4. I bet most of those hosts have no key-based auth and easily guessed passwords too...

pwg 13y ago

There is also ssh-faker: http://www.pkts.ca/ssh-faker.shtml http://www.pkts.ca/ssh-faker.shtml From the description: This program is called by /etc/hosts.deny whenever someone connects to port 22. Unless they type in a plaintext password or type the wrong password, they get an ssh-compatible error message, and a syslog message is generated. If they type in the right password, they are added to /etc/hosts.allow, and their next connection will reach the real sshd.