Support

Hello Jay,

no, that's neither possible nor desirable. The idea behind email notifications is to know that you're being attacked in real time. What happens if you set it to wait for 100 hack attempts in X minutes and the hacker guesses the correct password on the 99th attempt? That's the entire point. I understand that the emails are annoying at times like this. You can always log to your site's back-end and disable Admin Tools' emails by clearing the relevant email fields in Admin Tools' Web Application Firewall configuration page. After a while you may re-enable those emails.

Alternatively, you may try more strict auto IP blocking rules. You may set an IP block for 90 minutes if an IP throws 3 security exceptions within 10 minutes. This will gradually block all IPs involved in the attack, unless you are being hit by a very big botnet. In the latter case I'd be more worried about the resource depletion involved with such a large scale attack than the volume of emails received.

Hello Jay,

It's not possible to stop emails from GeoBlocking, but there are three alternatives to that.

The first alternative is the IP auto-ban I already mentioned. Once an IP gets auto-banned you won't receive emails about it for the duration of the ban.

The other alternative is disabling all email notifications except for failed and successful back-end logins. In order to do that you have to go to the Configure WAF page and remove the email address from the "Email this address on security exceptions" box.

Now, we have the third alternative: email filters. All mail clients –desktop or web-based– allow you to create email filters. If you observe Admin Tools' emails you'll see that there is a "Reason: something" mentioned in each one of them. It's easy creating email rules based on that string. Such rules could, for example, immediately delete all GeoBlocking notifications and keep receiving other emails. I've found that with a creative use of email filters you can do some crazy stuff impossible with me adding code to Admin Tools. For example I have it so that if someone logs in from an IP different than my regular static IP the email notification is forwarded to another email address which sends an SMS to my mobile. All you have to do is be creative with your email filters :)

Example 1: the IP is not blacklisted. It goes through the firewall and gets caught by the GeoBlocking feature. It emails you telling you that the GeoBlocking feature intercepted the access attempt.

Example 2: The IP address triggered the firewall repeatedly. It now became automatically blocked. You will not receive notifications about it until 2012-07-26 09:01:04 GMT when the ban will be automatically lifted. When Admin Tools sees that IP until 2012-07-26 09:01:04 GMT it will prevent it from accessing your site BEFORE it is processed by the rest of the firewall rules.

I mean, think about it. If an IP is blocked it would be stupid to waste our time checking it against the firewall rules. It's blocked. It must not be allowed to proceed. What good would it make having it go through the firewall and its GeoBlock feature?

I assumed that any IP on the Geo-IP list was the equivalent of being IP blocked.

Not quite. We have to read the IP, run it against the GeoIP database, determine the continent and country and check them against the list of the continents/countries to be blocked.

It seems like a waste of cycles analyzing the behavior of an IP address if it's already on the geo-ip block list?

The opposite holds true. Getting the IP is a very cheap operation. Checking it against the list of blocked IPs is also a very cheap operation. Checking it against the GeoIP database, however, is about 20-30x slower.

Wouldn't it be more efficient to 1) check it against the deny list and then immediately check the geo-ip list? If it's not on either, then finish processing the request.

Which is EXACTLY what we are doing, as I told you. If the IP is in the black list it's not being further processed.

I believe you are getting confused with how the auto-block works. After a specific IP has triggered several* security exceptions it is automatically blocked. So what happens in that case is that the request goes through the firewall, gets blocked and then the auto-ban is enforced. Since the IP is added to the deny list after it has gone through the firewall we can't go back in time and check the just updated deny list before going through the firewall. I believe that is self understood.

* User-configurable in the auto IP ban area of the WAF configuration page

Hi Jay,

I decided it's best to keep my business focused around Joomla!. You know what they say. The only way to be equally good in everything is being mediocre in everything. I try to make Akeeba Backup excellent and this requires a tight focus. For what is worth, I'm keeping a keen eye on Joomla! Platform's JWebApplication API and related development. I hope that in the not-so-distant future it will be possible to have a standalone version of Akeeba Backup which can back up and restore everything based on PHP and MySQL. Well, we'll see how that plan pans out :)