Battle of the Secure Distros

CrazyEd writes "LinuxSecurity is reporting that EnGarde Secure Linux has received the Network Computing Editor's Choice award to win the battle of the Secure Linux distributions. Well deserved, me thinks." Update: 06/10 15:16 GMT by T : An anonymous reader points out that Linuxlookup.com reviewed this distro last week, awarding it a perfect score.

Comments

Admin

[sofist]

A distro is (or any software for that matter(yes Windows to)) only secure if the admin who runs the distro knows what is he doing.

Re:Admin

[alapalaya]

I disagree with you. I think that to be a good sysadmin is quite difficult and requires a lot of study, trial and error and passion. (Please note, I'm not a sysadmin, even if I can accomplish the easier sysadmin tasks).
In particular, you must know in deep detail all the technologies involved in a complex networking environment (they are countless: DNS, email, NEWS, NIS, LDAP, routing, and so on...).
It is difficult to barely know all of them, and to secure an installation you must know them good. And this is no easy...

Of course I agree with the point that the software must be "secure-able", otherwise you can be the best sysadmin... you system will always be full of flwas if the software you are using is bugged (...who said something about the windows?...).
Cheers

Re:Admin

[UnderAttack]

IMHO, a 'secure distro' is secure by default. You plug in the CD, turn on the box, install it and just keep clicking 'ok'. At the end, you should end up with a secure box. Now it is up to the admin to open the holes.

However, many distros go a different path by enabling services and allowing installs with weak passwords (or no passwords).

For a nice security benchmark, see the Center for Internet Security. I wait for the day where a default install of RedHat will score a perfect 10 with it... (It is more around 5 right now on their 0-10 point scale).

Re:Admin

[dgym]

Too true, any secure system can be made insecure by a poor admin, but not all systems can be made secure by a competant admin.

These secure distros try to be by default very secure and should only normally become insecure by an admin doing something silly or not keeping up to date with patches. Some of the other distros don't pay as much attention to security, but a really good admin can nail these systems down too. I for one like the fact that this distro comes with no setuid-root programs, its a good precautionary measure.

In some systems, admins do not have a chance to secure the machine because of lack of control. This is normally the case where closed source software kindly leaves you with a gaping security hole, and until someone eventually comes out with a patch the best you can do is stop using it. Ofcourse you were probably using this software for a purpose, and so not using it for a while could not be an option, hence an all too common situation of knowingly running insecurely, and there is nothing the admins can do.

Infact millions of people have done this recently, with the realease of XP the installation was vulnerable to network based attacks from the start. The only way to correct the problem was to install a patch - which meant you had to connect to the internet using that machine to register the software and get the patch from 'the company that shall not be named'. When you have to make yourself vulnerable to get the patch that stops you being vulnerable, security is impossible.

The most valuable part of EnGarde Secure Linux is probably the patch system, if it (or something just like it) was taken up by more distros then securing boxes would be easier and therefor might happen more. I would like to see something similar in gentoo keeping me up to date, because finding out what is going on is often the hardest part. Was there a ptrace vulnerability I missed? Ohh damn.

Re:Admin

[fruey]

The key is this: there are too many admins who patently don't know what they're doing, and some who will even admit it.

I spend a lot of time with other people's networks, and have yet to see one which stands up to how I would run my network. That's how I make money, incidentally - fixing other people's networks and securing them where possible.

A guage of how secure things are out-of-the-box is important. Some people will never switch off the default daemons, etc. Some people insist on using some Microsoft DCOM rubbish and opening holes over their firewalls to do it because they can't do anything else. They don't know how and don't care to know.

So, this kind of survey is important for those lesser admins who are probably not geeks and just trying to hold on to their jobs. Perhaps they are good at other things and valuable for the company, and the same is too tight to invest in a proper sysadmin so they dump him the job because he can hack a few basics together and get it to work.

All those of you saying "RedHat isn't secure out of the box" and all that OpenBSD stuff are already enlightened. These surveys are not for you. They are for all those other readers who don't fathom why you're mentioning OpenBSD in the first place.

NSA not even mentioned.

[bodin]

Interesting that the NSA security enhanced linux is not even mentioned.

http://www.nsa.gov/selinux/

--
I vote for OpenBSD

Re:NSA not even mentioned.

[octogen]

NSA SELinux is (currently) not meant to be a secure Linux distribution. It's rather something like a "Demo"-Implementation of MAC in the Linux-Kernel.

Quotes: NSA SE-Linux FAQ
13.Is it secure?
[...] Put another way, "secure system" means safe enough to protect some real world information from some real world adversary that the information owner and/or user care about. Security-enhanced Linux is only a research prototype that is intended to demonstrate mandatory controls in a modern operating system like Linux and thus is very unlikely to meet any interesting definition of secure system. [...]

16.Did you try to fix any vulnerabilities?
No, we did not look for or find any vulnerabilities in the course of our work. We only changed enough to add our new mechanisms.

You can find the full SE-Linux FAQ here

RedHat

[ranulf]

It's a shame given how easy it is to make a RedHat box secure that they don't just do it by default.

Because I'm always installing Linux for clients, RedHat is always specified, so I have no choice, but I've got it down to taking about 10 minutes to have a really secure box. It's just a case of knowing what needs to be done, which sadly, Linux newbies won't know.

In my opinion, security should be paranoid to start with. If that stops the users from doing something, fine. They'll have an incentive to try and figure out how to allow what they wan to do. Make it too easy, and they'll just live in blissful ignorance.

Re:RedHat

[Phil Hands]

Because I'm always installing Linux for clients, RedHat is always specified, so I have no choice,...

I too regularly install GNU/Linux for clients, and more often than not they specify RedHat (occasionaly SuSE), but I've not installed anything other than Debian for years (except during RHCE/RHCX courses ;-), so you do have a choice.

The trick is to ask them why they specified RedHat. Most of them will cheerfully admit that they said that because it's the only distro.they've heard of so they were saying "RedHat Linux" in the same way they might say "Microsoft DOS", never realising there was a "DR-DOS" (once upon a time ;-).

It doesn't normally take too much effort to convince them that they are paying me for my expertise, so if I recommend a particular flavour they might as well listen.

The only time I'd take such a request seriously would be if they were already a RedHat shop, and had a lot of in-house RedHat expertise.

The last time that was claimed the "expert" turned out to be clueless, and the existing RedHat systems so broken (9GB swap, 800MB root, permissions all +rwx) that I ended up having to reinstall them anyway --- they're a Debian shop now ;-)

I've since decided that any RedHat shop that decides to hire me in, is probably not full of experts (otherwise they'd do it themselves), so take a lot of convincing that going with the flow is the wise thing to do.

