5 ms·

A big issue how? If you block password auth, ssh scanning is a nonissue.

by psanford 3y ago

aunderscored 3y ago
Unless an attack on the sshd is employed. Which is also possible
- psanford 3y ago
  Pre-auth sshd vulnerabilities are extremely rare and are not what ssh scanners are looking for.
bradknowles 3y ago
DDoS attack on your sshd?
- indigodaddy 3y ago
  One option could be to lock the port down to only your jump/bastion server source IP.
  - bradknowles 3y ago
    That fails to when you lose that IP address, or you lose that server.
    - indigodaddy 3y ago
      I suppose if you don’t have console access, sure. But inconvenient at worst imv.
      - bradknowles 3y ago
        If you have a way around that bastion server, then at least you've got a backup. But then you also have to worry about the security of that backup.
    - PLG88 3y ago
      Yes, better to make your bastion 'dark' without being tied to an IP address. This is how we do it at my company with the open source tech we have developed - https://netfoundry.io/bastion-dark-mode/ https://netfoundry.io/bastion-dark-mode/
- psanford 3y ago
  Are we just speculating? SSH scanners are not sources of DDoS. Large companies have ssh bastions on the internet and do not worry about ssh DDoS. Its not really a thing that happens. You don't need to freak out if you see a bunch of failed ssh auth attempts in your logs. Just turn off password based authentication and rest easy.
  - koito17 3y ago
    Agreed. Another thing you can do to drastically reduce the amount of bots hitting your sshd is to listen on a port that is not 22. In my experience, this reduces ~90% of the clutter in my logs. (Disclaimer: this may not be the case for you or anyone else)
    - TacticalCoder 3y ago
      Just to reduce the crap in the log and also because I can, I have my SSH servers (not saying what their IPs are) using a very effective measure: traffic is dropped from the entire world, except for the CIDR blocks, which I put in ipsets, of the five ISPs over three countries I could reasonably be in when I need to access the SSH servers. And if I'm really, say, in China or Russia an really need to access one of my servers through SSH, I can use a jump host in one of the three countries that I allow. So effectively: DROPping traffic from 98% of the planet. Boom.
      - bradknowles 3y ago
        Deny by default, allow only those sources that are considered trustworthy. And frequently re-evaluate who and what should be considered trustworthy.
        aborsy 3y ago
        Or close the ports, and install an agent that phones out such as Tailscale or twingate.
        3y ago
p_l 3y ago
Until a junior from another project enables password-based root logins because Juniper team that was on site to help them install beta-version of some software they collaborated on asked them to. Few days after they asked to redirect an entire subnet to their rack. And yes, you still need to remember to close password logins or at least pick serious password if you need them. Helps to have no root login over SSH and normal users that aren't defaults for some distro...
- psanford 3y ago
  It sounds like your organization has a bunch of problems. I'm sorry to hear that. But I don't think you can really blame those on ssh. There are plenty of organizations and individuals that can competently run ssh directly on the internet (on port 22) with zero risk to "ssh scanners."
  - p_l 3y ago
    I am not blaming this on SSH (also, no longer in that org for many years). I am just pointing out (also in few other, off-site discussions), that one should not even think of exposing a port before finishing locking it down. Because sometimes people forget, even experienced people (including myself), and sometimes that's enough (I think someone few weeks ago submitted a story which involved getting pwned through accidentally exposed postgres?). And there's enough people who get it wrong for various reasons that lowest of low script kiddies can profit buying ready-made extortion kits on chinese forums, getting a single VM with windows to run them, and extort money from gambling/gameserver sites. Not to mention all the fun stuff if you search for open VNC/RDP.
  - sumtechguy 3y ago
    Your security is only as good as the people running your system. Unfortunately not everyone has teams of the best of the best. Sometimes you get a the jr dev guy assigned to things. They do not know any better and just do as they are told. It is the deputized sheriff problem.
    - p_l 3y ago
yorwba 3y ago
Yes, if you follow the advice of "not exposing anything unless you deployed the security for it" of course you block password auth before exposing SSH to the internet. Not everyone is following that advice. Just last week I taught a friend about using tmux for long-running sessions on their lab's GPU server, and during the conversation it transpired that everyone was always sshing in using the root password. Of course plugging that hole will require everyone from the CTO downward to learn about SSH keys and start using them, so I doubt anything will change without a serious incident.
- op00to 3y ago
  > Of course plugging that hole will require everyone from the CTO downward to learn about SSH keys and start using them I had a similar issue 15 years ago, and tied the Linux boxes into Active Directory and authenticated via Kerberos. Worked nice, no SSH keys needed!

