Securing-your-web-server3593

Securing Your Web Server (Apache)

Prepared By:Kanchan Chakraborty

Web server (Apache) 

A web server like Apache, in its simplest function, is software that displays and serves HTML pages hosted on a server to a client browser that understands the HTML code.

Functionality 

 



 

The Web server will be accessible from the Internet; and, Only static HTML pages will be served The server will support name-based virtual hosting mechanism Specified Web pages can be accessible only from selected IP addresses or users (basic authentication) The server will log all the Web requests (including information about Web browsers) Or The web server must handle the PHP/Perl scripting language The PHP/Perl component must be able to read and write users' data in a locally installed MySQL database.

Security Assumptions 

 



The operating system must be hardened as much as possible, both against local and remote attacks; The server must not offer any network services except HTTP: (80/TCP); Remote access to the server must be controlled by a firewall, which should block all outbound connections, and allow inbound connections only to the 80/TCP port of the Web server; The Apache Web server must be the only service available on the system;

 













Only absolutely necessary Apache modules should be enabled; Any diagnostic Web pages and automatic directory indexing service must be turned off; The server should disclose the least amount of information about itself (security by obscurity); The Apache server must run under a unique UID/GID, not used by any other system process; Apache's processes must have limited access to the file systems (chrooting); and, No shell programs can be present in the Apache's chrooted environment (/bin/sh, /bin/csh etc.). Or The PHP configuration should take advantage of built-in security mechanisms PHP scripts must be executed in a chrooted environment







The Apache server must reject all requests (GET and POST), which contain HTML tags (possible Cross-Site-Scripting attack) or apostrophe/quotation marks (possible SQL Injection attack) No PHP warning or error messages should be shown to the web application's regular users It should be possible to store incoming GET and POST requests into a text file which will make it possible to use additional, host-based intruder detection system (HIDS), e.g. swatch.

Operating system 

UNIX or UNIX like system i.e. Linux, FreeBSD, etc. is best for Apache. MS Windows provide very limited securing capabilities to apache so not recommended.

Prerequisites 



OpenSSL should be already installed on your system if you want Apache and SSL encryption support. PosgreSQL should be already installed on your system if you want Apache and PostgreSQL database connectivity support.

Or 

MySQL should be already installed on your system if you want Apache and MySQL database connectivity support.







MM should be already installed on your system if you want Apache and MM high-performance RAM-based session cache support. OpenLDAP should be already installed on your system if you want Apache and LDAP directory connectivity support. IMAP & POP should be already installed on your system if you want Apache and IMAP & POP capability.

Software Preparation These installation instructions assume  Commands are Unix-compatible.  The source path is /var/tmp  Installations were tested on Red Hat Linux  All steps in the installation will happen in super-user account root.  Apache version number is 1.3.27+ (Why?)  Mod_SSL  Mod_Perl (Optional)  Mod_PHP

Packages    

Apache : http://www.apache.org/ Mod_Perl : http://perl.apache.org/ Mod_SSL : http://www.modssl.org/ Mod_PHP : http://www.php.net/

Step – 1 - Installation Decompress TAR balls and keep in one directory i.e. /var/tmp Copy  [root@localhost]/# cp apache_version.tar.gz /var/tmp  [root@localhost]/# cp mod_ssl-version-version.tar.gz /var/tmp  [root@localhost]/# cp mod_perl-version.tar.gz /var/tmp  [root@localhost]/# cp php-version.tar.gz /var/tmp  [root@localhost]/# cd /var/tmp/ Decompress  [root@localhost]/tmp# tar xzpf apache_version.tar.gz  [root@localhost]/tmp# tar xzpf mod_ssl-version-version.tar.gz  [root@localhost]/tmp# tar xzpf mod_perl-version.tar.gz  [root@localhost]/tmp# tar xzpf php-version.tar.gz

Mod_SSL –  

[root@localhost]/# cd mod_ssl-version-version [root@localhost]/# CC="egcs" CFLAGS="-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions" ./configure --with-apache=../apache_1.3.37 --withcrt=/etc/ssl/certs/server.crt --withkey=/etc/ssl/private/server.key

