Blog @ ARHS

Integrate FitNesse with Maven

There are 2 ways to do so:

Either run FitNesse from a JUnit test;

Or use a plugin that will do all the work.

JUnit

FitNesse's class JUnitHelper is very easy to use. You simply have to specify the FitNesse root directory and the output directory for the results.

public class FitnesseIT {      /**     * Run fitnesse tests     * @throws Exception if error occurs     */    @Test    public void runFitnesseTests() throws Exception {        JUnitHelper helper = new JUnitHelper(new File("fitnesse/root/dir",                new File(System.getProperty("java.io.tmpdir"), "fitnesse").getAbsolutePath());       helper.assertTestPasses("MyTest");    } }

There is also a JUnit 4 runner (FitNesseSuite) that you can use instead. It allows better integration with graphical test runners.

Note: By default, JUnitHelper will define the web server port to 0. Doing so, no web server will be started and only the underlying core FitNesse code will be used.

Good Practice

FitNesse is about integration tests, not unit tests. It is a good practice to separate both. Integration tests should run during the integration-test phase of the Maven build lifecycle.

Here is a small Maven configuration excerpt:

<plugin>    <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-surefire-plugin</artifactId>    <configuration>        <excludes>            <exclude>**/*IT.java</exclude>        </excludes>    </configuration> </plugin> <plugin>   <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-failsafe-plugin</artifactId>    <configuration>        <includes>            <include>**/*IT.java</include>        </includes>    </configuration>    <executions>        <execution>            <goals>                <goal>integration-test</goal>                <goal>verify</goal>            </goals>        </execution>    </executions> </plugin>

Surefire is used to run unit tests while failsafe is used to run integration tests. Integration tests classes will need to end in "IT".

Plugin

As an alternative to writing your own JUnit tests you may want to use a maven plugin. Several plugins exist, but from what we experienced, none is mature enough to provide a solution for all use cases.

For a simple solution, the fitnesse-launcher-maven-plugin works quite well. The following excerpt shows a simple configuration.

<plugin>   <groupId>uk.co.javahelp.fitnesse</groupId>   <artifactId>fitnesse-launcher-maven-plugin</artifactId>    <version>1.3.0</version>    <executions>        <execution>            <id>set-up</id>           <phase>pre-integration-test</phase>            <goals>                <goal>set-up</goal>            </goals>        </execution>        <execution>            <id>run-tests</id>           <phase>integration-test</phase>            <goals>               <goal>run-tests</goal>            </goals>        </execution>        <execution>            <id>tear-down</id>           <phase>post-integration-test</phase>            <goals>               <goal>tear-down</goal>            </goals>        </execution>        <execution>            <id>verify</id>            <phase>verify</phase>            <goals>                <goal>verify</goal>            </goals>        </execution>    </executions>    <configuration>        <useProjectDependencies>            <scope>compile</scope>        </useProjectDependencies>        <port>8888</port>        <testResourceDirectory>src/test/fitnesse</testResourceDirectory>       <createSymLink>true</createSymLink>        <test>MyTest</test>    </configuration> </plugin>  

When running maven (mvn verify), the plugin will:

Setup the FitNesse root directory (generates the base files to run the wiki);

Create a symlink on the web server to your src/test/fitnesse project directory. This directory contains the files defining your tests;

Replace a placeholder in your test files to use Maven compilation classpath. This avoids manual declaration;

Launch the web server and run the tests;

Clean things up;

Fail the build depending on the results of the tests.

Unfortunately, some things are missing:

If you want to run the tests without launching the web server (set the port to 0), you won't be able to use symlinks. You will have to copy the resources yourself to the FitNesse root directory (using maven-resources-plugin);

Sonar is not able to use these test results to produce coverage statistics out of the box;

You cannot define which version of FitNesse you want to use. You have to wait for an update of the plugin to use the latest version. You can always override the plugin's dependency to FitNesse, but this doesn't always work as expected.

Test Coverage with Sonar

Here comes the best part. We already have unit test coverage statistics in Sonar out of the box. But Sonar tells us it is possible to have a separate statistic for integration tests and an overall test coverage including both kinds of test.

We will have to use JaCoCo which does the job of computing the statistics. Then Sonar will be able to read these and display them.

JaCoCo

JaCoCo works by attaching an agent to the JVM that runs the tests. Here is how we can configure the JaCoCo plugin in Maven:

<plugin>    <groupId>org.jacoco</groupId>   <artifactId>jacoco-maven-plugin</artifactId>    <executions>        <execution>            <id>prepare-agent-test</id>            <goals>               <goal>prepare-agent</goal>            </goals>            <configuration>               <destFile>${basedir}/../cdbi-tools/target/jacoco/jacoco.exec</destFile>                <propertyName>testLineArgs</propertyName>                <includes>                    <include>com.arhs.project.*</include>                </includes>            </configuration>        </execution>        <execution>           <id>prepare-agent-it-test</id>            <goals>               <goal>prepare-agent</goal>            </goals>            <configuration>               <destFile>${basedir}/../cdbi-tools/target/jacoco/jacoco-it.exec</destFile>               <propertyName>itTestLineArgs</propertyName>                <includes>                    <include> com.arhs.project.*</include>                </includes>            </configuration>        </execution>        <execution>            <id>test</id>            <phase>test</phase>            <goals>                <goal>report</goal>            </goals>            <configuration>               <dataFile>${basedir}/../cdbi-tools/target/jacoco/jacoco.exec</dataFile>               <outputDirectory>${basedir}/../cdbi-tools/target/jacoco/reports-test</outputDirectory>            </configuration>        </execution>        <execution>            <id>int-test</id>           <phase>post-integration-test</phase>            <goals>                <goal>report</goal>            </goals>            <configuration>               <dataFile>${basedir}/../cdbi-tools/target/jacoco/jacoco-it.exec</dataFile>               <outputDirectory>${basedir}/../cdbi-tools/target/jacoco/reports-it-test</outputDirectory>            </configuration>        </execution>    </executions> </plugin>  

We configured 2 agents, one for each kinds of test. For each:

We defined a destination folder for the test results;

We defined a property name that will hold the arguments that needs to be passed to the JVM executing the tests;

We only included classes that are part of our project codebase.

Then we defined 2 executions of the report goal. Again one for each kind of test. This is probably not required for Sonar, but is a good way to debug your configuration. For each, we defined:

At what phase the goal is executed;

The data file from which the report will be generated;

The output directory for the report.

Test Execution

Once JaCoCo is configured, we still have to pass the JVM arguments to the JVM running the tests.

If using surefire or failsafe, it is very simple. Just specify the argLine property:

<plugin>   <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-surefire-plugin</artifactId>    <configuration>        <argLine>${testLineArgs}</argLine>        <excludes>           <exclude>**/*IT.java</exclude>        </excludes>    </configuration> </plugin> <plugin>   <groupId>org.apache.maven.plugins</groupId>   <artifactId>maven-failsafe-plugin</artifactId>   <configuration>       <argLine>${itTestLineArgs}</argLine>        <includes>           <include>**/*IT.java</include>        </includes>    </configuration>    <executions>        <execution>            <goals>                <goal>integration-test</goal>                <goal>verify</goal>            </goals>        </execution>    </executions> </plugin>

If using another plugin, I don't think it is feasible without a little plumbing work.

Note: In the end, we ended up using a hybrid solution where the fitnesse-launcher-maven-plugin was used only to setup the FitNesse root directory. All other steps are performed by other means (i.e. maven-resources-plugin to copy resources and maven-failsafe-plugin to execute the tests).

Sonar

Now that JaCoCo will be able to do its work and generate coverage results, we need to tell Sonar where to find them.

This is pretty easy. Simply define the following properties in your pom file:

<properties>    <sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>   <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>   <sonar.jacoco.itReportPath>${basedir}/../cdbi-tools/target/jacoco/jacoco-it.exec</sonar.jacoco.itReportPath>    <sonar.junit.reportsPath>${build.directory}/surefire-reports</sonar.junit.reportsPath>   <sonar.jacoco.reportPath>${basedir}/../cdbi-tools/target/jacoco/jacoco.exec</sonar.jacoco.reportPath>   <sonar.language>java</sonar.language> </properties>

End Result

Et voilà!

Enabling JMX remote connections is very simple. Under the Hotspot JVM, just specify the following system properties when starting the JVM:

-Dcom.sun.management.jmxremote.port=9910 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

Here we don’t want to bother with authentication and security features, so these are simply disabled.

In the background, an RMI registry will be started and listen on the port specified. You may already know it, but RMI only uses the specified port for the registry connection. The actual connection will be made on a random port. This of course leads to problems once a firewall gets in the way as you won’t be able to open the right port.

Until JDK 7 (JDK 7u4 to be precise), you had to go through a lot of pain to get RMI to use a specific port. Now a new system property made this a lot simpler:

-Dcom.sun.management.jmxremote.rmi.port=9911

This property is mysteriously undocumented in Oracle official documentation. I only came across it in several blog posts. It will force RMI to use this port instead of a random pick.

You can now open the two specified ports on your firewall and enjoy the rest of the day!

Commonly, when you face this kind of problem, you just start writing a newsletter or something similar. You expect this to be easy to do and be read by everybody; however this is quite never the case. Indeed, you will face several problems:

It will be complicated to have regular fresh information from everybody;

People already receive a lot of information by different means, so they will not be very keen to read your output;

Finally, it will be an additional thing they have to read or process in their inbox.

Taking this into account, we explored other ways to communicate efficiently within the company about what we do and what’s happening.

Inspired by the Agile practices we use every day to execute our projects, we have explored the idea of an information radiator. An "information radiator is the generic term for any of a number of handwritten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance” (definition by the Agile Alliance). So… let’s be concise: a kind of dashboard.

We decided to call our Information Radiator: Helios. Helios is the personification of the Sun in Greek mythology. One of his roles is to reveal all what happens on earth.

One important point was to be able to push good, fresh information to our people and avoiding having somebody full-time to gather and publish this information. Hopefully, at Arηs, we have a bunch of internal systems containing a lot of interesting information about the Arηs life.

So, we did what we are good at: we automated.

Helios is materialised by televisions (big ones! ;-)) which display, simultaneously in our premises in Luxembourg and in Belgium, a mix of information automatically retrieved from our systems, from the internet and dedicated internal news.

