[sf-lug] update from computer newbie

[Rick Moen]

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?

Fair question.

One way is to glean lessons from the security _history_ of that piece of
software.  Here are several infamous examples from earlier in Linux
history:

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
> passwords.
>    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
meaningless.

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
electrically.

> 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
> software. 

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
Craftsman.