Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
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.
Sorry to hear that. Do you know how it was compromised and how you found out?
I'm confused. I never disable root user and never got hacked.
Is the issue that the app is coded in a shitty way maybe ?
You can't really disable the root user. You can make it so they can't login remotely, which is highly suggested.
sudo passwd -l root
This disables the root user
There's no real advantage to disable the root user, and I really don't recommend it. You can disable SSH root login, and as long as you ensure root has a secure password that's different than your own account your system is just as safe with the added advantage of having the root account incase something happens.
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.
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.
I canβt even figure out how to expose my services to the internet, honestly itβs probably for the best Wireguard gets the job done in the end.
I'm having the opposite problem right now. Tightend a VM down so hard that now I can't get into it.
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.
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.
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.
Basic setup for me is scripted on a new system. In regards to ssh, I make sure:
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.
At least you had a backup
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.
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.
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
On a new linux install or image I will always:
- Setup new user to sudo
I hope it is not a passwordless sudo, it is basically the same as root.
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.
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!