Ivan Ristić

Programming in Lua 2ed now sold by Feisty Duck (PDF only)

The Feisty Duck book store yesterday increased the number of titles on offer by 100%, adding the digital version of Programming in Lua 2ed, written by Roberto Ierusalimschy.

If you don't know about Lua, it's a very nice embeddable scripting language, with low memory consumption, very fast interpreter, and even faster just-in-time compiler. I loved it so much I added it to ModSecurity, and it is now possible to write rules in a proper programming language. It's great for those times when you have complex requirements. I am seeing Lua slowly but surely taking over the open source world (when embedding and fast and reliable operation is required). It's already in ModSecurity, Snort 3.x is using it, and in the future it will be part of Apache too.

The book itself is very good too, with a 5-star score in Amazon.com reviews.

ModSecurity Handbook available for pre-order and early access

ModSecurity Handbook, which I announced a couple of days ago, is now available for pre-order and early digital access. We managed to meet our self-imposed deadline and have everything ready for November 24th, actually.

This book is a big deal, in more ways than one:

1. It took me more than 5 years to gather courage to start writing another book (after Apache Security, which I started writing in 2004).
2. This book is about ModSecurity, a project that is very dear to my heart. It makes me very happy that I will document everything I know about it.
3. I am releasing the book early because I want to interact with the readers while the content is still not finalised. With Apache Security I ended up being terribly unhappy because I was writing in isolation and because I couldn't seek feedback from the readers prior to publication.
4. To publish this book (and all my subsequent books), my wife and I started a publishing company and dealt with all the stuff that publishers have to deal with. The learning curve wasn't very difficult because of my previous experience in publishing, but there was a lot of things to do.
5. This book will be a living book. I intend to keep it up to date at all times, keeping up with the changes in ModSecurity. We've invested a significant amount of time into polishing a single-source publishing system, where the manuscript is kept as XML (DocBook, stored in a Subversion repository) and automatically converted to any of the supported formats (only PDF at the moment, but several forms of PDF, HTML and ePub in the near future). The system allows me to make changes and push updates instantly to all the readers!

The work is far from done, of course. First, I need to finish the book, first of all. Second, we'll have to figure out how to promote it effectively, and I somehow suspect that will be the hardest part. Perhaps, when it's all done, I'll write a blog post called "Adventures in Computer Book Publishing".

Update: The official Reference Manual and Data Formats Guide guide have been added to the book. There's about 230 pages of material right now, with the final count expected to be close to or over 300.

Announcing ModSecurity Handbook

It is a pleasure to announce my next book, ModSecurity Handbook, which features an in-depth coverage of ModSecurity, an open source web application firewall. I am very happy because, finally, ModSecurity will have the documentation it deserves.

The main highlights are the following:

• Step-by-step instructions for those just starting out
• Detailed explanations of the internals, and advanced techniques for seasoned users
• Includes the official ModSecurity Reference Manual and Data Formats Guide
• Available in digital format (PDF, HTML and ePub, although not all straight away) and as paperback (once the first edition is complete)
• Continually updated as ModSecurity evolves (with the updates included with purchase)
• Readers can talk to me to shape the book to work better for them

The complete table of contents is available on the book's web site.

I estimate that the book is about 75% complete. In a week's time (on November 24th) it will be available for early access and pre-order. The idea with the early access is to avoid the problem I experienced with Apache Security -- writing in isolation. This time, I want to engage with my readers before my book is published.

Also, it is pretty important that this book is (and will be) continually updated. I have the entire publishing workflow automated so whenever I make a change to the book, the update is automatically made available to the readers. With this feature, again, I want to avoid the painful experience that I had with Apache Security, where for years I wanted to provide updates but I couldn't. (Apache Security readers, fear not, the second edition is being worked on.) In the future, I hope to evolve the publishing toolchain to enable readers to make comments straight to the HTML version of the book that is kept online.

Planned usability improvements for ModSecurity 2.6

