Securing Ubuntu
joshrendek.com
joshrendek.com
The section that suggests putting
tmpfs /dev/shm tmpfs defaults,ro 0 0
I prefer guides that explain what they are telling you to do and why, providing a basis for real understanding. To that end, I'd recommend Linode's "Securing Your Server" guide[1] over this.
So it's absolutely useful, good of you to put it there. Some criticisms on, however:
If the above was the goal, for an advanced audience, it could have been way way shorter. More like a checklist of tools and techniques, short paragraph explaining your choice and maybe a link to your particular config file if you think that's applicable. And that'd be fine, even if it means that I personally would have to Google most things to find out what they're for, it's a great starting point.
If, however, your goal was introducing securing an Ubuntu box to relative newbies, by which I mean people who are quite familiar on the Linux command line (like me) but lack specific knowledge about networking, iptables and the tools of the trade (again, like me), your article should have been way way longer than it is :) Or maybe not longer necessarily, but way more in-depth. Maybe a series, even (that would be awesome, but perhaps a lot of work, I'm not saying you should put in a lot of time that you maybe don't have, just that what you do write ought to be optimal for the effort put in ;) ).
Most of what seems to be missing in your article are answers to the questions "why (should I use this)?" and "what (is this for)?", both for the "advanced" audience, as for the "newbies".
Probably most important is that you must state upfront that this article is about securing a web server. Some of the choices you make are relevant only for web servers, but it wasn't until halfway that you mention "since this machine will be running as a web server ..." and before there were some points I was wondering "hm I'm not sure if I'd want to lock my (desktop) box so tight, but hey this guy seems to know what he's talking about" ... maybe I'm stupid and I should have noticed earlier. In all fairness, if you'd have just titled your article "Securing an Ubuntu web server", I probably wouldn't even have clicked the link (cause I don't have much use for that info right now) and you wouldn't have got all this feedback ;-)
You should have a short sentence explaining "Fail2ban is a program that ...", and another sentence going "iptables is a tool/configfile part of .../command/(no idea honestly[0]) that is used for ...". Not asking for an in-depth explanation, but a one-sentence "what it is".
Most of your checklist of Bastille settings are just cryptic enough that I cannot guess what they would exactly do and whether my settings should be the same as yours. If you target an "advanced" audience, you could suffice with "I'm using Bastille for XYZ because it's good at doing PQR, check its manual, here's my config, in particular pay attention to options ABC". For a more "newbie" audience you might want to say "Bastille is a hardening program, it consists of a set of tools and programs and configures them and your system to harden it. A few examples are PQR, but there's much more". "These are my settings" (do these go into a config file or is it a list of questions that the sudo bastille command asks? you can assume that most of your audience is not using your article as a step-by-step tutorial, so this is not obvious), and then explain succinctly what each of them does. Maybe just copy bits from the Bastille manpage. Or maybe just explain the ones that are different from the default options, and/or the ones that you suppose people might want to change, and say for the others just "make JKL extra secure, leave this set to 'on', <link to docs> for more info".
Hope that was useful for you! (And I don't mean you should do a complete rewrite of this article btw, you can also just take this general advice for the next one you write)
[0] I'm guessing "configfile" and part of some low level Linux networking thing? If I had been sitting in front of a Linux desktop I'd have been reading the manpage on it by now.
Recommend any good articles?
Actually, thinking about it more (and others have commented on it already)... changing shm to read-only is pretty much just a bad idea in general to suggest.
What? Citation needed. /dev/shm is simply a mount point for a memory-backed filesystem, much like /tmp. There's absolutely nothing special you can do with it.
The POSIX shared memory (i.e. shm_open) implementation on Linux does put its files in /dev/shm. By making /dev/shm read-only you're effectively disabling POSIX shared memory. Maybe some applications have vulnerabilities because they use POSIX shared memory unsafely? In that case you probably want to identify and upgrade those applications instead of disabling something system-wide that may cause legitimate programs to break.
I think it's better to protect the entry point (ie. in PHP, use php.ini open_basedir).
/tmp sometimes uses tmpfs which is also memory based, but not always and you won't know until you're in /tmp.
[1] http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
[2] http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731....
It's as damn near bullet proof as you can get.
With SELinux root can build systems which are so secure that root himself cannot hack them.
Sounds like your administrator would be well served to spend more time studying real-world vulnerabilities and less time focusing on SELinux :)
See eg. http://grsecurity.net/~spender/exploits/exploit2.txt
So it technically would extinguish itself there and then.
It works on the principle of least privilege so you start with nothing and add what the process needs.
None of the bullets seems immediately harmful security-wise, but many of them have the potential to break legitimate applications or lock you out of your host.
If you intend to follow this guide then make sure you fully understand each step before applying it.
The pros always come down to eliminating noise from automated attacks. The cons always come down to having to specify a non-standard port to clients.
If you only support public key based authentication, then I'd argue there's little to gain by moving ports.
No, there never was a debate. The two changes address different concerns and you should always do both.
You turn off password authentication to prevent targeted brute force attacks, keyloggers and (more common) accidents such as typing your password into the shell.
You change the SSH-port to improve your odds in case of a vulnerability in the SSH-daemon itself (sweep-scans tend to probe only the default port).
Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it.
As I wrote in my initial comment: It's not about targeted attacks, it's about evading netblock scans.
Use shared keys like you would salt, sparingly and with lots of care and knowledge of how to use it.
Bullshit. Use one password-protected keypair for each critical zone (work, personal, etc.). Keep it on your main machine and do not copy it to "places". Also don't spread FUD on public forums about the most secure ssh auth-option (short of multi-factor).
This is not a drawback of key-based authentication versus passwords because you have the exact same problem with passwords. If you want to explain proper key-management then explain it. But don't make it sound as if key-auth was some esoteric option that should be carefully considered versus password auth. Key auth should always be the default and password auth should always be disabled, exceptions to this rule are very rare.
For example fail2ban is fine but it's almost always better to just use ssh key pairs.
His firewall configuration doesn't do anything basically, just gives access to the network services that are already running, and logging firewall errors is only good if they are actionable (they rarely are) otherwise they are just filling up disk space.
The sysctl entries, I haven't checked one by one by the look like the defaults in a modern distro.
Regarding the sysctl entries, I reviewed them down to execshield (after that there are tweaking entries) in a Amazon EC2 vanilla Ubuntu distro and all the entries are the same except log_martian (debatable, again, are you going to look at the logs, if then what are you going to do with them) and accept_redirects. Execshield is a RedHat thing, it's not used in Ubuntu.
Also, last I heard chroot is not secure for sandboxing, so why bother with it at all? I'd use cgroups or even lxc containers (those are pretty well supported in the latest ubuntu).
In my chroot /usr/bin, there are only two files (rssh, scp). In my chroot /lib there are only 16 files.
Compare to:
1670 in /bin /usr/bin /sbin
50507 in /lib /usr/lib /usr/lib64
For example if you have something horrible like a PHP script that does: echo system($_POST['whatever']) you at least should try and prevent it from doing "ls" and "cat" to start exploring the filesystem.
It's worth your time.
I installed it on a box with some ruleset and it seems to basically block everything. The configuration format also seems far from simple.
A good way to look at it is to start by installing it and a good rule-set. A good one could be the gotroot/ASL kit http://updates.atomicorp.com/channels/rules/
From that point your best bet would perhaps be one of the freely available 'getting started' guides like https://www.feistyduck.com/books/modsecurity-handbook/gettin...
Mostly though, my suggestion is to deploy it, have your application break (you should be doing this all in a staging environment), figure out if unbreaking your application can be done with scripting changes, bypassing rules, etc.
Have you filed security bugs for all these ways in which Ubuntu is apparently insecure by default? What does the security team have to say about this?
These are not "security bugs" in the sense of 0-day remote code execution vulnerabilities. These are simply configuration options which may increase security for certain use cases.
Setting up specific chroots , firewall rules and restrictions could well not make sense for many use cases.
Also stuff like fail2ban can lock you out of your server and requiring key based auth can be more complicated to get end users to configure if you are setting up for something like a shared hosting service.
Off to bat, don't edit iptables manually anymore. Use ufw.
I just setup a new Ubuntu server (12.10) this weekend and while I'm still tweaking it, I've been documenting my process.
I'll make it available here: https://docs.google.com/document/d/1J2o6Lmq00Lk3k3HPUVKnOvSK...
For some reason this doesn't work too well in OpenVZ VMs. You have to go via iptables directly.
1) Making sure SSH only accepts public keys. This removes the possibility of a hacker guessing a password.
2) Use fail2ban. This rate-limits SSH attempts.
3) Keep your packages up-to-date, especially Web applications.
4) Use a default-deny firewall configuration, and make sure your services bind to the localhost interface. Letting the outside world directly talk to your database, Redis and memcache lets someone see your application data without any security checks, and this should only be possible for the application itself.
I'm not exactly good with dev ops and tweaking operating sytems. Even If I do attempt to fix it up and secure it, it will leave me uneasy because I don't fully understand the things I've done.
If there was something trusted and ready-made would be great.
1: http://compilefailure.blogspot.de/2011/02/grsecurity-patched...
Why isn't this the default? (in other words: what does benefit from ro not being the default besides people trying to hack into the box?)
It may protect you in case of a mistake, your editor should warn you that the file is read-only.
I don't like the post, it's too complicated for small benefits (if any). Besides there's no "generic secure setup", I think it depends on what you want to do with that server (ie. making /dev/shm read only may have impact on some software).
EDIT: I think I misunderstood your comment.
/dev/shm is used by the POSIX shared memory implementation (i.e. shm_open) and can also be used as a general temporary directory (like /tmp) that's memory-backed. Legitimate applications use it and legitimate applications will break if you follow this advice.
There's nothing inherently unsafe with /dev/shm - it's very similar to /tmp. It's possible some applications use POSIX shared memory unsafely, but that's a problem with those applications. Doing something drastic like making /dev/shm read-only, if it even serves a legitimate security purpose, should only be done as a last resort.
The reasoning is that if someone does break into your system via apache/php or something else, they will almost always want to get a binary to elevate their access level (i.e. root the machine). They download a binary to a temporary location and execute the code (This can happen in apache/php directories too but most of the time these are locked down). Setting these to no-execute does not allow the attacker to execute code on your system. This is just a minor slowdown but does greatly help to prevent automated attacks.
The goal is to slow people down to improve your chances of being alerted. I think this is fiarly standard and is listed as a best practice via the NSA RHEL hardening guide [1].
[1] www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
As you said, setting noexec still helps preventing automated attacks.
Sources:- https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-am...