Working on a WAF solution for the Nginx ecosystem provides a lot of opportunities for discussion, given that such work is a meeting of crossroads. Mixing high-performance engineering, WAF technologies, ModSecurity DSL, and the OpenResty community puts lua-resty-waf in a unique context. I often get asked about other WAF solutions for Nginx, including Naxsi, and how these solutions compare to ModSecurity, lua-resty-waf (and other security OpenResty libs), and commercial solutions. I haven’t spent a lot of time working with the Naxsi project, but I’ve poked at it enough to at least start putting some thoughts on paper.
January tends to be a pretty quiet month in the admin/operations world. Most people are still coming back from holiday, new yearly plans are being made, meetings are held, and the server monkeys… sit and watch the graphs scroll by. The rest of the world’s gradual return to work means the start of a seasonal upswing, but we’re still in a relatively low point, so that generally means a light workload. That extra free time has given me a chance to put in a good chunk of work towards FreeWAF, cleaning up code, adding new features, and interacting with a total stranger (score!). I’ve just tagged a new release, v0.4, which provides a handful of new features that were sorely missing:
I’ve spent the better part of the last six months reworking the project I wrote for my Master’s thesis. The idea behind the project was to explore the costs, risks and requirements associated with developing a cloud WAF infrastructure, similar to what commercial cloud security providers like Cloudflare and Incapsula provide- and then provide that service free of charge. Totally unsustainable, of course, but as an academic exercise it was an incredibly educating experience. I’ve since decided to focus on releasing the source of the firewall engine powering the service, continuing to develop features and exploring new methods of anomalous and malicious behavior detection.
Volumetric layer 7 (HTTP) DDoS typically relies on overwhelming the target by inundating the target with a large number of (pseudo) legitimate HTTP requests, the end goal being resource starvation (typically, CPU cycles or available bandwidth, e.g. NIC saturation). Because layer 7 attacks require a full three-way handshake, spoofing source information is impossible (though using a proxy is a viable alternative- remember the XMLRPC issues earlier this year?); as such, the ability to control a large number of attacking machines becomes critical as the size of the target increases. Of course, other forms of HTTP DoS exist outside of volumetric resource starvation (such as Slowloris), but I wanted to take a look at common methods of defending (and circumventing said defenses) against resource starvation attacks via HTTP. This will also serve to demonstrate the weakness in deploying WAFs that rely exclusively on signature-based matching.
mod_sec audit logs are atrocious. There have been a few attempts to make parsing audit data more palatable- BitsOfInfo recently wrote up a proof of concept of working through audit logs with logstash, and the AuditConsole project from JWall provides a more comprehensive approach to collecting log data, but neither solutions addresses the inherent problem of how messy native audit log data is.
As part of my Master’s thesis I need a way to efficiently audit, sort and store audit logs; building my own parser, while doable, would be a waste of time, so I’ve forked the ModSecurity project on Github and built a patch that implements JSON logging directly in the application, replacing the old data log structures entirely. There’s still a long way to go, but the initial patch seems stable and produces valid JSON. Continue reading