*CC – C Compiler **egcs – Enhanced GNU Compiler System ***CFLAGS – O2 (i386), O3 (i586), O9 (i686) Optimization Option

PHP 4  [root@localhost]# cd apache_1.3.37 Configure  [root@localhost]# CC="egcs" OPTIM="-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions" CFLAGS="DDYNAMIC_MODULE_LIMIT=0" \  ./configure \  --prefix=/home/httpd \  --bindir=/usr/bin \  --sbindir=/usr/sbin \  --libexecdir=/usr/lib/apache \  --includedir=/usr/include/apache \  --sysconfdir=/etc/httpd/conf \  --localstatedir=/var \  --runtimedir=/var/run \  --logfiledir=/var/log/httpd \  --datadir=/home/httpd \  --proxycachedir=/var/cache/httpd \  --mandir=/usr/man

PHP4 This tells PHP4 to set itself up for this particular hardware setup with:  Compile without debugging symbols.  Enable safe mode by default.  Include IMAP & POP support.  Include LDAP directory support.  Include PostgreSQL / MySQL database support.  Include mm support to improve performance of Memory Library.  Enable inline-optimization for better performance.  Compile with memory limit support.  Assume the C compiler uses GNU ld. 

3. [root@deep ]/php-4.0# make && make install

Mod_PERL  [root@localhost] cd ../mod_perl-version.version/  [root@localhost] perl Makefile.PL EVERYTHING=1 APACHE_SRC=../apache_1.3.37/src USE_APACI=1 PREP_HTTPD=1 DO_HTTPD=1  3. [root@localhost]/mod_perl-version.version# make && make install

Apache  1. [root@localhost]/apache1.3.37# SSL_BASE=SYSTEM EAPI_MM=SYSTEM CC="egcs" OPTIM="-O9 -funroll-loops -ffast-math -malign-double -mcpu=pentiumpro -march=pentiumpro -fomit-frame-pointer -fno-exceptions" CFLAGS="DDYNAMIC_MODULE_LIMIT=0" \  ./configure \  --prefix=/home/httpd \  --bindir=/usr/bin \  --sbindir=/usr/sbin \  --libexecdir=/usr/lib/apache \  --includedir=/usr/include/apache \  --sysconfdir=/etc/httpd/conf \  --localstatedir=/var \  --runtimedir=/var/run \  --logfiledir=/var/log/httpd \  --datadir=/home/httpd \  --proxycachedir=/var/cache/httpd \  --mandir=/usr/man \  --add-module=src/modules/experimental/mod_mmap_static.c \  --add-module=src/modules/standard/mod_auth_db.c \

              



--enable-module=ssl \ --enable-rule=SSL_SDBM \ --disable-rule=SSL_COMPAT \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=php4 \ --activate-module=src/modules/perl/libperl.a \ --enable-module=perl \ --disable-module=status \ --disable-module=userdir \ --disable-module=negotiation \ --disable-module=autoindex \ --disable-module=asis \ --disable-module=imap \ --disable-module=env \ --disable-module=actions 2. [root@localhost]/apache1.3.37# make && make install

Step – 2: Chroot Jail  

Chroot Chrooting is the process through which you can change the root of a system to different location so that actual root system will safe from the intruders.

Benefit 







Apache by default runs as a non-root user, which will limit any damage to what can be done as a normal user with a local shell. The main benefit of a chroot jail is that the jail will limit the portion of the file system the daemon can see to the root directory of the jail. The jail only needs to support Apache; the programs available in the jail can be extremely limited. There is no need for setuid-root programs, which can be used to gain root access and break out of the jail.

Pros  If apache is ever compromised, the attacker will not have access to the entire file system.  Poorly written CGI scripts that may allow someone to access your server will not work. Cons  There are extra libraries you'll need to have in the chroot jail for Apache to work.  If you use any Perl/CGI features with Apache, you will need to copy the needed binaries, Perl libraries and files to the appropriate spot within the chroot space. The same applies for SSL, PHP, LDAP, PostgreSQL and other third-party programs.

Find Dependences  [root@localhost]/# ldd /usr/sbin/httpd         

