[svlug] Server Hardening

[Lord Sauron]

On Thursday 21 September 2006 09:58, Rick Moen wrote:
> Quoting Lord Sauron (lordsauronthegreat at gmail.com):
> > I'm totally new to hardening a server.  I'm a desktop person, so I
> > know a lot about that, but on the other side of the net I'm a total
> > newbie. So, educate me please!  I do want ten different answers,
> > since they all will have something to add.
>
> OK, so the first thing you do is re-examine the assumptions that
> suggested to you the principle of "hardening".  (I know you were not
> the one to bring it up, so please pardon me if I seem to be picking
> on you: I'm addressing this to others, as well.)  As usually
> intended, the idea in question is to start with a conventional system
> and apply some secret sauce that makes it "secure".
>
> That would be lovely; unfortunately, the world does not work that
> way. As Bruce Schneier says, "Security is a process, not a product."
> Instead, you start with building a deliberately simple, sparse,
> auditable system (with simple, small programs, exposing as little
> code as possible to attack), one that you can fully understand, has
> predictable characteristics, and uses nothing but well-designed
> software that fails to suck when examined for doing The Right Thing
> (e.g., input validation).  And have an explicit security policy. 
> (Every host has a security policy; most are merely implicit and not
> recognised.)
>
> So, for example, someone asked "Which wiki?" and you popped up with
> the usual suggestion of "MediaWiki" -- certainly a popular and
> ubiquitous suggestion.  After all, if it runs Wikipaedia, it must be
> pretty good, right?  Not so fast, though.  Let's look at the
> dependencies:
>
>   PHP 4.3 or higher  (5.0 or higher for MediaWiki 1.7 and up)
>   Any Web server, but Apache2 suggested
>   MySQL 4.0 and up (4.0.23 and up suggested).
>
> Does all that seem OK to you?  If you had much security background,
> you'd be shaking your head.  MySQL has had some significant security
> problems, but PHP's been a veritable sewer on account of fundamental
> desig and implementation errors, and many applications built
> on it have been just security train-wrecks.  Let's look at
> http://sourceforge.net/project/shownotes.php?group_id=34373&release_i
>d=375755 :
>
>   December 4, 2005
>
>   MediaWiki 1.5.3 is a security and bugfix maintenance release.
>
>   Validation of the user language option was broken by a code change
> in May 2005, opening the possibility of remote code execution as this
> parameter is used in forming a class name dynamically created with
> eval().
>
>   The validation has been corrected in this version.
>
> Oh, marvellous:  They screwed up input validation -- which is so
> _extremely_ common in developed PHP apps that you learn to just
> expect it.
>
> There are other items listed in that Changelog, but they're mostly
> cross-site scripting attacks and attacks/DoSes against the user's
> browser, none of which are vulnerabilities in MediaWiki per se.
>
> Now, MediaWiki's a whole lot better than most PHP software, but one
> point I'd like to make is that attempting to lock down an
> overfeatured, overcomplex piece of software is a gratuitously
> difficult and probably somewhat doomed effort, over the long term. 
> That is one reason why SVLUG's existing prototype wiki conversion is
> NOT on MediaWiki, but rather MoinMoin.  Here's MoinMoin's dependency
> list:
>
>   Python

I really need to learn Python...

> You probably also want a Web server, but you don't strictly need one,
> because MoinMoin can use the "built-in standalone Python http
> server", if you prefer.
>
>
> Important principles of security (quoting from _Firewalls and
> Internet Security: Repelling the Wily Hacker_ by Bill Cheswick and
> Steve Bellovin, which you should read):
>
>   "The moral of this story is, anything you don't understand is
>   dangerous until you do understand it."
>        -- character Beowulf Schaeffer in "Flatlander" by Larry Niven
>
>   Murphy's Axiom 1:  All programs are buggy.
>
>   Theorem 1 (Law of Large Programs):  Large programs are even buggier
>   than their size would indicate.  (Proof:  By inspection.)
>
>   Corollary 1.1:  A security-relevant program has security bugs.
>
>   Theorem 2:  If you do not run a program, it does not matter whether
> or not it is buggy.
>
>   Corollary 2.1:  If you do not run a program, it does not matter if
> it has security holes.
>
>   Theorem 3:  Exposed machines should run as few programs as
> possible; the ones that are run should be as small as possible.
>
> Cheswick and Bellovin's book is, of course, mostly about firewall
> design, but the principles enumerated are universally applicable to
> hosts.
>
> Security author Marcus J. Ranum puts it a different way:
>
> o  Run software that does not suck
> o  Absolutely minimize Internet-facing services
>
> See this essay ("What Sun Tsu Would Say"), ASAP:
> http://www.ranum.com/security/computer_security/editorials/master-tzu
>/

So, I should write my own minimalistic wiki if I really need a wiki and 
use Apache2/PHP5/MySQL4, shut down all the things I don't use and pray 
that there isn't any issues with subversion and ssh and rsync which 
I'll probably be using and pray that there's nothing wrong with 
whichever mail server I finally decide on using?

Cool.  Sign me up.  I was a bit skeptical of using mediawiki (was still 
not entirely sold on a wiki to begin with) and I'm generally pretty 
good about my code's ratings in the baboon-testing (almost literally 
letting a baboon beat on the keyboard and seeing how your app 
responds.)

> If you really want to learn security, reading a bunch of what Ranum,
> Schneier, and Cheswick/Bellovin wrote would be an excellent place to
> start.  Start with Ranum; he's hilarious, and the stuff's online for
> free:  http://www.ranum.com/security/computer_security/
>
> Then, you'll know without my having to argue with you why running
> Apache2 instead of 1.3 is a blunder, and why running out and
> installing PHP5 because it's the newest and shiniest is a really bad
> idea.

PHP4 still has OO features, right?

I'm not certain why I'd pick Apache2 over Apache1.3...  All I know is 
that it's better than IIS.  If 1.3 is better, then I'll use that.  I'm 
not certain why I need a multithreaded webserver.  I'm not even using a 
dual-core chip!

> (Read _Schneier's _Beyond Fear_ for why newer is bad in
> security-sensitive code.)
>
>
> Unfortunately, most computer geeks are completely hopeless at
> understanding security, because they have all the wrong instincts:
> They're gadget freaks, and go straight for the new-shiny complex
> thing over the tested, simpler, small, reliable one, every bloody
> time.

I'm the kid who got pissed off at Java's dorky syntaxing of arrays and 
learned C++.  I'm atavistic by nature - I'm not a hard sell for what 
you're trying to tell me.

-- 
http://lordsauronthegreat.googlepages.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20060921/3ffdc68d/attachment.bin