This is our second Blog post on recent upgrades on our CPanel Plans, where we are introducing new changes to our systems. In the last post, we covered Apache 2.4 and the step forward it provides in terms of performance and capability without sacrificing compatibility. We will now be covering more changes coming up that take advantage of new features and capabilities provided by Apache 2.4.

mod_security – Rethinking filters.

When mod_security was first released by the developers, the filters it included were basic and designed to catch a very wide variety of attack type traffic as it ran on the incoming POST/GET requests through regular expressions to validate them. This is a lot like code you would find in PHP scripts to validate credit card numbers, email addresses, or other data. It is just applied as a filter at the HTTP level as a Web Application Firewall or WAF. This was problematic for a variety of reasons including numerous false positives for WYSIWYG editors, forums, blogs, and many others.

Another problem with this approach was performance. The regular expressions were CPU heavy leading to a severe drop in performance. The amount of CPU drain was nearly as bad as PHP itself for awhile as the system struggled to process everything. Despite various attempts at making it lighter such as filtering only dynamic traffic, the software was still too heavy. That is when the authors converted to the Perl Compatible Regular Expression C library which is a much faster regular expression processing engine than the one it previously used. When this software was compared to the old regex (regular expression) engine, it was 2 – 4x faster making the rules much faster. It also encouraged more and better rule contributions as the regex syntax was from a known standard.

This same approach would continue to be used for years until Apache 2.4, advances in compilers provided by Chrome/Apple, and other changes allowed us to rethink filters.

PCRE-JIT – Borrowing from Chrome

When Microsoft Internet Explorer 6 roamed the earth, websites did not rely on AJAX Gmail/Google Docs interfaces. Due to the speed of the javascript interpreters, those browsers would not be capable of running modern web applications. It isn’t just language compatibility, but raw speed as advances have allowed browsers to run javascript hundreds into thousands of times faster. The how is a very neat trick.

If you look at programs running on your computer, they run native machine code as binary programs. They “speak” the same language as the hardware allowing them to run without an interpreter to slow the process down. Unfortunately, the extra step of involving an interpreter can slow the process down considerably compared to native code. That is where the idea of JIT or Just In Time compilers comes in.

It is faster to compile javascript then run it as native code than it is to run the code through an interpreter. The net gain is sometimes up to 500 – 1000% faster for javascript in complex operations.

For us, we can use the same trick with PCRE to speed up execution quite a lot by compiling it before executing using a Just In Time compiler built into PCRE.

http://sljit.sourceforge.net/pcre.html

For various types of complex regular expressions, the net result is 70 – 90% faster than before. For mod_security which is a very advanced regular expression processing engine itself, this is a significant gain. This allows us to run more data through the engine much faster than before while also taking advantage of features built into Apache 2.4 to filter more data in different ways. The increased speed has allowed us to deploy different types of filters to block exploits without the same false positives we have seen before.

Whitelisting – Whitelist by the ID

With the new JIT compiler also comes new whitelisting as we work on building a system that is more compatible. The new whitelisting features will allow us to selectively disable mod_security per folder, per domain, per rule ID, in .htaccess, and so on for a very flexible system. This will allow us to avoid many of the whitelisting problems so we can disable it for a single directory instead of an entire site providing more protection from exploiting robots.

Comodo WAF – New mod_security rules from Comodo.

Since mod_security was originally released, the focus has been on blocking bad robots based on GET/POST contents directed at specific scripts. The result of this has been rules that cause a considerable amount of false positives for WYSIWYG editors, theme editors built into popular scripts, and similar POST/GET requests. These have lead to a lot of whitelisting which disables mod_security and the filters leading to scripts being exploited.

As we looked for a new approach, the new Comodo WAF rule set took an interesting strategy with validation allowing us to avoid some of the POST/GET filters in favor of Apache 2.4 enabled validation. Unfortunately, this would filter a lot more via mod_security, but with other recent enhancements such as PCRE-JIT the system runs even faster than before as we block more bad robots using less system resources.

This system has also been in testing for awhile now with very few false positives while feeding attackers into the firewall.

Linux Malware Detect – Enhancements to scanning.

Finally, we have also modified the Linux Malware Detect engine to start to scan more potential malware before it is able to exploit vulnerable scripts. Without giving too much away, this reduces overlap, enables more comprehensive scanning, and has resulted in a massive drop in the amount of malware separate from mod_security changes.

In the next posts, we will go into more detail about additional changes to the platform including realtime blacklists, Spam Assassin, firewalls, and more.