Background: 15 years of experience in software and apparently spoiled because it was already set up correctly.

Been practicing doing my own servers, published a test site and 24 hours later, root was compromised.

Rolled back to the backup before I made it public and now I have a security checklist.

  • Punkie@lemmy.world
    2·
    3 months ago

    Basic setup for me is scripted on a new system. In regards to ssh, I make sure:

    • Root account is disabled, sudo only
    • ssh only by keys
    • sshd blocks all users but a few, via AllowUsers
    • All ‘default usernames’ are removed, like ec2-user or ubuntu for AWS ec2 systems
    • The default ssh port moved if ssh has to be exposed to the Internet. No, this doesn’t make it “more secure” but damn, it reduces the script denials in my system logs, fight me.
    • Services are only allowed connections by an allow list of IPs or subnets. Internal, when possible.

    My systems are not “unhackable” but not low-hanging fruit, either. I assume everything I have out there can be hacked by someone SUPER determined, and have a vector of protection to mitigate backwash in case they gain full access.

    • feddylemmy@lemmy.world
      1·
      3 months ago
      • The default ssh port moved if ssh has to be exposed to the Internet. No, this doesn’t make it “more secure” but damn, it reduces the script denials in my system logs, fight me.

      Gosh I get unreasonably frustrated when someone says yeah but that’s just security through obscurity. Like yeah, we all know what nmap is, a persistent threat will just look at all 65535 and figure out where ssh is listening… But if you change your threat model and talk about bots? Logs are much cleaner and moving ports gets rid of a lot of traffic. Obviously so does enabling keys only.

      Also does anyone still port knock these days?

  • Hozerkiller@lemmy.caEnglish
    1·
    3 months ago

    I’ve gotta say this post made me appreciate switching to lemmy. This post is actually helpful for the poor sap that didn’t know better, instead of pure salt like another site I won’t mention.

  • kibiz0r@midwest.socialEnglish
    1·
    3 months ago

    One time, I didn’t realize I had allowed all users to log in via ssh, and I had a user “steam” whose password was just “steam”.

    “Hey, why is this Valheim server running like shit?”

    “Wtf is xrx?”

    “Oh, it looks like it’s mining crypto. Cool. Welp, gotta nuke this whole box now.”

    So anyway, now I use NixOS.

    • Tablaste@linux.communityOPEnglish
      0·
      3 months ago

      I published it to the internet and the next day, I couldn’t ssh into the server anymore with my user account and something was off.

      Tried root + password, also failed.

      Immediately facepalmed because the password was the generic 8 characters and there was no fail2ban to stop guessing.

            • jatone@lemmy.dbzer0.comEnglish
              0·
              3 months ago

              we’re probably talking about different things. virtually no distribution comes with root access with a password. you have to explicitly give the root user a password. without a password no amount of brute force sshing root will work. I’m not saying the root user is entirely disabled. so either the service OP is building on is basically a goldmine for compromised machines or OP literally shot themselves in the root by giving root a password manually. something you should never do.

              • satans_methpipe@lemmy.world
                01·
                3 months ago

                Yeah I was confused about the comment chain. I was thinking terminal login vs ssh. You’re right in my experience…root ssh requires user intervention for RHEL and friends and arch and debian.

                Side note: did you mean to say “shot themselves in the root”? I love it either way.

              • satans_methpipe@lemmy.world
                01·
                3 months ago

                Ah fair enough, I know that’s the basis of a ton of distros. I lean towards RHEL so I’m not super fluent there.

      • lud@lemm.ee
        0·
        3 months ago

        Don’t use passwords for ssh. Use keys and disable password authentication.

        • Voroxpete@sh.itjust.works
          0·
          3 months ago

          More importantly, don’t open up SSH to public access. Use a VPN connection to the server. This is really easy to do with Netbird, Tailscale, etc. You should only ever be able to connect to SSH privately, never over the public net.

          • troed@fedia.io
            0·
            3 months ago

            It’s perfectly safe to run SSH on port 22 towards the open Internet with public key authentication only.

                • DefederateLemmyMl@feddit.nl
                  0·
                  3 months ago

                  A VPN like Wireguard can run over UDP on a random port which is nearly impossible to discover for an attacker. Unlike sshd, it won’t even show up in a portscan.

                  This was a specific design goal of Wireguard by the way (see “5.1 Silence is a virtue” here https://www.wireguard.com/papers/wireguard.pdf)

                  It also acts as a catch-all for all your services, so instead of worrying about the security of all the different sshds or other services you may have exposed, you just have to keep your vpn up to date.

  • gerryflap@feddit.nl
    0·
    3 months ago

    I’ve been quite stupid with this but never really had issues. Ever since I changed the open ssh port from 22 to something else, my server is basically ignored by botnets. These days I obviously also have some other tricks like fail2ban, but it was funny how effective that was.

    • surph_ninja@lemmy.world
      01·
      3 months ago

      We’re not really supposed to expose the ssh port to the internet at all. Better to hide it behind a vpn.

      But it’s too damn convenient for so many use cases. Fuck it. Fail2Ban works fine.

      You can also set up an ssh tarpit on port 22, which will tie up the bot’s resources and get them stuck in a loop for a while. But I didn’t think it was worth attracting extra attention from the bot admins to satisfy my pettiness.

  • DaCrazyJamez@sh.itjust.works
    0·
    3 months ago

    As a linux n00b who just recently took the plunge and set up a public site (tho really just for my own / selfhosting),

    Can anyone recommend a good guide or starting place for how to harden the setup? Im running mint on my former gaming rig, site is set up LAMP

  • satans_methpipe@lemmy.world
    11·
    3 months ago

    On a new linux install or image I will always:

    • Make new users(s)
    • Setup new user to sudo
    • Change ssh port
    • Change new user to authenticate ssh via key+password
    • Disable root ssh login
    • stebator@lemmy.world
      1·
      3 months ago
      • Setup new user to sudo

      I hope it is not a passwordless sudo, it is basically the same as root.

    • njordomir@lemmy.world
      1·
      3 months ago

      That’s more or less the advice I’ve gotten as well. I’ve also read good things about fail2ban which tries to ban sources of repeated authentication failures to prevent brute force password attempts. I’ve used it, but the only person who has managed to get banned is myself! I did get back in after the delay, but I’m happy to know it works.

  • Fair Fairy@thelemmy.club
    01·
    3 months ago

    I’m confused. I never disable root user and never got hacked.

    Is the issue that the app is coded in a shitty way maybe ?