7 ms·

This is why you should do one or more of the following at the very least. - Always use keys and disable password based login - Do not have ssh publicly expose

This is why you should do one or more of the following at the very least. - Always use keys and disable password based login - Do not have ssh publicly exposed, or at the very least only via a bastion server, but if that bastion server is publicly available, then you are still quite vulnerable (perhaps even more so if someone gets into your bastion and is able to ssh to all the things if you are using key-based logins from the bastion) - Always use a passphrase for your keys (helps with the “if someone breaks into your bastion scenario”)... but the best thing you can do is just don’t expose ssh to the public network

29athrowaway 6y ago
Using ssh in an obscure port helps a little bit. PAM modules also help.
- gnabgib 6y ago
  This particular malware doesn't seem to grok when you're using certs or keys, so while it'll never be successful it keeps trying (effectively a resource DOS). Obscure port does nothing.. it eventually finds it and then you'll see tons of servers try that port (unless you constantly move it). I'm not sure how you imagine Pluggable Authentication Modules would help? Fail2Ban or some sort of active IPS helps, but because the IPs are very varied (and presumably ever increasing) and infrequently re-attempt it doesn't help much. Note anyone running exposed SSH without keys or certs, should run the detection script[0] (which is just shell and you should read first before installing) provided by Guardicore [0]: https://github.com/guardicore/labs_campaigns/tree/master/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
  - LinuxBender 6y ago
    For my hobby servers, I listen on a non standard port. Not once in 20+ years has anything hit that port. Even when I've had domains / sites that ruffled feathers, no hits. It most certainly cuts out noise in logs and stops all the bots.
    - AndyMcConachie 6y ago
      I've also used a port other than 22 for sshd. And I can confirm that the past month I've been getting hit with lots of failed login attempts on ssh. My basic look at the logs shows it trying random dictionary words for usernames. And every connection attempt comes from a different IP.
      - linker3000 6y ago
        Yes, I'm seeing the same to my non-standard port and the connection attempts are from a large number of different addresses (and only usually 1 or 2 attempts from each) that Fail2Ban does not trigger.
    - Caligatio 6y ago
      A few months ago I started noticing failed login attempts on my non standard SSH port (> port 1024) so I moved it up a few port numbers. About 2-3 weeks ago, I noticed that it was getting hit again by failed login attempts. I then changed the port to the original and immediately started getting login attempts again... it kind of spooked me. I thought about using fail2ban but every login is a different IP (using my eyeballs, I didn't parse the logs).
      - LinuxBender 6y ago
        I take a different approach than fail2ban. My sftp servers use a standard port 22 and any time people try to log in, I create an account for them automatically via a cron job in the sftp-only group and a null password. The bots will spend years trying to log in repeatedly every few minutes. I have yet to see them upload anything interesting. Many years ago, bots would upload malware, then try to browse to it on port 80. But no more... These bots just want to get a shell and install malware / c&c tools. Some of them try port forwarding, but I have that restricted for the sftp users.
      - aesh2Xa1 6y ago
        You can still use fail2ban to block unique IP addresses if you use some supporting scripting. There's an example ([1]), which will check the IP addresses by country code. If they're all the same country then you can just block the whole country. You do not need to use firewalld, either, although this does. See the second link for something generic ([2]). [1] https://pagure.io/firewalld-blacklist/tree/master https://pagure.io/firewalld-blacklist/tree/master [2] https://www.linuxjournal.com/content/advanced-firewall-configurations-ipset https://www.linuxjournal.com/content/advanced-firewall-confi...
manishsharan 6y ago
Could you comment on my way of accessing my servers on AWS: My server are on VPC and no public ssh is allowed (nothing is open besides 443). When I want to login to my server , I run a script to modify security. (I have disabled ssh password logins and ssh is running on non standard port). And when I am done with task, I plug the hole in security group with another batch code. I am worried that I may be not exposing my servers with my practices.
- chewmieser 6y ago
  No op, but your practice is probably fine. More ideally, SSH would be locked down to your public IP address only. If you're already scripting this, you could just do a curl request to one of the many "what is my ip" services and set that instead of 0.0.0.0/0 as the security group IP address. We also use bastion hosts. They're whitelisted for key-based SSH only access for our public IP addresses. We can jump around to other servers once we login to that one, but our externally facing servers never advertise anything other their base service (:443 or whatever is running on them). I also use them with my personal servers and just leave them shut off when I'm not actively using them. This keeps costs down, but more importantly it permanently blocks off SSH access unless I'm specifically in need of it.
- ajawee 6y ago
  Did you try port knocking https://wiki.archlinux.org/index.php/Port_knocking https://wiki.archlinux.org/index.php/Port_knocking
dgellow 6y ago
If you do expose your SSH port, one option is to setup a firewall rule to allow your own public IP for connections to the SSH port and drop all the rest. If you're using Digital Ocean, you can set a firewall rule via the droplet web interface, that's quick to do. Otherwise just a simple iptables does the trick. Edit: if you have a static public IP, of course
- gnabgib 6y ago
  As long as you have a static IP that could never change, otherwise you'll deny yourself access after, for example a power outage where your router gets a new IP (or a random period of time where your ISP decides to change your IP, or you move, or you want to connect from another server). Using an alternative connection to activate the protocol is probably the only reasonable defense: * An https service that can enable a port for connections from an IP for a limited time (which has some security implications too since it would need root access, or to trigger something with root access) * Something built into KLO hardware, or software provided by your provider (including something simple like turn on the firewall a few minutes after boot, and using the reboot trigger and connecting in that brief window.. as long as you don't mind your server down - probably ok as an emergency recovery strategy) * Some form of port knocking
  - framecowbird 6y ago
    I’m not sure I trust myself to set up my own bastion securely. Are there any companies that offer secure bastions as a service? What I’m envisaging is: I pay somebody, make an account on their site and add 2FA, and then they give me a server with a static IP and handle the auth. Then all I have to do is to whitelist that static IP. Ideally it would function as both an HTTP proxy and an SSH proxy; like a ‘secure web portal’
    - alexchamberlain 6y ago
      How much would you pay for that?
