Slashdot Mirror
Linux Security: Reflections on 2002, Eye on 2003
Mirko Zorz writes "Here are the reflections on Linux security in 2002 and predictions for 2003 by Bob Toxen, one of the 162 recognized developers of Berkeley UNIX and author of the acclaimed book "Real World Linux Security" already in its 2nd edition. Read more at Help Net Security."
That was a rather disappointing article. He only made one Linux-related prediction: that there will be a major Linux virus. Besides that, everything else was generic and not Linux specific.
He says that he predicts (and hopes) that the practice of using honeypots, etc. will decrease; that it only serves to illustrate to managers that security will be breached. Thus, we can assume that all sufficiently weak security will be breached eventually, ergo this practice is useless.
He forgets the other valuable feature of honeypots. You can deploy prototype installations and observe the kinds of attacks in the wild, to get a feel for the capabilities of the advisary. These techniques change over time, and that information is invaluable when determining where effort needs to be focused in a security plan for your product.
This short-sightedness casts doubt on some of the other parts of his essay, other than on the obvious points (to us at least, those involving Microsoft, Hollywood, the man keepin us down, blah blah blah)
Fuck Beta. Fuck Dice
There will be flying cars to take us to and from work.
I have been pwned because my
2.) Use RPM based Linux Distribution and leave system alone (risky as swimming in a americanized river).
3.) Use OpenBSD and leave system alone (like sitting on a Sunday with your grandma in Utopia(tm)).
Is this the type of "security" they're talking about? I don't know of one system that advertises itself as "secure" other than OpenBSD. For an opensource site like slashdot I think the best tool for the job should definantelly be used.
Or if you insist on a RPM Linux solution, ge Bastille. And possibly look into a non-RPM based distro, for servers debian certainly works quite well. And if your server is IMPORTANT at all, subscribe to bugtraq, cert, and anything else that applies to your OS. It wouldn't hurt to check the homepage of your OS at least once a week either. And do routine audits on your system.
Security isn't hard if you actually make it a point to be conscious about it.
Ignore the "p2p is theft" trolls, they're just uninformed
Unfortunately, a fair number of "Mom and Pop" sites use IIS, though a surprisingly high percentage do use Linux. For this reason, before giving my credit card to a new web merchant I always do:
nmap -O -sS -F -P0 -T Aggressive newguy.com
Stealth port scan with agressive timing? Now that's consumer activism.
but more of an upswing in new exploits/overflows/etc as more people begin to scrutinize the code - think microsoft has anyone looking for "problems" to announce in a FUD campaign? New ways of distributing them will also be found - but even then there will be those who proclaim their immunity. "It was in an PassiveZ attachment, but since I just use an old line printer as my mail spool, it didn't get me".
Don't blame me, I voted for Kodos
Yeah, people act like only MS can get infected with a virus but there will be a major linux virus soon. It is going to happen. As linux gets more exposure more schmucks will write malicious code designed for busting up linux boxes. It is not like the Unix world is some foolproof world of rock hard servers.
After all, why did linux inherit the Unix concern for security?
Enough old-school unix guys have been bitten by the bad security in telnet and NIS and a half dozen old world Unix services with big nasty security issues.
Sure Bastille linux or RedHat secure server makes decent choice and OpenBSD is locked pretty tight right out of the box. That does not mean that it is impossible to break into those boxes. Just that it is more difficult. All you need is a one-day lag between a security issue posting on Cert and the patch to whatever software you are using coming up for your distro or OS. It can happen to any of us. It will happen to many of us.
The over-confident are always the funniest to watch when their shit hits the fan.
The honeypot thing is interesting. I have always wondered if you really get enough useful information from the attacks to warrant the time put into the systems. Somehow it just smacks of a geeky wanking waste of time. On the other hand, maybe the information from such implementations really make this worth it.
Any comments on this?
ACK
You guys should know that a trivial remote root hole for SSH was released today on bugtraq.
:)
Someone who wants karma bad enough should reply to this with the advisory
I really think that this Toxen guy should quit spouting on about SuSE installing too many services by default. None of the services he complains about is installed by default. He needs to really download and install a Linux distribution that has been released in the last couple of years. You have to turn on the services now at least for SuSE 8.1. He may have written some good stuff in his day but he should do some research before he makes a fool of himself in print.
Really, is Linux a Secure OS(tm)? No, not really. It's not as popular as Windows, and the security model is better developed than Windows (courtesy of the Unix legacy), which leads to it having fewer exploited exploits, but...
Is it really that much more secure? Not really.
The key to security is implementation. Solaris isn't inherently incredibly secure. Secure Solaris is. Linux? Nah. the NSA Linux? I imagine so!
FreeBSD (and the other BSDs even) was designed with the intention of being secure, and so it is far moreso. So is NSA Linux and Secure Solaris. That ha nothing to do with the inherent security of the base product, though.
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Nope, seems to me Toxen's pseudonym is "Zorz".
Comment removed based on user account deletion
No, this is not a troll, it's my book review. Toxen should write a book about his days working with the BSD folks, he'd sell a million. But as a Linux security book, I'd suggest the man pages first.
into and serving trojaned copies of the source
certainly does reflect badly on Sendmail's security.
If they can't secure their distribution machine,
how well can they code umpteen years of crappy code?
Of course, in spite of the OpenSSH bugs, I'd use them any day before the ssh.com code.
Of course honeypots can also be used to learn what hackers do. The Honeynet Project is a great place to go to learn how to set one up securely so it can't be used to attack other people.
In fact, today a new version of honeyd was released:
Toxen's fear of Honeynets and Honeypots shows the "if I don't understand it, it's not good" theory I find in too many managers. He should take some time to run a honeypot or two and see how useful they can be.Comment removed based on user account deletion
Man Gets 70mpg in Homemade Car-Made from a Mainframe Computer
Naturally, you should check the pgp signature and/or cryptographic checksums before trusting any code you download.
There are still bugs in SSH.com's version - mostly stability, but I bet there are several security bugs too. OpenSSH will be updated several hours after new bugs are found - can you say the same for SSH.com's versions? I don't think so, not if history is a guide.
your right, all those damn nimda infected desktop PC's had top secret info on them.
.... prototype designs ...... i could sell these .....
...... well get your head checked.
hey i cracked grandma's PC with code red..... look birthday photos !!!!
thats what i would classify as a yawn.
then you have the --> i just cracked IBM's (insert corporate type.) desktop
not saying that either will or has happend. but which would you fear more as an executive at HP , Sun, IBM et al ? your consumer end products getting hosed because of microsofts boo-boo. or your corporate infrastructure getting hosed ?
and yes i happen to work at one of the above mentioned companies and we easily run 30% of our desktops on linux. (with plans to get 80% to linux by the end of '03) (the other 20% is being kept for R&D and support purposes)
and if you were talking about unix
"Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe." --Albert Einstein
All security is an issue of the userland software, not necessarily the Linux kernel itself. The userland software in question is: all of it.
/other than that, the userland tools taste like chicken and the kernel still smells like hering.
Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes. Telnet and SSH still allows people to do bad things, as well as good things, to the hosted account's property.
Alas, the Linux kernel is a perfect angel...but hark, what do I see? A "Tux" http server in kernel space? That is quite dangerous. No matter what the performance benefits, leave those kind of user-services outside of the kernel because each and every bit of code in kernel land makes the Linux kernel that much more closer to an "unknown" exploit.
The userland software in question is: all of it.
/usr/local/apache/bin/httpd' and noone would ever get something like root by hacking into your apache webserver.
...). But access restrictions can't protect your system from users/processes who are privileged to override these restrictions, and that's why you need fine grained privilege controls to build really secure OSs.
No, only suid binaries. You don't hack into something which runs in the context of your own account (your own level of access).
Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes
That's the difference between a secure configuration of common OSs like Linux, Free/Net/OpenBSD,... and really secure OSs like VMS or Trusted Solaris (yes, Unix can be a really secure OS).
Secure OSs don't run things as root, they assign privileges to certain users and/or binaries instead. For example, you don't want to allow Apache to override the Discretionary Access Control when it actually only needs 'root' to open port 80.
On Trusted Solaris you just do 'setfpriv -m -a -f net_privaddr
That's how the 'principle of least privilege' works.
There is mainly one thing wich keeps your system secure: Access restrictions (users must not load kernel modules, mount disks, access files which they're not allowed to access,
There is a rationalization going on in business IT. This is not a recession at all.
I don't think any of the things he listed as vectors for a new Linux virus are realistic. There are too many different mail clients and instant messangers. On the other hand sendmail, apache, or bind would make great vectors. Even if their security is good all it takes is one flaw. And nobody is perfect.
Perhaps he should start by reading bugtraq. If he had, perhaps he would have seen this hole in ssh.com's lovely software in 2002.
http://online.securityfocus.com/bid/6247
Or, who can forget this unbeliavably idiotic mistake in their client from 2001
http://online.securityfocus.com/bid/3078
Yet he call's it more reliable that OpenSSH. Maybe he should look into the nice new privsep code in OpenSSH and comment on that. So called security experts make me wish public floggings were still a common event.
Linux is terrible at enforcing least privilige. With kernel changes, such as those provided by RSBAC or LIDS, you have the power to enforce much better privilige control, but it's all up to the user. What we really need is a mainstream kernel that supports ACLs and auditing on failed reads and a distribution that ships packages that have nice restrictive ACLs by default, for daemon users. That way, access can be given to only those files that they require and you can find out when they try to access a file that they shouldn't. Given proper default ACLs, a SINGLE deny read in your logs should indicate a compromise. That simple level of auditing would improve the security of Linux by at least an order of magnitude (well, assuming that someone's watching the logs, of course :)
I'm tired right now, but wasn't it the RIAA goons and not Microsoft? Correct me if I'm wrong.
As another responder so aptly pointed out, the package management system has nothing to do with security, unless you are using file verification as part of your security plan (which isn't a bad idea.. do "rpm -Va" for system-wide verification of all files known about in the rpm database).
However, if you have to support real-world applications, and not just your webserver at the other end of your cable modem, there is another aspect to system security and stability, and that is THIRD PARTY VENDOR SUPPORT.
Now, I realize that the number of guys on /. who actually do stuff for a living that doesn't include final exams is minimal. However, if my boss/engineering staff/customer wants a product for a specific purpose, say, backups, or CRM, or CMS, I don't have the power to say "well, sorry, but we only run StinkyFeet Linux, not Blue Bonnet like that vendor requires". If they don't can me, they'll just go with a Windows-based app to get around that headache.
So then, what good does it do to have several distros around? They all run the SAME PACKAGES, imagine that! And when there is a hole in OpenSausageStuffer on an RPM-based distro, there is going to be a hole in OpenSausageStuffer on a non-RPM-based distro. The Horror!
So instead of having one distro network-wide, which has the same version/feature set across all systems, and the same cronjobs for updates, etc, i now have several, because some fool decided that he didn't have the time to make the appropriate decisions and shut things off. hmmm...
And that doesn't even get into the headache of trying to deploy my own packages, or dealing with the preferences of my users, or with the terms of a contract.
In short, being a stick in the mud about distros isn't going to gain you anything. And not learning how to do your own security in favor of a crutch like Bastille isn't going to gain you anything either. Jay has a good idea, and it's great for noobs, but if I'm paying you (or if you're paying me) to secure a system you better fucking know exactly what is going on. And when security requirements change, you better be able to handle it. Relying on someone else's idea of secure is a place to start, not the final answer to your own security. Security is a process, not a product, no matter what your little imagination tells you.
When it comes to system security, the best distro for the job is the distro you know the best, not the /. poster's favorite distro. A newbie to HandCreamBSD isn't going to be any better off than a newbie to Blue Bonnet Linux.
--mandi
Toxen is recognized for developing the BSD lock(1) program.
If the honeypot is not breached is the system secure? Of course not. You have learned nothing. If you instead did that code audit and security audit then you would have more confidence that it was secure than when you started.
I stand by my claim that for most people, the time spent on a honeypot does not have technical value.
Bob Toxen, Author, Real World Linux Security, 2nd Ed.
Security Consulting,
SuSE first flushes existing rules and then adds new rules. Thus, for a short time there are no rules but the default for each chain is ACCEPT. They are saved only because networking has not yet been turned on. I suspect that this is more of an accident than intent because the correct solution is to first set the defaults to DROP, then add rules, then change the defaults to ACCEPT if that is your desire.
There are other weaknesses in the current SuSE.
Bob Toxen, Author, Real World Linux Security, 2nd Ed.
Security Consulting,
I said nowhere in my article that "IIS admins all suck" nor any comments on their ability. However, with minor hardening and good practices, a Linux web server mostly is at risk for compromise due only to a vulnerability discovered every year or more. From reports I've seen, an IIS server is at risk from a new remote compromise almost weekly. This represents a ratio of roughly 52 to 1 in risk.
I made no claims about the Operations staff at eBay, Barnes&Noble, etc. It does appear, however, that B&N uses special content-based filtering in front of their IIS server. The NMAP scan will show such special filtering by its inability to determine the operating system. No doubt they also have people on the ready 24x7 to instantly apply new patches.
I also never said "Buy Linux servers, they're going to be 'secure". I do believe "Start with Linux, then harden it as per 'Real World Linux Security, Second Edition', subscribe to bug tracking lists, patch quickly, and you will be much more secure, spend far less effort, and spend less money than dealing with Microsoft". UNIX, Macs, and other platforms also have a good history of security if hardened.
Bob Toxen, Author, Real World Linux Security, 2nd Ed.
Security Consulting,
You stated that you refused to use any online service running IIS. That seems a bit on the xenophobic and fanatical side.
/lot/ about your veracity. Good stuff.
I would certainly trust bn.com with my money. There is no reason for me to high-tail it to Amazon simply because bn.com uses IIS.
The Average User running nmap is another matter entirely.
The Average User would have to install WinPCAP. Unless the average user is running Linux in this case, where nmap must be run as root to use the -O switch.
Shortly, there is no reason for the average user to have nmap installed on their machine (linux or Win32). Same reason that the avg. user doesn't know how to use TCPDump, Ettercap, etc. NetCraft is easily accessible by anyone.
Of course, nothing's perfect. NetCraft goes by banners largely, so you end up with sites like Walmart.com, running IIS5 on Linux or Solaris.
Posting from work, I didn't have the time to respond past a quick rant. Nor did I ever expect a reasoned response. I really appreciate the fact that you took the time to read the article here and reply to posts, that says a
Thanks.
I like music