Support

0. I have no explanation for that. There's definitely something from your IP triggering this exception. If all your machines are shut down and nobody else is using your Internet connection the only plausible explanation lies in the realm of the paranormal. Sorry for being snarky, but what you describe simly can't happen within the realm of logic. The only other explanation which doesn't involve paranormal activity is human error: you accidentally trigger it while working on your machine but you're reading the log wrong. Remember that all times and dates are in GMT. Since you're in the US, GMT is 7 to 9 hours ahead of your local time (depending on which coast you live in). Maybe that's what is going on?

1. Yes, there is. Attackers don't have static IPs. They have dynamic IPs and they rotate them every few hours up to a few days at most. Blocking the IP for three years would definitely end up blocking legitimate traffic. Besides, automated scripts do stop messing with your site after a few minutes of getting no results from your server.

2. If you follow the documentation instructions for the .htaccess Maker and Admin Tools troubleshooting you can make it work. There are no shortcuts here, sorry.

3. Just because you can doesn't mean you should :) If you read the documentation you'll see that some of those options are meant to be used on specific categories of sites and do have side effects. For example, CSRFShield doesn't play well with components which (stupidly) do POST requests without a token. The XSSShield is very trigger finger happy; it will prefer to err on the side of false positive, ending up killing a lot of components' legitimate requests in the process. There's simply no way to make those features smarter (at least not without making your site dead slow).

4. The GeoIP databases are only 99% accurate. This means that 1 every 100 IPs will be either perceived as being from an unknown country or the wrong country. In other words, you may block up to 1% of your legitimate traffic. You will also block all traffic from US users abroad, US users using Tor for privacy reasons or US users using a hotspot with an IP belonging to a non-US range. Real example: WiFi on UK's trains ends up using a Swedish IP address. Moreover this feature provides ZERO protection against hackers. A hacker with an IQ slightly higher than a door knob would simply use a proxy to circumvent the GeoIP restriction.

The notifications that I am referring to are being emailed to me, nit ones thatI am seeing in a log

Turn on logging and check if they are logged. If they are not logged, they don't come from Admin Tools (at least, not Admin Tools on your live site)

I hear what you are "saying", but something is causing the email to go out other than what should be.

The email is only triggered by an exception, which is triggered by a request. The IP is fetched by PHP from Apache which trusts what the Operating System's TCP stack reports. It's a very well defined code path across all components of the system. The only thing that can trigger an exception email with your IP listed on it is a request either coming form your IP or with a forged TCP header which spoofs your IP. Now, even that is a far cry as the HTTP GET request to trigger it requires much more than one package. It's very very hard pulling this off. It makes no sense pulling an IP forgery just to irk someone by raising security exceptions on his site when he's asleep. It's like breaking through a top-end security system just to piss on somebody's living room every. single. night. Makes no sense whatsoever. So I guess we can rule this out too.

I've told you all my guesses. I have none left. Your IP –indisputably, as per your recount– from a time you are not on the computer and nobody else is using the Internet connection? It just doesn't add up. OK, here's one more thing to do. I will call this the "ghost test". When you are not on your computer, unplug the xDSL/cable modem from the power plug. If you still get an email from your IP then you definitely need to call Ghost Busters on this one, don't you agree? :)

I even thought that maybe the mail system was just re-sending the email again for some unknown reason, but checked the timestamps in the header and that does not seem to be the case.

It crossed my mind, but you'd have spotted that the contents would be the same.

One other new question... One of the sites we have AT on has a lot of registered users that seem to forget their passwords and so I get a ton of failed login attempt emails caused by legitimate users.  Is there a way to only get notified if there are failed attempts to access the backend of the site?

Of course, they are two different options.

It's already documented, but let me give you the overview anyway.

"Treat failed logins as security exceptions". When enabled, your users' failed front-end login attempts will be treated as security exceptions and you'll get emails about them in the email address defined in the "Email this address on security exceptions" option.

Filling in the "Email this address on failed administrator login" option will send an email to this email address every time a back-end login fails.

So, you have to set "Treat failed logins as security exceptions" to No and set an email in the "Email this address on failed administrator login" field to achieve the exact effect you want on your site.