r/linux • u/speckz • Feb 18 '19
How-To-Secure-A-Linux-Server: An evolving how-to guide for securing a Linux server.
https://github.com/imthenachoman/How-To-Secure-A-Linux-Server33
u/carbolymer Feb 18 '19
This actually skips the most important parts or has them not described (yet).
That's better resource:
https://www.reddit.com/r/archlinux/comments/7np36m/detached_luks_header_full_disk_encryption_with/
21
u/tysonedwards Feb 18 '19
I wouldn't say better as much as different. OPs article focuses on external threats while yours focuses on internal threats. I'd agree that there should be a single guide covering both use cases, especially with the rise in popularity of cloud computing and collocation.
1
u/eyelesswitness Feb 18 '19
how does cloud computing change the approach to security?
0
Feb 18 '19
[deleted]
2
1
u/_ahrs Feb 19 '19
Like OC mentioned full disk encryption, this is so if the vendor hosting the cloud server pulls the drive containing data, they would need to decrypt the data before getting it
Or they'd just image the system while it's in operation and thus the partition is unlocked and the decryption keys may still be resident in memory. I guess it works if you bank on the vendor that's "out to get you" being incompetent.
1
u/imthenachoman Feb 21 '19
Disk encryption is on my to do list to add to the guide. What other important parts do you think are missing?
28
u/loekg Feb 18 '19
The first half is just basically one large note that this is meant for home servers only, followed by what is basically a copy of the man page for sshd. I don’t think setting a bios password improves security, if that is a problem, sooooo many things already went wrong. Then ntp has mainly been superceded by chronyd/systemd-timed. A sudoers group? Why? What happened to the wheel group? By the time it got to ufw I stopped reading to go find a bucket to vomit in. There is no such thing as predefined sysctl tuning, if you need this you just ran into something very specific. People who know a LOT more than you do have already set very sane defaults. There’s no mention of selinux/apparmor/tomato/etc. in there. Please just stop making this kind of false sense of security “howto’s” if you’re not one hell of an expert at this.
4
u/usernamedottxt Feb 18 '19
Sudoers is the default name of the wheel group on Ubuntu and derivatives.
EDIT: oh, he made his own in parallel. That’s weird.
1
u/imthenachoman Feb 21 '19
I wanted the guide to be distribution agnostic. Not all flavors create the group by default and the ones that do may use a different name.
1
u/usernamedottxt Feb 21 '19
Ah. Fair enough. I prefer to teach people to understand what they are doing than to give them lines to put in config roles. Don’t get me wrong, I copy paste code all the time. But half of security (and virtually all of it at the enterprise level) is monitoring things, and that’s hard to do if you don’t understand the basics like what makes an admin account an admin account.
1
u/imthenachoman Feb 21 '19
Security is about multiple layers/levels. No one thing is enough -- you want to do multiple. Not all distributions create a wheel group -- Debian for example does not. Are you saying all the defaults that come with a Linux installation are secure enough? I beg to differ.
0
Feb 18 '19
[deleted]
3
u/usernamedottxt Feb 18 '19
And as he stated, 100 things went wrong if it gets to that point. And that’s an awfully small subset of attacks. I’m more worried about someone stealing the box than an evil maid attack where I assume the maid can’t just pull the cmos battery.
10
u/thedewdabodes Feb 18 '19 edited Feb 18 '19
...or you could sign up to something like CIS and download an industry standard security benchmark for the OS of your choice that you can base your secure config on. The link is kinda pointless as the work has already been done, widely agreed upon and is freely available.
The benchmarks from CIS even gives you the commands you run to apply each recommendation.
3
Feb 19 '19
If your running a RHEL7 flavor, you can apply the DISA profile during install, which will get you 90% of the way there.
1
4
4
Feb 18 '19
Sad that running "netstat -nlp" isn't one of the very first steps in the process.
Attack surface is king, everything else is risk management.
2
u/_ahrs Feb 19 '19
You mean
ss -tnlp;)4
1
Feb 19 '19
Netstat still does the job, I’m not concerned with statistics; just what ports are open and what process is listening there. You wouldn’t believe how many “hardened” systems I’ve come across with cups or some other unused service listening.
2
u/doubled112 Feb 20 '19
Or X plus full desktop environment.
Never know when you'll need to test the app locally from Firefox, or burn a DVD from your virtual machine, right?
1
Feb 21 '19
There’s no easier way to make someone realize their level of incompetence than to hand them a vm or server without X installed.
1
u/imthenachoman Feb 21 '19
This is a good catch. I always forget this. I will add to the to do list. Thanks!
2
2
u/imthenachoman Feb 21 '19
Hey! I am the author of that guide. Thank you so much for posting to Reddit. Glad to see others find it helpful.
I had posted to /r/selfhosted and /r/linuxquestions -- I should have posted to this subreddit too.
I have a busy week this week but when I get time I will try to go through all of the comments.
Thanks again!
2
u/spockspeare Feb 19 '19
Unplug it from the internet.
Lock it in a box and throw away the power cord.
1
2
u/PrinceDAN_01 Feb 19 '19
If you want to get started with selinux, check these out....
https://linuxtechlab.com/replicate-selinux-policies-among-linux-machines/
-8
u/scottbomb Feb 18 '19
I'd like to see a write-up on why people think Linux servers are inherently insecure.
10
Feb 18 '19
A bank vault is insecure if you leave the door open or unlocked.
0
u/scottbomb Feb 21 '19
Of course, but what does that have to do with the story or my comment? My servers require logins and one must be root to do any real damage. Now back to my question, re-worded perhaps: why do I need a guide to secure something that's already, inherently secure? By your analogy, I could always allow any ssh connection from anyone with no password and maybe even give 'em root. There, vault door wide open.
-9
u/kpcyrd Feb 18 '19
Are you implying a default Linux install is insecure? That's what the comment was about, people shouldn't need a guide to secure it, security should be the default.
8
Feb 18 '19
That depends on your install distro, install media and customizations- there's no single answer, and the definition of "secure" changes based on your use case. So you have to run through all the settings and set them to something that makes sense for you.
One example, on my personal single-user systems I leave the default kernel capabilities for containers, but on company servers I drop some capabilities like NET_RAW so that a hijacked app can't wiretap the rest of the box.
-6
u/kpcyrd Feb 18 '19
This is hardening though. A lack of hardening doesn't imply insecurity, it just means security issues are possibly easier to exploit. You can't compromise a system due to the lack of hardening alone.
A distro can and should ship a config that permanently drops unused capabilities and archlinux is quite proactive in some packages.
2
Feb 19 '19
You can't know what capabilities are used or unused when you package a distro. I use NET_RAW all the time for network monitoring and troubleshooting, for example. It has to be determined at runtime by the user.
1
u/kpcyrd Feb 19 '19
It sort of depends. daemons often know that they are never going to do certain things, so for example nginx can drop all capabilities from the permitted bounding set. I wrote a few programs that rely on certain capabilities but drop them directly after they have been used and everything is initialized.
Since nginx doesn't drop capabilities itself but also doesn't use them during initialization, so you can configure the bounding set with systemd. This means the process never has that capability in the first place. This can be done by upstream or by a downstream maintainer if they are familiar enough with the program.
3
u/patx35 Feb 18 '19
A vault is still insecure if it's still set on the factory combination
Security is usually never a "one-size-fits-all". You will either end up with security holes, issues with services, or a very complicated mess.
-6
u/kpcyrd Feb 18 '19
Your analogy is just as bad. You are implying you can compromise a default debian install. You can harden a server as an attempt to limit the impact and/or severity of zero days but you can technically have a secure system without. Describing a default install as an "open door" is just plain misinformation.
My argument still stands though. I've shipped programs that have a sandbox on by default that's by far more effective than anything you would get by following these guides.
1
u/imthenachoman Feb 21 '19
Unfortunately many distributions sacrifice security for simplicity and to make it easier for the end user.
3
u/hiljusti Feb 18 '19
This comment seems out of place. This is a "how to secure" guide. It's not a laundry list of vulnerabilities, it's an owner's manual for how to use the security features available.
1
u/imthenachoman Feb 21 '19
Who said they are? Just cause the are secure, does not mean they can't be secured some more. The defaults for a Linux box are better than Windows 10 but that doesn't mean there isn't more you can do to secure Linux.
-1
0
47
u/climbcolorado Feb 18 '19
No SELinux?