A big issue how? If you block password auth, ssh scanning is a nonissue.

aunderscored 3y ago

Unless an attack on the sshd is employed. Which is also possible

psanford 3y ago
Pre-auth sshd vulnerabilities are extremely rare and are not what ssh scanners are looking for.

bradknowles 3y ago

DDoS attack on your sshd?

indigodaddy 3y ago
One option could be to lock the port down to only your jump/bastion server source IP.
- bradknowles 3y ago
  That fails to when you lose that IP address, or you lose that server.
  - indigodaddy 3y ago
    I suppose if you don’t have console access, sure. But inconvenient at worst imv.
    - bradknowles 3y ago
      If you have a way around that bastion server, then at least you've got a backup. But then you also have to worry about the security of that backup.
  - PLG88 3y ago
    Yes, better to make your bastion 'dark' without being tied to an IP address. This is how we do it at my company with the open source tech we have developed - https://netfoundry.io/bastion-dark-mode/ https://netfoundry.io/bastion-dark-mode/
psanford 3y ago
Are we just speculating? SSH scanners are not sources of DDoS. Large companies have ssh bastions on the internet and do not worry about ssh DDoS. Its not really a thing that happens. You don't need to freak out if you see a bunch of failed ssh auth attempts in your logs. Just turn off password based authentication and rest easy.
- koito17 3y ago
  Agreed. Another thing you can do to drastically reduce the amount of bots hitting your sshd is to listen on a port that is not 22. In my experience, this reduces ~90% of the clutter in my logs. (Disclaimer: this may not be the case for you or anyone else)
  - TacticalCoder 3y ago
    Just to reduce the crap in the log and also because I can, I have my SSH servers (not saying what their IPs are) using a very effective measure: traffic is dropped from the entire world, except for the CIDR blocks, which I put in ipsets, of the five ISPs over three countries I could reasonably be in when I need to access the SSH servers. And if I'm really, say, in China or Russia an really need to access one of my servers through SSH, I can use a jump host in one of the three countries that I allow. So effectively: DROPping traffic from 98% of the planet. Boom.
    - bradknowles 3y ago
      Deny by default, allow only those sources that are considered trustworthy. And frequently re-evaluate who and what should be considered trustworthy.
      - aborsy 3y ago
        Or close the ports, and install an agent that phones out such as Tailscale or twingate.
        3y ago

p_l 3y ago

Until a junior from another project enables password-based root logins because Juniper team that was on site to help them install beta-version of some software they collaborated on asked them to. Few days after they asked to redirect an entire subnet to their rack. And yes, you still need to remember to close password logins or at least pick serious password if you need them. Helps to have no root login over SSH and normal users that aren't defaults for some distro...

psanford 3y ago
It sounds like your organization has a bunch of problems. I'm sorry to hear that. But I don't think you can really blame those on ssh. There are plenty of organizations and individuals that can competently run ssh directly on the internet (on port 22) with zero risk to "ssh scanners."
- p_l 3y ago
  I am not blaming this on SSH (also, no longer in that org for many years). I am just pointing out (also in few other, off-site discussions), that one should not even think of exposing a port before finishing locking it down. Because sometimes people forget, even experienced people (including myself), and sometimes that's enough (I think someone few weeks ago submitted a story which involved getting pwned through accidentally exposed postgres?). And there's enough people who get it wrong for various reasons that lowest of low script kiddies can profit buying ready-made extortion kits on chinese forums, getting a single VM with windows to run them, and extort money from gambling/gameserver sites. Not to mention all the fun stuff if you search for open VNC/RDP.
- sumtechguy 3y ago
  Your security is only as good as the people running your system. Unfortunately not everyone has teams of the best of the best. Sometimes you get a the jr dev guy assigned to things. They do not know any better and just do as they are told. It is the deputized sheriff problem.
  - p_l 3y ago

yorwba 3y ago

Yes, if you follow the advice of "not exposing anything unless you deployed the security for it" of course you block password auth before exposing SSH to the internet. Not everyone is following that advice. Just last week I taught a friend about using tmux for long-running sessions on their lab's GPU server, and during the conversation it transpired that everyone was always sshing in using the root password. Of course plugging that hole will require everyone from the CTO downward to learn about SSH keys and start using them, so I doubt anything will change without a serious incident.

op00to 3y ago
> Of course plugging that hole will require everyone from the CTO downward to learn about SSH keys and start using them I had a similar issue 15 years ago, and tied the Linux boxes into Active Directory and authenticated via Kerberos. Worked nice, no SSH keys needed!