After leaving Breach Security in February I took a break from ModSecurity. On the one hand, I was tired. On the other, I needed time to figure out what role I will have in the project, or if I wanted to have a role at all. Over time my interest in ModSecurity started to come back. Even more interestingly, I started to look at it with a fresh perspective. What would a newcomer make of it? In doing so I came up with a long list of small problems that need fixing. The beauty of my new position (a contributor) is that I no longer need to think where the project is heading next, but can spend as much (or little) time as I like working on the things that I have interest in.

Here's my list:

1. It is not clear what happens when an operator fails. I think a level 1 error message is emitted, but there is no effect on rule processing. This is a small anomaly that needs fixing. I believe the user should be given an option to be strict (block) or relaxed (not block). [MODSEC-12]
2. The variable REQUEST_URI is used directly from the Apache's structures. As a consequence the value may change between phases. ModSecurity should have one robust variable that refers to a path, to avoid small problems. The MODSEC-98 improvement fixed this issue.
3. At the moment we provide a raw REQUEST_URI and expect the users to use transformation functions to deal with evasion. That is inconveniencing our users; we should have REQUEST_URI pre-normalised. And, because we rely on Apache for normalization at the moment, doing normalization ourself would give use better control over the process and increase consistency. (For example, Apache does not always do the right thing when deployed in proxy mode.)
4. The REQUEST_BODY variable contains request bodies, but the variable is only available when the for urlencoded bodies. This is because in most cases it doesn't make any sense to store the entire request body in memory (think file uploads). There's a hack to force a request body into memory (ctl:forceRequestBody), but we need to provide a consistent way to deal with the inspection of request bodies.
5. Phase information should not be allowed in SecDefaultAction. That is something for rules to be concerned about.
6. Transformation options should not be allowed in SecDefaultAction, because transformations need only be configured on the per-rule basis. In fact, the entire situation with how SecDefaultAction works is murky and needs improvement.
7. SecArgumentSeparator should not be a main-only directive.
8. SecComponentSignature should not be a main-only directive.
9. ModSecurity should refuse to accept the rules that use variables in phases when they are not available. Why wait for the users to discover the problem the hard way?
10. There's no reason that non-existent response types are specified with "(null)". We should change that to "null", keep the old variant, but remove it from the documentation. This had been fixed, but I missed it.
11. The performance-tracking information (Stopwatch) -- which was just copied over from ModSecurity 1.9.x -- does not provide useful performance measurement. Done. Implemented Stopwatch2, which is a great improvement.
12. The users have been complaining about an elusive mod_deflate compatibility issue for ages now. It needs fixing. Done (MODSEC-89).
13. Allow main and virtual host configuration and phase 1 rules to be overridden in <Location> configuration contexts. Done (MODSEC-98).
14. Use international-friendly spelling: change "sanitise" to "sanitize". Done (MODSEC-95).
15. Use international-friendly spelling: change "normalise" to "normalize". Done (MODSEC-103).
16. Remove the obsolete PDF UXSS functionality. Done (MODSEC-96).

Tuning ModSecurity Console on Windows

For the users of ModSecurity, the free ModSecurity Console remains the best choice for the handling and storage of audit log alerts. There's one problem with it, though—the 64 MB of RAM it allocates is too small for a real deployment. The good news is that the memory usage can be tuned, along with a few other things. Ryan wrote about the console tuning before, here and here.

Ryan's advice will help you on a Unix platform, because the shell script that starts the console can be edited, but it doesn't work on Windows because there's no file to edit. On Windows, the console is started through an executable file. It took me some time to find a solution, after someone asked me for advice today.

ModSecurity Console is packaged using install4j, which is a fantastic packaging platform for Java applications. In order to tune the JVM parameters of Windows applications that run as services, simply create a text file that uses the same name as the executable, replacing the .exe extension with .vmoptions. In the case of ModSecurity Console you need to create modsecurity-console.vmoptions alongside modsecurity-console.exe. In the file, just put one JVM option on each line. For example:

-Xms512m
-Xmx1024m

