#web-server

Chroot and jails

Unix-like systems offer a feature allowing the user to run processes within an isolated filesystem. This is done using the chroot command, which provides means to change the apparent root directory.

The basic idea here is to “use a system within the system”, and run the processes related to your web-app from within that confined environment. There are various approaches to this, so we’ll explain the basics and point you to some tutorials that will provide detailed, step-by-step ways to do this. In general, the approach is the following:

Create a “jail” directory (e.g. /var/jail/ ) that will serve as a basis directory for your chrooted environment;

Install a light Linux distribution into this directory – e.g. using the debootstrap program;

Install your web-server binaries into your jail directory;

Write scripts to start and stop your web-server in the chrooted environment;

Place these scripts in your /etc/init.d/ directory, and make them executable;

Start your web-server using these scripts.

As a result, you end up with a web-application server being controlled from your “top” system, but without access to it. This ensures - to a certain extent – that in the case of a breach on your web-app, the breach will be limited to the “jail” environment only.

Alternatives to, or based upon, chroot exist. Linux Containers (LXC), Docker, AppArmor, etc., also provide isolation/containment functionalities and can be easier to deploy depending on your needs. In the case you’re running a BSD-like system, BSD Jails can also be worth looking at. We provide the right links towards the end of this article.

Mod_security and web-server config

Next, you want to setup a web application Firewall. On Ubuntu, mod_security provides a rules engine that will reject suspicious queries related to potential hacking attempts (this web-application firewall is also available on Windows, by the way…).

#Install mod_security admin@server:sudo apt-get install libapache2-modsecurity #Use the default set of rules admin@server:sudo mv /etc/modsecurity/modsecurity.conf{-recommended,}   #Enable mod_security admin@server:sudo nano /etc/modsecurity/modsecurity.conf   #Change the following line: SecRuleEngine DetectionOnly   #by: SecRuleEngine on   #Reload the Apache server admin@server:sudo service apache2 reload

Further customization is of course possible but this will get you started. Be careful not to define too many rules, as it might impair the performances of your web-server.

One last thing before going further: you don’t want to leave too much information for public eyes. By this, we mean server type and version, error stacks, etc. Therefore, make sure only generic 404 error messages are provided to your users and also remove all host-related information from the responses your users will get. On an Apache server, this is usually achieved by doing the following changes in your security.conf file:

ServerTokens ProductOnly ServerSignature Off

The first directive will limit the information related to the server (i.e. the user will only know that you’re running Apache), while the second directive forbids a possible trailing footer from being added under certain contexts (e.g. error messages).

So, the fun part now…

Before starting with the pentest thing, you should have a look at the OWASP project (https://www.owasp.org) and their top 10 ranking of vulnerabilities. Our goal here is not to re-invent the wheel, but to give you a quick insight on how to look for common flaws.

There are a lot of free and/or open-source software that can help you in this process. In this post, we’ll use the OWASP ZAP Scanner along with BurpSuite (free version).

What a scanner does is basically crawl a site and tamper with all the input parameters it finds. As such, all kinds of inputs are subject to manipulations in order to attempt various types of attacks. Depending on the response received by the scanner, it can deduce with more or less confidence that the application is subject – or not - to a given number of vulnerabilities.

The following example was made using the OWASP ZAP scanner and a web-application called WebGoat, which is designed to be vulnerable.

Using ZAP is as easy as defining the URL of the target and click on the “Attack” button:

The third and final step is collecting the results:

Though in this case, we can be rather confident that those vulnerabilities are real (the application was designed to be vulnerable), in real life it is important to make manual checks in order to validate your scan results. For this, you need an intercepting proxy, such as BurpSuite, WebScarab, or Paros (this list is not extensive – ZAP also acts as a proxy). In our case, we will use BurpSuite.

Setting BurpSuite as a proxy is as simple as defining a listening port number (8080 by default) and clicking on “Intercept is on”. In your browser, you must then specify that you connect through a proxy, running on 127.0.0.1 and listening on the port number you gave. You can then intercept the requests you send:

And of course you can manipulate the value of each parameter before forwarding it to the application, in order to attempt various attacks:

BurpSuite is not limited to just intercept and manipulate. There are a number of very interesting attack features (e.g.  the Intruder and Repeater tools) that can help you in performing multiple kinds of attacks, from enumerating user IDs to brute-forcing passwords, auto-replacing specific values in the requests or responses, etc. There are a lot of detailed, step-by-step tutorials out on the Web, and we recommend going through a few of them in order to grasp a better perspective of what this tool is offering.

Recommend links and reads:

Tomcat security (chroot): http://oreilly.com/catalog/tomcat/chapter/ch06.pdf

BurpSuite: http://portswigger.net/burp/download.html

BurpSuite tutorials: https://www.pentestgeek.com/2014/07/02/burp-suite-tutorial-1/ and http://www.securityninja.co.uk/hacking/burp-suite-tutorial-the-intruder-tool/

OWASP ZAP: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

WebGoat (practice): https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

LXC: https://linuxcontainers.org/

Docker: https://www.docker.com/

AppArmor: http://wiki.apparmor.net/

BSD Jails on FreeBSD: https://www.freebsd.org/doc/handbook/jails.html