Apache or httpd is a strong and well tested webserver.
To install the Apache web server for this hardening guide on fedora run the following command as root:
[root@localhost] ~# yum install httpd mod_evasive mod_gnutls mod_security mod_selinux -y
A few modules I need to look into (TODO):
Apache starts up using root privileges initially. Dropping the privileges is highly recommended as soon as possible (which it does if alternative credentials are supplied in it's configuration).
Additionally, the Apache web server can be used to remotely execute dynamic code if a vulnerability is found with the privileges the process is running as. This could be very dangerous... The languages allowed to be executed should be chosen wisely and hardened appropriately.
User credentials can be passed through the web server so it is strongly recommended that SSL certificates be used. If SSL certificates are available there are very few reasons not to use SSL everywhere.
The only exception I have been able to come up with is for an application that is extremely latency sensitive, contains no sensitive data, and have the data verified in a different way (through data signatures like HMAC or GPG). The latter is not necessarily required.
By default Apache only runs on port 80 using TCP, if SSL is enabled it will also use port 443 over SSL. Additional ports can be configured by the admin.
-A SERVICES -m tcp -p tcp --dport 80 -j ACCEPT -A SERVICES -m tcp -p tcp --dport 443 -j ACCEPT
This service is very sensitive to the flood attack rules. It is recommended these be adjusted to allow twice the maximum number of connections expected during a time frame or alternatively to allow traffic on these two ports too bypass the anti-flood rules.
If you use
mod_security you should note that in my testing each Apache thread
increases it's resident memory size by ~27Mb using the stock configuration. For
servers that need to handle a high volume of requests this may not be
acceptable. If using
mod_security you DEFINITELY need to adjust the
MaxClients (they are aliases of each other so should always
be the same).
Tuning ServerLimit/MaxClients with the worker MPM
- Start up the apache server
- Use the
psutility to determine the size of client threads (will be in Kb)
- Determine that max amount of RAM the apache process should be allowed to use
- Subtract the
parentprocesses RAM from that
- Divide the remaining RAM by the size of the client threads, this is your ServerLimit / MaxClient value
An example of this is provided below:
[root@localhost ~]# /etc/init.d/httpd start Starting httpd: [ OK ] [root@localhost ~]# ps aux -u apache | grep httpd root 2238 0.7 0.4 177132 9312 ? Ss 10:45 0:00 /usr/sbin/httpd apache 2240 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2241 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2242 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2243 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2244 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2245 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2246 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd apache 2247 0.0 0.2 177132 5124 ? S 10:45 0:00 /usr/sbin/httpd root 2249 0.0 0.0 103376 832 pts/0 S+ 10:45 0:00 grep --color=auto httpd [root@localhost ~]# PARENTMEMORY=$((9312/1024)) [root@localhost ~]# CHILDMEMORY=$((5124/1024)) [root@localhost ~]# APACHERAM=1024 [root@localhost ~]# echo $(($(($APACHERAM-$PARENTMEMORY))/$CHILDMEMORY)) 203
The parent process will have a running user of 'root', all of the children processes will have 'apache'. In the above example the parent process is using 9312Kb of memory or ~9Mb, the child process is using 5124Kb or ~5Mb, and we're allowing Apache to use up to 1Gb of memory (1024Mb). With that knowledge we can see that we should set ServerLimit and MaxClients to "203" each.
This is the main configuration file. This differs quite a bit from the configuration files that come with most distributions, most notably most of the modules are disabled and sections of the config are only applicable if certain modules are loaded. This preserves compatibility with any functionality I may need in the future while removing the bloat of the modules.
To use this configuration you'll need to create the directory
/var/www/html/default. Any additional domains should be created in
/var/www/html with their domain name as the folder name.
This file is being included here as it will be needed most places that I run Apache. Please refer to the PHP section below for more information.
mod_evasive is a crafty little module designed to limit the impact of DoS and
DDoS attacks. This won't stop them but it will help defend against them. It
will also send notices to an admin if desired (it's an optional feature which
can be disabled).
The one potential problem I can see cropping up is with AJAX requests. Those can come in fast and hard, and they are intentional and necessary, if that becomes a problem (you'll get a 403 response when you trip and it will last for DOSBlockingPeriod seconds) then play with the DOSPageCount setting and the DOSSiteCount setting. Alternatively you can just program your AJAX clients to understand what happened and to react accordingly.
The GnuTLS module provides SSL encryption for web requests. It's quite a bit
more flexible than
mod_ssl though it hasn't been audited as thoroughly. It is
also considered an 'experimental' module for apache even though it's been in
the wild for two years.
WARNING: While this is a good module to have loaded it sextuples the amount of memory used by child processes. You will need to tune the server's performance settings accordingly. This may have a huge impact on high-traffic sites.
With that out of the way this is a very good application firewall to have as
part of the defense-in-depth doctrine, though it's configuration can be a
mod_security module gives your Apache Web server increased
ability to inspect and process input from Web clients before it's acted on by
the scripts or processes waiting for the input.
mod_security module even lets you inspect Web server output before it's
transmitted back to clients. I love this feature: it allows you to watch out
for server responses that might indicate that other filters have failed and an
attack has succeeded!
With that said this isn't the file you should actually be looking at. Yes this
is where everything will get loaded but the stock Fedora
mod_security for the
most parts loads up
mod_security rules in other places including the Core
ModSecurity Rule Set which will get updated with the rest of your server.
The variables that you'll want to play around with are located in
/etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf and if you want to
write your own rules in
Some changes I'd recommend in
- Uncomment the rule that limits argument name length to 100 characters
- Uncomment the rule that limits the value of an argument's length to 400 characters
- Uncomment the rule that limits the total argument length to 64000 characters
- Review the restricted extension types
After keeping an eye on the logs for a few weeks and ensuring that there aren't
any false positives, you should change the line
SecDefaultAction "phase:2,pass to
mod_selinux module allows us to extend SELinux contexts into individual
web applications or virtual hosts without impacting the memory usage of
individual child processes (The parent process seems to use about 100Kb of
memory more but this is negligible).
Since I don't use the built in apache authentication I'm limited to restrictions based on virtual hosts, which is still a rather large gain of security.
You can additionally adjust contexts based on the IP the user is connecting from.
If you enable the environment module (
env_module) in apache the domain may be
available for use within the application (it would be
hasn't been tested. With PHP you may need to add the
E to the string
variable_order, and adjust
auto_globals_jit in the
Changing contexts with the stock SELinux rules is denied! You will need to create a SELinux policy to allow it.
Virtual Host Contexts
To make use of this feature you need to define contexts within each of the
virtual host configuration directives after enabling
mod_selinux by adding
the following line:
The trailing domain should be different for virtual host (the next one would be c2).
IP Based Contexts
You can set contexts based on the IP address being connected from by adding the following line within a Directory definition:
SetEnvIf Remote_Addr "10.13.37.(25[0-5]|2[0-4][0-9]|[1-9]?[0-9])$" SELINUX_DOMAIN=*:s0:c1
This does not exist upon the default installation and will need to be created. No certificates are automatically generated when you install the GnuTLS module, if you need them you will need to generate them yourself.
Delete this file, it has no use and should be removed.
Please note that name based virtual hosts are not supported on SSL connections
mod_ssl. They work quite well with
mod_gnutls and browsers that
support SNI (Server Name Indication, as described in section 3.1 of
RFC3546). Compatibility with older browsers may be impacted.
Name based virtual hosts allow you to re-use an IP to host multiple websites.
This is only officially supported for unencrypted connections, however by using
the GnuTLS module you can easily set this up with SSL based hosts as well. An
example of how to use this can be seen in the
virtual_hosts.conf file on this
I don't really use these so I'm not including documentation, this section is mostly so other people referencing this documentation can be aware that they can have different virtual hosts bound to specific IP addresses rather than hostnames.
[root@localhost] ~# yum install php php-suhosin
Additional PHP packages that may be needed and that I've found very useful:
The following is for production use,
mysql.trace_mode may be useful in development.
This is the config file for the suhosin extension. If an application isn't working check the logs generated by suhosin to see if it is the issue.
Sometimes it's just needed to prevent access to something for a little while,
HTTP basic authentication can help! If you're using the hardened configuration
above you'll need to enable a few modules to actually use it and make sure that
a .htaccess file has permission to override
AuthConfig. Add the following
lines if they aren't already there in the section where you load modules:
LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule authn_file_module modules/mod_authn_file.so LoadModule authz_user_module modules/mod_authz_user.so
Additionally if you want to use group based authentication add:
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
First create a user to use for the login:
htpasswd -c .htpasswd demouser
Additional users can be added by omitting the
Create or append the following to a
.htaccess file in the directory you want
AuthType Basic AuthName "Some Name Describing the site" AuthUserFile /path/to/.htpasswd Require valid-user
That's it you'll have HTTP Basic authentication. If you want to use a group
file you'll need to change the setting in the
.htaccess file to match:
AuthType Basic AuthName "Some Name Describing the site" AuthUserFile /path/to/.htpasswd AuthGroupFile /path/to/.htgroups Require group demogroup
And create a group file
.htgroups with the following:
demogroup: demouser someotheruser
Before going through this you need to ensure that the tools for compiling ruby are installed on the system these are listed in Ruby.
Ensure that ruby is installed on the system as well as the development headers needed to compile the passenger module, this is all done as root:
yum install ruby curl-devel ruby-devel httpd-devel apr-devel apr-util-devel -y
gem install passenger passenger-install-apache2-module
I wasn't able to get this working at the current time as there is a bug in passenger 3.0.12 that prevents it from being compiled with GCC 4.6.