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.
Had this years ago except it was a dumbass contractor where I worked who left a Windows server with FTP services exposed to the Internet and IIRC anonymous FTP enabled, on a Friday.
When I came in on Monday it had become a repository for warez, malware, and questionable porn. We wiped out rather than trying to recover anything.
questionable?
Yeah just like that. Ask more questions
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.
- 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?
Also does anyone still port knock these days?
If they did, would we know?
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.
I use port knock. Really helps against scans if you are the edge device.
Also does anyone still port knock these days?
Enter Masscan, probably a net negative for the internet, so use with care.
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.”
Sure yeah it’s a discovery tool OOTB, but I’ve used it to perform specific packet sequences as well.
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.
Fsil2ban piped to pfblocker works great. Plus snort
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.
Almost the same here. I also change some ssh settings: disable root login, disable password, allow only public key login. That’s about it. I never had any problems.
Hmmm those are some good extra tips. I’ll take a look, thanks!
At least you had a backup
I usually just follow this
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.
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.
I’m having the opposite problem right now. Tightend a VM down so hard that now I can’t get into it.
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.
Yeah, about this; any ssh server that can be run as user and doesn’t do shenanigans like switching user?
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.
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)
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.
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.
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
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
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.
Now that you mentioned it, it didn’t! I recall even docker Linux setups would yell at me.
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?
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.
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…
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: 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.
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.
what’s netbird
https://netbird.io/. Wireguard based software defined networking, very similar to Tailscale.
Tailscale? Netbird? I have been using hamachi like a fucking neanderthal. I love this posts, I learn so much
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.
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.
Any idea what ip addresses were used to compromise it?
This is like browsing /c/selfhosted as everyone portforwards every experimental piece of garbage across their router…
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.
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.
hey, thats me!
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.
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.
I don’t think I’m ever opening up anything to the internet. It’s scary out there.
I don’t trust my competence, and if I did, I dont trust my attention to detail. That’s why I outsource my security: pihole+firebog for links, ISP for my firewall, and Tailscale for tunnels. I’m not claiming any of them are the best, but they’re all better than me.
Isp for firewalls might not be better than you. Get something dedicated.
Ubiquiti or pfsense is a good start.
Permitting inbound SSH attempts, but disallowing actual logins, is an effective strategy to identify compromised hosts in real-time.
The origin address of any login attempt is betraying it shouldn’t be trusted, and be fed into tarpits and block lists.
Endlessh and fail2ban are great to setup a ssh honeypot. There even is a Prometheus exporter version for some nice stats
Just expose endlessh on your public port 22 and if needed, configure your actual ssh on a different port. But generally: avoid exposing ssh if you don’t actually need it or at least disable root login and disable password authentication completely.
https://github.com/skeeto/endlessh https://github.com/shizunge/endlessh-go https://github.com/itskenny0/fail2ban-endlessh
If it is your single purpose to create a blocklist of suspect IP addresses, I guess this could be a honeypot strategy.
If it’s to secure your own servers, you’re only playing whack-a-mole using this method. For every IP you block, ten more will pop up.
Instead of blacklisting, it’s better to whitelist the IP addresses or ranges that have a legitimate reason to connect to your server, or alternatively use someting like geoip firewall rules to limit the scope of your exposure.
Since I’ve switched to using SSH keys for all auth Ive had no problems I’m aware of. Plus I don’t need to remember a bunch of passwords.
But then I’ve had no training in this area. What do I know
I’ve recently seen login attempts using keys, found it curious…
Probably still looking for hosts that have weak Debian SSH keys that users forgot to replace. https://www.hezmatt.org/~mpalmer/blog/2024/04/09/how-i-tripped-over-the-debian-weak-keys-vuln.html
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.
You’re not wrong! Devops made me lazy
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.
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!
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
deleted by creator
