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.
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.
On a new linux install or image I will always:
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.
I'm having the opposite problem right now. Tightend a VM down so hard that now I can't get into it.
At least you had a backup
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.
Fsil2ban piped to pfblocker works great. Plus snort
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'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.
Another thing you can do under certain circumstances which I'm sure someone on here will point out is depreciated is use TCP Wrappers. If you are only connecting to ssh from known IP addresses or IP address ranges then you can effectively block the rest of the world from accessing you. I used a combination of ipset list, fail2ban and tcp wrappers along with my firewall which like is also something old called iptables-persistent. I've also moved my ssh port up high and created several other fake ports that keep anyone port scanning my IP guessing.
These days I have all ports closed except for my wireguard port and access all of my hosted services through it.
You can't really disable it anyway.
Hardening is mostly prevent root login from outside in case every other layer of authentication and access control broke, do not allow regular user to su/sudo into it for free, and have a tight grip on anything that's executable and have a setuid bit set. I did not install a system from scratch in a long time but I believe this would be the default on most things that are not geared toward end-user devices, too.
I usually just follow this
This sounds like something everyone should go through at least once, to underscore the importance of hardening that can be easily taken for granted
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 interested, how do you expose your services (on your PC I assume) to the internet through wireguard? Is it theough some VPN?
Just a note, while wireguard makes its own VPN tunnel, it differs slightly in that it isn't the typical VPN server with vpn connecting clients, it is more akin to a peer network. Each peer device gets it's own "server" and "client" config section in the setup file. And you share the public keys between each peer before hand, and set the IPs to use.
Wireguard IS a VPN. He has somehow through his challenges of exposing services to the internet, exposed wireguard from his home to the internet for him to connect to. Then he can connect to his internal services from there.
It's honestly the best option and how I operate as well. I only have a handful of items exposed and even those flow through a DMZ proxy before hitting their destination servers.
VPN’s are neat, besides the fact they’re capable of masking your IP & DNS they’re also capable of providing resources to devices outside a network.
A good example is the server at my work is only accessible on my works network, to access the server remotely without exposing it directly to the internet would be to use a VPN tunnel.
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!
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
The other poster gave you a lot. If that's too much at once, the really low hanging fruit you want to start with is:
The rest requires research, but these steps will protect you from the most common threats pretty effectively. The world is full of bots poking at every service they can find, so keeping them out is crucial. You won't be protected from a dedicated, knowledgeable attacker until you do the rest of what the other poster said, and then some, so try not to make too many enemies.
Thank you!
The TLDR is here : https://www.digitalocean.com/community/tutorials/recommended-security-measures-to-protect-your-servers
You won’t be protected from a dedicated, knowledgeable attacker until you do the rest of what the other poster said, and then some,
You're right I didn't even get to ACME and PKI or TOTP
https://letsencrypt.org/getting-started/
https://openbao.org/docs/secrets/pki/
https://openbao.org/docs/secrets/totp/
And for bonus points build your own certificate authority to sign it all.
https://smallstep.com/blog/build-a-tiny-ca-with-raspberry-pi-yubikey/
Paranoid external security. I'm assuming you already have a domain name. I'm also assuming you have some ICANN anonymization setup.
This is your local reverse Proxy. You can manage all this with a container called nginx proxy manager, but it could benefit you to know it's inner workings first. https://www.howtogeek.com/devops/what-is-a-reverse-proxy-and-how-does-it-work/
https://cloud9sc.com/nginx-proxy-manager-hardening/
https://github.com/NginxProxyManager/nginx-proxy-manager
Next you'll want to proxy your IP address as you don't want that pointing to your home address
https://developers.cloudflare.com/learning-paths/get-started-free/onboarding/proxy-dns-records/
Remote access is next. I would suggest setting up wireguard on a machine that's not your webserver, but you can also set that up in a container as well. Either way you'll need to punch another hole in your router to point to your wire guard bastion host on your local network. It has many clients for windows and linux and android and IOS
https://github.com/angristan/wireguard-install
https://www.wireguard.com/quickstart/
https://github.com/linuxserver/docker-wireguard
Now internally, I'm assuming you're using Linux. In that case I'd suggest securing your ssh on all machines that you log into. On the machines you're running you should also install fail2ban, UFW, git, and some monitoring if you have the overhead but the monitoring part is outside of the purview of this comment. If you're using UFW your very first command should be sudo ufw allow ssh
https://www.howtogeek.com/443156/the-best-ways-to-secure-your-ssh-server/
https://github.com/fail2ban/fail2ban
https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands
Now for securing internal linux harden the kernel and remove root user. If you do this you should have a password manager setup. keepassx or bitwarden are ones I like. If those suck I'm sure someone will suggest something better. The password manager will have the root password for all of your Linux machines and they should be different passwords.
https://www.makeuseof.com/ways-improve-linux-user-account-security/
https://bitwarden.com/help/self-host-an-organization/
Finally you can harden the kernel
https://codezup.com/the-ultimate-guide-to-hardening-your-linux-system-with-kernel-parameters/
TLDR: it takes research but a good place to start is here
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.
- 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?
Enter Masscan, probably a net negative for the internet, so use with care.
I use port knock. Really helps against scans if you are the edge device.
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.
Also does anyone still port knock these days?
If they did, would we know?
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.
I disabled ssh on IPv4 and that reduced hacking attempts by 99%.
It's on IPv6 port 22 with a DNS pointing to it. I can log into it remotely by hostname. Easy.
sudo sudoku
echo gecko
Do not allow username/password login for ssh. Force certificate authentication only!
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.
...
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.
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?
Why though? If u have a strong password, it will take eternity to brute force
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.
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
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...
By allowing password login and using weak passwords or by reusing passwords that have been involved in a data breach somewhere.
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.
glad my root pass is toor and not something as obvious as password123
toor, like Tor, the leet hacker software. So it must be super secure.
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.
That's incredible, I've got the same combination on my luggage.
Looking at ops other comment, weak password and no fail2ban
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.
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...
Any idea what ip addresses were used to compromise it?
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.
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.
Did all that, minus the no ssh root login (only key, obviously) plus one failed attempt, fail2ban permaban.
Have not had any issues, ever
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.
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
Use gnome powder to shrink, go behind the counter, kick his ass and get your money back.
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.
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 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.
Don't SSH in as root. Create/use your low-privileged user and add it to the sudo group (with a secure password!), then disable root login for SSH.
You may not want root login.
ssh-keygen -t ed25519
For that new key hotness
Key based authentication is so hot right now
i use su -
This is like browsing /c/selfhosted as everyone portforwards every experimental piece of garbage across their router...
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.
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!
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.
Good on you learning new skills.
This is why other sysadmins and cybetsecurity exist. Be nice to them.