In the past two weeks I set up a new VPS, and I run a small experiment. I share the results for those who are curious.

Consider that this is a backup server only, meaning that there is no outgoing traffic unless a backup is actually to be recovered, or as we will see, because of sshd.

I initially left the standard “port 22 open to the world” for 4-5 days, I then moved sshd to a different port (still open to the whole world), and finally I closed everything and turned on tailscale. You find a visualization of the resulting egress traffic in the image. Different colors are different areas of the world. Ignore the orange spikes which were my own ssh connections to set up stuff.

Main points:

  • there were about 10 Mb of egress per day due just to sshd answering to scanners. Not to mention the cluttering of access logs.

  • moving to a non standard port is reasonably sufficient to avoid traffic and log cluttering even without IP restrictions

  • Tailscale causes a bit of traffic, negligible of course, but continuous.

  • James@lemmy.ca
    link
    fedilink
    English
    arrow-up
    53
    ·
    2 years ago

    Public key auth, and fail2ban on an extremely strict mode with scaling bantime works well enough for me to leave 22 open.

    Fail2ban will ban people for even checking if the port is open.

    • devtimi@lemmy.world
      link
      fedilink
      English
      arrow-up
      12
      ·
      2 years ago

      Honest question, is there a good default config available somewhere or is what apt install fail2ban does good to go? All the tutorials I’ve found have left it to the reader to configure their own rules.

      • Sleepkever@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 years ago

        Honestly the default config is good enough to prevent brute force attacks on ssh. Just installing it and forgetting about it is a definite option.

        I think the default block time is 10 minutes after 5 failed login attempts in 10 minutes. Not enough to ever be in your way but enough to fustrate any automated attacks. And it’s got default config for a ton of services by default. Check your /etc/fail2ban/jail.conf for an overview.

        I see that a recidive filter that bans repeat offenders for a week after 10 fail2ban bans in one day is also default now. So I’d say that the results are perfect unless you have some exotic or own service you need fail2ban for.

    • JubilantJaguar@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      5
      ·
      2 years ago

      If Fail2Ban is so important, why the h*** does it not come installed and enabled as standard?!

      Security is the number-1 priority for any OS, and yet stock SSHD apparently does not have Fail2Ban-level security built in. My conclusion is that Fail2Ban cannot therefore be that vital.

  • u_tamtam@programming.dev
    link
    fedilink
    English
    arrow-up
    29
    ·
    2 years ago

    Or, you know, just use key auth only and fail2ban. Putting sshd behind another port only buys you a little time.

    • nomadjoanne@lemmy.world
      link
      fedilink
      English
      arrow-up
      14
      ·
      2 years ago

      Yeah but the majority of bots out there are going after easy prey. Honestly, if you use public key authentication with ssh you should be fine, even if it is on port 22. But it does of course clog up access logs.

      • marcos@lemmy.world
        link
        fedilink
        English
        arrow-up
        7
        ·
        2 years ago

        The majority of bots out there are stopped by just using a hard to guess password. It’s not them that you should be worried about.

    • MangoPenguin@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      0
      ·
      2 years ago

      I’ve noticed that a lot of the scans these days almost always switch IPs after 2-3 attempts, making IP blocking a lot more difficult.

      • u_tamtam@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        2 years ago

        Let’s say that you could ban for an indefinitely large amount of time after a single failure to authenticate, that’d make them run out of IPs much quicker than you’d run out of CPU/BW, so I don’t really see the issue

          • u_tamtam@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            2 years ago

            True, but very unlikely (once your ssh client is configured once and for all), and in that event you can always switch connection (use a data network, proxy, vpn, hop from another server you have ssh access, etc)

  • Feathercrown@lemmy.world
    link
    fedilink
    English
    arrow-up
    22
    ·
    2 years ago

    I opened a raw text channel on the Telnet port for a personal game engine project and someone tried to enable commands and do some shady stuff. Unfortunately for them, that’s not a valid chess move.

  • spagnod@lemmy.world
    link
    fedilink
    English
    arrow-up
    20
    ·
    2 years ago

    Just do it properly and configure sshd securely. When you have a machine exposed to the internet, you should expect it to be attacked. If you really want to give the finger to bots, run endlessh on port 22 and keep sshd on a non-standard port. Stay safe.

  • elscallr@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    2 years ago

    If you do want to open 22, and there are plenty of good reasons to want to, just implement something called port knocking and you can do it safely.

    Note with this you still need good authentication. That means no passwords, key based auth only.

  • MoshpitDaddy@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 years ago

    I don’t know if it was mentioned already but how could I check if my ports are under “attack”? OPs graphic looks really nice

    • aesir@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 years ago

      Hi, to check attacks you should look at the logs. In this case auth.log. Being attacked on port 22 is not surprising neither really troublesome if you connect via key pair.

      My graph was showing egress traffic, on any kind of server the traffic due to these attacks would have been invisible but on a backup server which has (hopefully) only ingress you can clearly see the volume of connections from attackers from bytes teansmitted

  • SheeEttin@lemmy.worldBanned
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    2 years ago

    The best reason is reducing attack surface. It’s such an easy thing to do. I don’t know why people still expose services they don’t need to.

    • lungdart@lemmy.ca
      link
      fedilink
      English
      arrow-up
      16
      ·
      2 years ago

      Moving the port doesn’t reduce attack surface. It’s the same amount of surface.

      Tailscale is a bit controversial because it requires a 3rd party to validate connections, a 3rd party that is a large target for threat actors, and is reliant on profitability to stay online.

      I would recommend a client VPN like wireguard, or SSH being validated using signed keys against a certificate authority your control, with fail2ban.

  • ShortN0te@lemmy.ml
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 years ago

    And yet it is more likely that tailscale get owned since the reward is much higher. I take my chances with my secured openssh server at port 22 vs a 3rd party company who controlls the access.

        • Rearsays@lemmy.ml
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 years ago

          Wireguard doesn’t respond but I agree open-ssh is pretty solid. Can’t speak for any of the other ssh implementations. It can also be poorly configured. Like you could use a password

          • droans@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            arrow-down
            1
            ·
            2 years ago

            The benefit of Wireguard is that if you screw it up, it just won’t work. It basically enforces security.

            Well, unless you tried to use the original PFSense module.

  • notabot@lemm.ee
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 years ago

    You really shouldn’t have something kike SSHD open to the world, that’s just an unnecessary atrack surface. Instead, run a VPN on the server (or even one for a network if you have several servers on one subnet), connect to that then ssh to your server. The advantage is that a well setup VPN simply won’t respond to an invalid connection, and to an attacker, looks just like the firewall dropping the packet. Wireguard is good for this, and easy to configure. OpenVPN is pretty solid too.

  • Entheon@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 years ago

    What software did you use you monitor this? I am newish to self hosting and would like to secure my connection better.

    • aesir@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      2 years ago

      Sorry, it’s the built-in console of Google Cloud. But there are so many monitoring solution around that you can probably find one of your liking. Look on awesome-selfhosted for “monitoring”

  • solberg@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    2 years ago

    Is public key authentication not good enough? Tailscale is cool but can be tedious if you also use other VPNs