Plain and simple: this book is a must read if you’re either thinking about deploying ModSecurity to protect your web applications or already have a basic ModSecurity deployment and want to learn how to customize it for your environment. Because I’m already well versed with ModSecurity, I decided read this book cover to cover without the distraction of the keyboard so that I could truly focus on how well complex topics like web application firewalls (WAF) and web application security could be covered in 250 pages. After about 5 hours of reading, I had reached the appendices and spent the next 2 days working back through the rulesets I use to protect my own web properties. Not only do I feel that I now have a more secure set of rules, I have also documented the performance impacts of ModSecurity on the Apache processes and reduced the overall response time of my applications by about 6ms.
The first 2 chapters of the book deal with installing, configuring, and rule writing basics for ModSecurity 2.5 with Apache 2.x. Magnus Mischel walks the reader through installing and configuring the module in Apache and making sure the installation is working properly. The chapter assumes best case scenarios for defaults in the operating system while in my experience, ModSecurity installs rarely go that easily. That being said, the preface of the book specifies that a good understanding of system administration principles is suggested to get the most out of the book and distribution specific installation guides for ModSecurity are widely available online. Mischel then goes on to introduce the ModSecurity rule writing syntax which he very astutely presents in two sections: rule grammar and structure followed by practical examples of how to write rules to mitigate vulnerabilities. Even after spending 1.5 years running numerous production instances of ModSecurity with custom rules, Mischel’s in depth coverage of the topic still had me hunting around for my highlighter to mark sections of the chapter containing syntax features that I didn’t know existed.
The book also does a great job of covering ModSecurity performance and logging. Mischel uses httpperf to benchmark server response time, memory usage, and processor load and presents the results for Apache with/without ModSecurity and with/without the default ruleset. Readers will find that this data will be invaluable if they ever need to sell the security benefit vs. system performance degradation to system administrators and executives. The chapter on logging and auditing offers an in depth look at the features available in ModSecurity offering insight on real world log and audit needs balanced with the processing overhead associated with excessive data collection. Mischel also provides a detailed implementation guide for deploying the ModSecurity Console with mlogc giving administrators and analysts a dashboard for monitoring alerts in a environment using multiple instances of ModSecurity.
One of the chapters I was most looking forward to reading was “Blocking Common Attacks” where Mischel presents a number of common web application vulnerabilities, offers an overview of the causes and impacts of said vulnerabilities and presents a virtual patch using a series of ModSecurity rules. To be perfectly honest, I was left a little disappointed with lack of depth in some of the content. While I understand that in depth coverage of web application vulnerabilities is probably beyond the scope of the book, the additional knowledge required to fully understand the causes and exploits of the issues that are presented in this book is likely beyond the average skill set of a system administrator. I was also left a little disappointed with the section on cross site request forgeries (CSRF) which never offered any virtual patching examples to mitigate the issue. Negatives aside, Mischel does a great job at presenting ModSecurity rules for mitigating 14 types of web application vulnerabilities such as cross site scripting (XSS), sql injection (SQLi), and shell code execution.
Mischel spends an entire chapter discussing configuring ModSecurity using a positive security model tailored to a YABB (Yet Another Bulletin Board) deployment. For a veteran ModSecurity user, this was by far the best chapter in the book, even though Mischel suggest you use Ethereal (Wireshark) as your local web proxy (you should be using Burp Suite by Portswigger). I can only hope that readers who are rolling out new ModSecurity installations or who are looking to improve existing deployments read this chapter and realize the value of this approach and choose to do the same to protect their applications.
By including the full ModSecurity directive and variable reference and a detailed guide on Regular Expressions, Magnus Mischel has created a complete guide to ModSecurity that is not only a great introduction to the WAF technology, but also a great desk reference for the experienced administrator.
Title: ModSecurity 2.5
Author: Magnus Mischel
Publisher: PACKT Publishing
Front page taglines:
* Securing your Apache installation and web applications
* Prevent web application hacking with this easy-to-use guide
While I think that Jeremiah Grossman is absolutely on to something with his theories of alignment of interests in Web Security, I would argue that attaining the goal would go against human nature. Since the dawn of time, human have been in competition with one another and the only thing that’s really changed is the prize for being “best”. In pre-historic times, it was food, fire, and a safe place to sleep. In the middle ages it was land, crops, and livestock. In modern economies, it’s all about the money. For those actively participating in society, money virtually defines who you are in society. Actors, sports professionals, and CEOs of fortune 500 companies rake in hundreds of thousands of dollars and their quality of life shows it with nice cars and lavish housing. While middle class and below are barely making ends meat and most are working very hard for every dollar they spend.
Things aren’t much different in the business world. Companies who perform well go public and have millions of investors, companies who perform poorly go out of business, and once again, the measure of success is money. The examples cited by Jeremiah (SSL for web traffic, data encryption, and getting rid of IFrames) just further illustrate my point. While these practices would do a great deal for protecting their customers, they cost money and affect the bottom line profits, and therefore are not implemented. Yes, I know that security incidents end up costing the company more money in damage control than it would have cost for the safeguards to be implemented in the first place. This is the line security professionals have been giving senior executives for years. Has it worked? It doesn’t seem like it: Ask any of the 60% of the top 100 most popular websites who’ve hosted malware in the first half of 2008. (Websense security Labs™ (State of internet security -Q1 – Q2, 2008)
At this moment, the greatest asset that has been given to security professionals are regulations. Whether they be industry (PCI-DSS, SOX, etc) or Government (FISMA, NIST standards, etc) these regulations on IT Security have proposed to fine/hold legally responsible companies who do not attempt to enforce a minimum level of safeguards to protect their customers. By no means am I saying that these standards are perfect, there is far too little enforcement, the rules are not always described clearly and there are many cases where auditors are coerced into giving a passing grade to infrastructures which do not meet the requirements. What I am saying is that the idea of fining companies for failing to protect consumer data is the right way to go when you’re dealing with executives who’s primary driver is making money for the company.
I propose the following to answer Jeremiah’s question “How do we get the owners of 187 million websites, 17 million developers, browser vendors, universities, governments, ISPs, compliance auditors, and security researchers all to pull in the same direction towards a more secure Web?”:
Establish more laws and industry regulations defining how companies should conduct themselves.
Admittedly, this is a double edged sword. More checkboxes != more security, but it does give the professionals in the field some solid backing when presenting security concerns to executives.
Academics and researchers must collaborate to change the education system.
Remember the old saying “work to make the world better for your children”? We have an army of little tech savvy kids coming through the education system. Lets teach them about information security and privacy issues so that as they move into consumerism, they will instinctively demand security from the products they consume.
Figure out a better way to demonstrate the value of IT Security services.
This seems to be the Achilles heel of the IT Security world. How do you demonstrate the value of preventative counter measures? Yes, I know, another question VS. an answer.
Offer better security solutions and products.
As stated in Jeremiah’s article, “Security vendors love strongly enforced compliance standards as it frees up budget for their solutions, which may not reduce risk, but have to be purchased to satisfy a checkbox”. We don’t need more checkbox solutions, we need tools that actually empower companies with the right information so that they can easily get a snap shot of the current security posture. White Hat Security has a great tool/service hybrid where vulnerability data collected during automated assessment is pre-vetted by WhiteHatSec security engineers before being presented to the customer. As a quick disclaimer, I don’t work for WhiteHatSec, but have had the opportunity to see their product in action.
Greater focus on outreach and communications.
As the final, and perhaps most important solution, I propose a greater focus on outreach and communication. Security is still a field where only those who have the history and passion for computers truely understand what’s going on. This needs to change. The average web consumer must be educated to understand the personal ramifications of the “laiser faire” attitude that plagues the web application security world.
Please feel free to share you thoughts in the comments, I’m very interested to hear what my peers have to say on this subject.