{"id":934,"date":"2012-08-03T09:09:29","date_gmt":"2012-08-03T01:09:29","guid":{"rendered":"http:\/\/rmohan.com\/?p=934"},"modified":"2012-08-03T09:09:43","modified_gmt":"2012-08-03T01:09:43","slug":"hardening-linux-web-servers","status":"publish","type":"post","link":"https:\/\/mohan.sg\/?p=934","title":{"rendered":"Hardening Linux Web Servers"},"content":{"rendered":"

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\u2014programming best practices, such as always verifying user input, are useless when the code is running on a server which hasn\u2019t 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.<\/p>\n

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

The most common and apt analogy for security is the onion. That is to say it is a layered approach\u2014any 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.<\/p>\n

Only a basic understanding of GNU\/Linux and common command line tools is assumed.<\/p>\n

Note: due to formatting constraints, long lines of code are often broken into several smaller lines using the \\<\/code> 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.<\/p>\n

Security is a process, not a result<\/strong><\/p>\n

Security at the system level<\/h1>\n

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.<\/p>\n

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

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.<\/p>\n

Network security<\/h2>\n

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<\/code> and netstat<\/code>.<\/p>\n

netstat<\/h2>\n

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<\/em> is necessary for the program field to work properly).<\/p>\n

$ netstat -l -n -p -t -u -w<\/code><\/p>\n

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

The output will look something like this:<\/p>\n

Note: Certain columns have been omitted for space<\/p>\n

\n
  proto Local Address      State    PID\/Program name\r\n  tcp   127.0.0.1:8005    LISTEN   4079\/java\r\n  tcp   0.0.0.0:8009      LISTEN   4079\/java\r\n  tcp   0.0.0.0:3306      LISTEN   18542\/mysqld\r\n  tcp   0.0.0.0:80        LISTEN   23736\/httpd\r\n  tcp   0.0.0.0:8080      LISTEN   4079\/java\r\n  tcp   0.0.0.0:22        LISTEN   11045\/sshd\r\n  tcp   0.0.0.0:3128      LISTEN   23283\/(squid)\r\n  tcp   127.0.0.1:25      LISTEN   24453\/master\r\n  udp   0.0.0.0:3130               23283\/(squid)\r\n  udp   0.0.0.0:32870              23283\/(squid)<\/pre>\n<\/div>\n
Understanding the output from netstat is pretty simple. The first field is the protocol, and you will notice that when the protocol is udp<\/code>, there is no state (as obviously udp<\/code> is stateless unlike tcp<\/code>). The next interesting field is the Address field. 0.0.0.0:80<\/code> means that the server will respond to any IPs on port 80, while 127.0.0.1:80<\/code> means that the server is only listening to the loop back device.<\/p>\n
nmap<\/h2>\n
Another tool in our arsenal is nmap<\/code>, the network mapper. nmap<\/code> is good for determining what ports and services are available on a server from other machines on the network.<\/p>\n
(Note: The default option is -sS<\/code>. However, when the system being scanned is running a firewall, such as iptables<\/code>, it won\u2019t work, as firewalls that block icmp<\/code> traffic will also block the subsequent scan and the results will be meaningless. The -P0<\/code> option disables pinging the host before scanning it, The -O<\/code> (as in \u201coh\u201d rather than zero) is to enable nmap<\/code>\u2019s operating system detection via the network stack fingerprint.)<\/p>\n
$nmap -P0 -O 10.0.2.10<\/code><\/p>\n
The output will look something like this:<\/p>\n
\n
 The 1661 ports scanned but not shown below are in \r\n                                    state: filtered)\r\n  PORT    STATE  SERVICE\r\n  22\/tcp  open   ssh\r\n  443\/tcp closed https\r\n\r\n  Device type: general purpose\r\n  Running: Linux 2.6.X\r\n  OS details: Linux 2.6.7 - 2.6.8\r\n  Uptime 40.462 days since Mon Dec 26 10:05:57 2005<\/pre>\n<\/div>\n
