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.
Technically it's still a public server. Just more so.
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.
You over estimate my competence. I do intend to leave my ISP firewall up and intact, but I could build layers behind it.
I run everything on a minipc (beelink eq12), which I intend to age into a network box (router, dns, firewall) when I outgrow it as a server. It'll be a couple years and few more users yet though.
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.
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.
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.
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.
sudo sudoku
echo gecko
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.
That wouldn't be defense in depth. You want to limit anything that's not necessary as it can become a source of attack. There is no reason root should be enabled.
I don't understand. You will still need to do administrative tasks once in a while so it isn't really unnecessary, and if root can't be logged in, that will mean you will have to use sudo instead, which could be an attack vector just as su.
Why do like, houses have doors man. You gotta eliminate all points of egress for security, maaaan. /s
There's no particular reason to disable root, and with a hardened system, it's not even a problem you need to worry about...
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.
Yeah, about this; any ssh server that can be run as user and doesn't do shenanigans like switching user?