Hi all,
I found a hobby in trying to secure my Linux server, maybe even beyond reasonable means.
Currently, my system is heavily locked down with user permissions. Every file has a group owner, and every server application has its own user. Each user will only have access to files it is explicitly added to.
My server is only accessible from LAN or VPN (though I’ve been interested in hosting publicly accessible stuff). I have TLS certs for most everything they can use it (albeit they’re self signed certs, which some people don’t like), and ssh is only via ssh keys that are passphrase protected.
What are some suggestions for things I can do to further improve my security? It doesn’t have to be super useful, as this is also fun for me.
Some things in mind:
- 2 factor auth for SSH (and maybe all shell sessions if I can)
- look into firejail, nsjail, etc.
- look into access control lists
- network namespace and vlan to prevent server applications from accessing the internal network when they don’t need to
- considering containerization, but so far, I find it not worth foregoing the benefits I get of a single package manager for the entire server
Other questions:
- Is there a way for me to be “notified” if shell access of any form is gained by someone? Or somehow block all shell access that is not 2FA’d?
- my system currently secures files on the device. But all applications can see all process PIDs. Do I need to protect against this?
threat model
- attacker gains shell access
- attacker influences server application to perform unauthorized actions
- not in my threat model: physical access
That sounds extremely painful to manage and prone to error if you aren’t using containers.
It does require some effort to manage, but I would argue it’s easier to keep all packages (including dependencies) up-to-date across the system, which is a huge security benefit imo.
The permission system, once you set it up, you never need to change it unless you’re changing something.
Get your firewall right then maybe add fail2ban.
You could also consider IDs/IPs on your primary router/firewall if this is internal. If not you can install surricata on a public server. Obviously if you go with something as powerful as surricata you no longer need fail2ban.
Keep a sharp eye on any users with sudo. Beyond that consider docker as others have mentioned.
It does add to security because it allows the developers a bit more control of what packages are utilized for their applications. It creates a more predictable environment.
AppArmor or SELinux, OSSEC, TPM and SecureBoot boot chain.
How so? They clearly say physical access is not in there threat model. If someone has root it is game over.
I would reconsider docker because if a specific application leaks some sort of shell access or system file access you’ll be protected out side of container host escalation.
Unrelated to security, I prefer docker because it leaves the server very clean if you remove different apps. Can also save time configuring more complex applications or applications that conflict with system libraries.
Add fail2ban on your list of applications it watches logs for invalid logins and puts them on firewall block rules after so many failed attempts.
I really wish there was a system wide package manager for docker containers, which would update software in all your containers at once similar to how a typical package manager would.
I did not completely rule out docker, but I wonder if I can obtain most of its benefits without this major con with package management. I mean I know it’s possible, since its mostly kernel features, but it would be difficult to simulate and the tooling is probably lacking (maybe nsjail can get me closer).
You can have a look at systemd-nspawn and machinectl actually. Sounds like exactly what you’re looking for :)
I am really interested in systemd-nspawn. Unfortunately I have openRC now (I liked it’s simplicity) so can’t try out systemd yet.
Is machinectl tied to systemd also?
Docker performs some syscall filtering as well which may reduce the kernel attack surface. It can be pain to set up services this way, but it could help frustrate an attacker moving laterally in the system.
Processes in the container cannot see external processes for example as I think interested the OP.
There are entire books dating back to the 80’s that go into this, that are still fairly valid to this day.
If you want to take things further at your own risk, look into how to use TPM and Secure Boot to your advantage. It’s tricky, but worth a delve.
For network security, you’re only going to be as effective as the attack hitting you, and self-hosting is not where you want to get tested. Cloudflare is a fine and cheap solution for that. VLANS won’t save you, and an on-prem attack won’t save you here. Look into Crowdsec.
Disable any wireless comms. Use your BIOS to ensure things like Bluetooth is disabled…you get the idea. Use RFKill to ensure the OS respects the disablement of wireless devices.
At the end of the day, every single OS in existence is only as secure as the attack vectors you allow it to have. Eventually, somebody can get in. Just removing the obvious entry points is the best you can do.
VLANs are for organizing traffic, not authorization of traffic.
Can be pretty easily spoofed by packet.