Asynchronous ModSecurity Enhancement

LiteSpeed Web Server’s proprietary ModSecurity engine already delivers stellar performance. We’ve achieved that with an implementation that is highly optimized and well-integrated into the server. In-depth testing shows that LiteSpeed’s ModSecurity solution is faster and more efficient than Apache’s or nginx’s.

Even so, ModSecurity, being CPU intensive, can be a drag on performance. Our implementation already reduces the CPU impact with measures such as:

• Intelligently skipping some rules based on the request input
• Caching regex results to speed up regular expression matching
• Execution suspension for long-running rule processing

That said, we’re not ones to rest on our laurels! And that is why we are pleased to announce a major feature enhancement for LiteSpeed Web Server v6.0: an Asynchronous ModSecurity Engine.

The Problems with ModSecurity

Implementing ModSecurity is a challenge due to the heavy reliance on CPU, limited resources available, and ModSecurity’s tendency to clog the main event loop thread.

Clogging the Main Event Loop Thread

Popular ModSecurity rulesets contain hundreds of rules. Depending on the input size, one request could take upwards of a few hundred milliseconds to scan. In an event-driven server, where the main event loop thread handles all events, everything else must wait while a ModSecurity scan executes.

LiteSpeed already has a mechanism in place that tracks the time spent in the ModSecurity engine, and suspends execution if necessary, to give other events a chance to process in a timely manner. But even with this execution suspension, the main event loop can still get bogged down by ModSecurity. For example, regular expression execution cannot be interrupted, and some of these executions (particularly during ReDoS attacks) can be highly expensive.

Limited CPU Resources Available

The main event loop thread uses a single CPU core. When executing ModSecurity rules in the main event loop thread, the only way to get better performance is to increase the number of worker processes, which means upgrading to a more powerful license.

Solving ModSecurity’s Problems

One obvious solution to the problem of CPU resources is to create more lshttpd workers. The more workers available, the more CPU processing power ModSecurity can take advantage of. But managing a large number of workers means a more expensive license. Until now.

LiteSpeed is introducing a better way.

As of LiteSpeed Web Server v6.0, we have introduced a separate worker thread pool for ModSecurity processing. When a request needs to be scanned, it is offloaded to the dedicated thread pool. The benefits of this are numerous:

• Most importantly, it allows the main event loop thread to become available immediately for processing the next event.
• CPUs with a large number of cores can be better utilized without having to upgrade to a more powerful license.
• The worker thread pool may have a different priority and CPU affinity from the main event loop thread, which minimizes the potential impact of thread scheduling.
• With a dedicated worker thread, LiteSpeed’s ModSecurity engine is able to scan the response body. Support for applying ModSecurity to a response body was not available until now, mainly due to the problems described above.

LiteSpeed Web Server v6.0 is available now. Download it and try it out today!