Now that I know what services are listening on which ports, I can go about securing them. In some cases, the solution will be disabling the unwanted service via inetd<\/code>; in others, I will use iptables<\/code> rules to block external access to that port.<\/p>\n
In the context of a web server, I would recommended disabling all services managed by inetd<\/code> (if they aren\u2019t already).<\/p>\n
\/etc\/xinetd.conf<\/code> (Red Hat): this file usually has some minimalistic configuration of the logging software and then an include statement for all the files under \/etc\/xinetd.d<\/code>, which are configuration files for each service run through the super server.<\/p>\n
\/etc\/inetd.conf<\/code> (Debian): Debian has a much simpler configuration layout\u2014one simple file \/etc\/inetd.conf<\/code> containing one line for each service managed by inetd<\/code>.<\/p>\n
iptables<\/h2>\n
The venerable iptables<\/code> has been the standard Linux firewall since the 2.4 kernel. The kernels that come with Red Hat and Debian have the proper modules enabled; however, on Debian systems you may need to install the iptables<\/code> user land tools. Configuring iptables<\/code> is fairly simple: iptables<\/code> has chains, rules and targets. iptables<\/code> has three built in chains: FORWARD<\/code>, INPUT<\/code>, and OUTPUT<\/code>. To create an effective firewall I will append rules to chains that will be matched by connection type, source or destination address or state. In more advanced configurations, it is favorable to create custom chains and then reference them in the default chains; but, to demonstrate the basic principles, I am just going to append rules to the three default chains. When a connection is being matched against the configured rules, each rule is checked. If it matches, it is executed, if not, the next rule is tested. As such, the rules allowing traffic should be appended first, and the very last line in any chain should be a deny rule. This is the most secure firewall configuration, where everything is dropped except the explicitly allowed connections.<\/p>\n
If you use Debian, run:<\/p>\n
\n
  $apt-get install iptables ( to install iptables )\r\n  $apt-cache search iptables ( to search for packages related to iptables)<\/pre>\n<\/div>\n
To get started with iptables I will list the current rule set using the following command:<\/p>\n
\n
  $iptables --list<\/pre>\n<\/div>\n
(Note: Output has been modified due to formatting constraints.)<\/p>\n
\n
   Chain INPUT (policy ACCEPT)\r\n   target     prot   opt     source   destination\r\n   ACCEPT     all       anywhere  anywhere \\ \r\n            state RELATED,ESTABLISHED\r\n\r\n   Chain FORWARD (policy ACCEPT)\r\n   target     prot   opt     source   destination\r\n   ACCEPT     all       anywhere anywhere   \\\r\n                        state RELATED,ESTABLISHED\r\n\r\n   Chain OUTPUT (policy ACCEPT)\r\n   target     prot   opt     source   destination\r\n   DROP       tcp       anywhere anywhere  \\\r\n                                       tcp dpt:ssh<\/pre>\n<\/div>\n
The partial listing above shows rules that allow incoming traffic that isn\u2019t new; that is to say: the connection has been established from inside the network. IP forwarding follows the same rule, and using ssh<\/code> to connect out to other hosts is blocked.<\/p>\n
The flush command with no options will flush all rules; if a chain is passed, all rules in that chain will be flushed. I\u2019ll flush all rules and begin configuring the firewall.<\/p>\n
\n
  $iptables -F \r\n    or \r\n  $iptables -F INPUT \r\n  $iptables -F FORWARD\r\n  $iptables -F OUTPUT<\/pre>\n<\/div>\n
