It would be great to have a switch called "undo" which would undo the changes the last asl -f -s did to your system.

This way if it changes a file in a way that breaks your system or a certain subset of functionality (web, ftp, ssh, w/e) you can easily roll back.

I like this idea.

It particular, I'd like to see a feature that would allow people to roll-back mod_sec rules.

Sure, I can do it by getting the last rules rpm and installing manually, but what if the asl site is down at the time? (and sure, I can fix mod_sec rules when they go wrong, but maybe other people can't).

I used to use a script I called panic.sh which I remember Scott chuckling about when he saw it a few years back. My rules update script backed up the existing rules and installed the new ones, while the panic script copied the backup over the new ones in the event of a problem.

Something similar might be good in ASL 3

Faris.

The old ones are still there incidentally, in /var/asl/updates/

Ah! Interesting.

Looking at them in date order I see that the mod_sec rule size went from 567k (compressed) in early December 2008 to 1.5Mb (compressed) in mid December 2008 and then way down to 279k at the end of January 2009.

Unfortunately this is probably why I'm able to run the rules these days.

But I'm going off topic so I'll leave it there.

Faris.

Yeah we were rolling the .svn dirs into those tar.gz's before, so the .conf's that you're loading are largely uniform. Its a good debugging observation though!

Yes, the rule sizes did NOT go down, we just removed the subversion directories from the rule files which is why they are smaller. In fact the rule sizes have gone up and will continue to do so as they include application specific rules. They are compiled at runtime into modsec and into apache. Most of the rule logic never occurs on most systems because much of the ruleset size now is related to rules for specific applications. If you don't have that application the rule logic will not fire.

The blacklists are an exception, they always get called and not application specific. We try to keep them to only the current malware/spam sources or known long term sources of trouble. The blacklists are a "backup" ruleset to help cover cases we might not have thought of, so if you want to reduce the memory footprint of the rules the blacklists are a good choice as they are not a mandatory ruleset but more of backup parachute if you will. If you have the memory though we highly recommend you run ALL the rules - we do and all of our systems.

Ah, that's very interesting about the svn stuff (and the rest).

Thanks Scott, thanks Mike.

Faris.