If you have a good technical reason not to install RedHat, and you can justify it, give it a try.

The worst that happens is they say no (and you get to look smug if their decission bites them).

The best that might happen is that they decide to respect your opinion, which bodes well for the future business relationship, and means you get to work on the system you feel best fits the problem, which avoids stress and frustration.

Re:RedHat

[ranulf]

Depends on exactly what your requirements, but generally turn off everything you don't need.

I start with a shell alias like this:
alias nsl='netstat -alnp --protocol=inet|cut -c-6,21-94|tail +2|grep -v ESTABLISHED|grep -v CLOSE_WAIT'

At a glance you will see what services are running and listening to ports. The "Local Address" column is the most useful. Anything starting 127.0.0.1 can be safely ignored, the rest will be based on what you feel you need.

As a general rule, boxes I configure offer WWW (port 80), SMTP (port 25), POP3 (port 110) and DNS (port 53). I turn everything else off, or if I do need it, I firewall it (see later).

Now, how to get rid of things. Obviously, this varies from thing to thing, but take for example the lines starting
udp 0.0.0.0:2599
tcp 0.0.0.0:
udp 0.0.0.0:111

Now, as I'm not running NFS or NIS, I don't need any of these services. If you're not sure what, say, port 111 is, the -p option to netstat is great - it lists the PID and process name, so we know to close down portmap. Now, this is started by /etc/rc.d/init.d/portmap via a symlink in /etc/rc.d/rc3.d (assuming you start in runlevel 3). Simply rename the link there to start with a K, like this:
[root@pootle init.d]# cd /etc/rc.d/rc3.d/
[root@pootle rc3.d]# mv S14nfslock K86nfslock_S14
[root@pootle rc3.d]# mv S13portmap K87portmap_S13
[root@pootle rc3.d]# ./K86nfslock_S14 stop
[root@pootle rc3.d]# ./K87portmap_S13 stop

Now, run netstat again, and see what ports remain for you to tidy up. You'll probably remain with ones that you really do want to keep, e.g. postgres on 5432, tomcat control on 8008, MySQL on 3306, etc...

