Auditing firewalls

In a recent blog I discussed the security improvements brought by changing our certification authority, but that isn't our only recent change. Our v2.8 release contained a number of other technology changes and improvements and we'll discuss a couple of them here.

The first was our implementation of a Web Application Firewall (WAF) on all of our services. Just as a network firewall scrutinises and blocks traffic at the network layer, a WAF functions as a gatekeeper higher up the stack, at the level of the web application. A WAF can fully scrutinise the content of http-level requests and block any that violate defined security rules.

We chose the modsecurity WAF as it was the best fit with our existing platform, and we're running the compatible elements of both the OWASP Core Rules and the Trustwave Spiderlabs commercial rules. I use the phrase "compatible elements" because a big part of implementing a WAF is screening out all the false positives caused by differences between the application set the rules were designed for and the application(s) the WAF is deployed against. With that compatibility work now complete, all Longevitas and Projections Toolkit web traffic is being scanned and health-checked as it interacts with our services.

One further change we made was around off-server audit and log-collection. Were a server to experience an intrusion, then it may be possible for a sufficiently privileged attacker to edit the content of system logs on that server to hide their activities. In practice, when you implement a HIDS on all servers as we do, such stealthy attacks are very difficult to achieve without raising alerts. A further defence against such a risk is to no longer store critical logging and audit on the server itself, but to collect the logs on an internal, non-public server. This off-server logging is exactly what we have put in place: while our HIDS events have always been off-server, with 2.8 we've added centralised DBMS auditing and centralised logging for selected linux system logs.

We may build on these improvements in future releases, with the potential to customise WAF rules or extend the log collection to other areas of our systems. However these recent improvements already add valuable extra layers to our defence in-depth.  

Written by: Gavin Ritchie
Publication Date:
Last Updated:

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.