qeternity 6y ago
I’m curious why people say not to have ssh exposed if you only have key auth enabled. It seems to me that every single other password + some other number of protections is inherently weaker than simple old public key auth.

29athrowaway 6y ago

Using ssh in an obscure port helps a little bit. PAM modules also help.

gnabgib 6y ago
This particular malware doesn't seem to grok when you're using certs or keys, so while it'll never be successful it keeps trying (effectively a resource DOS). Obscure port does nothing.. it eventually finds it and then you'll see tons of servers try that port (unless you constantly move it). I'm not sure how you imagine Pluggable Authentication Modules would help? Fail2Ban or some sort of active IPS helps, but because the IPs are very varied (and presumably ever increasing) and infrequently re-attempt it doesn't help much. Note anyone running exposed SSH without keys or certs, should run the detection script[0] (which is just shell and you should read first before installing) provided by Guardicore [0]: https://github.com/guardicore/labs_campaigns/tree/master/FritzFrog https://github.com/guardicore/labs_campaigns/tree/master/Fri...
- LinuxBender 6y ago
  For my hobby servers, I listen on a non standard port. Not once in 20+ years has anything hit that port. Even when I've had domains / sites that ruffled feathers, no hits. It most certainly cuts out noise in logs and stops all the bots.
  - AndyMcConachie 6y ago
    I've also used a port other than 22 for sshd. And I can confirm that the past month I've been getting hit with lots of failed login attempts on ssh. My basic look at the logs shows it trying random dictionary words for usernames. And every connection attempt comes from a different IP.
    - linker3000 6y ago
      Yes, I'm seeing the same to my non-standard port and the connection attempts are from a large number of different addresses (and only usually 1 or 2 attempts from each) that Fail2Ban does not trigger.
  - Caligatio 6y ago
    A few months ago I started noticing failed login attempts on my non standard SSH port (> port 1024) so I moved it up a few port numbers. About 2-3 weeks ago, I noticed that it was getting hit again by failed login attempts. I then changed the port to the original and immediately started getting login attempts again... it kind of spooked me. I thought about using fail2ban but every login is a different IP (using my eyeballs, I didn't parse the logs).
    - LinuxBender 6y ago
      I take a different approach than fail2ban. My sftp servers use a standard port 22 and any time people try to log in, I create an account for them automatically via a cron job in the sftp-only group and a null password. The bots will spend years trying to log in repeatedly every few minutes. I have yet to see them upload anything interesting. Many years ago, bots would upload malware, then try to browse to it on port 80. But no more... These bots just want to get a shell and install malware / c&c tools. Some of them try port forwarding, but I have that restricted for the sftp users.
    - aesh2Xa1 6y ago
      You can still use fail2ban to block unique IP addresses if you use some supporting scripting. There's an example ([1]), which will check the IP addresses by country code. If they're all the same country then you can just block the whole country. You do not need to use firewalld, either, although this does. See the second link for something generic ([2]). [1] https://pagure.io/firewalld-blacklist/tree/master https://pagure.io/firewalld-blacklist/tree/master [2] https://www.linuxjournal.com/content/advanced-firewall-configurations-ipset https://www.linuxjournal.com/content/advanced-firewall-confi...

manishsharan 6y ago

Could you comment on my way of accessing my servers on AWS: My server are on VPC and no public ssh is allowed (nothing is open besides 443). When I want to login to my server , I run a script to modify security. (I have disabled ssh password logins and ssh is running on non standard port). And when I am done with task, I plug the hole in security group with another batch code. I am worried that I may be not exposing my servers with my practices.

chewmieser 6y ago
No op, but your practice is probably fine. More ideally, SSH would be locked down to your public IP address only. If you're already scripting this, you could just do a curl request to one of the many "what is my ip" services and set that instead of 0.0.0.0/0 as the security group IP address. We also use bastion hosts. They're whitelisted for key-based SSH only access for our public IP addresses. We can jump around to other servers once we login to that one, but our externally facing servers never advertise anything other their base service (:443 or whatever is running on them). I also use them with my personal servers and just leave them shut off when I'm not actively using them. This keeps costs down, but more importantly it permanently blocks off SSH access unless I'm specifically in need of it.
ajawee 6y ago
Did you try port knocking https://wiki.archlinux.org/index.php/Port_knocking https://wiki.archlinux.org/index.php/Port_knocking

dgellow 6y ago

If you do expose your SSH port, one option is to setup a firewall rule to allow your own public IP for connections to the SSH port and drop all the rest. If you're using Digital Ocean, you can set a firewall rule via the droplet web interface, that's quick to do. Otherwise just a simple iptables does the trick. Edit: if you have a static public IP, of course

gnabgib 6y ago
As long as you have a static IP that could never change, otherwise you'll deny yourself access after, for example a power outage where your router gets a new IP (or a random period of time where your ISP decides to change your IP, or you move, or you want to connect from another server). Using an alternative connection to activate the protocol is probably the only reasonable defense: * An https service that can enable a port for connections from an IP for a limited time (which has some security implications too since it would need root access, or to trigger something with root access) * Something built into KLO hardware, or software provided by your provider (including something simple like turn on the firewall a few minutes after boot, and using the reboot trigger and connecting in that brief window.. as long as you don't mind your server down - probably ok as an emergency recovery strategy) * Some form of port knocking
- framecowbird 6y ago
  I’m not sure I trust myself to set up my own bastion securely. Are there any companies that offer secure bastions as a service? What I’m envisaging is: I pay somebody, make an account on their site and add 2FA, and then they give me a server with a static IP and handle the auth. Then all I have to do is to whitelist that static IP. Ideally it would function as both an HTTP proxy and an SSH proxy; like a ‘secure web portal’
  - alexchamberlain 6y ago
    How much would you pay for that?

qeternity 6y ago

I’m curious why people say not to have ssh exposed if you only have key auth enabled. It seems to me that every single other password + some other number of protections is inherently weaker than simple old public key auth.