asl-lite issue

[czar]

i'm seeing issues getting subscribed rules with asl-lite:

# asl-lite -u
Checking for updates..
ASL version is current: package asl is not installed
[OK]
APPINV rule updates are available: 201308071122 [INFO]
CLAMAV rule updates are available: 201310061404 [INFO]
GEOMAP rule updates are available: 201310061338 [INFO]

Update failed for some reason, retrying with full debug information...
--2013-10-06 21:20:07-- http://czar:*password*@www.atomicorp.co ... 404.tar.gz
Resolving http://www.atomicorp.com... 198.71.51.132
Connecting to http://www.atomicorp.com|198.71.51.132|:80... connected.
HTTP request sent, awaiting response... 401 Authorization Required
Reusing existing connection to http://www.atomicorp.com:80.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://updates.atomicorp.com/channels/r ... 404.tar.gz [following]
--2013-10-06 21:20:08-- http://updates.atomicorp.com/channels/r ... 404.tar.gz
Resolving updates.atomicorp.com... 74.208.166.51, 74.208.172.195, 74.208.112.216, ...
Connecting to updates.atomicorp.com|74.208.166.51|:80... connected.
HTTP request sent, awaiting response... 401 Authorization Required
Authorization failed.

exiting...



was fixed with:

# cat /etc/hosts | grep ato
74.208.166.51 http://www.atomicorp.com

it seems not to do authorization at updates.atomicorp.com since it made it at http://www.atomicorp.com

Fix is working:

# asl-lite -u
Checking for updates..
ASL version is current: package asl is not installed
[OK]
APPINV rule updates are available: 201308071122 [INFO]
CLAMAV rule updates are available: 201310061404 [INFO]
GEOMAP rule updates are available: 201310061338 [INFO]
Updating MODSEC to 201310061404: updated [OK]
OSSEC rule updates are available: 201309301638 [INFO]

[hostingg]

asl-lite was End of Life a couple of years ago, see the product page:

ASL Lite

Note: ASL Lite is End of Life and is no longer supported. Please use ASL.

[uwallrodt]

I have been subscribed to the ModSecurity Rules for nearly a year and all was working well using asl-lite
Automatic updates of rules from a rules subscription using asl-lite on cpanel are no longer working since 6th of October.
I don't want to be forced to subscribe to ASL (I'm using configserver) and I don't want to update my rules manually every day.

So is there no solution for automatic updates?

[uwallrodt]

I changed my /etc/asl/config and it's working now with asl-lite:

Change

UPDATEPATH="www.atomicorp.com/channels/rules/subscription"/

to

UPDATEPATH="updates.atomicorp.com/channels/rules/subscription"/

When running /var/asl/bin/asl-lite -u it looks like there is a re-direct happening to the new path but then the authorization fails.
Changing the path in the config then fixes the problem.

[sOliver]

This should be sticky and atomicorp might want to think twice about cancelling ASL-Lite apparently there are more than enough customers who dont want the full ASL and are disappointed this is gone

Sorry for the rant, but I'm not happy with the cancellation

Anyway, still getting the error below:
Error: ASL Version list could not be retrieved. This could be caused by a DNSresolution problem on http://www.atomicorp.com, or your IP could be blocked.

[mikeshinn]

Thank you for the question. You're seeing thats because asl-lite does not support the new update clusters. You should expect it to have issues from time to time with it, its old, it was never supported (asl-lite has always been a free and unsupported tool) and it is no longer maintained as documented on the asl-lite wiki page:

https://www.atomicorp.com/wiki/index.php/ASL_Lite

We know that some of our customers just want a supported modsecurity rules updater, and feel that they do not need the additional protection and management capabilities ASL provides. We respect that and we are working on just such a tool. Its just about done and we'll be making it available, for free, to all our existing rules customers.

You might ask why we dont maintain asl-lite anymore. It seems like a simple problem with a simple solution: keep the rules up to date. And it may seem that way, except its unfortunately for us not that simple. The kink in all of this is the problem of keeping modsecurity up to date. And thats more important than it may seem at first glance, and a bit of a chore behind the scenes.

Aside from the fact that vulnerabilities are discovered in modsecurity from time to time, and in some cases are extremely severe (like the vulnerability that made it possible to completely bypass any rule, written by anyone), which require that modsecurity itself be kept up to date, the biggest problem is that modsecurity changes, and it sometimes changes a lot. This means that the rule language changes, things go away and things are added, or something just doesnt work like it used to and we have to rewrite the logic in the rules to cope with that.

In practical terms this can be pretty severe, if the installed mosecurity DSO doesnt understand the language, it will throw a syntax error and apache wont even start! And in the best case, it might load the rules, but its not processing them correctly because the behind the scenes logic has changed so the rules dont work correctly. In short, the problem with modsecurity is that rules arent universally supported between versions, they are basically version specific.

So we know that any rule updater must be intelligent enough to know when to upgrade modsecurity itself so that the modsecurity version matches whats required for that version of the rules. That means any rule updater has to be able to download everything it needs, install the tools it needs to install and manage software (and sometimes to compile a DSO), handle all the exceptions that can occur when upgrading an apache DSO and any necessary libraries (and to figure out what version of apache and libraries is installed), to be able to compile a DSO when the platform doesnt support RPMS (cpanel for example, which requires all sorts of other logic for those kinds of exceptions), to lint the rules (including custom ones to make sure apache will start regardless of what rules are installed), roll the rules back to a working config if something goes wrong (again so there is no disruption to apache), only enable rules that work with that version of modsecurity (what do you do if the user doesnt want to upgrade modsecurity?), handle enabling/disabling rule classes based on what the user wants (dont install rules the user doesnt want), and so on.

Right now, ASL does all of this and more, but we understand that you feel you dont need the additional protection that ASL provides, and we respect that. We will be releasing a tool to just allow you to update your rules and to make sure modsecurity is kept up to date soon. Its just about done. If you would like to beta test it, please send an email to support.

As soon as this new tool is generally available, we'll let everyone know.