So people can know in real time: the newcomers in the company, the birthdays (those guys usually offer croissants, so interesting to know! :-)), the weather, the traffic, the on-going projects (with a summary on the scope and techno), the current job openings… All this retrieved automatically via a set of REST services. And at the same time, we are able to provide also information on events or social activities (running, football…) we organise, contracts we win or important milestones we reach.

The greatest advantage of Helios is that information is always available, easily accessible and continuously up to date. It improved considerably the knowledge people have on Arηs (about people and projects) and on what we are performing on a daily basis. Moreover, Helios allows us to strengthen the corporate culture, and cohesion among the Arηs group by welcoming newcomers and celebrating birthdays.

One of the important things about this project is that it scales, no matter how big the company is. It will be even more powerful with the continuous growth of the company since a bigger company will have more data and thus the number of possibilities to share analytics on this data will grow exponentially.

Currently, Helios is only available within ARHS premises… but we are thinking to extend it somehow for our colleagues working at our customers. It would be great if we can do something there too.

Adding new features to Helios will be a continuous challenge required to keep a strong internal communication and to empower our employees!

First off, a good help for defining Semantic Web comes from, well, semantics: sēmantikós is ancient Greek for significant. We can start by asserting that:

Semantic Web is a movement aimed to give significance to web contents.