Next, I am going to append the rules to the appropriate chain. A high level overview of the firewall will be the following:<\/p>\n
    \n
  1. Allow outgoing connections initiated from the host<\/li>\n
  2. Allow inbound ssh connections on port 2<\/li>\n
  3. Allow inbound http connections on port 80<\/li>\n
  4. Allow inbound https connections on port 443<\/li>\n
  5. Block outbound ssh connections<\/li>\n
  6. Block everything else<\/li>\n<\/ol>\n
    \n
      # Enable stateful filtering allowing connections \r\n  # initiated on host be allowed.\r\n  $iptables -A INPUT -m state --state \\ \r\n        RELATED,ESTABLISHED -j ACCEPT\r\n\r\n  $iptables -A OUTPUT -m state --state \\ \r\n    NEW,RELATED,ESTABLISHED -j ACCEPT\r\n\r\n  # Allow Incoming SSH, HTTP, HTTPS\r\n  $iptables -A INPUT -p tcp -m tcp \\\r\n            --dport 22 -j ACCEPT\r\n  $iptables -A INPUT -p tcp -m tcp \\\r\n            --dport 80 -j ACCEPT\r\n  $iptables -A INPUT -p tcp -m tcp \\\r\n            --dport 443 -j ACCEPT\r\n\r\n  # Allow Everything from the local host\r\n  $iptables -A INPUT -s 127.0.0.1 -j ACCEPT\r\n\r\n  # Block Outgoing SSH connections\r\n  $iptables -A OUTPUT -p tcp -m tcp \\\r\n            --dport 22 -j DROP\r\n\r\n  # Block Everything else\r\n  $iptables -A INPUT -j DROP\r\n  $iptables -A FORWARD -j DROP<\/pre>\n<\/div>\n
    To save the changes I have made to the firewall rules I use the iptables-save<\/code> command:<\/p>\n
    \n
      $iptables-save > \/root\/firewall<\/pre>\n<\/div>\n
    Later if I wanted to restore my saved rules I would run the iptables-restore<\/code> command:<\/p>\n
    \n
      $iptables-restore -c \/root\/firewall<\/pre>\n<\/div>\n
    It\u2019s a very good idea to have these rules applied at boot time; check your distribution\u2019s documentation for this. In general, on Debian systems the network configuration scripts can be used for this, and on Red-Hat systems a startup script in \/etc\/init.d<\/code> is appropriate.<\/p>\n
    Changing the default port that `OpenSSH` listens on is a good way to avoid brute force attacks<\/strong><\/p>\n
    Hardening SSH<\/h2>\n
    The OpenSSH<\/code> package comes installed by default on most distributions. The default configuration on most distributions is pretty lax and favors functionality over security. Allowing root<\/em> logins, listening on all IPs on port 22, and allowing all system accounts to ssh<\/code>-in are all potential security holes.<\/p>\n
    Edit \/etc\/ssh\/sshd_config<\/code> in your favorite editor and change the following lines.<\/p>\n
    \n
      # ListenAddress defines the IP address ssh will \r\n  # listen on\r\n\r\n  #ListenAddress 0.0.0.0 -> ListenAddress 10.0.2.10 \r\n\r\n  #Only accept SSH protocol 2 connections\r\n  #Protocol 2,1 -> Protocol 2     \r\n\r\n  #Disable root login\r\n  PermitRootLogin yes -> PermitRootLogin no\r\n\r\n  #Disable allowing all system accounts to ssh in, \r\n  # only allow certain users (space delimited)\r\n  AllowUsers userName1 userName2 userName3\r\n\r\n  # Change Default port\r\n  Port 22 -> Port 2200<\/pre>\n<\/div>\n
    After making the changes, restart the SSH server for the changes to take affect:<\/p>\n
    \n
    $ \/etc\/init.d\/ssh restart<\/pre>\n<\/div>\n
    Partition for security<\/strong><\/p>\n
    File system security<\/h2>\n
    The UNIX file system has several standard directories: \/<\/code>, \/tmp<\/code>, \/var<\/code>, \/usr<\/code> and \/home<\/code>. The two that present the weakest links for a variety of attacks are \/tmp<\/code> and \/var<\/code>. The two most common attacks are: \u201cDenial of Service\u201d, by causing the root partition to fill up with logs or other junk (assuming all these directories are mounted on one partition); and running rootkits from the \/tmp<\/code> directory.<\/p>\n
    One solution to file system Denial of Service attacks is to have these directories mounted on their own partitions, this will prevent the \/<\/code> file system from filling up and stop that avenue of attack.<\/p>\n
    Rootkits typically write to the \/tmp<\/code> directory and then attempt to run from \/tmp<\/code>. A crafty way to prevent this is to mount the \/tmp<\/code> directory on a separate partition with the noexec<\/code>, nodev<\/code>, and nosuid<\/code> options enabled. This prevents binaries from being executed under \/tmp<\/code>, disables any binary to be suid<\/em> root, and disables any block or character devices from being created under \/tmp<\/code>.<\/p>\n
    Edit \/etc\/fstab<\/code> with your favorite editor, find the line corresponding to \/tmp<\/code> and change it to look like this one.<\/p>\n
    \n
     \r\n\r\n  \/dev\/hda2  \/tmp  ext3  nodev,nosuid, noexec  0  0<\/pre>\n<\/div>\n
    Wikipedia [6] defines rootkits as a set of software tools frequently used by a third party (usually an intruder) after gaining access to a computer system. This translates to custom versions of ps<\/code> that won\u2019t list the irc server the attacker installed, or a custom version of ls<\/code> that doesn\u2019t show certain files. Tools like chkrootkit<\/code> must be run in combination with IDS systems like fcheck<\/code> to prevent the successful deployment of rootkits.<\/p>\n
    chkrootkit<\/code> is very simple to run, and doesn\u2019t require any installation or configuration.<\/p>\n
    It\u2019s a good idea to run chkrootkit<\/code> at regular intervals, see the script below used by fcheck<\/code> for inspiration.<\/p>\n
    \n
     # Use the wget utility to download the latest\r\n # version of chkrootkit\r\n\r\n wget ftp:\/\/ftp.pangeia.com.br\/pub\/seg\/pac\/chkrootkit.tar.gz\r\n tar -xzvf chkrootkit.tar.gz\r\n cd chkrootkit-version (whatever version is)\r\n .\/chkrootkit<\/pre>\n<\/div>\n
    The next layer of file system security is maintaining and verifying the integrity of configuration files that are typically located under \/etc<\/code>. Intrusion Detection Systems (IDS) allow us to create cryptographic identifiers of important configuration files and store them in a database. They are then periodically re-created and verified against those stored in the database. If there is a mis-match, the file has been changed, you know your system integrity has been violated and which aspects of it are affected. Two well known IDS packages are tripwire<\/code> and fcheck<\/code>, which work equally well. However, fcheck<\/code> has a much simpler configuration and installation process, which is why I favored it for this article.<\/p>\n
    fcheck<\/h2>\n
    Download fcheck<\/code> (see resources) and unpack it. fcheck<\/code> is a cross-platform Perl<\/em> script which runs on UNIX and Windows systems (as long as they have Perl installed).<\/p>\n
    \n
      $mkdir \/usr\/local\/fcheck\r\n  $cp fcheck \/usr\/local\/fcheck\r\n  $cp fcheck.cfg \/usr\/local\/fcheck<\/pre>\n<\/div>\n
    Edit \/usr\/local\/fcheck\/fcheck.cfg<\/code> with your favorite editor and change the following values: Directory<\/code>, FileTyper<\/code>, Database<\/code>, Logger<\/code>, TimeZone<\/code>, and Signature<\/code>.<\/p>\n
    \n
      # Directories that will be monitored\r\n  # if there is a trailing \/ it will be recursive \r\n\r\n  Directory       = \/etc\/\r\n  Directory       = \/bin\/\r\n  Directory       = \/sbin\/\r\n  Directory       = \/lib\/\r\n  Directory       = \/usr\/bin\/\r\n  Directory       = \/usr\/sbin\/\r\n  Directory       = \/usr\/lib\/\r\n  TimeZone        = PST8PDT # For Pacific Standard\r\n\r\n  # Database of file signatures\r\n\r\n  DataBase        = \/usr\/local\/fcheck\/sol.dbf\r\n  Logger          = \/usr\/bin\/logger -t fcheck\r\n\r\n  # Utility to determin file type\r\n  FileTyper       = \/bin\/file \r\n\r\n  # What to use to create signatures Database of \r\n  # file signatures\r\n\r\n  $Signature      = \/usr\/bin\/md5sum#\r\n  DataBase        = \/usr\/local\/fcheck\/sol.dbf\r\n  Logger          = \/usr\/bin\/logger -tfcheck\r\n\r\n  # Utility to determin file type\r\n\r\n  FileTyper       = \/bin\/file<\/pre>\n<\/div>\n
    Also edit the fcheck<\/code> script and change the path of the configuration file to \/usr\/local\/fcheck\/fcheck.cfg<\/code><\/p>\n
    Then run fcheck<\/code> for the first time to create the baseline database.<\/p>\n
    \n
    # Options explained:\r\n# c create the database\r\n# a is for all\r\n# d is to monitor directory creation \r\n# s is to create signatures for all files\r\n# x is for extended permissions monitoring\r\n\r\n$ .\/fcheck -cadsx<\/pre>\n<\/div>\n
    To test that everything has been setup correctly run the following commands and fcheck<\/code> should alert you to the difference.<\/p>\n
    \n
    $ touch \/etc\/FOO \r\n$ .\/fcheck -adsx<\/pre>\n<\/div>\n
    fcheck<\/code> should display some information about \/etc\/FOO<\/code>. $rm \/etc\/FOO<\/code> will prevent future messages.<\/p>\n
    Next, create a short shell script that will be run periodically by cron<\/code> and check for changes. Open your favorite editor and create \/usr\/local\/bin\/fcheck_script<\/code>.<\/p>\n
    When using the `cron` utility lookout for _symlink attacks_<\/strong><\/p>\n
    \n
      #!\/bin\/bash\r\n\r\n  # Use mktemp instead of $$ to prevent sym-link attacks\r\n  FCHECK_LOG=`mktemp`\r\n\r\n  # Grep for any changes  \r\n  \/usr\/local\/fcheck\/fcheck -adsx  \\ \r\n  | grep -Ev ^PROGRESS: |^STATUS:^$ > $FCHECK_LOG\r\n\r\n  # If there were any changes email the sys-admin\r\n  if [-s $FCHECK_LOG ] then\r\n      \/usr\/bin\/mail -s fcheck \\\r\n      `hostname` youremail@yourprovider.com  < \\\r\n       $FCHECK_LOG\r\n      \/bin\/rm $FCHECK_LOG\r\n  fi<\/pre>\n<\/div>\n
    The cron<\/code> utility will be used to run periodic checks of the file-system and will compare it to the baseline database. The following command will edit root\u2019s crontab<\/em>:<\/p>\n
    \n
    $ crontab -e\r\n\r\n# Add this line to run the script every 15 minutes \r\n# using nice lower priority when the system load \r\n# is high.\r\n*\/15 * * * * nice \/usr\/local\/bin\/fcheck_script > \\\r\n                          \/dev\/null<\/pre>\n<\/div>\n
    Symlink Attacks<\/h2>\n
    Side Note: Symlink Attacks running an IDS package usually involve running a script at a pre-configured time using the cron utility. This opens up systems to symlink attacks. Symlink Attacks rely on the attacker knowing that a certain file is going to be created at a certain time with a certain name. A common shell scripting technique that generates some randomness is the use of $$, which is the PID<\/em> of the running script. However, this is vulnerable to Symlink Attacks because most PIDs are below 35K and most file systems can have 35K files. The correct technique is the use of mktemp<\/code>, which is a truly random file name.<\/p>\n
    Install and configure common services<\/h1>\n
    At this stage, you should have a solid base to build upon. The next step is to compile and install the software servers you will use to serve up your web applications. Installing software from source can be tedious; and there is a great temptation to use the packaged binaries that come with your distribution of choice. I would recommend against this. In a world of zero day exploits, the time it takes the package maintainer to compile and distribute the binaries may be unacceptable. By compiling from the source, you will be in full control of your security situation.<\/p>\n
    Apache 2.2.0<\/h2>\n
    Now to start compiling and install the services you will be using. Apache<\/em> is a good place to start, since other packages have compile time dependencies on it.<\/p>\n
    Always verify the `checksums` of packages you download, if there is a mismatch start over and download it again<\/strong><\/p>\n
    \n
        md5sum httpd-2.2.0.tar.gz  \r\n    tar -xzvf httpd-2.2.0.tar.gz \r\n    .\/configure --prefix=\/usr\/local\/apache \\\r\n           --enable-ssl --enable-speling \\ \r\n           --enable-rewrite --enable-proxy  \r\n    make  \r\n    make install<\/pre>\n<\/div>\n
    MySQL 5.0.18<\/h2>\n
    Download the MySQL<\/em> binaries from the mysql site (see resources). This is an exception to my mantra of compiling from source\u2014since the binaries come directly from MySQL<\/em>, as soon as there is an update you can download the latest version.<\/p>\n
    Note: due to space constraints {.} is shorthand for the version of the tarball.<\/p>\n
    \n
      md5sum mysql-{.}-linux-i686-glibc23.tar.gz\r\n  cp mysql-{.}-linux-i686-glibc23.tar.gz \/usr\/local\r\n  tar -xzvf mysql-{.}-linux-i686-glibc23.tar.gz\r\n  ln -s \/usr\/local\/mysql-{.}-linux-i686-glibc23 \\\r\n                                   \/usr\/local\/mysql\r\n\r\n  groupadd mysql\r\n  useradd -g mysql mysql\r\n  cd mysql\r\n  scripts\/mysql_install_db --user=mysql\r\n  chown -R root  .\r\n  chown -R mysql data\r\n  chgrp -R mysql .\r\n  bin\/mysqld_safe --user=mysql &\r\n  cp  support-files\/mysql.server \/etc\/init.d\/mysql\r\n\r\n  # Make sure that mysql is started if \r\n  # there is a reboot\r\n\r\n  cd \/etc\/rc3.d\/\r\n  ln -s \/etc\/init.d\/mysql S90mysql\r\n  ln -s \/etc\/init.d\/mysql K90mysql\r\n\r\n  # Copy the configuration file\r\n  cp support-files\/my-medium.cnf \/etc\/my.cnf<\/pre>\n<\/div>\n
    PHP 5.1.2<\/h2>\n
    Now download the php<\/em> package from the php.net site (see resources).<\/p>\n
    \n
      md5sum php-5.1.2.tar.gz\r\n  tar -xzvf php-5.1.2.tar.gz\r\n  .\/configure --with-prefix=\/usr\/local\/php \\ \r\n      --with-apxs2=\/usr\/local\/apache\/bin\/apxs \\\r\n      --with-mysql=\/usr\/local\/mysql\r\n  make\r\n  make install\r\n  cp php.ini-dist \/usr\/local\/php\/php.ini<\/pre>\n<\/div>\n
    Tomcat 5.5.16<\/h2>\n
    Apache-Tomcat<\/em> is also an exception to my always compile rule.<\/p>\n
    \n
      md5sum apache-tomcat-5.5.16.tar.gz\r\n  tar -xzvf apache-tomcat-5.5.16.tar.gz<\/pre>\n<\/div>\n
    mod_jk<\/h2>\n
    Download mod_jk<\/code> from the the tomcat project page (see resources).<\/p>\n
    \n
      tar -xzvf jakarta-tomcat-connectors.tar.gz\r\n  cd jakarta\/jk\/native\r\n  .\/configure --with-apxs=\/usr\/local\/apache\/bin\/apxs\r\n  make\r\n  make install<\/pre>\n<\/div>\n
    mod_security<\/h2>\n
    mod_security<\/code> is the most excellent Apache module written by Ivan Ristic.<\/p>\n
    \n
      md5sum modsecurity-apache-1.9.2.tar.gz\r\n  tar -xzvf modsecurity-apache-1.9.2.tar.gz\r\n  cd modsecurity-apache-1.9.2\/apache2\r\n  \/usr\/local\/apache\/bin\/apxs -cia mod_security.c<\/pre>\n<\/div>\n
    Configuring Apache 2.2.0<\/h2>\n
    By this point, you should have installed all of the services and apache modules needed to host and secure PHP and Java environments. Now it\u2019s time to take a look at properly configuring everything for security.<\/p>\n
    _Apache 2.2.0_ has the ability to list both statically compiled and shared modules with the `-M` option to `apachectl`<\/strong><\/p>\n
    Apache 2.2.0<\/em> introduces a new configuration layout and new default options in the httpd.conf<\/code> file. In previous versions of Apache, there was only one configuration file by default, which was conf\/httpd.conf<\/code>; in the current version, the Apache project has taken another step towards its goal of making configuration more managable and modular. The conf\/httpd.conf<\/code> is the main configuration file with include statements for the various configuration files under conf\/extra<\/code> such as httpd-ssl.conf<\/code> and httpd-vhosts.conf<\/code>.<\/p>\n
    Another new and exciting security feature in Apache 2.2.0<\/em> is that the root httpd.conf<\/code> access is denied to all directories. This can be confusing to users coming from previous versions such as 2.0.55 but it is a great step forward in terms of security.<\/p>\n
    Here is the configuration directive mentioned above; I would suggest leaving it the way it is. We will allow access for specific virtual-hosts and directories later on.<\/p>\n
    \n
      # Default access control  \\\r\n  # Highly restrictive and applies \\\r\n  # to everything below it.\r\n\r\n  <Directory \/>\r\n    Options FollowSymLinks\r\n    AllowOverride None\r\n    Order deny,allow\r\n    Deny from all\r\n  <\/Directory><\/pre>\n<\/div>\n
    Every host, which Apache will be responsible for, will be a virtual host or \u201cvhost\u201d. So, start by uncommenting the Include<\/code> directives at the bottom of conf\/httpd.conf<\/code>. This is done so that the httpd-vhosts.conf<\/code>, httpd-ssl.conf<\/code> and httpd-dedfault.conf<\/code> are included in the main httpd.conf<\/code> configuration file.<\/p>\n
    Yet another cool new feature in Apache 2.2.0<\/em> is the ability to see all modules both statically compiled and shared with the -M<\/code> option to apachectl<\/code>.<\/p>\n
    \n
      # Edit \/usr\/local\/apache\/conf\/httpd.conf\r\n\r\n  # Move the LoadModule Statement for mod_security \r\n  # to the top of all module\r\n  # statements. This is needed to use SecChrootDir\r\n\r\n  # Add the following line to load mod_jk\r\n   LoadModule jk_module   modules\/mod_jk.so\r\n\r\n  # The default User and Group is set to daemon, \r\n  # create and apache user and group and then \r\n  # configure apache to run as such.\r\n  User apache\r\n  Group apache\r\n\r\n  # List all modules to verify that mod_jk, \r\n  # mod_security, mod_php, and mod_ssl \r\n  # are correctly installed and loaded.\r\n   \/usr\/local\/apache\/bin\/apachectl -M \r\n\r\n  # Virtual hosts \r\n\r\n  Include conf\/extra\/httpd-vhosts.conf \\\r\n  -> Include conf\/extra\/httpd-vhosts.conf \r\n\r\n  # Various default settings\r\n  Include conf\/extra\/httpd-default.conf \\\r\n  -> Include conf\/extra\/httpd-default.conf \r\n\r\n  # Secure (SSL\/TLS) connections\r\n   Include conf\/extra\/httpd-ssl.conf \\\r\n  -> Include conf\/extra\/httpd-ssl.conf<\/pre>\n<\/div>\n
    Now it\u2019s time to descend into the extra directory to configure virtual hosts. Open httpd-vhosts.conf<\/code> in your favorite editor. Next, configure the document root to be \/srv\/www\/vhost1<\/code>. Also, add the AddType<\/code> directive for php<\/em>. PHP<\/em> files don\u2019t have to have the .php<\/code> file extension. In fact, it\u2019s probably a good idea if they are .html<\/code> files. By using the .php<\/code> file extention you are advertizing more information about your setup than you need to.<\/p>\n
    `mod_security` makes `chrooting` Apache easy!<\/strong><\/p>\n
    Here is the full vhost configuration stanza. It is annotated with inline comments: please take the time to read through it.<\/p>\n
    \n
      # Enable mod_security engine\r\n  SecFilterEngine On\r\n\r\n  # Chroot Apache the easy way just make sure \r\n  # your web content is under the chrooted directory\r\n\r\n  # Note: The log directives must also be valid \r\n  # directories releative to the chroot dir.\r\n\r\n  # Note: THIS CANNOT GO INSIDE VHOST STANZA\r\n  # as it applies to the entire apache configuration\r\n  SecChrootDir \/chroot\/apache\r\n\r\n  # Delete the 2nd Vhost stanza as you will only be \r\n  # using one for now\r\n  <VirtualHost *:80>\r\n    ServerAdmin webmaster@mydomain.com\r\n    DocumentRoot \/srv\/www\/vhost1\r\n    ServerName vhost.mydomain.com\r\n    ServerAlias www.mydomain.com\r\n    ErrorLog logs\/vhost.mydomain.com-error_log\r\n    CustomLog logs\/vhost.mydomain.com-access_log \\ \r\n                        common\r\n\r\n    # The PHP engine will interpret all \r\n    # .php and .html files for php code\r\n    AddType application\/x-httpd-php .php .phtml \\ \r\n                         .html\r\n\r\n    AddType application\/x-httpd-php-source .phps\r\n\r\n    # Add a local Directory directive to override \r\n    # the global Deny From all in conf\/httpd.conf\r\n    <Directory \/>\r\n      Options FollowSymLinks\r\n      AllowOverride None\r\n      Order deny,allow\r\n      Allow from all\r\n    <\/Directory>\r\n\r\n    # Restrict Access to sensitive files\r\n    <FilesMatch \"\\.(inc|txt|tar|gz|zip)$\">\r\n      Deny from all\r\n    <\/FilesMatch>\r\n\r\n    # Configure MOD_JK\r\n    JkWorkersFile \\\r\n             \"\/usr\/local\/apache\/conf\/workers.properties\"\r\n    JkLogFile \\\r\n               \"\/usr\/local\/apache2\/logs\/mod_jk_www.log\"\r\n    JkLogLevel info\r\n    JkLogStampFormat \"[%a %b %d %H:%M:%S %Y] \"\r\n    JkOptions +ForwardKeySize +ForwardURICompat \\ \r\n                                    -ForwardDirectories\r\n    JkRequestLogFormat \"%w %V %T\"\r\n\r\n    # Any URL that begins with \/java\/ will be \r\n    # forwarded to the java webapp in tomcat\r\n    JkMount \/java\/* ajp13\r\n\r\n    # Enable and configure MOD_SECURITY\r\n\r\n    # See the mod_security documentation \r\n    # link in resources [3]\r\n\r\n    # POST Scanning is disabled by default\r\n    SecFilterScanPOST On\r\n\r\n    # Make sure only content with standard \r\n    # encoding types is accepted\r\n    SecFilterSelective HTTP_Content-Type \\\r\n\r\n    \"!(^$|^application\/x-www-form-urlencoded$|^multipart\/form-data;)\"\r\n\r\n    # Default Action is to reject request, log, and\r\n    # then return HTTP Response 404 which is \r\n    # File Not Found. \r\n    # Another option would be 403 which is access\r\n    # denied.\r\n    SecFilterDefaultAction \"deny,log,status:404\"\r\n\r\n    # Enable URLEncoding validation. This can \r\n    # prevent Cross-Site Scripting attacks \r\n    SecFilterCheckURLEncoding On\r\n\r\n    # Catch and Prevent PHP Fatal Errors from \r\n    # being displayed to the USER\r\n    SecFilterSelective OUTPUT \"Fatal error:\" \\\r\n                    deny,status:500\r\n\r\n    # Obviously you have to code up this custom \r\n    # Error Page\r\n    ErrorDocument 500 \/php-fatal-error.html \r\n\r\n    # This can be useful to avoid stack overflow \r\n    # attacks default is 0 255 ie All bytes allowed\r\n    SecFilterForceByteRange 32 126\r\n\r\n    <\/VirtualHost><\/pre>\n<\/div>\n
    Here is the mod_jk<\/code> configuration file apache\/conf\/workers.properties<\/code> (referenced above):<\/p>\n
    \n
      worker.list=ajp13\r\n  workers.tomcat_home= \\\r\n        \/usr\/local\/java\/apache-tomcat-5.5.12\r\n\r\n  workers.java_home=\/usr\/local\/java\/jdk1.5.0_06\r\n  worker.ajp13.type=ajp13\r\n  worker.ajp13.host=localhost\r\n  worker.ajp13.port=8009<\/pre>\n<\/div>\n
    Apache can be used to configure other web consoles such as the Tomcat Manager application<\/strong><\/p>\n
    The configuration stanza below is a variation on an article:<\/p>\n
    \n
    <VirtualHost *:80>\r\n  ServerAdmin webmaster@zero-analog.com\r\n  DocumentRoot \/srv\/www\/hercules.zero-analog.com\r\n  ServerName hercules.zero-analog.com\r\n  ErrorLog logs\/hercules.zero-analog-error_log\r\n  CustomLog logs\/hercules.zero-analog-access_log \\\r\n                                             common\r\n\r\n  <Directory \/>\r\n      Options FollowSymLinks\r\n      AllowOverride None\r\n      Order deny,allow\r\n  <\/Directory>\r\n\r\n  <FilesMatch \"\\.(inc|txt|tar|gz|zip)$\">\r\n      Deny from all\r\n  <\/FilesMatch>\r\n\r\n  # This whole stanza is really to forward http \r\n  # requests to https:\/\/ tomcat manager\r\n  # so appended \/html to the rewrite target. \r\n  # since the full path is manager\/html \r\n\r\n  <IfModule mod_rewrite.c>\r\n   <IfModule mod_ssl.c>\r\n       <Location \/manager>\r\n         RewriteEngine on\r\n         RewriteCond %{HTTPS} !^on$ [NC]\r\n         RewriteRule . \\\r\n          https:\/\/%{HTTP_HOST}%{REQUEST_URI}\/html \\\r\n                                [L]\r\n        <\/Location>\r\n   <\/IfModule>\r\n  <\/IfModule>\r\n\r\n<\/VirtualHost>\r\n\r\n# This is the ssl-vhost under extra\/httpd-ssl.conf \r\n\r\n<VirtualHost _default_:443>\r\n  # General setup for the virtual host\r\n  DocumentRoot \"\/srv\/www\/outpost.zero-analog.com\"\r\n  ServerName hercules.zero-analog.com:443\r\n  ServerAdmin webmaster@zero-analog.com\r\n\r\n  ErrorLog \/usr\/local\/apache2\/logs\/error_log\r\n  TransferLog \/usr\/local\/apache2\/logs\/access_log\r\n\r\n  <Directory \/>\r\n    Options FollowSymLinks\r\n    AllowOverride None\r\n    Order deny,allow\r\n  <\/Directory>\r\n\r\n  RewriteEngine on\r\n  RewriteRule \"^\/manager$\" \\\r\n    \"https:\/\/outpost.zero-analog.com\/manager\/html\" \\\r\n                                               [R,L]\r\n\r\n   JkWorkersFile \\\r\n       \"\/usr\/local\/apache2\/conf\/workers.properties\"\r\n   JkLogFile \\\r\n       \"\/usr\/local\/apache2\/logs\/mod_jk_hercules.log\"\r\n   JkLogLevel info\r\n   JkLogStampFormat \"[%a %b %d %H:%M:%S %Y] \"\r\n   JkOptions +ForwardKeySize +ForwardURICompat \\\r\n                             -ForwardDirectories\r\n   JkRequestLogFormat \"%w %V %T\"\r\n   JkMount \/manager\/* ajp13\r\n\r\n   #   Enable\/Disable SSL for this virtual host.\r\n   SSLEngine on\r\n\r\n   # List the ciphers that the client is permitted \r\n   # to negotiate. See the mod_ssl documentation\r\n   # for a complete list.\r\n   SSLCipherSuite  ALL:!ADH:!EXPORT56:RC4+RSA: \\ \r\n         +HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL\r\n\r\n   # Server Certificate: Point SSLCertificateFile\r\n   # at a PEM encoded certificate.\r\n\r\n   SSLCertificateFile \\ \r\n                \/usr\/local\/apache\/conf\/server.crt\r\n\r\n   # Server Private Key:\r\n   SSLCertificateKeyFile \\ \r\n                \/usr\/local\/apache\/conf\/server.key\r\n\r\n   SSLOptions +FakeBasicAuth \\\r\n              +ExportCertData \\\r\n              +StrictRequire\r\n\r\n   <FilesMatch \"\\.(cgi|shtml|phtml|php)$\">\r\n           SSLOptions +StdEnvVars\r\n   <\/FilesMatch>\r\n\r\n   <Directory \"\/usr\/local\/apache2\/cgi-bin\">\r\n           SSLOptions +StdEnvVars\r\n   <\/Directory>\r\n\r\n   BrowserMatch \".*MSIE.*\" \\\r\n           nokeepalive ssl-unclean-shutdown \\\r\n            downgrade-1.0 force-response-1.0\r\n\r\n   # Per-Server Logging:\r\n   # The home of a custom SSL log file. \r\n   # Use this when you want a compact non-error \r\n   # SSL logfile on a virtual host basis.\r\n\r\n   # *** Note there are \\ characters in this \r\n   # string. These are not my artificial line-\r\n   # breaks, please include them ***\r\n\r\n   CustomLog \/usr\/local\/apache2\/logs\/ssl_request_log \r\n             %t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \\\"%r\\\" %b\"\r\n\r\n<\/VirtualHost><\/pre>\n<\/div>\n
    Configuring PHP<\/h2>\n
    I have already copied the php.ini<\/code> to \/usr\/local\/php\/php.ini<\/code> so that it will be read by the PHP<\/em> engine at startup. By default it\u2019s fairly secure, but there are one or two things you can do to improve security.<\/p>\n
    Disable PHP display_errors for security<\/strong><\/p>\n
    \n
      # Edit \/usr\/local\/php\/php.ini with your \r\n  # favorite editor\r\n\r\n  # Since you're are going through the trouble of \r\n  # hiding PHP files you might as well disable \r\n  # this as well\r\n   expose_php = On -> expose_php = Off \r\n\r\n  # You really don't want users, or worse yet \r\n  # an attacker to see error messages\r\n   display_errors = On -> \\\r\n      display_erros = Off \r\n\r\n  # But you do want them logged \\\r\n   log_errors = Off -> log_errors = On \r\n\r\n  # Log to a file\r\n  ;error_log = filename -> \\\r\n       error_log = \/var\/log\/php-err<\/pre>\n<\/div>\n
    Another option to consider is the Hardened-PHP project<\/em> (see resources section). This is the brain child of three German developers, who continously perform code audits of popular PHP applications. They also release a patch for the standard PHP code, which fixes bugs and security holes in fringe configuration cases, where the main project developers have not had the time or the desire to find a fix.<\/p>\n
    Configuring Tomcat<\/h2>\n
    The main configuration files from Tomcat are under $CATALINA_HOME\/conf<\/code>. The following files are of interest:<\/p>\n