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.

  • MonkderVierte@lemmy.ml
    0·
    2 months ago

    Yeah, about this; any ssh server that can be run as user and doesn’t do shenanigans like switching user?

  • Punkie@lemmy.world
    0·
    2 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
      0·
      2 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?

      • josefo@leminal.space
        0·
        2 months ago

        Literally the only time I got somewhat hacked was when I left the default port of the service. Obscurity is reasonable, combined with other things like the ones mentioned here make you pretty much invulnerable to casuals. Somebody needs to target you to get anything.

      • kernelle@0d.gs
        0·
        2 months ago

        Also does anyone still port knock these days?

        Enter Masscan, probably a net negative for the internet, so use with care.

        • davidgro@lemmy.world
          0·
          2 months ago

          I didn’t see anything about port knocking there, it rather looks like it has the opposite focus - a quote from that page is “features that support widespread scanning of many machines are supported, while in-depth scanning of single machines aren’t.”

          • kernelle@0d.gs
            0·
            2 months ago

            Sure yeah it’s a discovery tool OOTB, but I’ve used it to perform specific packet sequences as well.

  • otacon239@lemmy.world
    0·
    2 months ago

    I’ve always felt that if you’re exposing an SSH or any kind of management port to the internet, you can avoid a lot of issues with a VPN. I’ve always setup a VPN. It prevents having to open up very much at all and then you can open configured web portal ports and the occasional front end protocol where needed.

    • FauxLiving@lemmy.world
      0·
      2 months ago

      Exactly.

      All of my services are ‘local’ to the VPN. Nothing happens on the LAN except for DHCP and WireGuard traffic.

      Remote access is as simple as pressing the WireGuard button.

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

      • cm0002@lemmy.world
        0·
        2 months ago

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

        Oof yea that’ll do it, your usually fine as long as you hardened enough to at least ward off the script kiddies. The people with actual real skill tend to go after…juicer targets lmao

        • Tablaste@linux.communityOPEnglish
          0·
          2 months ago

          Haha I’m pretty sure my little server was just part of the “let’s test our dumb script to see if it works. Oh wow it did what a moron!”

          Lessons learned.

      • lud@lemm.ee
        0·
        2 months ago

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

        • Voroxpete@sh.itjust.works
          0·
          2 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·
            2 months ago

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

                • designatedhacker@lemm.ee
                  0·
                  2 months ago

                  Are you talking a VPN running on the same box as the service? UDP VPN would help as another mentioned, but doesn’t really add isolation.

                  If your vpn box is standalone, then getting root is bad but just step one. They have to own the VPN to be able to even do more recon then try SSH.

                  Defense in depth. They didn’t immediately get server root and application access in one step. Now they have to connect to a patched, cert only, etc SSH server. Just looking for it could trip into some honeypot. They had to find the VPN host as well which wasn’t the same as the box they were targeting. That would shut down 99% of the automated/script kiddie shit finding the main service then scanning that IP.

                  You can’t argue that one step to own the system is more secure than two separate pieces of updated software on separate boxes.

                • DefederateLemmyMl@feddit.nl
                  0·
                  2 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.

          • josefo@leminal.space
            0·
            2 months ago

            Tailscale? Netbird? I have been using hamachi like a fucking neanderthal. I love this posts, I learn so much

      • stoy@lemmy.zip
        0·
        2 months ago

        I ran a standard raspian ssh server on my home network for several years, default user was removed and my own user was in it’s place, root was configured as standard on a raspbian, my account had a complex but fairly short password, no specific keys set.

        I saw constant attacks but to my knowledge, it was never breached.

        I removed it when I realized that my ISP might take a dim view of running a server on their home client net that they didn’t know about, especially since it showed up on Shodan…

        Don’t do what I did, secure your systems properly!

        But it was kinda cool to be able to SSH from Thailand back home to Sweden and browse my NAS, it was super slow, but damn cool…

        • troed@fedia.io
          0·
          2 months ago

          Why would a Swedish ISP care? I’ve run servers from home since I first connected up in … 1996. I’ve had a lot of different ISPs during that time, although nowadays I always choose Bahnhof because of them fighting the good fights.

          • stoy@lemmy.zip
            0·
            2 months ago

            They probably don’t, unless I got compromised and bad traffic came from their network, but I was paranoid, and wanted to avoid the possibility.

      • JustEnoughDucks@feddit.nl
        0·
        2 months ago

        Lol ssh has no reason to be port exposed in 99% of home server setups.

        VPNs are extremely easy, free, and wireguard is very performant with openvpn also fine for ssh. I have yet to see any usecase for simply port forwarding ssh in a home setup. Even a public git server can be tunneled through https.

        • MonkeMischief@lemmy.today
          0·
          2 months ago

          Yeah I’m honest with myself that I’m a security newb and don’t know how to even know what I’m vulnerable to yet. So I didn’t bother opening anything at all on my router. That sounded way too scary.

          Tailscale really is magic. I just use Cloudflare to forward a domain I own, and I can get to my services, my NextCloud, everything, from anywhere, and I’m reasonably confident I’m not exposing any doors to the innumerable botnet swarms.

          It might be a tiny bit inconvenient if I wanted to serve anything to anyone not in my Tailnet or already on my home LAN (like sending al someone a link to a NextCloud folder for instance.), but at this point, that’s quite the edge case.

          I learned to set up NGINX proxy manager for a reverse proxy though, and that’s pretty great! I still harden stuff where I can as I learn, even though I’m confident nobody’s even seeing it.

          • JustEnoughDucks@feddit.nl
            0·
            2 months ago

            Honestly, crowdsec with the nginx bouncer is all you need security-wise to start experimenting. It isn’t perfect security, but it is way more comprehensive than fail2ban for just getting started and figuring more out later.

            Here is my traefik-based crowdsec docker composer:

            services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    environment:
      GID: $PGID
    volumes:
      - $USERDIR/dockerconfig/crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml
      - $USERDIR/data/Volumes/crowdsec:/var/lib/crowdsec/data/
      - $USERDIR/dockerconfig/crowdsec:/etc/crowdsec/
      - $DOCKERDIR/traefik2/traefik.log:/var/log/traefik/traefik.log:ro
    networks:
      - web
    restart: unless-stopped

  bouncer-traefik:
    image: docker.io/fbonalair/traefik-crowdsec-bouncer:latest
    container_name: bouncer-traefik
    environment:
      CROWDSEC_BOUNCER_API_KEY: $CROWDSEC_API
      CROWDSEC_AGENT_HOST: crowdsec:8080
    networks:
      - web # same network as traefik + crowdsec
    depends_on:
      - crowdsec
    restart: unless-stopped