libpam.so.0 =>/lib/libpam.so.0 (0x40016000) libm.so.6 =>/lib/libm.so.6 (0x4001f000) libdl.so.2 =>/lib/libdl.so.2 (0x4003b000) libcrypt.so.1 =>/lib/libcrypt.so.1 (0x4003e000) libnsl.so.1 =>/lib/libnsl.so.1 (0x4006b000) libresolv.so.2 =>/lib/libresolv.so.2 (0x40081000) libdb.so.3 =>/lib/libdb.so.3 (0x40090000) libc.so.6 =>/lib/libc.so.6 (0x400cb000) /lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)

Create Directory Struture (Similar in dependencies)  [root@localhost ]/# mkdir /chroot/httpd  [root@localhost ]/# mkdir /chroot/httpd/dev  [root@localhost ]/# mkdir /chroot/httpd/lib  [root@localhost ]/# mkdir /chroot/httpd/etc  [root@localhost ]/# mkdir -p /chroot/httpd/usr/sbin  [root@localhost ]/# mkdir -p /chroot/httpd/var/run  [root@localhost ]/# mkdir -p /chroot/httpd/var/log/httpd  [root@localhost ]/# chmod 750 /chroot/httpd/var/log/httpd/  [root@localhost ]/# mkdir -p /chroot/httpd/home/httpd

Copy all found dependencies into created directory along with File Access Permissions (No other writable) 









[root@localhost ]/# cp -r /etc/ssl /chroot/httpd/etc/ � require only if you use mod_ssl feature. [root@localhost ]/# chmod 600 /chroot/httpd/etc/ssl/certs/ca.crt � require only if you use mod_ssl feature. [root@localhost ]/# chmod 600 /chroot/httpd//etc/ssl/certs/server.crt � require only if you use mod_ssl feature. [root@localhost ]/# chmod 600 /chroot/httpd/etc/ssl/private/ca.key � require only if you use mod_ssl feature. [root@localhost ]/# chmod 600 /chroot/httpd/etc/ssl/private/server.key � require only if you use mod_ssl feature.

users authentication with .dbmpasswd password file 



 

  

To change the permissions on the dbmmanage program, use the following command: [root@localhost ]/# chmod 750 /usr/bin/dbmmanage To create a username and password, use the following command: [root@deep ]/# /usr/bin/dbmmanage /etc/httpd/.dbmpasswd adduser username New password: Re-type new password: User username added with password encrypted to l4jrdAL9MH0K.

Now copy the passwd and group files inside the /chroot/httpd/etc chrooted directory and remove all entries except for the user that apache runs as in both files passwd and group.  

[root@localhost ]/# cp /etc/passwd /chroot/httpd/etc/ [root@localhost ]/# cp /etc/group /chroot/httpd/etc/

Edit the passwd file, vi /chroot/httpd/etc/passwd and delete all entries except for the user apache run as in our configuration, it's www: 

www:x:80:80::/home/www:/bin/bash

Edit the group file, vi /chroot/httpd/etc/group and delete all entries except the group apache run as, in our configuration it,s www: 

www:x:80:

Then you will also need /etc/resolv.conf, /etc/nsswitch.conf and /etc/hosts files in your chroot jail in same directory structure to resolve hosts name.

Step – 3: Securing CGI Applications       

         

Configuring PHP add the following lines to httpd.conf AddModule mod_php4.c AddType application/x-httpd-php .php AddType application/x-httpd-php .inc AddType application/x-httpd-php .class A few changes must also be made in the PHP configuration file (/chroot/httpd/usr/local/lib/php.ini). Parameter Description safe_mode = On safe_mode_gid = Off open_basedir = directory[:...] (Only this dir. Accessible by Scipts) safe_mode_exec_dir = directory[:...] (Executable program refused to run by Apache) expose_php = Off (Do not show PHP Info) register_globals = Off display_errors = Off log_errors = On error_log = filename

Changing the file extension 

In order to change the extensions, all the *.php files should be renamed to *.dhtml (for example), and the following line should be changed in /chroot/httpd/usr/local/apache/conf/httpd.conf:



AddType application/x-httpd-php .php



to the new one:



AddType application/x-httpd-php .dhtml