This would normally be a job for the firewall. If you have one, use it! However, just in case a machine inside your net is compromised, you can run additional filtering rules on every machine. For instance, my /etc/sysconfig/ipchains file looks like this:
# open up the POP server
-A input -p tcp -s 0/0 -d 0/0 110 -y -j ACCEPT
# open up the WWW server
-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
...
# close all reserved ports
-A input -p tcp -s 0/0 -d 0/0 0:1023 -y -j REJECT
-A input -p udp -s 0/0 -d 0/0 0:1023 -j REJECT

# protect mysql
-A input -p tcp -s 0/0 -d 0/0 3306 -y -j REJECT
# protect postgres
-A input -p tcp -s 0/0 -d 0/0 5432 -y -j REJECT
-A input -p udp -s 0/0 -d 0/0 1026 -j REJECT

and so on. Basically, the theory is, explicitly open up the ports <1024 that you want to allow access to, and block anything else to the priviledged ports. Then, by default allow all higher ports access (otherwise, you'll get problems connecting from the machine to other machines), but explicitly close services you don't want publically available, e.g. databases, etc...

Other stuff you'll want to do is remove telnet and ftp from your machine and install openssh. With both of those protocols, you run the risk of passwords being snooped along the way, and ftp gets hacked fairly regularly. If you do need to upload files regularly from Windows machines, check out WinSCP2 - it's really good.

Next off is protecting services that have a track record of being hacked, such as named. There are several tricks; running as a non-root user is always best if you can, running in a chrooted environment is better still. The first gives the program so few privileges that it can basically only access files it owns. Good, unless you have have local root-exploitable holes. The second runs the application completely in a sandbox, where it sees a very restricted view of the directory system, e.g. on my machine, all DNS data lives under /chroot/named, and if it was hacked, the best they'd be able to do is destroy DNS data. This can be complicated to set up, and I'd advise you to search the web for in-depth discussions.

I will often use a combination of techniques, e.g. DNS on my systems run as user named, live in a chrooted filesystem, and also have packet filtering rules, so that they only talk to machines which are dedicated secondary DNS servers.

Of course, you also need to audit anything that is left available. If you run CGI scripts that will accept data unchecked and pass it to a shell command, your machine will be compromised. Keep an eye on security mailing lists or websites - if you run software that vulnerabilites are discovered in, you need to patch them quick, e.g. SSH bugs found a few months ago, etc... But by keeping things down to an absolute minimum (using seperate boxes for each service if you can) and really considering who needs to use them, you stand a good chance of being really secure.

This is getting too long now! Hope some of this helps...

I disagree (with your disagreement...)

[jabbo]

and I am a professional sysadmin. I get paid a lot to do my job and I don't feel like there is anything mystical about it (that sort of nonsense is for university admins that have to deal with incompetent bosses -- more power to 'em, but I don't). What I feel adds value is not mere understanding of the protocols (relatively easy) but rather, the ability to choose the correct tool (protocol, framing, hardware, software) for the job, and make it work so that the rest of the people involved can do their jobs without noticing (or if they do, saying, "hey, that's really cool and easier than before!"). Needless to say I do a good deal of development to make this happen, and again, that is more challenging than administering boxes (IF you start with a sane rollout and upkeep process -- yes, RPM/apt/pkg_add is your friend; yes, CVS/CVSup/Rsync is your friend; no, ad-hoc changes are not the Better Way to proceed).

When you rattle off NNTP and crap like NIS/LDAP as if they were equivalent in complexity to full BGP4/MBGP routing, I think you belie a superficial understanding of the situation. Even something as nastily complicated as BGP route maps is not nearly as challenging as dealing with people, professionally and personally, in a fast-paced environment that values results over process or the latest fad technologies. In that respect I do not believe it is significantly harder to earn one's keep as a sysadmin than to do so as a VP Sales or a Comptroller. It's just a totally different set of technical skills used to do the job.

I don't doubt that you meant well, but really, choosing the right tool for the job (and then using it well) is not so difficult in most cases. 'Tis a poor craftsman who blames his tools!

That's because...

[jabbo]

Most federal agencies seem to evaluate Windows against proprietary Unix solutions and (duh) find that Windows is cheaper. If they *really* care about security they almost always have their own solution (often in hardware) that you will be asked to code to / talk with / work in conjunction with. Short of that, offering to use NSA SELinux (because of the NSA's "approved" cachet) really seems to open a lot of doors for Linux.

En Garde may be better, for all I know. But I'll be using SELinux for gov't clients wanting high security, and OpenBSD for my need-to-be-hardened services, because I know they are excellent tools for those applications. (sorry folks...)

The above are just my experiences. For all I know it could be a vast conspiracy to provide disinformation :-). But, the odds are against it.