networks:
  web:
    external: true

            https://github.com/imthenachoman/How-To-Secure-A-Linux-Server this is a more in-depth crash course for system-level security but hasn’t been updated in a while.

        • Björn Tantau@swg-empire.de
          0·
          2 months ago

          Love Hetzner. You just give them your public key and they boot you into a rescue system from which you can install what you want how you want.

          • r00ty@kbin.life
            0·
            2 months ago

            I think their auction servers are a hidden gem. I mean the prices used to be better. Now they have some kind of systrem that resets them when they get too low. But the prices are still pretty good I think. But a year or two ago I got a pretty good deal on two decently spec’d servers.

            People are scared off by the fact you just get their rescue prompt on auctions boxes… Except their rescue prompt has a guided imaging setup tool to install pretty much every popular distro with configurable raid options etc.

            • Björn Tantau@swg-empire.de
              0·
              2 months ago

              Yeah, I basically jump from auction system to auction system every other year or so and either get a cheaper or more powerful server or both.

              • r00ty@kbin.life
                0·
                2 months ago

                I monitor for good deals. Because there’s no contract it’s easy to add one, move stuff over at your leisure and kill the old one off. It’s the better way to do it for semi serious stuff.

            • jatone@lemmy.dbzer0.comEnglish
              0·
              2 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
                0·
                2 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.

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

  • ikidd@lemmy.worldEnglish
    0·
    2 months ago

    This is like browsing /c/selfhosted as everyone portforwards every experimental piece of garbage across their router…

    • smiletolerantly@awful.systems
      0·
      2 months ago

      Meh. Each service in its isolated VM and subnet. Plus just generally a good firewall setup. Currently hosting ~10 services plubicly, never had any issue.

      • ikidd@lemmy.worldEnglish
        0·
        2 months ago

        Well, if you actually do that, bully for you, that’s how that should be done if you have to expose services.

        Everyone else there is probably DMZing their desktop from what I can tell.

    • InputZero@lemmy.world
      0·
      2 months ago

      Yeah the only thing forwarded past my router is my VPN. Assuming I did my job decently, without a valid private key it should be pretty difficult to compromise.

    • MonkeMischief@lemmy.today
      0·
      2 months ago

      portforwards every experimental piece of garbage across their router…

      Man some of those “It’s so E-Z bro” YouTubers are WAY too cavalier about doing this.

  • mlg@lemmy.worldEnglish
    0·
    2 months ago

    Lol you can actually demo a github compromise in real time to an audience.

    Make a repo with an API key, publish it, and literally just watch as it takes only a few minutes before a script logs in.

  • Admiral Patrick@dubvee.orgEnglish
    0·
    2 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.

      • corsicanguppy@lemmy.caEnglish
        0·
        2 months ago

        Please examine where devops allowed non-system people to be the last word on altering systems. This is a risk that needs block-letter indemnification or correction.

        It’s not that devops made ya lazy. I’ve been doing devops since before they coined the term, and it’s a constant effort to remind people that it doesn’t magically make things safe, but keeping it safe is still the way.

        • Tablaste@linux.communityOPEnglish
          0·
          2 months ago

          Ah not to discount devops, I mean that in a good way.

          Devops made me lazy in that for the past decade, I focus on just everything inside the code base.

          I literally push code into a magic black box that then triggers a rube goldberg of events. Servers get instanced. Configs just get magically set up. It’s beautiful. Just years of smart people who make it so easy that I never have to think about it.

          Since I can’t pay my devops team to come to my house, I get to figure it all out!

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

      We have it at my company its just a very small group and we have to manually enable it for production and its through tools like teleport. Staging and the like its free game there for them for debugging, same infra through. Gives us best of all worlds

  • kibiz0r@midwest.socialEnglish
    0·
    2 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.

    • pageflight@lemmy.worldEnglish
      0·
      2 months ago

      Good point about a default deny approach to users and ssh, so random services don’t add insecure logins.

    • DefederateLemmyMl@feddit.nl
      0·
      2 months ago

      Do not allow username/password login for ssh

      This is disabled by default for the root user.

      $ man sshd_config

