Category: Open Source

We’ve gone through quite a few security / penetration / web application tests at work (often as part of compliance with HMG SPF / InfoSec standards for UK Government projects) and thought it would be useful to list some of the steps you need to consider (hardening, configuring etc) to ensure your application has a reduced security exposure. I feel that you should view security testing as an opportunity to improve the quality of your work rather than see it as a box ticking exercise (ultimately the testing is about making your application more secure which can only be a good thing). Whilst a lost of our work is based on LAMP (Linux, Apache, MySQL, PHP) many of the concepts below apply regardless of the technology used.

Firewalls and Port Access

Firewalls and access to ports – one of the most obvious – but you need to consider whether the risk profile requires one or 2 levels of hardware firewall, or whether iptables is sufficient. Can you lock down the environment such that you only expose port 80 or 443 to wider internet and create a restricted IP address based white list for administration (eg SSH access)? On many of our Architectures we only expose the load balancer(s) and or proxy layer to the internet, everything else is not available at all to general IP addresses across the internet.

If you do have to have SSH open to all make sure that you install denyhosts (which helps to prevent SSH brute force attacks by adding persistant bad username/password attempts to /etc/hosts.deny – preventing access from the offending IP address)

Cross Site Scripting (XSS) and SQL Injection vectors

Check that your application does something sensible if someone attempts to put javascript into text input boxes. Check that putting in something like:

“><script>alert(‘If you see this in an alert box there is a XSS vector in your application’)</script> into a username box (for example) does. If it brings up an alert dialog you know you have a problem. See the  XSS Wikipedia page for more info.

Similarly for SQL – if you put in rogue SQL key words does it mess with the SQL that is run? Do something non- destructive (particularly if you are spot checking a live web site environment!) A good example I like to use is can I add parameters to a where clause to see data I shouldn’t be able to see.

Personally I prefer 2 levels of checks for SQL Injection and XSS type code in application input: – one at the application input layer (eg sanitising user input asap) and another at the database interface / wrapper layer to ensure nothing nasty can get sent to be stored or messed about with on the database tier.

Server Hardening / Configuring

Ensuring the server is setup and configured properly

Google for and check the hardening guide for the operating system for recommended steps.

Ensure that security updates are being applied on a regular basis.

Ensure that anti-virus software is installed (for the Linux Platform ClamAV is an option)

Review (and peer review if possible) the configuration files for the main services on this box – for LAMP this means a minimum of:

(You can run locate <name of config file> to check where it is located)

• /etc/ssh/sshd_config

• php.ini

• httpd.conf / apache2.conf (depending on how the server is configured) and configuration files for virtual hosts / SSL configuration

• my.cnf (or other database config)

• Load Balancer config files (for Pound this is typically /etc/pound.cfg)

These checks are particularly important if you are having a white box review of your system (where you give the SSH login details to a security tester to check the configuration).

Pre test checks

Before you hand over the system to the Internet Security guys run some of the kinds of tools that they will be running yourself to see what is available. As a minimum run an NMAP command against your ip addresses:

nmap -A -vv [IP Address]

And see what ports (and information about the ports) is returned. Also check if NMAP can enumerate what Operating System and Versions of Web Server software is running (can you do anything to remove version numbers or product names?)

These days  I like to use Backtrack (a Linux Distribution design for security testing) for security checks. I am running it as a Virtual Machine from with my Windows 7 machine (http://g0tmi1k.blogspot.com/2010/01/tutorial-video-how-to-install-backtrack.html as a useful video for getting it set up).

I could probably write all day about security but hopefully this gives a feel for the key aspects. Would be interested to hear anyone’s tips or must dos for LAMP security.