The theory behind module selection says that the smaller the number of modules running, the smaller the chances of a vulnerability being present in the server. Still, I do not think you will achieve much by being too strict with default Apache modules. The likelihood of a vulnerability being present in the code rises with the complexity of the module. Chances are that the really complex modules, such as mod_ssl (and the OpenSSL libraries behind it), are the dangerous ones.

Your strategy should be to identify the modules you need to have as part of an installation and not to include anything extra. Spend some time researching the modules distributed with Apache so you can correctly identify which modules are needed and which can be safely turned off. The complete module reference is available at http:// httpd.apache.org/docs-2.0/mod/.

The following modules are more dangerous than the others, so you should consider whether your installation needs them:

mod_userdir

Allows each user to have her own web site area under the ~username alias. This module could be used to discover valid account usernames on the server because Apache responds differently when the attempted username does not exist (returning status 404 ) and when it does not have a special web area defined (returning 403 ).

mod_info

Exposes web server configuration as a web page.

mod_status

Provides real-time information about Apache, also as a web page.

mod_include

Provides simple scripting capabilities known under the name server-side includes (SSI). It is very powerful but often not used.

On the other hand, you should include these modules in your installation:

mod_rewrite

Allows incoming requests to be rewritten into something else. Known as the “Swiss Army Knife” of modules, you will need the functionality of this module.

mod_headers

Allows request and response headers to be manipulated.

mod_setenvif

Allows environment variables to be set conditionally based on the request information. Many other modules’ conditional configuration options are based on environment variable tests.

In the configure example, I assumed acceptance of the default module list. In real situations, this should rarely happen as you will want to customize the module list to your needs. To obtain the list of modules activated by default in Apache 1, you can ask the configure script. I provide only a fragment of the output below, as the complete output is too long to reproduce in a book:

  $ ./configure --help
  ...

[access=yes	actions=yes	alias=yes			]
[asis=yes	auth_anon=no	auth_dbm=no					]
[auth_db=no	auth_digest=no	auth=yes		]
[autoindex=yes	cern_meta=no	cgi=yes	]
[digest=no	dir=yes	env=yes	]
[example=no	expires=no	headers=no				]
[imap=yes	include=yes	info=no	]
[log_agent=no	log_config=yes	log_forensic=no]
[log_referer=no	mime_magic=no	mime=yes ]
[mmap_static=no	negotiation=yes proxy=no			]

 

[rewrite=no	setenvif=yes	so=no	]
[speling=no	status=yes	unique_id=no	]
[userdir=yes	usertrack=no	vhost_alias=no ]

  ...

As an example of interpreting the output, userdir=yes means that the module mod_userdir will be activated by default. Use the --enable-module and --disable-module directives to adjust the list of modules to be activated:

  $ ./configure \
  > --prefix=/usr/local/apache \
  > --enable-module=rewrite \
  > --enable-module=so \
  > --disable-module=imap \
  > --disable-module=userdir

Obtaining a list of modules activated by default in Apache 2 is more difficult. I obtained the following list by compiling Apache 2.0.49 without passing any parameters to the configure script and then asking the httpd binary to produce a list of modules:

  $ ./httpd -l
  Compiled in modules:
    core.c
    mod_access.c
    mod_auth.c
    mod_include.c
    mod_log_config.c
    mod_env.c
    mod_setenvif.c
    prefork.c
    http_core.c
    mod_mime.c
    mod_status.c
    mod_autoindex.c
    mod_asis.c
    mod_cgi.c
    mod_negotiation.c
    mod_dir.c
    mod_imap.c
    mod_actions.c
    mod_userdir.c
    mod_alias.c
    mod_so.c

To change the default module list on Apache 2 requires a different syntax than that used on Apache 1:

  $ ./configure \
  > --prefix=/usr/local/apache \
  > --enable-rewrite \
  > --enable-so \
  > --disable-imap \
  > --disable-userdir