“Significance?” may Wally ask. “I don’t see why should a machine be aware about what web content means – let alone the feasibility of it!”

I’m not speaking about any AI here, which goes well beyond my understanding. Rather, The Semantic Web aims to add metadata – that is, data that describes other data – to web pages: doing so, the World Wide Web becomes machine-readable.

Think about how most of the web of today represents a paradox: it is hosted and runs on computers, but made for people to understand it; also, think about how web pages are presented in natural language, but computers cannot get any meaning out of them. Instead, by using metadata machines, they are able to:

Uniquely identify data Content is not only an occurrence in the page, but rather a well-defined entity uniquely identified by a URI. For example, Barak Obama is uniquely identified by http://www.usa.gov/people/BarakObama.

Store and find relationships between data This is achieved by using triples that are combinations subject – predicate – object, each of which is a uniquely identified entity, as per point (1). For Example:

BarakObama has_role president

From within this perspective, we can assert that

Semantic Web is the persistence layer of the presentation content.

“Persistence of the presentation content?” Wally asks, astonished. “What is this guy jabbering about? He sure needs a quick refresh about web-apps layers!”

Actually there is no blasphemy in my statement above: Semantic Web is a persistence layer for web-related content, only not in the conventional form. There is no relational database involved here, but a distributed semantic knowledge in the form of reusable models.

