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.
At least you had a backup
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
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.
- Setup new user to sudo
I hope it is not a passwordless sudo, it is basically the same as root.
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.
Good point about a default deny approach to users and ssh, so random services don’t add insecure logins.
i use su -
Do not allow username/password login for ssh. Force certificate authentication only!
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.
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. ...Why though? If u have a strong password, it will take eternity to brute force
I like to spin up a public facing server and run tcpdump
Lol! Honeypot or just bored?
Actually I was troubleshooting a Firewall issue on site. I just forgot to use the filter arguments to reduce the output.
Oooof, I know that feeling.
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.
Did all that, minus the no ssh root login (only key, obviously) plus one failed attempt, fail2ban permaban.
Have not had any issues, ever
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.
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.
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.
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).
deleted by creator
echo gecko
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.
Ah, timeless classic.
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 safesell 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.
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.
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.
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.
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.
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.
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: truehttps://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?
Which distro allows root to login via SSH?
Not very many. None of the enterprise ones, at least.
All of them if you configure it?
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)
Now that you mentioned it, it didn’t! I recall even docker Linux setups would yell at me.
Most distributions disable root by default
Which ones? I’m asking because that isn’t true for cent, rocky, arch.
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.
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.
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
Mostly Ubuntu. And… I think it’s just Ubuntu.
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.
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
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.
Weird. My last setup had a NAT with a few VMs hosting a few different services. For example, Jellyfin, a web server, and novnc/vm. That turned out perfectly fine and it was exposed to the web. You must have had a vulnerable version of whatever web host you were using, or maybe if you had SSH open without rate limits.
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.
I shared it because, out there, there is a junior engineer experiencing severe imposter syndrome. And here I am, someone who has successfully delivered applications with millions of users and advanced to leadership roles within the tech industry, who overlook basic security principles.
We all make mistakes!
There’s a 40 year I.T. veteran here that still suffers imposter syndrome. It’s a real thing I’ve never been able to shake off
Just look at who is in the White House, mate - and not just the president, but basically you can pick anyone he’s hand-picked for his staff.
Surely that’s an instant cure for any qualified person feeling imposter syndrome in their job.
This sounds like something everyone should go through at least once, to underscore the importance of hardening that can be easily taken for granted
Yeah, about this; any ssh server that can be run as user and doesn’t do shenanigans like switching user?
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.
I search commits for “removed env file” to hopefully catch people who don’t know how git works.
–verbose please?
edit: never mind, found it. So there’s dumbasses storing sensitive data (keys!) inside their git folder and unable to configure .gitignore…
yeah, I just tried it there, people actually did it.I always start with .gitignore and adding the .env then making it.
Anywho, there’s git filter-repo which is quite nice and retconned some of my repos for some minor things out of existence :P
I searched for “added gitignore” and I found an etherum wallet with 25 cent.
My work is transferring to github from svn currently
My condolences
You gremlin lmao
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.