The above configuration will allocate 512 MB to the console at startup, with the option to use up to 1024 MB in total.

ModSecurity training at OWASP AppSec Europe 2009

Looking at the OWASP AppSec Europe 2009 schedule, I was happy to notice the attendees will be offered a ModSecurity training course. I taught the ModSecurity training course at AppSec Europe last year, but that was essentially a vendor-given session. This year, however, we have a member of community, Christian Folini (also known as the author of REMO) teaching the course, and I think that's a significant step forward!

Signing the ModSecurity Contribution Agreement

Two months after leaving it, I went back: I signed the ModSecurity Contribution Agreement. If you read my blog post on open source dual licensing from a few days ago, the one where I explain how it is difficult to get user contributions to a dual-licensed open source project, you may wonder if I had told the truth. I had. I had said it was difficult to get contributions, but not impossible.

This is an interesting position for me to be in because I used to be on the other side, explaining to others why dual-licensing should not be a barrier to their contributing. It's only fair that I sign on the dotted line, isn't it? But—with the discussion on dual licensing in mind—why did I do it? It all comes down to motivation.

When you have big ideas it makes sense to start your own project, work hard, and benefit from your work. But when your ideas are not of the new-project sort, and generally not worth changing your life for, then the best thing to do is share your ideas (in the form of a code contribution) to a well-established project. By doing that you scratch your itch and get other people to benefit from your work.

And I don't feel bad about giving my time and code to Breach Security (who owns ModSecurity). Not in the slightest. After all, many man-years have been invested in ModSecurity. What do you think my contributions are going to be worth compared to what has already been given away to me?

ModSecurity at ApacheCon US 2008

In a few weeks' time I will present my favourite talk, Web Intrusion Detection with ModSecurity, at the ApacheCon US 2008 in New Orleans:

Intrusion detection is a well-known network security technique--it introduces monitoring and correlation devices to networks, enabling administrators to monitor events and detect attacks and anomalies in real-time. Web intrusion detection does the same but it works on the HTTP level, making it suitable to deal with security issues in web applications. This session will start with an overview of web intrusion detection and web application firewalls, discussing where they belong in the overall protection strategy. The second part of the talk will discuss ModSecurity and its capabilities. ModSecurity is an open source web application firewall that can be deployed either embedded (in the Apache HTTP server) or as a network gateway (as part of a reverse proxy deployment). Now in it's sixth year of development, ModSecurity is mature, robust and flexible. Due to its popularity and wide usage it is now positioned as a de-facto standard in the web intrusion detection space.

This is the same talk I presented at ApacheCon Europe 2008 in Amsterdam and the OWASP AppSec US 2008 conference in New York, and it's getting better every time I do it. This is going to be my first ApacheCon in the US and I am really looking forward to it. It's the place to be if you are involved in any way with the projects of the Apache Software Foundation.

Speaking about ModSecurity at ApacheCon Europe 2008

I will be speaking about ModSecurity at ApacheCon Europe in Amsterdam later this year.  I hear ApacheCon Europe 2007 (also in Amsterdam) was great so I am looking forward to participating this year. Interestingly, for some reason or another, this will be the first time ModSecurity will be officially presented to the Apache crowd, in spite of the fact we've been going at it for years. As always, the best part is meeting the people you've been communicating with for years.

Intrusion detection is a well-known network security technique -- it introduces monitoring and correlation devices to networks, enabling administrators to monitor events and detect attacks and anomalies in real-time. Web intrusion detection does the same but it works on the HTTP level, making it suitable to deal with security issues in web applications. This session will start with an overview of web intrusion detection and web application firewalls, discussing where they belong in the overall protection strategy. The second part of the talk will discuss ModSecurity and its capabilities. ModSecurity is an open source web application firewall that can be deployed either embedded (in the Apache HTTP server) or as a network gateway (as part of a reverse proxy deployment). Now in its fifth year of development, ModSecurity is mature, robust and flexible. Due to its popularity and wide usage it is now positioned as a de-facto standard in the web intrusion detection space.