httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorge Schrauwen <>
Subject Re: A fundamentally secure Apache server, any interest?
Date Mon, 16 Nov 2009 19:05:12 GMT
On Mon, Nov 16, 2009 at 5:11 PM, Sander Temme <> wrote:
> Hi Kevin,
> Definitely not the right list: this is where we discuss development of the Apache HTTP
Server code. may be a better forum within  Outside Apache,
several initiatives exist to look into hardening web servers.  The Center for Internet Security
<> is one of them.
> On Nov 16, 2009, at 8:42 AM, Sweere, Kevin E CTR USAF AFRL/RYT wrote:
>> I work for the US Air Force.  We have a prototype that dramatically,
>> fundamentally increases a web server's security.
>> We run an Apache server within a minimized, user-level-only, Linux variant
>> only within RAM and from only a DVD (no harddrive).  With no shells, hackers
>> have nowhere to go.  With no persistent memory, malware has no place to
>> reside.  A simple reboot restores the website to a pristine state within
>> minutes.
> I agree.  Putting the entire OS and content on a read-only device (whether DVD or otherwise)
significantly reduces your exposure to attacks for all these reasons.  The OS will need *some*
writable space (like /tmp and /var/run), but I assume you made like Knoppix and Ubuntu Live
and their ilk, and use RAM disks for that.
>> Because a LiveDVD holds the OS, apps and content, its best for static,
>> non-interactive, low-volume, high-value, highly-targeted websites.  Any
>> change means burning a new DVD, but this also makes testing easier and less
>> noisy.  Logs are tricky to extract.
> You could write logs to a RAM disk, with obvious implications on retention.  Or you
could spool them to another server either through a network mount or mod_log_spread.  The
httpd configuration language allows you to put log files in any place you like, and there
are several approaches to rotating log files if space is an issue.  Or you can use a third
party module to write logs like the aforementioned mod_log_spread, which is not part of httpd
>> While it has worked well, some of us believe its usability drawbacks (e.g.
>> limited ability to receive input from users, every change needs a new DVD)
>> outweigh its great security benefits making it unmarketable (in govt or
>> industry) and thus just another prototype to leave on the shelf.
> You are in for a perpetual war between Operations (whose pager goes off when things break)
and dev (whose time-to-market is implicated by the fixed environment).  You could mitigate
that problem by reading site content from a remote machine, either continuously over a network
mount or by copying it into a RAM disk on boot.  The former might be slower, but would allow
for more frequent site updates.  It's a trade-off, as usual.
> Keeping the remote mount read-only (even for root) will allow you achieve your goal of
a read-only environment.
> More comprehensive upgrades that would involve adding modules or changing configuration
parameters should trigger a change management process that would lead to an update of the
boot image.

You could just mount everything ro from a remote host then, even the
config for example, could be mounted from a remote host.

I guess a rw usb key with OS + config would work too if you can
somehow force it ro only when booting from it.

>> I'm curious what your group thinks.  Thanks in advance -- I don't quite know
>> with whom to discuss this idea.
> As Mark points out, this would be very secure but very hard to manage, and my impression
is that time-to-market pressure and available expertise frequently cause ideas like this to
fall by the wayside.
> Fundamentally, booting web heads from a read-only medium like an optical drive or PXE
is a sound idea.  Any initiative, installation method or distribution that makes this easier
to manage might increase adoption.
> S. <bikeshed>I'd base it on BSD though</bikeshed>
> --
> Sander Temme
> PGP FP: 51B4 8727 466A 0BC3 69F4  B7B8 B2BE BC40 1529 24AF

Thats all that comes to mind atm.


View raw message