You can look at the model as the repository containing the instances of your data, which are expressed in the form of triples by using one of the formats nowadays available, namely: plain XML, Turtle, RDFa, and others. Let’s take, for example, the triple at point (2) above: by using Turtle notification, it is expressed as follows (NB: the namespace http://www.usa.gov/ is replaced by namespace usagov: for ease of read)

<usagov:people/BarakObama> <usagov:roles/has_role> < usagov:roles/president>

where all of the 3 participants (subject, predicate and object) are actual instances of entities stored on the model.

“Ok, but a model in itself is nothing more than a container of data, with no meaning whatsoever for the machine!”, Wally protests, understandably.

Here is where ontologies kick in.

If you look at the model as a dictionary, then the ontology is the rules applied to the entries of that dictionary. For example, if our ontology contains the following rules:

<usagov:roles/has_role> <http://www.w3.org/2000/01/rdf-schema#domain> <usagov:classes/person> <usagov:roles/has_role> <http://www.w3.org/2000/01/rdf-schema#range> <usagov:classes/role>

then our triple asserting that Barak Obama is the President of the United States is valid if and only if:

<usagov:people/BarakObama> is of type <usagov:classes/person> <usagov:roles/president> is of type <usagov:classes/role>

Ontologies drive the meaning of the models: changing their content triggers a change in the significance of the models that make use of them. Also – as you can see from the example above – our ontology may use or extend other ontologies, such as RDF, RDFs or OWL. All this considered, we can easily assert that

Semantic Web is a distributed combination of reusable dictionaries (models) and rules (ontologies).

 “I’m still not convinced: this is nothing more than I can do with traditional databases and dedicated business rules!”

This is correct, but only if you are not interested in flexibility, costs, and inference of data.

First off, ontologies are declarative: they are written in standard XML and may be maintained by people with few or no knowledge of the system using them. An ontology administrator may express the business logic of the system by feeding appropriate rules to the ontology. In a few words, ontologies give the possibility to define what must be done, without taking care about the how.

Secondly, on the application side, ontologies are handled by one of the RDF (Resource Description Framework) reasoning engines available in the market, with no need of customized logic.

Finally, ontologies set the stage for a very important feature of the Semantic Web: inference.

Semantic Web is a way for triggering new knowledge.

Take a conventional storage system, such as a relational database: it relies on the assumption that data is all it is present. If data is not present, then it assumes it does not exist.

With semantic storages, on the contrary, new knowledge may be triggered by reasoning on existing data. This process is called inference.

Let’s take our presidential example: if our ontology defines the rule

<usagov:roles/president> <http://www.w3.org/2002/07/owl#sameAs> <usagov:roles/commander_of_army>

then the system can infer that

<usagov:people/BarakObama> <usagov:roles/has_role> <usagov:roles/commander_of_army>

In this case, our ontology makes usage of a well-known and very powerful concept of another ontology, OWL’s sameAs: it expresses the bi-directional equivalency between its domain and range.

As for direct data, a change in the ontology may trigger a different meaning for inferred data as well: the rule

<usagov:roles/president> <http://www.w3.org/2002/07/owl#sameAs> <usagov:roles/housekeeper>

would force Obama to clean up the White House every Saturday.

In conclusion, Semantic Web is a natural approach for organizations that are interested in:

Gathering data across heterogeneous information systems (redundant, fragmented, incomplete) and give it a structure and an identity;

Giving a meaning to that data on the basis of ontologies: this provides the data with a semantic behaviour;

Inferring reasoning on data;

Guaranteeing sources of data via unique URI identification.

And, should Wally be still unconvinced, after all I don’t know what Semantic Web is, but when I see it I recognize it!

Our solution

Our goal: we wanted to comply with these arbitrary rules without compromising on the design of the application. We did not want to change existing client or server code.

Our solution: Inject the “almost” standard X-HTTP-Method-Override header transparently on the client-side, and decode it just as transparently on the server-side.

On the server side

We wrote a servlet Filter inspired by Spring’s HiddenHttpMethodFilter. For convenience, we extended Spring’s OncePerRequestFilter. This filter intercepts the request before it’s handed to the servlet and checks if there’s an X-HTTP-Method-Override header present. If so, the request is wrapped in an object that will return the real HTTP method and passed down the filter chain. The Spring MVC controller will see a DELETE or a PUT method just as it should.

package com.arhsgroup.web; import java.io.IOException; import java.util.Locale; import javax.servlet.FilterChain; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletRequestWrapper; import javax.servlet.http.HttpServletResponse; import org.springframework.util.StringUtils; import org.springframework.web.filter.OncePerRequestFilter;   /**  * {@link javax.servlet.Filter} that converts the X-HTTP-Method-Override into HTTP methods, retrievable via  * {@link HttpServletRequest#getMethod()}.  */ public class HeaderHttpMethodOverrideFilter extends OncePerRequestFilter {       public static final String HTTP_METHOD_OVERRIDE_HEADER_NAME = "X-HTTP-Method-Override";       @Override     protected void doFilterInternal(final HttpServletRequest request, final HttpServletResponse response,             final FilterChain filterChain) throws ServletException, IOException {           final String headerValue = request.getHeader(HTTP_METHOD_OVERRIDE_HEADER_NAME);         if ("POST".equals(request.getMethod()) && StringUtils.hasLength(headerValue)) {             final String method = headerValue.toUpperCase(Locale.ENGLISH);             final HttpServletRequest wrapper = new HttpMethodRequestWrapper(request, method);             filterChain.doFilter(wrapper, response);         } else {             filterChain.doFilter(request, response);         }     }       /**      * Simple {@link HttpServletRequest} wrapper that returns the supplied method for      * {@link HttpServletRequest#getMethod()}.      */     private static class HttpMethodRequestWrapper extends HttpServletRequestWrapper {           private final String method;           /**          * Constructor.          *          * @param request the wrapped request          * @param method the overridden method          */         public HttpMethodRequestWrapper(final HttpServletRequest request, final String method) {             super(request);             this.method = method;         }           @Override         public String getMethod() {             return method;         }     } }

This filter needs to be added to your web.xml.

<web-app>     ...         <filter>                <filter-name>headerHttpMethodOverrideFilterChain</filter-name>                <filter-class>com.arhsgroup.web.HeaderHttpMethodOverrideFilter</filter-class>         </filter>         <filter-mapping>                <filter-name>headerHttpMethodOverrideFilterChain</filter-name>                <url-pattern>/data/*</url-pattern>         </filter-mapping>         ... </web-app>

On the client-side

For the client-side, most solutions you’ll google will require you to adapt every AJAX call you make in order to change the method and add the header. We opted for a less intrusive solution that leverages the jQuery. ajaxPrefilter function, which lets you add a filter through which every jQuery AJAX call will go.

$.ajaxPrefilter(function(options, originalOptions, jqXHR) {     if (options.type == 'PUT' || options.type == 'DELETE') {         var headerValue = options.type;         jqXHR.setRequestHeader('X-HTTP-Method-Override', headerValue);         options.type = 'POST';     } });

Conclusion

This solution allowed us to deploy a work-around in a few minutes that did not force us to lower our coding standards and quality. The app is even still able to respond to real DELETE and PUT requests that don’t include the X-HTTP-Method-Override header. When (if ever) the HTTP method restriction is lifted, we’ll only have to remove the jQuery.prefilter and our app will continue to work just as well, and respect RESTful principles a little more.

PS: Of course, if the firewall or the reverse-proxy also strips the custom headers, as a last resort, you’ll have to adapt this solution to work with e.g. request parameters.

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

In terms of user accounts, you’ll typically start with your almighty root user.  Due to the extensive rights this user account has, it is advised to limit its use. In short: no login as root. Therefore, the first thing you need to do (after changing the root password, of course) is to create a new, privileged user account in the sudoers group and ensure that you can access your web-server with this new user account. Then, you can disable root login. The key concept here is need-to-have basis: impactful things should not be performed lightly, nor by everyone.

#Change the root password root@server# passwd Changing password for user root New password: Retype new password: passwd: all authentication tokens updated successfully. #Create new user root@server# useradd admin root@server# passwd admin Changing password for user admin New password: Retype new password: passwd: all authentication tokens updated successfully. #Add new user to wheel group root@server# groupadd wheel root@server# adduser admin wheel #Edit the /etc/sudoers, adding the wheel group as a privileged one if not already the case root@server# nano /etc/sudoers […] # root and users in group wheel can run anything on any machine as any user %wheel ALL = (ALL) ALL

Next, passwords… As you may have read over the past years, major website breaches were highlighted in the news. Millions of credentials stolen, accounts compromised, you know the story… Simply put: the days of passwords are over. Setting up public key authentication for your server takes an additional 3 minutes and will block a large part of hacking attempts…

# As root, edit the known_hosts file, adding ip/public key pairs of machines that are allowed to # access your server root@server# nano /home/admin/.ssh/known_hosts # Add the ip/key pairs... # As root, change permissions to this file to read only, and make sure only admin has access to # it root@server# chmod 400 /home/admin/.ssh/known_hosts root@server# chown admin:admin /home/admin -R # Prevent password login over SSH root@server# nano /etc/ssh/sshd_config # Add the following lines: PermitRootLogin no PasswordAuthentication no # And, if you do have a static IP address and want to restrict connections over SSH only from # there: AllowUsers admin@< static_ip >

Another tool (Linux-specific) that may prove useful is fail2ban. This software detects and blocks brute-force attacks coming from single sources (i.e. it won’t do anything against distributed attacks). Its default configuration is sufficient in most cases, but you’re clearly invited to investigate its more complex uses…

# Installing fail2ban: root@server# apt-get install fail2ban

Now, let’s think about how people access your host in a general way. Assuming (we assume a lot) you have a somewhat classic server delivering cool stuff over HTTP/HTTPS, you probably should only open ports 80 and 443, along with 22 for SSH access… Here comes firewalling time. The iptables firewall coming with most Linux distributions allows the implementation of fine-tuned firewalling rules. The rules provided below allow traffic on ports 80 and 443, while restricting access to port 22 (SSH) to the defined IP address only (this is in the case you do have a static IP address).

#Allow SSH from your static IP only (firewall level): root@server# iptables -A INPUT -i eth0 -p tcp -s static_ip --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT root@server# iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 4 --name DEFAULT --rsource -j DROP root@server# iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT #Allow incoming HTTP and HTTPS: root@server# iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -m state --state NEW,ESTABLISHED -j ACCEPT root@server# iptables -A OUTPUT -o eth0 -p tcp -m multiport --sports 80,443 -m state --state ESTABLISHED -j ACCEPT #Set DROP as default policy: root@server# iptables -P INPUT DROP

Finally, you should take into account that new vulnerabilities are discovered daily. In order to ensure you use non-vulnerable software, you should discipline yourself to perform an update/upgrade of your system on a recurring basis (e.g. daily, and every time a major vulnerability is published). Automating this is up to you, but bear in mind that it’s always better to test before going live… Additionally, make sure you take upgrades from trusted and non-beta repositories only…

Upcoming: a follow-up article on web-application security, which will provide insights on things to take into account when deploying a web-server. Keywords: server security, sudoers, public key authentication, fail2ban, iptables Recommended reads, if you need government-grade security (or just in case you’re interested in going any further) :

Security benchmarks from the Center for Internet Security: https://benchmarks.cisecurity.org/

NIST Special Publication SP800-123, Guide to general server security: http://csrc.nist.gov/publications/nistpubs/800-123/SP800-123.pdf