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
    1·
    7 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.

    • Tablaste@linux.communityOPEnglish
      0·
      7 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.

              • steventhedev@lemmy.world
                0·
                7 months ago

                Many cloud providers (the cheap ones in particular) will put patches on top of the base distro, so sometimes root always gets a password. Even for Ubuntu.

                There are ways around this, like proper cloud-init support, but not exactly beginner friendly.

              • satans_methpipe@lemmy.world
                0·
                7 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.

  • Admiral Patrick@dubvee.orgEnglish
    0·
    7 months ago

    And this is why every time a developer asks me for shell access to any of the deployment servers, I flat out deny the request.

    Good on you for learning from your mistakes, but a perfect example for why I only let sysadmins into the systems.