[svlug] Server Hardening
lordsauronthegreat at gmail.com
Thu Sep 21 16:26:20 PDT 2006
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
> 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
> 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
> 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
> 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
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
> 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:
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
> 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
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
> (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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 191 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20060921/3ffdc68d/attachment.bin
More information about the svlug