Linux Distribution Security Reviewed 195
qbasicprogrammer writes: "Security Portal has a review on the security of Red Hat, SuSE, TurboLinux, and Caldera Linux distributions." Debian and Slackware are absent, but its a decent piece.
This discussion has been archived.
No new comments can be posted.
Linux Distribution Security Reviewed
Related Links Top of the: day, week, month.
Always draw your curves, then plot your reading.
Re:Focus of distro (Score:1)
I thought I had a point... maybe not...
Debian (Score:1)
If I owned stock in Debian Inc. I would be demanding that the CEO be fired. How can Bruce Peren's cash those big checks without shame?
Clearly Debian Inc. is nothing compared to the amazing TurboLinux or the powerful Servers I've built with Mandrake. No proper e-commerce site can be run without KDE as the desktop powering the whole thing!
In all fairness (Score:1)
My suggestion for the next person who does this would be to explain exactly why and how you are doing the rating. Also, offer tips for those of us under-geeks that have yet to realize the full potential of Linux.
Security is probably my biggest beef with Linux, and I'm speaking from personal experience, not FUD that MS or any other company fed me. I got hacked within two weeks of an installation, and only one day after using IRC with the box.
I think that a similar review would spark interest for me as well.
Re:No kidding (Score:2)
This shouldn't have to be this way. At the very least, there is no reason to accept this situation. The OpenBSD crew pride themselves on the fact that no remote vulnerability, has been found in 3 years, and no local one in 2, I think. I am sure the BSD's would be mentioned more often on bugtraq too if hey had as many users looking for exploits as certain linux distributions do, but still... It's rarely (if ever) the kernel that leads to a root exploit, so you know who to blame.
Do you trust a security reviewer who uses Outlook? (Score:2)
Here is a section of the mail header of one of the author's messages:
Reply-To: "Kurt Seifried" <seifried@securityportal.com>
From: "Kurt Seifried" <seifried@securityportal.com>
To: [slug address removed]
References: [removed to protect the innocent]
Subject: Re: [SLUG] A comment on Linux Security Reviews
Date: Wed, 26 Jul 2000 01:36:25 -0600
Organization: SecurityPortal
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
--
"You take a distribution! Rename! Stamp CD's! IPO!"
- CmdrTaco, Geeks in Space, Episode 2 from 6:18 to 6:23.
Re:This is a Review? (Score:1)
Yes, Debian has not had a stable release for some time.
If you want cutting edge, you use the unstable branch. More than 'probably very useable' - it's more up-to-date than say RedHat because it's continually being updated (hence the name "unstable")
--
"You take a distribution! Rename! Stamp CD's! IPO!"
- CmdrTaco, Geeks in Space, Episode 2 from 6:18 to 6:23.
Re:security... (Score:1)
when you say "installed linux" don't you mean a linux distribution? Linux is only the kernel. Which distribution are you talking about? For a +3 post, it sure is clueless.
Re:security... (Score:1)
An yes, the only safe uncrackable configuration is to have your system welded shut in a steel box with no connectivity. Well, even that could be broken into with enough gumption.
Re:security... (Score:2)
Almost all of them are turned off in a default install as of Red Hat Linux 6.2.
Yes, we have bugs, but we (at least try to) fix them.
Re:Response from the author to various things (Score:4)
As for it being a year before woody ships with a 2.4 kernel, it may be a year before 2.4 is remotely stable. 2.4 may not even be feature frozen yet, despite claims to the contrary; Linus seems to be adding a new feature a week. IMHO shipping 2.4 as the default kernel in any distribution would be irresponsible at this point.
Re:ummm... (Score:4)
- 3.9: 16/7/99
- 4.0: 28/11/99
- 7.0: 27/4/00
- 7.1: 27/6/00
Compare to Red Hat:- 5.2: 12/10/98
- 6.0: 20/4/99
- 6.1: 26/9/99
- 6.2: 8/3/00
So you are looking at 5-6 months between RH releases, and 2-5 months for Slackware. Oops, looks like the reviewer was just a lazy fuckbag.reviewer.streetCred = 0;
Re:Nope! (Score:2)
40-50 characters? man... you really take yer passwords seriously...
let me guess, you use different passwords for every system?
tagline
Re:Here's one (Score:1)
Frankly, yes.
The concept of groups has no clearer demonstration of purpose than the example you've cited. Groups exist so that you can assemble a list of people who should be allowed access to a certain resource or set of resources (in this case, a file), and will deny access for anyone not in that group.
Adding new groups is not a workaround for your problem, it is the solution to your problem.
If you want to debate the merits of having one centralized group list that only the superuser has access to, that's another issue entirely.
Re:This is a Review? (Score:1)
If they were reviewing (sp?) Windows, i think it would be proper to only review the latest versions. I dont know what version of the linux kernel was out 2 years ago, but i presume is was 2.0.x or 0.x. Do you want them to review these? No. So what are you complaining about? They only review recent versions of products?
Mark Duell
Re:up2date? (Score:1)
It's on the download-able ISO image.
Just configure it to point to ftp.redhat.com instead of priority.redhat.com.
It works. Just be aware that at times ftp.redhat.com is busy and you won't be able to connect.
I'm not too fond of the program, but it automates the process, painfully, but it works.
think of it as a homeowner (Score:2)
Interesting... (Score:2)
Re:No kidding (Score:3)
Now all we have to do is convert the manpages to html or add a blink format tag to groff.
--
This is a Review? (Score:5)
Except they're missing the point.
What kind of a system administrator would settle for a default install? What kind of security department would ALLOW security holes to stay open? Sure, it's part of the vendor's job to make sure their product is up to par with what's expected of them, but ALL of the responsibility does NOT rest with the people who put together the distribution!
A Detail Oriented, Security Concious, Responsible SysAdmin is 90% of the equation.
And by not reviewing all relevant distributions, they're putting their 'review' on a slant. That's like saying "We're reviewing Windows security. We're only including Windows 98SE and Windows 2000, and we're leaving out Windows 95 and 98 because, let's face it, they're 2+ years old. RIDICULOUSLY SLOW RELEASE SCHEDULE." Bah. If you're going to take the time to write something like this, review ALL major distributions. Don't pick and choose your review candidates because (rightfully so) it looks like you're playing favorites.
I for one, am a very happy Slackware user, and have been for years. Needless to say, I was quite disappointed to find a lack of a Slackware review. (Slackware is quite a secure/stable distro, by the way.)
I haven't played with Debian too much to know a lot about it's implementations and security, but I can imagine Debian users feel slighted by this as well.
(My solution to the distro war? Use whatever you like. It's pretty simple, really.)
-- Give him Head? Be a Beacon?
Re:Response from the author to various things (Score:1)
It's obvious that you are not aware of the meaning of the words "stable" and "unstable" as they relate to Debian. Slink is "stable" because it's packages do not change much (Slink has been updated for security reasons and Y2K stuff, that's about it). Woody is "unstable" because it's packages get updated frequently (like, every day).
Yes, it does look like Potato will be released just before 2.4, so it will miss out on it initially. However, it will probably contain 2.4 in a future minor release (like when 2.4 actually gets released). There shouldn't be much to it -- I'm running 2.3.99 pre8 (okay so it's a little old) on a stock Potato system with no upgrades required from when I was running 2.2.
It's interesting that you make a comment here about the services that are active in a default install ("OpenBSD, secure by default, requires the admin to do things to make it less secure"). Your article did not touch on that issue at all.
You'd get to sleep all of your 8 hours if only you installed Debian on all 6 of your linux servers. apt-get - the greatest system administration tool ever.
--
"You take a distribution! Rename! Stamp CD's! IPO!"
- CmdrTaco, Geeks in Space, Episode 2 from 6:18 to 6:23.
Re:security... (Score:2)
Re:Kurt is usually the man.... (Score:1)
Re:ummm... (Score:2)
[root@host] > apt-get update
[root@host] > apt-get upgrade
And at that point, you're done. It will fix all known security problems.
Re:Oh Boy (Score:1)
--
"You take a distribution! Rename! Stamp CD's! IPO!"
- CmdrTaco, Geeks in Space, Episode 2 from 6:18 to 6:23.
Re:Do you trust a security reviewer who uses Outlo (Score:1)
The author is trying to find an objective metric for security, and unfortunately for him what is easy to measure is not particularly relevant, and what is relevant is extremely difficult to measure. Without actually knowing much about Debian or Slackware, I would expect either to be more secure than any of RedHat, SuSE, Turbo, Caldera, Mandrake, Storm, because of an emphasis on doing it right rather than having the latest and greatest.
Think of new bugs as exploits that require zero effort on the part of the exploiters.
Importantce of Security: FOR NEWBIES (Score:5)
[slashdot.org]
Now, I know you're thinking "why would a cracker or skript kiddie attack me? what do I have?" Security is just for NetAdmins and big corporations, right? Wrong-o, buddy. You have many things that are just what a potential vandal might want, be they software bits, personal information (/. login cookies, for example), or just distributed processor power for the next big dDoS attack. So it'd be a good idea to keep the baddies out, right?
[slashdot.org]
I'll admit, I didn't start the guru that I am. I've been attacked, and one time, actually cracked. And I didn't know it for weeks. The malicious bit of code sat running a process on my desktop, and I didn't even think to question it, as that this whole enuichs thing was pretty new to me. But eventually, as I came to learn more, I saw what happened, and how they got in.
[slashdot.org]
Silly me, I didn't think to shut off access to port 647284a-3. As you're by now well aware, that's the port that listens for transmissions from the Daemon Quarlakath. Not really an issue most of the time, as that in order to summon Quarlakath, the attacker needs to slaughter the third born black goat under a Summer Moon. So, like linux security, you get one shot, and one shot only! You also need to chant several passages from the book of Lizzaft, in the original Tongue That Cannot Be Spoken. Last I checked they weren't giving classes in Tongue That Cannot Be Spoken in your averate Community College! So I didn't bother with port 647284a-3. No big deal, I thought, that'll NEVER happen.
[slashdot.org]
And of course, it did. Once I understood what happened, I had to get that malicious daemon OUT of my system before it started a dDoS or slaughtering first born children or giving me a charley horse. So I did what any fledgeling Systems person would do, I summoned Taccatha, the Warrior Angel and sworn enemy of Quarlakath. And lo, the battle inside my box raged on for three weeks. When it was finished, Taccatha was victorious, and Quarlakath was banished to the Sulpher pits of Analorp from whence he came. But, of course, I had to pay Taccatha tribute for his service, and I'm still washing the blood of The Thousand Serpents off my walls. For such little things you'd never guess that they'd bleed so much.
So until next time, trkwjjoi hrrwompt snki!
Re:Here's one (Score:1)
Assume a lot of files in the group, scattered in several different directories, folders, or whatever they are called, and now add members or delete members, and just try to remember where all the files are. Should make for some very anomalous results.
RedHat, mayby other distributions, creates a group with the same name as a new user. To handle group membership, create a user with same name as the group. With some mechanism so that the user can effectively edit her/his one line in
Re:ummm... (Score:2)
Kurt is usually the man.... (Score:4)
major non-commercial distros. I can't say
what Slackware's security is like since I don't
use it, but Debian really gets the shaft...
and undeservedly so. Kurt seems to go on the
notion that any distro which ships software that
hasn't been reved in 6 months or more is
insecure. So in his eyes, Debian is not secure
due to the long release cycles. I find that
to be quite the opposite. Special apt-get
security mirrors, security mailing lists, and
patches that are usually available a couple of
days after an exploit is announced....Debian
does pretty well IMHO.
And it doesn't hurt that they don't ship with
sendmail as their default MTA.
I've offered to write an article for
securityportal on how to secure a Debian box from
remote exploit, but I've not heard back from
Kurt yet. I suppose he isn't in control of article
submissions tho. They'll be suprised to see that
the article is pretty much:
apt-get remove rsh
apt-get install ssh
apt-get install portsentry
apt-get install aide
apt-get remove telnetd
apt-get remove ftpd
edit a couple of config files and reboot. Of
course, local exploits are a whole nother story.
That's true of most Unices tho...except for OBSD.
Anyway, anyone who hasn't used Debian...don't
let this article turn you off to it. I don't
think Kurt has really used Debian very much.
I don't see how he could disregard it like that
if he had. Disappointing from someone who writes
the LASG.
IMHO, of course.
Re:Comprehensive security review? I think not (Score:1)
up2date? (Score:2)
Why didn't the author even mention up2date (the Red Hat RPM update agent) or corresponding utilities in other distributions?
A great many of his arguments evaporate when these automated utilities are considered.
Re:And yet... (Score:2)
Except that the Windows model is one of end user system administration.
Mot only is central administartion of Windows machines hard this is also one of the factors working against replacing Windows.
Re:ummm... (Score:1)
Re:This article does not fit linux (Score:2)
Re:security... (Score:2)
If the only way to FTP files off the system is non-anonymously, people have to send passwords in plain text. Anonymous FTP doesn't have the risk of giving away passwords, the worst that can happen is that somebody exploits a buffer overrun (or similar) in the FTP server - and that server is chrooted, right?
I agree that FTP is generally worth disabling, but why pick on anonymous, when it's the non-anonymous kind that lets sniffers get hold of users' passwords? (You could have separate FTP and login passwords, but that's not the default setup.)
Re:This article does not fit linux (Score:2)
To put it into perspective, what would you say if your computer's RAM went south and Dell told you to go ask Micron because they're the ones who made the RAM? I can hear to obsceneties now.
Real Security (Score:1)
NT has a decent security model. But Microsoft's goals with NT is functionality, not security. So with file permission defaults such as Everyone: FULL CONTROL and Exchange KM Server Admin passwords being "Password", it's not hard to see that M$ wants Admins to have an easy job. Everything works, but it ain't secure. Although one can configure NT to be secure, it will take many hours of work and tests.
On the other side of the spectrum, consider OpenBSD. Paranoid? Obviously. Everything's off, users have no access to anything, users can't su unless they're allowed. Here, security is well taken care of, but the admin's big job here is opening up the system so users can get some functionality.
Then put Linux in the middle. A relatively secure OS, with (as most distros) almost all daemons running without even asking for them. Shut off sendmail, wu-ftpd, httpd, etc, and boom, magnitudes more security.
Then consider the admin who uses the root account straight through telnet. One co-worker I knew does this on a regular basis, then brags that he's never been cracked!!! Patching bugs is the easy part...
Re:Kurt is usually the man.... (Score:2)
Re:The best security (Score:1)
Crackers don't always compromise a system for content. Off the top of my head I can think of several reasons why a cracker would dive into a machine that had NO user files on it.
Tell ya what. Why not post your IP address to a major cracking site and say "I've got nothing you want, so I'm safe, right fellas?" Stand back. Wait 30 minutes.
Re:why no debian? (Score:1)
Re:This is a Review? (Score:2)
Re:Too bad Mandrake is missing. (Score:1)
Let me guess... (Score:1)
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Too bad Mandrake is missing. (Score:2)
why no debian? (Score:1)
it is key to remember that no system (not even OpenBSD) is completely secure. paranoia is the key.
Re:That's predictable. Solaris isn't a total dog. (Score:2)
Let's see.. NT accounts for 65% of the cracks, but only 20% of the market.. Unix-only webservers account for almost 75% of the market, but only 29% of the cracks. That only makes NT 8 to 9 times more likely to be hacked. (I discarded the other 6 percent as the error percentage, hence the range.)
Apologies to Microsoft; Their product sucks, but it isn't as insecure as I stated!
Security is important in a distro (Score:1)
The latest is not the most secure (Score:3)
There are numerous cases where newer software packages have introduced new security hole.s For example, Pam added some features, and in the process, added a new local->root hole. When the ISC added a new feature to BIND, the new feature had a, you got it, remote root hole. The capability features to the 2.2.x kernels added new security concerns. And so on.
To say that Debian is insecure because it has not had a major update is just plain silly. Does he also think that OpenBSD is insecure because it still uses BIND 4.x instead of the latest and greatest Bind 8.x? For the record, I am a RedHat and not a Debian user.
The article also did not look at things like "How many services does this distro run out of the box?".
- Sam
security... (Score:2)
I'd like to see an approach more on par with the *BSD crew - disable everything by default and/or make it the most restrictive. That way, if a user wants to learn to do something they'll read the man page or the manual and learn how to do it AS WELL AS what the risks are / how to properly configure it. This is much more in line for both neophyte and experienced users as you shouldn't be running something you don't know how to use on a public network like the internet.. you're just gagging for it then. :/ Just my $0.02.
You're kidding, right? (Score:1)
Re:Security is important in a distro (Score:1)
YASSS (Score:2)
See it was just a bunch of charts and graphs, I skipped to the "conclusions" section and found the following item: "All the major vendors have improved over time. That is to say, the number of updated packages released for security reasons and not just "normal" upgrade activity is decreasing, which suggests decreases in the number of security flaws."
Yes, that's right, the author finds that the number of updated packages is decreasing and concludes it's because security is getting better. If IDC released this report with s/Linux/Windows run against it we'd be all over them like green on grass.
Nothing to see here.
--
Give us our karma back! Punish Karma Whores through meta-mod!
Any Linux (Score:1)
Any Linux 2.2+ (with ipchains) is more secure than *BSD. Unfortunately, the BSD ipf utility doesn't work prorperly. It gives an ioctl(SOIADDR): Bad file descriptor error and tells me that my device is not configured. (What device! I've been on the internet with the darn box!)
Therefore, no matter what distribution of Linux you run, be happy in the knowledge that BSD is less secureRe:This is a Review? (Score:1)
That's why I use OpenBSD.
This article does not fit linux (Score:2)
Ridiculosuly Slow? (Score:3)
I beg to differ on that point. As one who follows Slackware development very closely, there is almost always daily changes to the ChangeLog. These fixes typically consistent of either upgrading a package to a more recent current version or fixing a security bug (a more rare occurence).
Just as with every other distributions, Slackware stays on top of new developments and security fixes. The main version may not increment as often (it typically jumps two or three times a year), but it is nowhere near backward or slow as the reviewer seems to imply. Check out Slackware's main site [slackware.com] for evidence of my opinion.
Re:Focus of distro (Score:2)
You are suggesting that it would be good policy to delay security releases because some users might not want them? Even Microsoft doesn't use this argument...
--
Give us our karma back! Punish Karma Whores through meta-mod!
Re:security... (Score:1)
Re:why no debian? (Score:1)
Unfortunately, this is basicly correct. There are three exceptions here. First, some programs (the good mp3 players, for example) use asynchronous i/o with completion routines running at interrupt time. These run even if the system-wide cooperative task isn't running. Second, there was a hack called the "menutasking enabler" which modified the system menubar routines to give background applications processing time while the foreground app had a menu pulled down. I'd be surprised if it still worked under OS 9, and it was buggy (if a background app scrolled some graphics "underneath" the menu, then the menu got moved too) but it was still very clever. Third, if a background app has launched any preemptive threads (using the multiprocessing manager, which you can do even on a single-processor machine) then these will continue to run, although they're not allowed to make any user-interaction related system calls.
Debian and Slack (Score:2)
The release schedules are not ridiculously slow, only relative to Linux distributions. Other OS's wish they could compete like that; Windows gets releases of its consumer version every three years or so.
And besides, what do release schedules have to do with security? Do they make D&S better? Worse? Unfair? Why?
I know people who would argue both ways.
MYTH: slow releases mean security bugs stay in longer
FACT: Debian (probably slackware too) releases package updates as quickly as any other distro when it comes to newly discovered vulnerabilities. Check http://security.debian.org (by the way those exploits on the page now are global, not debian-specific)
I know people (not me) who also feel that your system is more stable when you don't upgrade with every new version that comes out. This is the same thing, and I partially agree, to various extents depending on the circumstances.
What I don't understand is why this insigniicant difference in market strategy invalidates these two distributions, and why the author chose to disclude them. I also think the "ridiculous" needs some explaining... can we moderate articles "Flamebait"?
Re:Linux "security" is disastrously obsolete. (Score:2)
Re:Linux "security" is disastrously obsolete. (Score:2)
Remember that story about Fortune 500 companies running only NT? Well, I ran a similar test on the sites on the Hot100 list. OpenBSD did not get a single entry in 120+ URLs (some entries had more than one URL listed). Linux got 17%, FreeBSD in the low twenties, and Solaris took it home with over 40%. There were AIX, IRIX, BSDI, and NetBSD, in the sample, so you really can't say the results weren't spread out.
Here's one (Score:2)
I have a project that I work on with three other students/employees, with files stored on a University/company system. I want to make my files read/write for just us four, but there is no group in
What do I do? Make three hard links to each file, with different permissions on each one? Beg root to make a new group every time some situation like this comes up? Those are workarounds, not solutions.
Unix follows the first rule of security: Simplicity!
Translation: "I only use Linux". Commercial Unices have had ACLs for longer than Linux has been around. There's a Posix ACL standard API, in fact, which one or two beta extensions to the ext2 filesystem allow you to use in Linux.
Nope! (Score:2)
Nitpick about "early adopters" (Score:2)
Re:Kurt is usually the man.... (Score:2)
Yes, reboot. Not because the system needs it
but because I like to know what is going to be
running after an unattended reboot. Just in case
the power goes out when I am on vacation I will
still have piece of mind that I know *exaclty*
what will be running because I sat there and
*WATCHED* the boot messages the last time.
Yes, you could go so single user, but it's still
not the same level of comfort because there are
some things that can still be slightly different
than after a reboot.
Re:Real Security (Score:2)
Re:ummm... - right on (Score:2)
I have to say, also, that the authors dismissal of Debian and Slackware seem like either he didn't research those distros, or was too lazy to try and compile the information to his 'metrics' about them.
Most Important Points the article makes... (Score:3)
"Vendors need to make hardening scripts available (or support existing ones like Bastille Linux), and tell the users to use them--something like the default email that OpenBSD sends to root after a new install, telling root to read "man afterboot.""
"Vendors need to turn stuff off and make users enable it, or, during install, make users aware of what they are doing (similar to SuSE's "Do you really want to turn inetd on?"). "
On my first entry into Linux, I installed Caldera's OpenLinux 2.3. The reason for this is that I had done some research and found that it was the only distribution at the time that autodetected the Voodoo3 video card I was using. I ran it for a while and was very happy, some annoying problems in that most software and drivers released for linux are now designed for RedHat, so the files that they looked for were in the wrong place. So I had to make a lot of symlinks, etc. Big deal, standard linux installation garbage that everyone has to deal with.
Then my box got root compromised. The cracker/script kiddie had used one of many buffer overflow 'sploits, along with a RootKit to get on my system and hide his tracks. The way I found out was that I chose to use a graphical login, which displayed as icons all user accounts (which i believe RedHat did not have at the time. the root exploit script the cracker used was designed for redhat). I found out that many of my files had been trojanned, and that I was basically going to have to wipe the drive and start over.
Now the problem is that Caldera and most other distros automatically leave all services on. This includes the infamous wu-ftp daemon, among others known to have security issues. If there were a simple dialog at install about which services the user wanted enabled and which disabled, I think the linux market as a whole would be much more secure. But then, now I know, and knowing is half the battle.
---------
WHAT Exactly was the point of this article?! (Score:2)
It looks to me like the author simply decided it was time to have Fun With Graphs(tm). All he did was look at the number of security fixes different distributions have. What does that prove? If a distribution has a gaping security hole in it and it was never fixed, it would end up looking better by the standards of this article. Nowhere is it taken into account what percentage of security holes were actually plugged with these fixes, how long the fixes took, or how serious the security problems are. Furthermore, if a certain distribution goes a long time before being replaced with the next version, then it's likely to have many more fixes. Does this mean it's insecure? Of course not! Why would it?
Which brings us to the issue of Debian and Slack. The author probably ignored them for the very reason I mentioned above, but that's silly. In my opinion these two distributions (especially Debian) are among the most secured Linux distros out there, in part because of their slow release cycles. If they don't try to instantly cram every new feature into the distro then they have more time to make sure that everything in there is working. It's outright foolish to completely ignore these distros in a security analysis, but then this article isn't much of an analysis anyway. Maybe it's for the better.
chkconfig --del Quarlakath (Score:2)
Re:Secure... (Score:2)
well... if you can get a hold of the /etc/passwd file (shadow file, if needed) most of the passwords will be yours in relatively short order.
Repeat after me - if someone has access to your encrypted password file, you are already screwed. Implementing insane password policies can help this, but the encryption will only slow down a crack, not make it impossible.
Its similar in NT land, too... If you can get at the password hash, you /will/ be able to get every password... Its just a matter of time.
Lesson? Make an insane password policy - at least 8 characters, incude mix-case, numbers and symbols. Use shadow passwords. Have a backup root account.
and be paranoid
tagline
Re:WHAT Exactly was the point of this article?! (Score:2)
to warnings and advisories. Given that most break ins are due to
running outdated software with known security vulnerabilities, that
seems to me worthwhile.
Re:Home users (Score:2)
You've hit the nail right on the head. Fact: any company that relies on its computing resources for its business (read: everyone with more than about 1 employee) and does not hire a competent systems administrator is reckless and irresponsible.
If the management of a widget manufacturer buys inferior widget components to save money, and then finds themselves unable to sell widgets, the shareholders will most likely dismiss them. In some countries, there may be legal proceedings as well. Why? They failed to protect shareholder value. Instead of paying a fair price for a necessary input, they tried to cut corners. How is this case any different? Yes, competent systems administrators are expensive. The greenest of us are paid $60k a year. A 20-year Unix guru veteran administrator is worth $200k or more. But evaluate that cost against the costs associated with a security breach. For a small firm, and a simple skript-kiddie breach, the costs might simply be some lost time spent fixing the system, maybe a few hundreds or thousands of dollars - each time. For a medium-sized firm, or for a more insidious or far-reaching breach, costs will rapidly exceed even the most extravagantly paid sysadmins' employment costs.
Managers who fail to hire competent workers for necessary positions are guilty of mismanagement. Managers who fail to provide their staff with the tools they need to do their jobs (software upgrades, operating systems with adequate security models, etc.) are guilty of mismanagement. These are the guilty parties.
The fact that competent systems administrators are hard to find and expensive provides no justification for insisting that every software vendor try to divine all their millions of customers' security needs and provide for them out of the box. First, it's impossible to make everyone happy. What may seem lax to me looks fascist to most. Some people don't need any security at all - those with non-networked machines with no sensitive or valuable data. Second, there will always be bugs, errors, and omissions in software. Even OpenBSD issues patches and updates from time to time. If you are going to have a system, you must maintain it by applying vendor patches as needed. While this is not difficult, it does imply some measure of competence and vigilance.
All that said, there are differences in security between various vendors' offerings. Some systems (*cough*solaris*cough*) cannot be secured by any means, because the vendor is so lax about providing updates for known problems. Other vendors ship systems in intentionally insecure configurations (sgi). Others try to ship secure systems, but invariably fail to do so. Creating and maintaining a secure environment requires a competent administration staff regardless of the vendor and operating platform you select. While some vendors make it easier to do so by providing full source, frequent updates, and perhaps even auditing their code base, no amount of effort on their part can provide a level of security appropriate for every possible customer.
This provides an interesting opportunity for ISPs. Customers without the necessary interest or competence to maintain an appropriate level of security could purchase firewalling and other services from their ISP. This way, regardless of the type of system they have selected, they can be reasonably sure that a breach will not occur. Naturally such services would cost much less than hiring a full-time administrator. This model seems especially viable for home users, who often have no experience, hardware, or interest needed to provide sufficient security. But such offerings are generally made either to large customers, or to home users as a mandatory, no-extra-charge component (blocking port 25 for example). Hopefully this will change, as ISPs broaden their offerings.
Regardless of how you feel about staffing policies and distribution management (ever put one together?), it is irrational to expect what you do from vendors. No Linux distribution can possibly meet the needs of every possible user. Especially out of the box with no configuration. While some security measures should probably be included, I would much prefer choosing myself which additional measures should be taken. I do not appreciate vendors who try to box me into a certain security model. For example, a vendor might ship a distribution in such a way that Kerberos provides the entire security model. What, then, if I am on a network that uses OpenSSH DSA as the primary authentication security model? I am forced to strip out as much Kerberos as I can - often recompiling packages - and then add on my desired security measures. It's much easier to start with a system that has no preconceived ideas about security models, and then add on whatever I feel is appropriate for my circumstances. I don't expect - or want - distributors to try to guess my needs and provide only for the needs they assume. That is the mark of Microsoft and so many other failed vendors. The vendors who are succeeding today provide a wide range of flexible options to their customers. The one-size-fits-all, out of the box and go mentality is evil and shall not earn my business, now or ever.
As any sysadmin will tell you: Maintin it, or unplug it. There is no excuse.
Response from the author to various things (Score:2)
Wow, got slashdotted, this is pretty nifty (and our servers are handling it well this time which is nice). Anyways there's a lot of comments I feel I should respond to, so here goes:
The debian/Slackware issue: Debian has "official" releases like every 2 years, thus generating stats on it are near impossible. I know the distro is maintained (read: http://www.securitypo rtal.com/lskb/articles/kben10000078.html [securityportal.com], I am well aware of how dpkg/etc works. Here's the thing, you will never release a bug free software package, especially something like Debian which has a lot of packages. Like kernel 1.0 it's sometimes just best to shove it out the door and give users something a lot better then the last "officially stable" release. Side note: looks like Debian will release the next major one before 2.4, meaning it'll be another year or two before "stable" gets a 2.4 kernel, sigh). As for slackware I don't know anyone using it in a production environment anymore (there probably are..). I used Slackware for .. about 2 years when I started out, it is not something I'd want to put on 10 machines and maintain.
As for default installs, guess what, most admins do leave the defaults. Many people simply don't realize how dangerous these services are, or that they really need to be kept up to date. A default install like OpenBSD, secure by default, requires the admin to do things to make it less secure, (admitedly OpenBSD 2.7 with no security patches has a number of holes that are pretty serious). SOmething like %50 of machines on the Internet are insecure, why? A lot of them are simply because the default OS install was done and very few (or no) updates. Taking care of one machine at home isn't to bad, I have to care and feed 6 linux servers for my personal network, and sometimes I forget to do things, I'm only human (and I like to sleep 8 hours a day).
Good response for what? Red Hat isn't a distro for the people who want the latest and greatest updates as soon as possible. It's a distro for those who require a very tested solution. That's why Red Hat is often behind on the technology by the time it gets to .2, because they're focusing on the testing.
Leaving your users hanging in the wind for 2 weeks with a local root exploit is not good. Yes I know 2.2.16 has a ton of problems, but you should be giving customers the choice, not just leaving them in the lurch with no update.
As for Caldera/Turbo, Caldera is a pretty popular corporate distro, and Turbo is huge in asia (remember, there's more to the world then just the US market).
Note to slashdot: make the *******ing text entry box bigger!!!!! like 80 by 40 would be nice.
Kurt Seifried [mailto]
response from a debian developer (Score:2)
> I have not fully covered Slackware and Debian, with their ridiculously
> slow release schedules.
I'm very disappointed on two levels: First that you provide such a
comprehensive and useful report and yes omit one of the more popular linux
distributions[6], and second that you have made such an erronous assumption
about Debian's release methodology.
Your main mistake is that you have failed to realize that Debian
releases timely security fixes, which are distributed to Debian users
via the internet. Users can choose to configure their systems to receive
these updates[1]. This makes release intervals orthagonal to whether users
receive security fixes.
Moreover, Debian has _frequent_ minor releases. These releases consist
mostly of security fixes, and they serve to get the security fixes out
to fresh Debian installs, plus to anyone who installs from CD and does
not set up their system to receive security fixes via the net. You may
have missed these releases, since in Debian, "2.1" is a new major
release (with an implied "r1"), while "2.1r2" is the first minor release
-- an unusual nomecleture compared to the other distributions.
Interestingly, minor releases of Debian 2.1 have occurred more frequently
than minor releases of Red Hat 6 (which, as you note, "shoves a new version
out the door every 6 months like clockwork").
Debian
2.1
2.1r2 8 days
2.1r3 167 days
2.1r4 104 days
2.1r5 117 days
Red Hat
6.0
6.1 161 days
6.2 175 days
[ Interestingly, a poster on slashdot has numbers[5] that show that
the other distribution you left out (Slackware) also releases just as
frequently as Red Hat. ]
In light of these problems, I think it would be quite beneficial if you
added Debian to your paper. Security announcement since 1998 are
archived in both the archives of the debian-security-announce mailing
list[3], and on http://security.debian.org/ (which also includes
advisories from 1997). So, I dug up some numbers (I read the changelog
pointed to by footnote 2, and counted security fixes. This is probably
not as accurate as your numbers.)
Release Security Alerts
2.1 1
2.1r2 16
2.1r3 19
2.1r4 5
2.1r5
Moving on to the second part of your paper, specific indicidents and how
quickly distributions responded, I've looked up some data on Debian's
responses.
Local root exploit in kernel 2.2.15, announced on June 8th.
On June 12th, Debian announced[4] it had fixed the hole *before*
the exploit was announced, and thus was not vulnerable.
fdmount, announced May 22.
Debian has never installed it suid, and thus has never been
vulnerable (as you noted -- thanks).
By the way, I think this section of your paper looked at too few holes to
draw any real conclusions from. But Debian seems to have been near the
head of the pack in this limited sampling.
In closing, I'd like to point out that the current 1 and a half 5 year --
not 2 year as you continually state -- gap between Debian 2.1 and 2.2 is
so far an exception, and not -- as you continually imply -- a rule. Major
Debian releases:
1.1
1.2 6 months
1.3 7 months
2.0 12 months
2.1 8 months
2.2 (19 months?)
--
see shy jo, fond of lies, damn lies, and statistics
[1] (For instructions to configure a Debian system to receive such fixes,
see for example, http://security.debian.org/, in the 5th paragraph.)
[2] This information from ftp://ftp.debian.org/debian/dists/stable/Debian2.
[3] http://www.debian.org/Lists-Archives/debian-secur
http://www.debian.org/Lists-Archives/debian-secur
http://www.debian.org/Lists-Archives/debian-secur
[4] http://www.debian.org/security/2000/20000612
[5] http://slashdot.org/comments.pl?sid=00/07/25/1444
[6] I'm not going to argue this in detail, but just see how people reacted to
your ommissions on slashdot. Debian has a rather large mindshare, though
its market share is less quantifiable.
http://slashdot.org/article.pl?sid=00/07/25/14442
--
Re:ummm... (Score:3)
-JD
And yet... (Score:2)
And I don't think it's unreasonable to disable everything by default and force the user to learn about the OS to enable anything. I'd expect a seasoned system administrator to know how to install and set up a ftp server. I wouldn't expect a newbie to understand why they should disable it. Most of the newbies are going to willfully ignore decades of sysadmin experience (Witness how many of them insist on logging in and doing everything as root) so why make it easy for them to do so? I also think the distributions should set them up to refuse root logins, but that's just me.
I'm not saying we should try to figure out what's secure for everyone. I'm saying we should aim for some sensible defaults. Most of the home users don't NEED an FTP server running. Or telnet, or apache, or even inetd for that matter. And many of the more clued in people are going to want to install their own anyway (How many people rpm -e telnetd and install SSH instead?)
Re:This article does not fit linux (Score:2)
No kidding (Score:2)
Of course, even if your newbiews are clued in enough to get rid of all the crap the distribution enables by default, the first thing most newbies want to do is set all their friends up with logins on their system. And everyone knows that once you compromise a local account, getting root is trivial. Is there any reason for all the games to have root privs? Then why are so many of them setuid? Any package that requests a setuid bit should have a HUGE WARNING in BIG BOLD BLINKING LETTERS that doesn't go away for at least TWO MINUTES before it installs. This goes not only for games but for standard system services as well. Eventually I hope Linux privs will render the setuid bit completely unnecessary.
I agree that everything should be disabled by default. In addition, setuid usage should be structly audited and the setuid bit should only be granted when there's absolutely no other way to provide a vital service.
Re:This is a Review? (Score:2)
What kind of a system administrator would settle for a default install?
A reasonable one! Why should anyone expect an operating system to be shipped with security holes?
Put it this way -- would you extend the same courtesy to Microsoft if you installed NT and it was riddled with security holes?
--
Re:security... (Score:2)
What I find amazing is how many services are enabled per default on these distributions.
This is one of the attitudes I don't understand. Why shouldn't I have every blasted service turned on if I want to? Are the Linux services so riddled with security holes that the only safe configuration is to have the whole computer turned off?
--
Focus of distro (Score:3)
Good response for what? Red Hat isn't a distro for the people who want the latest and greatest updates as soon as possible. It's a distro for those who require a very tested solution. That's why Red Hat is often behind on the technology by the time it gets to .2, because they're focusing on the testing.
Red Hat is an IT distro. If you want Red Hat-ness without the IT requirements, try Mandrake.
Re:why no debian? (Score:3)
ummm... (Score:4)
"I have not fully covered Slackware and Debian, with their ridiculously slow release schedules. "
So... since when does release schedule have ANYTHING to do with security? Sure, Debian and Slackware don't release new versions often. This doesn't mean they don't release security fixes.
I've said it before, and I'll say it again: Debian is the easiest distribution to keep up-to-date, security wise. I often recieve updated packages via apt before the security announcement even hits Bugtraq. And since it takes all of 2 minutes to get the updates and apply them, it is easy for me to keep it up-to-date. Compare this, for example, with having to constantly search down the news/new packages/etc , which you have to do with other distros.
Debian likes to make sure the release is rock solid before releasing it. I'll be the first to admit that sometimes it is a bit slow. But this does not make the distribution less secure. In reality, it helps make it more secure.
Anyways, that comment alone was enough to make me skeptical of the actual knowledge of the author. It is a really ignorant, offhand remark to make, and has no relevance to security. But that is just me.
Re:ummm... (Score:2)
Re:That's predictable. Solaris isn't a total dog. (Score:2)
Then again, I've only been tracking it bi-weekly since December, so my conclusions may be skewed by the short timespan.
BTW, a Windows NT/2000 webserver in the internet is something like twenty-five times more likely than Linux to be cracked because of a security flaw. Go take a look at the attrition.org's hack counts and the last webserver report. I wouldn't trust NT or Windows2000 to be secure unless in a locked box surrounded by twenty bags of Redi-Mix.
Re:security... (Score:2)
2) you might want to install ssh to avoid connecting to your box via unencrypted connections from outside
3) you might want to install portsentry so you can see if ppl are scanning your box (you can let portsentry automaticaly add them to you firewall)
4) you might want to install logcheck (aka logsentry). it will mail you as soon as it finds something strange in logs.
if you do all those four things i guarantee you that 99% of crackers will not be able to get into your box and rest of the crackers (1% those who are not script kiddies) wont be intressted in a home system from some random guy.
Re:security... (Score:2)
2. Likewise, go into
3. Make sure every user on the machine (especially root) has a "strong" password, i.e. not a dictionary word, and with strange combinations of alphanumerics. If you don't know if your password is good, download a password cracker and crack your own passwd file. Of course, your passwd file shouldn't have any passwords in it, since you should really be using shadow passwords. This is the default on most distributions now, but if you don't have an
4. Go to your distributions' security updates site daily and check for new updates. If you find any for packages you have installed, install them. Likewise, read securityfocus.com and other sites like it (or just subscribe to bugtraq) on a daily basis, and if you find you have a vulnerability which your distrtibution is not patching, download a new version for yourself and compile it from the sources.
5. Harden your general permissions and so forth. A good script to do this in my opinion is sherpa (http://rcrelia.hypermart.net/sherpa/) which will also convert your passwd file to shadow if needs be. In general most distributions install way too much software by default. You could probably improve your security greatly just by going through the package list, reading the descriptions, and getting rid of anything which you don't use, especially if it deals with the network or is setuid.
If you want to be really ridiculously paranoid, there are other things you can do as well, such as installing an IDS like tripwire or snort. In general however, the steps above when done properly will keep out 99% of the script kiddies who are most likely using their l33t portscanners to check your subnet for the "cool exploit of the week." If a security professional is really, really determined to get into your machine, then you may not be able to stop him given enough time. But as long as your name doesn't end with "himomura" this shouldn't be a problem.
-W.W.
STOP FEEDING THE TROLLS (Score:2)
After trying to figure out if someone is trolling for karma, I figured out that all of the replies to the post are part of the post itself. If you click on any of the replies to the above post, you get the reply from the original thread.
I dunno of any of the repliers being quoted are trolls harvesting for karma, but every time this "post" and its "replies" get modded up, it wastes points better meant for real replies.
Kind of an interesting social engineering hack, if nothing else. Either way, please ignore this post in the future.
Jay (=
(My second try on this...)
Re:Kurt is usually the man.... (Score:2)
apt-get -b source portsentry
apt-get -b source aide
Daniel
Debian Missing? (Score:3)
Why should the presence/absence of a CD iso-image matter?
Re:Linux "security" is disastrously obsolete. (Score:2)
Re:security... (Score:3)
I know the feeling. The most important thing you can do, as the previous poster said, is disable everything network-related that you don't need right now. Comment everything out in /etc/inetd.conf, add a line "ALL: ALL" to /etc/hosts.deny (thus denying access to many network services by default), and turn off every daemon that you don't know what it is (don't worry, you most likely won't break anything), probably by removing entries from /etc/rc.d/. Then, check out Mandrake's updates regularly for reports of any software with security holes, and upgrade or remove that software.
That's the easy (and most important) part. Then, you can install a kernel-level packet filter (ipchains, iptables) to block all suspicious packets, and install and use ssh rather than telnet and ftp, which are incredibly insecure (anybody nearby with a packet sniffer can compromise your system). Finally, 'chmod 755' all suid root programs (their permissions start with "-rws", and they are often used to gain root from a normal account) from /usr/bin and /usr/sbin, though this is not really so important for a single-user machine.
Once you've done all that, your system is rather tight. Always stay paranoid, though, and regularly install security patches and read your logs as often as possible. You can then re-enable services as you learn how to configure them properly. Also check out the linux security HOWTO [unc.edu], though it mostly says what I just said (but is much more wordy :).
Home users (Score:4)
Your enthusiasts are going to have the full range of skill sets, from rank beginner to seasoned UNIX gurus. They don't have to justify their desire to install the OS, and they should be able to do so while remaining reasonably certain that if they connect it to the Internet, they won't immediately be taken over by script kiddies.
Moreover a reasonably competent system administrator who is responsible for a fair sized chunk of a large company is going to want to choose the distribution that allows him to do as little work as possible once he installs a new platform. He's also going to want automated tools so he can update a thousand machines at a shot and more automated tools so that most of the log crap gets filtered, so he only needs to pay attention to the trouble spots.
Furthermore I've yet to run across a company that has a resonably competent system administrator. Many of them are hired to point and drool at NT systems and are given responsibility for the UNIX machines as an afterthought. With many more, a group gets a UNIX box and its administration gets tacked on to someone else's job description. Test code, write reviews, administer UNIX box. Write documentation, administer UNIX box. Take customer calls, monitor network status, administer UNIX box. Write database software, administer UNIX box. Beats having to hire a sysadmin for $125,000 a year, doesn't it?
Forgetting RedHat Rawhide and others ... (Score:2)
I believe a set of kernel 2.2.16-1 RPMs appeared on RedHat Rawhide within days. It wasn't until 2 weeks later when the 2.2.16-3 kernel set was tested before RedHat officially announced the RPMs with the press release.
Note to reviewer: At least we have the option of running untested stuff at our own risk from various distro test labs and sites. You don't have that option with "Muppet Labs". ;->
-- Bryan "TheBS" Smith
Re:ummm... (Score:2)
--
Debian / Slackware (Score:3)
Oh please. A slow release schedule should mean that the distribution is MORE secure if anything. It means that the software included is tried and tested. This is one of the reasons why Debian potato uses a 2.2 kernel and a 3.3 XF86.
Is this the best reason they could come up with to not cover Slack and Debian? Either this guy is flat out lazy or he knew something about Debian and Slackware that would just not compare well against the others. Either way it makes me question his knowledge of the material at hand.
Besides, Debian's apt makes security updates tons easier than reading bugtraq and making sure you download the right RPMs.
[..] will focus on the major Linux distributions: Red Hat, SuSE, TurboLinux and Caldera, plus a few others.
Since when are TurboLinux and Caldera major distributions? Major distributions in my opinion are RH, SuSE and Debian. Slackware, while excellent, is too much a geek niche to be considered major. TurboLinux suffers the same categorization for Asian language support and I just don't know what anyone would do with Caldera.
Too bad Mandrake is missing. (Score:2)
I'm not sure why Mandrake was left out; the author even praises their efforts toward a secure distribution. Hmm, they even include it in the final wrap-up, though with no supporting data. Too bad.
I'm sorry to see Mandrake missing from this line up. Maybe an interesting accompanying piece would be a comparison of the three default Mandrake installations side by side.
yours,
john
Re:Kurt is usually the man.... (Score:2)
Kurt Seifried has always disregarded the Debian/GNU Linux and Slackware distributions for as long as I've started reading his material. Just digging up a past hard-copy of the Linux Administrator's Security Guide [securityportal.com] from last year, it is interesting to note he provides the following distribution notes in his guide:
Seifried still hasn't gotten around to writing any information for either of them for his now fully online version of the guide. Speaking as a Debian user (note: I'm still outraged by how Seifried has brushed Slackware aside) and a person who frequents irc.debian.org's #Debian a lot; the philosophy of Debian is that the latest does not equal the greatest unlike most commercial distributions. These long release cycles are there so that when you get a stable copy of Debian, you're assured that months of testing have ironed out bugs and security holes that would otherwise bring down essential services you may be providing. Debian's apt-get is still one of the best and easiest to use tools out there for keeping a system up to date and secure. Remember that Debian also takes a three-pronged approach to releasing new versions as well. Stable for those who the utmost reliability. Frozen (i.e. beta) for those who wanting new releases that are close to becoming stable. And of course, Unstable (i.e. alpha) for those wanting to be cutting edge. Debian has release cycles that can suit anyone.So please don't let Seifried's lack of experience (and credibility) in dealing with Debian and Slackware be influential in your decision to use them.