A less well known feature of ASL is that it can detect attempts to brute force web application authentication. In concert with the HIDS, it will track these failures and much like the brute force rules after so many attempts it will shun the IP.

We write rules for web app brute force protection based on feedback, and we'd like feedback about what applications you'd like us to protect. So far we have rules for these web apps:

PhpBB
vBulletin
WordPress
Joomla
Wikimedia
SugarCRM

We know this isn't a complete list, so please let us know what apps you'd like us to protect.

So let us know!

To develop the rules we will need a working copy of the web application and the ability to download it and run it on our test servers, so please make sure you can provide that before you ask!

Just some ideas: Drupal, Typo3, MODx, Movable Type, Magento, osCommerce, ZenCart, Dokuwiki, PmWiki, Moodle, Gallery.

Thought I'd add a new one I was exposed to recently, XenForo (PHP/MySQL as far as I can tell)

Can I add Prestashop to the hat too please? www.prestashop.com

Will do!

+1 for ZenCart, Drupal and Joomla

Joomla is already in the rules, and we'll add in the others as well.

New ones added:

Plesk GUI
Drupal
Typo3
MODx
Moodle
osCommerce
Magento
ZenCart
Dokuwiki
Prestashop

PmWiki: doesnt actually return anything if authentication fails, it returns the same page it uses when you first access a protected page. So I'm not sure brute force can be detected easily with pmwiki. If you have a setup you want us to look at, please provide a URL with an authentication page.

Should have these added tomorrow:
Gallery
Movable Type

Let us know if you have any other requests!

Is there anyway to make these rules less trigger happy? ie allow them a couple of wrong ones before blocking - we are getting numerous complaints from people in regards to his blocking people when they accidentally type wrong password or username on mainly joomla.

also have had reports of the "forgotten password" on wordpress triggering the lockout(unconfirmed as yet though)

Do you mean the shuns, or the initial alerts (the initial alerts do not block by the way).

THe shunning.

The current thresholds are:

8 failures in 10 seconds. ((fast) login failures)
10 failures in 60 seconds. (brute force (slow) login failures)
60 failures in 900 seconds. (Very Slow)

You can disable one or more of these by opening the rule manager, and search for the web applications name. For example, if you search for Joomla, you will see three rules that deals with login failures: 60156, 60157, 60908 that correspond to those thresholds above in that order.

You can not change the thresholds at this point in ASL. That will be supported in a future version of ASL.

like always your list contains any entries I would suggest as well
http://owncloud.org
would be an app I would like to see being protected.
Thanks a lot

I have a custom CMS system I wrote myself. Although the login system is actually an open source login auth module for the framework I use. Wondering if you would support that also or not?

It's actually a pretty secured login system and has it's own basic brute-force protection,but doesn't hurt to have more layers on the onion.

Added to the list.