[sf-lug] update from computer newbie
rick at linuxmafia.com
Sun Jul 9 15:34:25 PDT 2006
Quoting jim stockford (jim at well.com):
> boy, the attack of the white corpuscles!
> The general problem I have with the recent stream is that
> of generalness: don't run cruddy software, be aware of
> the risks....
> Gosh, how do I know?
One way is to glean lessons from the security _history_ of that piece of
software. Here are several infamous examples from earlier in Linux
o The standard nameserver software, used by everyone, was BIND v. 8.x,
which ran as the root user and suffered a series of disasterous
security breaches (usually buffer overruns), such that you were
forever applying the patch of the month if you wanted to stay ahead
of the attackers. Why? It turned out that BIND8 was basically
unfixable spaghetti code from long-gone UC Berkeley graduate
students, and maintainer Paul Vixie readily admitted this and said
that patching was just a stopgap while a real solution was developed.
That real solution was a ground-up total rewrite that he commissioned
from Nominum, Inc., which was released as BIND 9.x -- having not a
single line of code inherited from BIND8, but rather entirely new
code written from the specification of what BIND8 was supposed to
have implemented. BIND9 has its flaws (slow, large, overfeatured,
monolithic design), but has had a good security history and is said
to be soundly written and (unlike BIND8) legible. Moreover, it
drops root privilege after binding to port 53, so only a tiny portion
of the code ever runs as root.
o Similarly, the standard print daemon used to be lpd or its fork
lprNG. Both ran as root and had the same spagetti-code problem
and resulting recurring woes. Smart people used hostaccess files
(/etc/hosts.allow, /etc/hosts.deny) or address/port filtering to
limit access -- why permit the Internet to talk to your print
server? -- but the real solution was to throw away lpr and switch
to CUPS, which also had other advantages like mere humans being
able to set up, configure, and debug it.
o Sendmail prior to the last few years was a very similar case for
very similar reasons: overfeatured monolithic binary that ran
with root authority, that suffered recurring breaches. Of late,
it's been extensively fixed and drops root privilege per prior
comments about BIND9.
o wu-ftpd and ProFTPd are overfeatured ftp daemons written as
unfixable spaghetti code. wu_imapd and qpopper are mail
delivery agents, ditto. The NFS rpc.statd and rpc.mountd daemons
are questionably written generally and have had a few problems,
though exposing NFS to public networks is unwise anyway. Same
story to a degree with Samba. And OpenSSL has had a few buffer
overflows and remains a point of concern.
o Lately, because the bad guys figure lots of unwary sysadmins
unwisely install Web apps outside their distros' package regimes,
attacks have concentrated there since the above daemons have
mostly been fixed and are kept updated. Sysadmins forget that
Web apps have to process public data, starting with the URL lines
fed to them. Therefore, they must do careful input validation --
and unfortunately a lot of "casual Web apps" developed by
inexperienced PHP and Perl coders, including AWstats,
WebHints, and the two XMLRPC libraries for PHP (used to build
some of the more bloated PHP apps) have turned out to have
basically _no_ input validation checking at all, which is why
they keep showing up on the "critical security alert" lists.
To recap and point out a few trends:
1. Overfeatured apps are bad, especially if they have to handle
data from arbitrary public sources. Security-sensitive code
should have only the feature set necessary, and not the kitchen
sink (***COUGH*** MSIE ***COUGH***).
2. Some apps turn out to have been so badly written that they
cannot be fixed, and you need to find something else
(wu-ftpd, ProFTPd, lpd/lprNG, BIND8, AWstats)
3. All other things being equal, a big do-it-all monolithic design
is bad for security-sensitive apps, and modular design is better --
but dropping privilge after starting's a pretty good substitute.
4. Software that for some reason you need to install outside your
package-management system needs to be watched carefully for
unfixed security holes.
> My experience is
> * One box was directly hooked up on the net. I walked by
> and saw the LED blinking furiously. I'd been cracked:
> some guy, seems like in Korea, set up malware that was
> attacking the internet from my box. I pulled the plug, put
> in a new hard drive, reinstalled, and used better
> I inspected /root/.bash_history and learned a lot about
> cracking and rootkits.
> Speakeasy sent me harsh mail.
That's happened to most people, at various times. Depressingly,
usually your system was actually cracked by an automated script that
strobes up and down IPs and runs canned attacks against them, looking
for the computer equivalent of an unlocked front doorknob.
> ...the hated NAT....
Yes, it violates the end-to-end principle, but without it, we'd have run
out of IPv4 space long ago, so it's something we live with. (Not
coincidentally, providers charge significantly for extra real IPs.)
> ...apparent hit rate....
For reasons already noted, relative attack "hit" rate is pretty
To continue my door metaphor, you and a neighbour are sitting down and
comparing how many times during the day you heard someone twisting your
appartment door knobs. With you, five times. With him, 25 times. Should
you conclude that his appartment faces a 5x greater threat than yours does?
No; you should both make sure you _lock your doors_, and stop obsessing
over meaningless trivia.
The MS-Windows world with its grandiose "firewall" software that sends
you melodramatic notices about an "attack in progress" has conditioned
many people to obsess over meaningless trivia.
> My hard drives have died, data lost, grinding of teeth. Now I have
> RAID 1, with dual drives, pretty much all partitions are mirrored.
Yes? And how are your backups? Test-restored a set lately? I hope you
aren't confusing mirroring with backups. You'd learn the difference in
a hurry the moment that a misbehaving process clobbers the data on both
drives simultaneously, or a failing PSU or host adapter burns them out
> If data is small, floppies work great.
Gosh, I remember floppies. Of course, these days we have USB thumb
drives, and rsyncing to remote hosts over the LAN, and CDRs -- all of
which are much more reliable and faster.
> If big files and no CD burner, what about sending data
> off in an encrypted stream to some online repository?
Not _my_ data, thanks: http://linuxmafia.com/faq/Essays/winolj.html
> But how do I know what's cruddy in the Linux world?
One suggestion: Read Linux Weekly News, spot trends. Talk to other
people. Learn from experience but more so from others' experience.
> But trusting internet reports is akin to trusting rumor or trade mags.
I didn't mean swallowing whole accounts from net.randoms. Some stories
are internally consistent and check out against scrutiny; others don't.
Learning a bit of how security actually works is of course essential, if
you don't want to suffer the awful fate of warring pundits.
> Detecting malware is forensics--a seemingly unclimbable learning curve.
1. No, not really. Did you follow the provided link, and read
"Constructive Paranoia at the End of 2003", by the way?
2. Preventing it's much more useful than detecting it, I do believe.
> Marcus's story of the princes seems to suggest that I write my own
No. I can only suggest that you read it again.
> My purpose is to learn, mainly to get money in the industry,
> secondarily to oppose MSFT.
Perhaps I shouldn't denigrate other people's hobbies, but isn't it a bit
of a waste of time to "oppose Microsoft"? I mean, you can use Snap-On
tools without declaring yourself the implacable enemy of all things
More information about the sf-lug