Security is a process, not a result. It is a process which is difficult to adopt under normal conditions; the problem is compounded when it spans several job descriptions. All the system level security in the world is rendered useless by insecure web-applications. The converse is also true—programming best practices, such as always verifying user input, are useless when the code is running on a server which hasn’t been properly hardened. Securing forward facing GNU/Linux web servers can seem like a daunting task, but it can be made much easier by breaking the process into manageable portions.

This article will cover installing, configuring and hardening free software web servers and associated software including Apache 2.2.0, MySQL 5.0.18, PHP 5.1.2, Apache-Tomcat 5.5.16 and common Apache modules such as mod_security, mod_ssl, mod_rewrite, mod_proxy and mod_jk. Common security mistakes in web-applications and how to fix them will also be discussed, focusing on PHP and Java environments.

The most common and apt analogy for security is the onion. That is to say it is a layered approach—any one layer is inadequate, the onion is the sum of its layers. With that in mind, this article attempts to bridge the knowledge gap between system administrators and web developers, allowing individuals tasked with security to achieve a layered security solution.

Only a basic understanding of GNU/Linux and common command line tools is assumed.

Note: due to formatting constraints, long lines of code are often broken into several smaller lines using the \ character. This is not a return and when typing in the line you should not hit the enter key, it is just to prevent line wrapping. Output from commands will also be limited to relevant fields, so the output will look slightly different when you run the commands on your system.

Security is a process, not a result

Security at the system level

System level security is one of the most crucial layers in any defense. Hardening at the system level is roughly categorized into network security and file system security.

Network level security can be increased by securing common services such as xinetd (otherwise known as the super server) and OpenSSH, by correctly configuring or disabling them and enabling a firewall (in our case, iptables.

File-System security can be increased by: preventing common avenues of attack, such as root kits; enabling intrusion detections systems (IDS) to verify the integrity of key configuration files; by using tools to detect and remove root kits; and by configuring your logging system so that it will log to a remote host, thereby protecting the integrity of your system logs.

Network security

The first thing you need to do to secure a system from network attacks is find out which processes are listening for connections and on which ports. There are several time tested tools available for this: nmap and netstat.

netstat

The following command will show you which ports are being listened on, the IP address of the listening socket, and which program or PID is associated with the socket (note: running as the super-user or root is necessary for the program field to work properly).

$ netstat -l -n -p -t -u -w

(-l is for listening, -n is for IP information and -p is for program/PID information, -t, -u, -w are for tcp, udp and raw socket connections. By setting these flags, I disable displaying information about unix sockets which are not relevant to network security, as they are only used for interprocess communication on the current host.)

The output will look something like this:

Note: Certain columns have been omitted for space

  proto Local Address      State    PID/Program name
  tcp   127.0.0.1:8005    LISTEN   4079/java
  tcp   0.0.0.0:8009      LISTEN   4079/java
  tcp   0.0.0.0:3306      LISTEN   18542/mysqld
  tcp   0.0.0.0:80        LISTEN   23736/httpd
  tcp   0.0.0.0:8080      LISTEN   4079/java
  tcp   0.0.0.0:22        LISTEN   11045/sshd
  tcp   0.0.0.0:3128      LISTEN   23283/(squid)
  tcp   127.0.0.1:25      LISTEN   24453/master
  udp   0.0.0.0:3130               23283/(squid)
  udp   0.0.0.0:32870              23283/(squid)

Understanding the output from netstat is pretty simple. The first field is the protocol, and you will notice that when the protocol is udp, there is no state (as obviously udp is stateless unlike tcp). The next interesting field is the Address field. 0.0.0.0:80 means that the server will respond to any IPs on port 80, while 127.0.0.1:80 means that the server is only listening to the loop back device.

nmap

Another tool in our arsenal is nmap, the network mapper. nmap is good for determining what ports and services are available on a server from other machines on the network.

(Note: The default option is -sS. However, when the system being scanned is running a firewall, such as iptables, it won’t work, as firewalls that block icmp traffic will also block the subsequent scan and the results will be meaningless. The -P0 option disables pinging the host before scanning it, The -O (as in “oh” rather than zero) is to enable nmap’s operating system detection via the network stack fingerprint.)

$nmap -P0 -O 10.0.2.10

The output will look something like this:

 The 1661 ports scanned but not shown below are in 
                                    state: filtered)
  PORT    STATE  SERVICE
  22/tcp  open   ssh
  443/tcp closed https
        
  Device type: general purpose
  Running: Linux 2.6.X
  OS details: Linux 2.6.7 - 2.6.8
  Uptime 40.462 days since Mon Dec 26 10:05:57 2005