Persistant SSH Threats?

For the past few months my server has seen an SSH connection attempt about once a minute. There is no reason to SSH to my server as there is nothing on it except at static website.

The SSH connections are coming from seemingly random IP addresses, rarely from the same one twice.

Is anyone else seeing such connection patterns?

14 points | by daly 1552 days ago

13 comments

  • SignalsFromBob 1552 days ago
    Yes, it's normal. Just people scanning for SSH ports to attack.

    What I did was take the IANA IPv4 address space list[1] and add firewall rules to drop packets to port 22 coming from /8's that I would never connect from. I'm in the US, so it made sense for me to drop connections from subnets assigned to RIPE, APNIC, etc. It didn't eliminate the problem, but it reduced the connection attempts considerably.

    1. https://www.iana.org/assignments/ipv4-address-space/ipv4-add...

  • Snawoot 1552 days ago
    Yeah, it's common. I hide my critical services with pyknock[1] - it's a modern successor of port-knocking implementation, based on HMAC signatures rather than on simple port sequence.

    [1] - https://pypi.org/project/pyknock/

  • slap_shot 1552 days ago
    Related question that has crossed my mind: what is this risk exposure of a linux server that is accessible via the internet that has port 22 enabled, and only has users with --disabled-password set (requiring ssh connection)?

    As a follow up, what is increased benefit (if any) if port 22 is only accessible by a certain IP address (e.g. my home address)?

    [-]
    • MrLabCoat 1552 days ago
      I do something similar but added a knock daemon and changed the default ssh port 22 to something else.

      So far I haven’t had any issues, fail2ban works, and it seems safe.

      I do have my home IP added to the whitelist and others set to drop.

      I was told in a networking class this is the second best way to protect ssh other than not running ssh.

      Any thoughts on this setup as well? Maybe oversights that I’m not seeing?

    • jmngomes 1552 days ago
      It's hard to quantify that "risk" in simple terms, but --disabled-password is a basic must as it seriously mitigates popular attack vectors like brute forcing.

      Filtering ssh connections at firewall level helps, and certainly reduces log entries for port scans and can halt less sophisticated attackers, but it doesn't mitigate attack vectors like a DDoS or a well funded actor.

  • lbonanomi 1552 days ago
    At least this can make for very exciting wallpapers?

    https://dev.to/lbonanomi/hello-worm-mapping-ssh-probes-with-...

  • m-p-3 1552 days ago
    Totally normal, make sure to use a secure mean of access like pubkeys, turn off normal password authentication, and optionally put fail2ban and totp[1]

    [1]: https://www.digitalocean.com/community/tutorials/how-to-set-...

    IMPORTANT: If you do setup totp, make sure your server is actually syncing its clock with NTP, because if there is a significant time-drift you might be locked out from accessing SSH remotely.

  • codegeek 1552 days ago
    Welcome to the world of servers. There are these bots/scripts running all over the internet that are scanning for stuff like this and always trying to brute force into servers they can find and get in. The good news is that this is not only targeted at you. The bad news is that you cannot do much about them except ensuring that your servers are hardened and have the right security setup. There are tools like fail2ban etc. that can block those IP addresses but again, you cannot really stop them as you will get these hits from random IPs all over the world.
  • icedchai 1552 days ago
    Yes, for decades. Move SSH off of port 22 and you’ll see far fewer attempts.
    [-]
    • kees99 1552 days ago
      No idea why you are being downvoted, this is a solid advice. Masscan [1] claims to scan whole IPv4 Internet for a single port in 5 minutes. Moving to a random high port would increase scan time 64000-fold, to 7 months.

      You'd still be advised to disable password-based auth and/or configure fail2ban, though.

      [1] https://github.com/robertdavidgraham/masscan

      [-]
      • parliament32 1552 days ago
        It's a bad idea, privileged ports are a thing for a reason.

        https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....

        https://adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-ano...

        [-]
        • kees99 1552 days ago
          You have a point there, but it's far, far from being so clear-cut.

          Privileged ports is a measure to guarantee that daemon listening there was started with root privileges. Which is a useful guarantee on a shared server, less so on a single-purpose or personal server.

          Plus, if you have an sshd started at boot, and already listening on a pre-defined high port, there is very little chance another program could bind to the same port, save crashing and racing the daemon.

          Finally, in ssh protocol, server authenticates itself to the client, so even if by some trickery a bogus ssh server would bind to the same port, it will either need to access /etc/ssh/ssh_host_*_key, which are enforced to be root-readable only, or risk being trivially detected by a client comparing presented public key to that saved from last login in the ~/.ssh/known_hosts.

          There are also some DPI firewalls, or just port-based firewall that can block ssh traffic on a non-standard port, but assuming we are talking about your own server, that should be easy to rectify too.

          [-]
          • parliament32 1552 days ago
            You understand the risks, but it's also a bad idea because it's effectively security-by-obscurity. I can port scan your host and find your SSH port in just a few minutes. Port knocking is better but still not foolproof unless you're doing some crazy 12-port sequence... And not having hordes of chinese bots hammering on our SSH port makes us slip up and do silly things like leaving password auth enabled.

            There's no harm in having connection attempts on your ssh port. Changing your port will not make you more secure against a dedicated attacker, and you just make things harder for yourself (and marginally less secure, for the reasons you mentioned) with no real benefit.

            And like I mentioned in the other comment, just use SSH keys and disable password auth. It's not hard, and it's all it takes to thwart every bot that hits you on port 22. If you want to be more hardcore you can run fail2ban or firewall the port down to your country or whatever.

            It's the equivalent of "I connect to my host via IP address instead of having DNS records because it'll be harder for them to find!".

            [-]
            • demosthenex 1552 days ago
              Obscurity is just one more security tactic. Security by obscurity as the only defense is bad. As an additional layer to many defenses it is a sound choice.

              You still paint camoflage on a tank.

            • icedchai 1552 days ago
              There's no harm in those attempts, but they are annoying. Even with fail2ban there is extra stuff running, unnecessary connections, junk in your logs. The benefits of moving SSH off 22 for your personal, internet facing servers outweigh the negatives.
    • parliament32 1552 days ago
      SSH is less secure on an unprivileged port, this is a bad move. Use ssh keys and fail2ban, and filter your logs if you care about the attempts that much. This is like complaining that you're seeing web scrapers in your http access log: it's just background noise, it doesn't matter.
      [-]
  • jmngomes 1552 days ago
    That's normal, it's often referred to as background noise: https://en.wikipedia.org/wiki/Internet_background_noise

    It stems from automated port scans sweeping IP ranges looking for vulnerable/exploitable systems.

    A simple way to address it is to use something like fail2ban to ban repeat offenders. Blacklist services like abuseipdb.com may help further, but ban with caution.

  • actionowl 1549 days ago
    Blacklistd (available natively on FreeBSD and NetBSD) are a good defense against these attacks. If you're using Linux you'll have to use fail2ban or something that scans log files for a similar. Using public key authentication and disabling password authentication is also a good idea.
  • em10fan 1552 days ago
    Yes, this is normal.

    Any server exposed on the internet will be probed constantly by botnets.

  • ihalip 1552 days ago
    I notice the same thing: connections from random combinations of IPs/usernames.

    Sadly, that comes with having a public accessible server: people wanting to hack their way in.

  • daly 1552 days ago
    I have SSH disabled.
    [-]
    • Snawoot 1552 days ago
      Are you Telnet or RDP person?
  • SlipperySlope 1552 days ago
    With X.509 certificates (publickey) and no passwords enabled, my new AWS server got lots of failed entries in /var/log/auth.log.

    Following best practices, I set my sshd_config to specify another listening port - not 22.

    My log is now clear of failed attempts.