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
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.
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
ERRATA:
8 01.txt as soon as it becomes
--- begin cut & paste ---
To: BugTraq
Subject: Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
Date: Jan 6 2003 8:05PM
Author: Global InterSec Research
Message-ID:
In-Reply-To:
As some may have gathered, the advisory recently posted by mmhs@hushmail.com
was indeed a fake, intended to highlight several unclear statements made in GIS2002062801.
The advisory in question is currently being updated with more detailed information and will
be
re-posted at: http://www.globalintersec.com/adv/openssh-2002062
available.
Note that the kbd-init flaw described in GIS2002062801 was proven to be exploitable in our lab
although not all evidence to demonstrate this was provided in the original advisory. A mistake
was made in the original advisory draft, where chunk content data was shown, rather than the
entire corrupted malloc chunk. This will be amended in the revision.
Also note that to our knowledge there are currently no known, exploitable flaws in OpenSSH 3.5p1,
due to its use of PAM as suggested by mmhs@hushmail.com. It is almost certain that the posted
bogus advisory was also intended to cause alarm amongst communities using OpenSSH, through
miss-information.
Global InterSec LLC.
--- end cut & paste ---
The original advisory I was talking about can be found here.
Sorry for misguiding you, humble slashdot readers.
Comment removed based on user account deletion
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.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.
You guys should know that a trivial remote root hole for SSH was released today on bugtraq.
The posting appears to be a fake. (I wonder why your snake oil alerts didn't go off...)
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.