Web users will not see *.php extension in the URL address which is what immediately suggests that the PHP technology is being used at the server side.

The last step - Defending against CSS and SQL Injection attacks 



In order to perform that, we will use the mod_security module, which we enable by adding the following line into httpd.conf: AddModule mod_security.c

To enable logging of the GET and POST requests, it suffices to add the following section to httpd.conf:  

    

AddHandler application/x-httpd-php .php SecAuditEngine On SecAuditLog logs/audit_log SecFilterScanPOST On SecFilterEngine On



 





The above commands will enable the Audit Engine, which is responsible for logging requests, and the Filtering POST Engine, which will make it possible to log POST requests. In order to protect web application against CSS attacks, the following lines should also be inserted before "": SecFilterDefaultAction "deny,log,status:500" SecFilter "<(.|\n)+>“ The first line causes that the server to return the "Internal Server Error" message when the request contains the search phrase from any SecFilter variable. The second line sets up the filter to search for HTML tags in the GET and POST requests.



 



One of the typical signatures of SQL Injection attack is the appearance of an apostrophe (') or quotation mark (") in the GET or POST request. By rejecting all the requests containing those characters, we can make the use of SQL Injection technique very difficult: SecFilter "'" SecFilter "\"" Note, that although filtering the <, >, ', " characters lets us defend against CSS and SQL Injection attacks, it can lead to the improper functioning of the PHP application. It happens, because regular users cannot use those characters in the HTML forms. To solve that problem, the JavaScript language can be used on the client side, which should replace the prohibited characters with special tags, e.g. < > " etc.

Step – 4:Secure your Apache Configuration *Hide the Apache Version number, and other sensitive information. *Make sure Apache is running under its own user account and group *Ensure that files outside the web root are not served *Turn off directory browsing *Turn off server side includes *Turn off CGI execution Contd.



Don't allow Apache to follow symbolic links.



Turning off multiple Options



Turn off support for .htaccess files



Disable any unnecessary modules



Make sure only root has read access to Apache's config and binaries



Lower the Time-out value



Limiting large requests



Limiting the size of an XML Body



contd.



Limiting Concurrency



Restricting Access by IP



Adjusting Keep Alive settings



Adjusting Keep Alive settings.



Make sure you've installed latest security patches.

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: ServerSignature Off ServerTokens Prod

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: Server: Apache If you're super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security

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. User Apache Group Apache

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: Order Deny,Allow Deny from all Options None AllowOverride None Order Allow,Deny Allow from all

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

Turn off server side includes

This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes Options -Includes

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 Options -ExecCGI

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 Options -FollowSymLinks

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

Turn off support for .htaccess files This is done in a Directory tag but with the AllowOverride directive. Set it to None. AllowOverride None 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: AccessFileName .httpdoverride Order allow,deny Deny from all Satisfy All

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 Load Module To disable the module you can typically just add a # at the beginning of the line. To search for modules run: grep Load Module httpd.conf 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: chown -R root:root /usr/local/apache chmod -R o-rwx /usr/local/apache

Lower the Time-out 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. Timeout 45

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: LimitRequestBody 1048576 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.

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: LimitXMLRequestBody 10485760

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:

Order Deny,Allow Deny from all Allow from 176.16.0.0/16 Or by IP: Order Deny,Allow Deny from all Allow from 127.0.0.1

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: SecChrootDir /chroot/apache There are however some caveats however, so check out the docs for more info.

Summary Achieving a high level of a web server's security using server-side technologies (PHP, ASP, JSP etc.) is a very difficult task in practice. Reasons:  Server itself does not defend against poor programming techniques.  Server side technology’s (ASP, PHP, JSP etc.) vulnerability also make the web server attack prone.  Applying of security patches and removal of unused files is necessary to make your web server more defensive.  We cannot forget that the security of the whole environment depends not only on Apache's or PHP's configuration, but also and foremost - on the web application itself.  Programmers need to analyze their code or application before deploying it over production server.  Regular monitoring of Logs and CGI behavior necessary to run Web Server long lasting without Attack.  Making a dedicated Web Server involve Cost and may be overhead and compromising it, needs analysis.

Questions?

THANK YOU