Securing Apache 2: Step-by-Step
Artur Maj 2004-06-21
When choosing a web server, Apache very often wins against its competitors because of
stability, performance, that fact that it's open source, and many other advantages. But when
deciding on which version of Apache to use, the choice is not always so simple. On the one
hand there is a very popular, stable version used by millions of users, version 1.3, and on the
other hand, there is an enhanced and re-designed version 2.0.
And even if the new version has got a lot more extensions and features, some people still
decide to use version 1.3, because in their opinion this branch is more stable and secure. As
a matter of fact, there is some truth in this statement. Since version 1.3 has been used by
millions of users for a long time, most security holes in this version are very likely to be
already discovered. At the same time version 2.0 may have many more as-yet undiscovered
vulnerabilities, just sleeping and waiting to be found.
Continuing the step-by-step fashion from the previous series (Securing Apache, Securing
PHP, and Securing MySQL), this article shows how to install and configure Apache 2.0 to
minimize the risk of unauthorized access or successful break-in, even if new security
vulnerabilities in Apache web server are found. Thus, it will be possible to enjoy the new
features of Apache 2.0 without worrying too much about its security bugs, regardless if they
are only imaginary, or are in fact real and serious threats.
Functionality requirements
In the world of security, there are a few golden principles that should always be followed. One
such principle is the rule which says that only absolutely required parts of the software should
be used. All other components should be disabled, made inaccessible or not even be installed
at all.
The logic behind this rule is very simple -- if there is software with dozens of components that
are enabled by default, finding only one security vulnerability in any one of these components
can put the whole system at risk of a successful break-in. On the other hand, if only a few
absolutely necessary components are enabled, finding a new security bug doesn't necessary
mean that the software is vulnerable -- because the discovered bug may affect components
that are not enabled, or are not installed. The probability of a successful break-in in this case
is obviously much lower than in case of the default installation.
Therefore, before starting to secure Apache 2, it is very important to know what functionality
we really expect from the web server. This will allow us to prepare the list of modules that we
will leave enabled, while the rest will be disabled during compilation time.
According to this rule, this article assumes that very basic functionality of Apache will be
used:
评论0