applications:web:apache:secure []

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Serveur web Apache ======
 
===== 20 ways to Secure your Apache Configuration =====
\\ 
source : [[https://www.petefreitag.com/item/505.cfm|Pete Freitag]]

Here are 20 things you can do to make your apache configuration more secure.

==== First, make sure you've installed latest security patches ====
There is no sense in putting locks on the windows, if your door is wide open. As such, if you're not patched up there isn't really much point in continuing any longer on this list. Go ahead and bookmark this page so you can come back later, and patch your server.

You'll need a way to know when new Apache Server vulnerabilities are published. I like to use stack.watch to notify me when new Apache httpd server vulnerabilities are published. The service is free, and will send you an email whenever new vulnerabilities exist.

==== Hide the Apache Version number, and other sensitive information. ===
By default many Apache installations tell the world what version of Apache you're running, what operating system/version you're running, and even what Apache Modules are installed on the server. Attackers can use this information to their advantage when performing an attack. It also sends the message that you have left most defaults alone.

There are two directives that you need to add, or edit in your ''httpd.conf'' file:
<code bash>
ServerSignature Off
ServerTokens Prod
</code>
The ServerSignature appears on the bottom of pages generated by apache such as 404 pages, directory listings, etc.

The ServerTokens directive is used to determine what Apache will put in the Server HTTP response header. By setting it to Prod it sets the HTTP response header as follows:

<code bash>Server: Apache</code>
If you're super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security (see below).

==== Make sure apache is running under its own user account and group ====
Several apache installations have it run as the user nobody. So suppose both Apache, and your mail server were running as nobody an attack through Apache may allow the mail server to also be compromised, and vise versa.
<code bash>
User apache
Group apache
</code>

==== Ensure that files outside the web root are not served ====
We don't want apache to be able to access any files out side of its web root. So assuming all your web sites are placed under one directory (we will call this /web), you would set it up as follows:
<code bash>
<Directory />
  Order Deny,Allow
  Deny from all
  Options None
  AllowOverride None
</Directory>
<Directory /web>
  Order Allow,Deny
  Allow from all
</Directory>
</code>
Note that because we set Options None and AllowOverride None this will turn off all options and overrides for the server. You now have to add them explicitly for each directory that requires an Option or Override.

==== Turn off directory browsing ====
You can do this with an Options directive inside a Directory tag. Set Options to either None or -Indexes
<code bash>Options -Indexes</code>

==== Turn off server side includes ====
This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes
<code bash>Options -Includes</code>

==== Turn off CGI execution ====
If you're not using CGI turn it off with the Options directive inside a Directory tag. Set Options to either None or -ExecCGI
<code bash>Options -ExecCGI</code>

==== Don't allow apache to follow symbolic links ====
This can again can be done using the Options directive inside a Directory tag. Set Options to either None or -FollowSymLinks
<code bash>Options -FollowSymLinks</code>

==== Turning off multiple Options ====
If you want to turn off all Options simply use:
<code bash>Options None</code>
If you only want to turn off some separate each option with a space in your Options directive:
<code bash>Options -ExecCGI -FollowSymLinks -Indexes</code>

==== Turn off support for .htaccess files ====
This is done in a Directory tag but with the AllowOverride directive. Set it to None.
<code bash>AllowOverride None</code>
If you require Overrides ensure that they cannot be downloaded, and/or change the name to something other than .htaccess. For example we could change it to .httpdoverride, and block all files that start with .ht from being downloaded as follows:
<code bash>
AccessFileName .httpdoverride
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>
</code>

==== Run mod_security ====
''mod_security'' is a super handy Apache module written by Ivan Ristic, the author of Apache Security from O'Reilly press.

You can do the following with mod_security:
  * Simple filtering
  * Regular Expression based filtering
  * URL Encoding Validation
  * Unicode Encoding Validation
  * Auditing
  * Null byte attack prevention
  * Upload memory limits
  * Server identity masking
  * Built in Chroot support
  * And more

==== Disable any unnecessary modules ====
Apache typically comes with several modules installed. Go through the apache module documentation and learn what each module you have enabled actually does. Many times you will find that you don't need to have the said module enabled.

Look for lines in your httpd.conf that contain ''LoadModule''. To disable the module you can typically just add a ''#'' at the beginning of the line. To search for modules run:
<code bash>grep LoadModule httpd.conf</code>
Here are some modules that are typically enabled but often not needed: ''mod_imap'', ''mod_include'', ''mod_info'', ''mod_userdir'', ''mod_status'', ''mod_cgi'', ''mod_autoindex''.

==== Make sure only root has read access to apache's config and binaries ====
This can be done assuming your apache installation is located at /usr/local/apache as follows:
<code bash>
chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache
</code>

==== Lower the Timeout value ====
By default the Timeout directive is set to 300 seconds. You can decrease help mitigate the potential effects of a denial of service attack.
<code bash>Timeout 45</code>

==== Limiting large requests ====
Apache has several directives that allow you to limit the size of a request, this can also be useful for mitigating the effects of a denial of service attack.

A good place to start is the ''LimitRequestBody'' directive. This directive is set to unlimited by default. If you are allowing file uploads of no larger than 1MB, you could set this setting to something like:
<code bash>LimitRequestBody 1048576</code>
If you're not allowing file uploads you can set it even smaller.

Some other directives to look at are ''LimitRequestFields'', ''LimitRequestFieldSize'' and ''LimitRequestLine''. These directives are set to a reasonable defaults for most servers, but you may want to tweak them to best fit your needs. See the documentation for more info.

==== Limiting the size of an XML Body ====
If you're running mod_dav (typically used with subversion) then you may want to limit the max size of an XML request body. The ''LimitXMLRequestBody'' directive is only available on Apache 2, and its default value is 1 million bytes (approx 1mb). Many tutorials will have you set this value to 0 which means files of any size may be uploaded, which may be necessary if you're using WebDAV to upload large files, but if you're simply using it for source control, you can probably get away with setting an upper bound, such as 10mb:
<code bash>LimitXMLRequestBody 10485760</code>

==== Limiting Concurrency ====
Apache has several configuration settings that can be used to adjust handling of concurrent requests. The ''MaxClients'' is the maximum number of child processes that will be created to serve requests. This may be set too high if your server doesn't have enough memory to handle a large number of concurrent requests.

Other directives such as ''MaxSpareServers'', ''MaxRequestsPerChild'', and on Apache2 ''ThreadsPerChild'', ''ServerLimit'', and ''MaxSpareThreads'' are important to adjust to match your operating system, and hardware.

==== Restricting Access by IP ====
If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 176.16 network:
<code bash>
Order Deny,Allow
Deny from all
Allow from 176.16.0.0/16
</code>
Or by IP:
<code bash>
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</code>

==== Adjusting KeepAlive settings ====
According to the Apache documentation using HTTP Keep Alive's can improve client performance by as much as 50%, so be careful before changing these settings, you will be trading performance for a slight denial of service mitigation.

KeepAlive's are turned on by default and you should leave them on, but you may consider changing the '''MaxKeepAliveRequests'' which defaults to 100, and the ''KeepAliveTimeout'' which defaults to 15. Analyze your log files to determine the appropriate values.

==== Run Apache in a Chroot environment ====
chroot allows you to run a program in its own isolated jail. This prevents a break in on one service from being able to effect anything else on the server.

It can be fairly tricky to set this up using chroot due to library dependencies. I mentioned above that the ''mod_security module'' has built in chroot support. It makes the process as simple as adding a ''mod_security'' directive to your configuration:
<code bash>SecChrootDir /chroot/apache</code>

There are however some caveats however, so check out the mod_security docs for more info.