This document outlines the security measures necessary for setting up an Apache web server, detailing its functions, security assumptions, and prerequisites. It emphasizes the importance of hardening the operating system, implementing a chroot jail, and configuring PHP securely to prevent attacks such as SQL injection and cross-site scripting. The document also covers the installation steps for various modules and the need for proper user authentication and access management.

1. Securing Your Web Ser ver
(A pache)
OSScamp, Impetus Noida, Sept, ’07
Pradeep Kr. Sharma
Account Management Executive, OSSCube

2. Web ser ver (A pache)
• 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.

3. 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.

4. 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;

5. • 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

6. • 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.

7. 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.

8. 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.

9. • 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.

10. 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

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

12. 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

13. 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 --with-
crt=/etc/ssl/certs/server.crt --with-key=/etc/ssl/private/server.key
*CC – C Compiler
**egcs – Enhanced GNU Compiler System
***CFLAGS – O2 (i386), O3 (i586), O9 (i686) Optimization Option

14. 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

15. 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

16. 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

17. 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

18. • --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

19. 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.

21. 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.

22. 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.

23. 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)

24. Create Dir ector y Str uctur e (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

25. 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.

26. 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.

27. 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.

28. 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

29. 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.

30. 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:
• <IfModule mod_security.c>
• AddHandler application/x-httpd-php .php
• SecAuditEngine On
• SecAuditLog logs/audit_log
• SecFilterScanPOST On
• SecFilterEngine On
• </IfModule>

31. • 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 "</IfModule>":
• 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.

32. • 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. &lt; &gt; &quot; etc.

33. Summar y
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.

34. Questions?

35. T hank you!
For more information, contact us:
OSSCube
India: +91 995 809 0987
USA: +1 919 791 5427
Web: www.osscube.com
Mail: info@osscube.com