I didn't know you were supposed to disable root user...
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.
You're viewing a single thread.
Interesting. Do you know how it got compromised?
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.
Don't use passwords for ssh. Use keys and disable password authentication.
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.
It's perfectly safe to run SSH on port 22 towards the open Internet with public key authentication only.
https://nvd.nist.gov/vuln/detail/cve-2024-6409 RCE as root without authentication via Open SSH. If they've got a connection, that's more than nothing and sometimes it's enough.
That attack vector is exactly the same towards a VPN.
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.
Yeah I don't do security via obscurity :D I agree you need to keep your Internet facing services up to date.
(No need to educate me on Wireguard, I use it. My day job is slightly relevant to the discussion)
Yeah I don’t do security via obscurity
Another one who misunderstands that phrase... Yes, obscurity shouldn't be your only line of defense, but limiting discoverability of your systems should be an integral part of your security strategy.
There's no difference to the work I need to do to secure an open SSHd vs an open WireGuard server. None.
Yes I harden, and penetrate, systems for a living. If your systems need remote access there is no standard (neither in fintech or military) that classifies SSHd as being "worse" than a VPN.
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.
Why is your VPN jump box better than an SSH jump box?
Tailscale? Netbird? I have been using hamachi like a fucking neanderthal. I love this posts, I learn so much
what's netbird
https://netbird.io/. Wireguard based software defined networking, very similar to Tailscale.
wow crazy that this was the default setup. It should really force you to either disable root or set a proper password (or warn you)
Most distributions disable root by default
Which ones? I'm asking because that isn't true for cent, rocky, arch.
Mostly Ubuntu. And... I think it's just Ubuntu.
Fedora (immutable at least) has it disabled by default I think, but it's just one checkbox away in one of the setup menus.
Standard Fedora does as well
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.
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.
#no thank you lol
Rocky asks during setup, I assume centOS too
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.
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.
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.
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.
Now that you mentioned it, it didn't! I recall even docker Linux setups would yell at me.
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
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.
Which distro allows root to login via SSH?
All of them if you configure it?
Not very many. None of the enterprise ones, at least.
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...
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...
That feels like sorcery, doesn't it? You can still do this WAY safer by using Wireguard or something a little easier like Tailscale. I use Tailscale myself to VPN to my NAS.
I get a kick out of showing people my NextCloud Memories albums or Jellyfin videos from my phone and saying "This is talking to the box in my house right now! Isn't that cool!?" Hahaha.
I'm almost glad I had to go that route. Most of our ISPs here in the U.S will block outgoing ports by default, so they can keep the network safe sell you a home business plan lol.
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.
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.
Ah, timeless classic.
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.
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.
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.
That's rad! Thanks so much for sharing that! Definitely gonna give this a read. Very much appreciated. :)
Any idea what ip addresses were used to compromise it?