httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael.Schro...@telekurs.de
Subject Re: German document about Apache Security
Date Wed, 14 May 2003 12:51:40 GMT

Hi Kess,

> The document contains 167 pages and I haven't read them all.
> It looks good at a first view - and maybe more interesting:
> The study attests the Apache HTTP Server to be secure by
> default installation. Great ;)

I see a problem in the meaning of the term "default
installation" here that may have a lot of consequences
for the unwary reader of this study.

Many installations existing in the real world are using
a "default installation" - which is _not_ the one from
the Apache Group, but the one of some packager (Suse,
Red Hat etc.).
For these "default installations" basic statements from
the study don't apply any more, to say the least.
But how would an "average Apache admin" know about these
different meanings of "default"?

Let me just take a section from the "management summary"
of this paper, on page 12:

"Die Strukturierung des Webservers in Module erlaubt zum
einen die leichte Erweiterbarkeit, zum anderen - und das
ist unter Sicherheitsaspekten wesentlicher - erlaubt dies
eine minimale Konfiguration des Webservers: Nicht benötig-
te Funktionalität wird nicht nur per Konfigurationsoption
abgeschaltet, sondern ist überhaupt nicht im Webserver
vorhanden. Entsprechend ist auch die voreingestellte
Konfiguration des Webservers eher konservativ: Es werden
nur einige wenige Module aktiviert, die gerade für eine
Basisfunktionalität als Webserver ausreichen.
Zusätzliche Erweiterungen (die damit u. U. auch zusätzli-
che Risiken bedeuten) müssen vom Anwender explizit bei der
Kompilierung eingebunden und später in der Konfiguration
aktiviert werden."

... or in my quick translation:

"The module structure of the Webservers on one hand allows
for easy extensibility, on the other hand - and this is
more fundamental under security aspects - allows for a
minimal configuration of the web server: Functionality
which isn't of current use is not only disabled via confi-
guration option but isn't present in the web server at all.
Thus the default configuration of the web server is rather
conservative: Only a small set of modules is activated that
just suffice for a basic funktionality as web server.
Additional enhancements (which may mean additional risks)
have to be added by the admin explicitly during compilation
and activated in the configuration later."

Sounds great, and is definitely true for Apaches being
created by the "configure" mechanism using its default
settings (although 'configure' does the config activation
automatically when you add more modules, I believe).

But what about the binaries that are shipped for platforms
like Solaris or IBM-AIX that don't provide a C compiler
without additional payment? What about the pre-installed
"default" Apaches on Suse or Red Hat machines?
They are rather the opposite of the above description:
They load and activate each and every module on earth
just "to make life easier" for the less informed "admin",
to make the thingy "work out of the box without effort".
Have you ever read one of their 'httpd.conf' "defaults"
without choking? These packagers 'think the Microsoft way'
("most users are stupid, thus rather make the thing run-
ning insecurely than too difficult to handle, or else our
customer will turn to Microsoft") and write their configu-
ration "defaults" accordingly. Oops.

Actually, it is not the Apache Webserver which can be
called safe or unsafe - it is the administration concept
of the people who install and run an Apache server.
And if these admins "outsource" their admin job to the
packager, they get what they pay for - which isn't a lot.

It took me quite some of work to break down a standard
httpd.conf file into a set of about 15 or 20 include
files, one for each Apache module or "feature" (I treat
"ScriptAlias" and options enabling CGI directly and/or
via SSI as one "feature", although they're using direc-
tives from different modules, just as an example), and
then decide which include files to actually use within
which of my virtual hosts.
But since I did that, there isn't a line with in my
httpd.conf any more that I don't know why it is there.

I believe the httpd.conf default might well be a lot
more restrictive (using more <IfModule> scopes even for
base modules, to make the admin aware of what belongs
where?) and modular, if a maximum of maintainability
were the ultimate goal. (Unfortunately, modules and fea-
tures are not always easy to be mapped to one another.)
Currently its main goal seems to be some compromise
between restrictive default and easy enabling of
additional features that you just uncommment from
the config file - sometimes even without understan-
ding the consequences.
But then, maybe I am thinking too much from the pro-
grammer's point of view who knows the concept of mo-
dular data modelling, while other admins would have
problems messing around with "all that many configu-
ration files". Sigh.

I didn't find the former three-files structure of the
Apache configuration any better than the one-file
structure - but since the "include" directive is on
offer, anyone is now free to use his/her individual
way of writing an Apache configuration.
And being able to do so is a true value that I see
in the configuration language.


Regards,

      Michael



P.S.: It is only some weeks ago thet one of our

      customers asked me to mail him a DSO of

      mod_gzip because the security concept of his

      company didn't allow him to install a C

      compiler and compile the Apache source ...

      (don't ask me why their security concept

      _did_ allow them to install a file they

      received from some person they hardly know;

      I didn't ask him, as he is our customer. ;-)



---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message