...
       PermitRootLogin
               Specifies whether root  can  log  in  using  ssh(1).   The  argument  must  be  yes,  prohibit-password,
               forced-commands-only, or no.  The default is prohibit-password.
...
    • LordCrom@lemmy.world
      0·
      2 months ago

      If it’s public facing, how about dont turn on ssh to the public, open it to select ips or ranges. Use a non standard port, use a cert or even a radius with TOTP like privacyIdea. How about a port knocker to open the non standard port as well. Autoban to lock out source ips.

      That’s just off the top of my head.

      There’s a lot you can do to harden a host.

      • Faresh@lemmy.mlEnglish
        0·
        2 months ago

        dont turn on ssh to the public, open it to select ips or ranges

        What if you don’t have a static IP, do you ask your ISP in what range their public addresses fall?

  • DavidGA@lemmy.world
    0·
    2 months ago

    Although disabling the root user is a good part of security, leaving it enabled should not alone cause you to get compromised. If it did, you were either running a very old version of OpenSSH with a known flaw, or, your chosen root password was very simple.

      • DavidGA@lemmy.world
        0·
        2 months ago

        It should be a serious red flag that your VPS host is generating root passwords simple enough to get quickly hacked.

        • Tablaste@linux.communityOPEnglish
          0·
          2 months ago

          I’m pretty sure they assumed if you bought their service, you have the competency to properly set it up.

          And I proved them wrong.

  • ramius345@sh.itjust.works
    0·
    2 months ago

    You should turn off ssh password logins on external facing servers at a minimum. Only use ssh keys, install fail2ban, disable ssh root logins, and make sure you have a firewall limiting ports to ssh and https.

    This will catch most scripted login attempts.

    If you want something more advanced, look into https://en.m.wikipedia.org/wiki/Security_Technical_Implementation_Guide and try to find an ansible playbook to apply them.

    • Oisteink@feddit.nl
      0·
      2 months ago

      Just turn off password logins from anything but console. For all users. No matter where it runs.

      It becomes second to nature pretty fast, but you should have a system for storing / rotating keys.

      • Refurbished Refurbisher@lemmy.sdf.org
        0·
        2 months ago

        How do I whitelist password logins? I only disabled password logins in SSHd and set it to only use a key.

        I also like to disable root login by setting its default shell to nologin, that way, it’s only accessible via sudo or doas. I think there’s a better way of doing it, which is how Debian does it by default when not setting a root password, but I’m not sure how to configure that manually, or even what they do.

        • Oisteink@feddit.nl
          0·
          2 months ago

          Right - so console/tty login is restricted by pam and its settings. So disabling ssh root logins means you can still log in as root there.

          To lock root you can use passwd -l

          If locking root I would keep root shell so i could sudo to root.

          So my normal setup would be to create my admin user with sudo rights, set «PasswordAuthentication no» in sshd config and lock root with «sudo passwd -l root» Remember to add a pubkey to admin users authorizedkeys, and give it a secure but typable password

          My root is now only available through sudo, and i can use password on console. Instead of locking root you can give it secure typable password. This way root can log in from console so you dont need sudo for root access from console.

          It boils down to what you like and what risks you take compared to usable system. You can always recover a locked root account if you have access to single-user-mode or a live cd . Disk encryption makes livecd a difficult option.

        • Oisteink@feddit.nl
          0·
          2 months ago

          To whitelist password logins in ssh you can match username and give them yes after you set no (for all). But i see no reason for password logons in ssh, console is safe enough (for me).

    • smiletolerantly@awful.systems
      0·
      2 months ago

      Did all that, minus the no ssh root login (only key, obviously) plus one failed attempt, fail2ban permaban.

      Have not had any issues, ever

  • communism@lemmy.ml
    0·
    2 months ago

    How are people’s servers getting compromised? I’m no security expert (I’ve never worked in tech at all) and have a public VPS, never been compromised. Mainly just use SSH keys not passwords, I don’t do anything too crazy. Like if you have open SSH on port 22 with root login enabled and your root password is password123 then maybe but I’m surprised I’ve never been pwned if it’s so easy to get got…

    • pageflight@lemmy.worldEnglish
      0·
      2 months ago

      The one db I saw compromised at a previous employer was an AWS RDS with public Internet access open and default admin username/password. Luckily it was just full of test data, so when we noticed its contents had been replaced with a ransom message we just deleted the instance.

    • cmnybo@discuss.tchncs.deEnglish
      0·
      2 months ago

      By allowing password login and using weak passwords or by reusing passwords that have been involved in a data breach somewhere.

      • communism@lemmy.ml
        0·
        2 months ago

        That makes sense. It feels a bit mad that the difference between getting pwned super easy vs not is something simple like that. But also reassuring to know, cause I was wondering how I heard about so many hobbyist home labs etc getting compromised when it’d be pretty hard to obtain a reasonably secured private key (ie not uploaded onto the cloud or anything, not stored on an unencrypted drive that other people can easily access, etc). But if it’s just password logins that makes more sense.

  • Rentlar@lemmy.ca
    0·
    2 months ago

    I do worry about putting up public servers that other people might rely on because there’s something I might not realize making it vulnerable.

    So far I have pubkey root login only on the VPSs I’m messing around with, but my ol’ reliable private key from 6 years ago might be beginning to fall behind on encryption standards.

  • DaCrazyJamez@sh.itjust.works
    0·
    2 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