Dynamically block certain requests on trigger?

Hello!
I am a relatively inexperienced Apache administrator, running a small
public website. Traffic is extremely low, and in general the site runs
fine.

However, I have noticed huge, automated vulnerability scans from random IP
addresses. Typically a single IP will request several thousand invalid
addresses over the course of a few minutes, wait a few minutes, and try
again, scanning for things like phpMyAdmin and other tools that I presume
could commonly be left unsecured by accident. Below is a brief excerpt from
my error logs, with redundant requests removed. (I've also censored my www
folder location):

[Tue Nov 10 13:50:59 2009] [error] [client 206.210.109.21] File does not
exist: ...www/phpmyadmin
[Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does not
exist: ...www/php-my-admin
[Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does not
exist: ...www/phpMyAdmin-2.2.3
[Tue Nov 10 13:51:19 2009] [error] [client 206.210.109.21] File does not
exist: ...www/phpMyAdmin-2.8.2
[Tue Nov 10 13:51:20 2009] [error] [client 206.210.109.21] File does not
exist: ...www/admin
[Tue Nov 10 13:51:43 2009] [error] [client 206.210.109.21] File does not
exist: ...www/mysql
[Tue Nov 10 13:52:02 2009] [error] [client 206.210.109.21] File does not
exist: ...www/sql
[Tue Nov 10 13:52:25 2009] [error] [client 206.210.109.21] File does not
exist: ...www/database

Most of these bots tend to hit the same URLS, and some also try to execute
common scripts:

[Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
'...www/dbadminmain.php' not found or unable to stat
[Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
'...www/myadminmain.php' not found or unable to stat
[Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
'...www/mysqlmain.php' not found or unable to stat
[Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
'...www/mysqladminmain.php' not found or unable to stat
[Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
'...www/phpadminmain.php' not found or unable to stat
[Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
'...www/phpmyadminmain.php' not found or unable to stat
[Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
'...www/phpmyadmin1main.php' not found or unable to stat
[Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
'...www/phpmyadmin2main.php' not found or unable to stat
[Sat Nov 07 08:32:12 2009] [error] [client 134.106.13.97] script
'...www/pmamain.php' not found or unable to stat

At best, this is instructive in which locations are commonly exploited, but
this spam outweighs legitimate traffic! I end up with 4MB log files, while
the access log file is maybe 40kB. It looks like these dolts hit
"http://random.yahoo.com/fast/ryl" (based on the referrer tag) and
continuously scan the net. What I would like is to dynamically deny IP
addresses based on certain criteria. These bots always generate a ton of
404 responses and hit common invalid URLs, something legitimate clients
will never do.

What would would be perfect is a module that watches for conditions like
these, and if they trigger, drops requests from that IP for the next 24
hours. For example. if anybody requests "phpmyadmin" at all, I don't want
the server to even respond (just drop the request, no 404) for awhile, even
to legitimate requests. Preferably, it would also log the block action as
well.

I can only assume this problem has been tackled before, so maybe that's the
wrong approach. If that is the case, what is a low CPU/bandwidth solution
to this problem?

Thanks for your assistance!
Nathaniel Kofalt

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Dynamically block certain requests on trigger?

On 14-Nov-2009, at 08:24, kofal002@umn.edu wrote:

> What would would be perfect is a module that watches for conditions =
like these, and if they trigger, drops requests from that IP for the =
next 24 hours. For example. if anybody requests "phpmyadmin" at all, I =
don't want the server to even respond (just drop the request, no 404) =
for awhile, even to legitimate requests. Preferably, it would also log =
the block action as well.

The simplest option is using IPTABLES to setup a rule (we used to do =
this for SSH).

fail2ban might be an option for you. It has nothing to do with apache =
specifically, but it looks for these sorts of massive floods and then =
bans the IP from the server. I'm pretty sure it has a WWW/apache module =
for apache (I use it for sash and smtp intrusion as I've not noticed the =
trouble you describe). Be aware that the default values might seem =
rather strict to some people. 5 failures in 10 minutes equals a two week =
ban. It's possible that fail2ban is only working on AUTH/LOGIN failures =
though. Still, should get you started, I guess.

I started here:
=
fail2ban>


--=20
'There's Mr Dibbler.'
'What's he selling this time?'
'I don't think he's trying to sell anything, Mr Poons.'
'It's that bad? Then we're probably in lots of trouble.' --Reaper Man


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Dynamically block certain requests on trigger?

kofal002@umn.edu wrote:
> Hello!
> I am a relatively inexperienced Apache administrator, running a small
> public website. Traffic is extremely low, and in general the site runs
> fine.
>
> However, I have noticed huge, automated vulnerability scans from
> random IP addresses. Typically a single IP will request several
> thousand invalid addresses over the course of a few minutes, wait a
> few minutes, and try again, scanning for things like phpMyAdmin and
> other tools that I presume could commonly be left unsecured by
> accident. Below is a brief excerpt from my error logs, with redundant
> requests removed. (I've also censored my www folder location):
>
> [Tue Nov 10 13:50:59 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/phpmyadmin
> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/php-my-admin
> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/phpMyAdmin-2.2.3
> [Tue Nov 10 13:51:19 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/phpMyAdmin-2.8.2
> [Tue Nov 10 13:51:20 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/admin
> [Tue Nov 10 13:51:43 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/mysql
> [Tue Nov 10 13:52:02 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/sql
> [Tue Nov 10 13:52:25 2009] [error] [client 206.210.109.21] File does
> not exist: ...www/database
>
> Most of these bots tend to hit the same URLS, and some also try to
> execute common scripts:
>
> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
> '...www/dbadminmain.php' not found or unable to stat
> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
> '...www/myadminmain.php' not found or unable to stat
> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
> '...www/mysqlmain.php' not found or unable to stat
> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
> '...www/mysqladminmain.php' not found or unable to stat
> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
> '...www/phpadminmain.php' not found or unable to stat
> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
> '...www/phpmyadminmain.php' not found or unable to stat
> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
> '...www/phpmyadmin1main.php' not found or unable to stat
> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
> '...www/phpmyadmin2main.php' not found or unable to stat
> [Sat Nov 07 08:32:12 2009] [error] [client 134.106.13.97] script
> '...www/pmamain.php' not found or unable to stat
>
> At best, this is instructive in which locations are commonly
> exploited, but this spam outweighs legitimate traffic! I end up with
> 4MB log files, while the access log file is maybe 40kB. It looks like
> these dolts hit "http://random.yahoo.com/fast/ryl" (based on the
> referrer tag) and continuously scan the net. What I would like is to
> dynamically deny IP addresses based on certain criteria. These bots
> always generate a ton of 404 responses and hit common invalid URLs,
> something legitimate clients will never do.
>
> What would would be perfect is a module that watches for conditions
> like these, and if they trigger, drops requests from that IP for the
> next 24 hours. For example. if anybody requests "phpmyadmin" at all, I
> don't want the server to even respond (just drop the request, no 404)
> for awhile, even to legitimate requests. Preferably, it would also log
> the block action as well.
>
> I can only assume this problem has been tackled before, so maybe
> that's the wrong approach. If that is the case, what is a low
> CPU/bandwidth solution to this problem?
>
> Thanks for your assistance!
> Nathaniel Kofalt

Anyone have an idea for this?

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Re: Dynamically block certain requests on trigger?

Nathaniel Kofalt wrote:
> kofal002@umn.edu wrote:
>> Hello!
>> I am a relatively inexperienced Apache administrator, running a small
>> public website. Traffic is extremely low, and in general the site
>> runs fine.
>>
>> However, I have noticed huge, automated vulnerability scans from
>> random IP addresses. Typically a single IP will request several
>> thousand invalid addresses over the course of a few minutes, wait a
>> few minutes, and try again, scanning for things like phpMyAdmin and
>> other tools that I presume could commonly be left unsecured by
>> accident. Below is a brief excerpt from my error logs, with redundant
>> requests removed. (I've also censored my www folder location):
>>
>> [Tue Nov 10 13:50:59 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/phpmyadmin
>> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/php-my-admin
>> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/phpMyAdmin-2.2.3
>> [Tue Nov 10 13:51:19 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/phpMyAdmin-2.8.2
>> [Tue Nov 10 13:51:20 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/admin
>> [Tue Nov 10 13:51:43 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/mysql
>> [Tue Nov 10 13:52:02 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/sql
>> [Tue Nov 10 13:52:25 2009] [error] [client 206.210.109.21] File does
>> not exist: ...www/database
>>
>> Most of these bots tend to hit the same URLS, and some also try to
>> execute common scripts:
>>
>> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
>> '...www/dbadminmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
>> '...www/myadminmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
>> '...www/mysqlmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
>> '...www/mysqladminmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
>> '...www/phpadminmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
>> '...www/phpmyadminmain.php' not found or unable to stat
>> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
>> '...www/phpmyadmin1main.php' not found or unable to stat
>> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
>> '...www/phpmyadmin2main.php' not found or unable to stat
>> [Sat Nov 07 08:32:12 2009] [error] [client 134.106.13.97] script
>> '...www/pmamain.php' not found or unable to stat
>>
>> At best, this is instructive in which locations are commonly
>> exploited, but this spam outweighs legitimate traffic! I end up with
>> 4MB log files, while the access log file is maybe 40kB. It looks like
>> these dolts hit "http://random.yahoo.com/fast/ryl" (based on the
>> referrer tag) and continuously scan the net. What I would like is to
>> dynamically deny IP addresses based on certain criteria. These bots
>> always generate a ton of 404 responses and hit common invalid URLs,
>> something legitimate clients will never do.
>>
>> What would would be perfect is a module that watches for conditions
>> like these, and if they trigger, drops requests from that IP for the
>> next 24 hours. For example. if anybody requests "phpmyadmin" at all,
>> I don't want the server to even respond (just drop the request, no
>> 404) for awhile, even to legitimate requests. Preferably, it would
>> also log the block action as well.
>>
>> I can only assume this problem has been tackled before, so maybe
>> that's the wrong approach. If that is the case, what is a low
>> CPU/bandwidth solution to this problem?
>>
>> Thanks for your assistance!
>> Nathaniel Kofalt
>
> Anyone have an idea for this?
>
Check out the Allow/Deny directives in the documentation. I'm still
learning too, this is what i'm doing:

This matches my default doc root...


Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order Deny,Allow

## International Spammers

# amsterdam spammers
Deny from 194.8.74
Deny from 194.8.75

# korea spammers
Deny from 125.60.28
Deny from 125.135.222
Deny from 125.141.225

# thailand spammers
Deny from 202.149
Deny from 118.175

# argentina spammers
Deny from 200.43.234

# czech republic spanmmers
Deny from 81.91

# china spammers
Deny from 114.255
Deny from 61.187
Deny from 202.120.38

# ukraine spammers
Deny from 212.3

# italy spammers
Deny from 85.42

# france spammers
Deny from 91.121.85

# moldova republic spammers
Deny from 87.248

# india spammers
Deny from 122.165

# brasil spammers
Deny from 189.72

# japan spammers
Deny from 163.221.116
Deny from 203.140.76

# taiwan spammers
Deny from 210.69.23

# africa spammers
Deny from 196.12.220


## United States Spammers

# florida
Deny from 64.29.148





--
Norman Registered Linux user #461062 -Have you been to www.apache.org yet?-

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: Re: Dynamically block certain requests on trigger?

Norman Peelman wrote:
> Nathaniel Kofalt wrote:
>> kofal002@umn.edu wrote:
>>> Hello!
>>> I am a relatively inexperienced Apache administrator, running a
>>> small public website. Traffic is extremely low, and in general the
>>> site runs fine.
>>>
>>> However, I have noticed huge, automated vulnerability scans from
>>> random IP addresses. Typically a single IP will request several
>>> thousand invalid addresses over the course of a few minutes, wait a
>>> few minutes, and try again, scanning for things like phpMyAdmin and
>>> other tools that I presume could commonly be left unsecured by
>>> accident. Below is a brief excerpt from my error logs, with
>>> redundant requests removed. (I've also censored my www folder
>>> location):
>>>
>>> [Tue Nov 10 13:50:59 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/phpmyadmin
>>> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/php-my-admin
>>> [Tue Nov 10 13:51:05 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/phpMyAdmin-2.2.3
>>> [Tue Nov 10 13:51:19 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/phpMyAdmin-2.8.2
>>> [Tue Nov 10 13:51:20 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/admin
>>> [Tue Nov 10 13:51:43 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/mysql
>>> [Tue Nov 10 13:52:02 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/sql
>>> [Tue Nov 10 13:52:25 2009] [error] [client 206.210.109.21] File does
>>> not exist: ...www/database
>>>
>>> Most of these bots tend to hit the same URLS, and some also try to
>>> execute common scripts:
>>>
>>> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
>>> '...www/dbadminmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:08 2009] [error] [client 134.106.13.97] script
>>> '...www/myadminmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
>>> '...www/mysqlmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:09 2009] [error] [client 134.106.13.97] script
>>> '...www/mysqladminmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
>>> '...www/phpadminmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:10 2009] [error] [client 134.106.13.97] script
>>> '...www/phpmyadminmain.php' not found or unable to stat
>>> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
>>> '...www/phpmyadmin1main.php' not found or unable to stat
>>> [Sat Nov 07 08:32:11 2009] [error] [client 134.106.13.97] script
>>> '...www/phpmyadmin2main.php' not found or unable to stat
>>> [Sat Nov 07 08:32:12 2009] [error] [client 134.106.13.97] script
>>> '...www/pmamain.php' not found or unable to stat
>>>
>>> At best, this is instructive in which locations are commonly
>>> exploited, but this spam outweighs legitimate traffic! I end up with
>>> 4MB log files, while the access log file is maybe 40kB. It looks
>>> like these dolts hit "http://random.yahoo.com/fast/ryl" (based on
>>> the referrer tag) and continuously scan the net. What I would like
>>> is to dynamically deny IP addresses based on certain criteria. These
>>> bots always generate a ton of 404 responses and hit common invalid
>>> URLs, something legitimate clients will never do.
>>>
>>> What would would be perfect is a module that watches for conditions
>>> like these, and if they trigger, drops requests from that IP for the
>>> next 24 hours. For example. if anybody requests "phpmyadmin" at all,
>>> I don't want the server to even respond (just drop the request, no
>>> 404) for awhile, even to legitimate requests. Preferably, it would
>>> also log the block action as well.
>>>
>>> I can only assume this problem has been tackled before, so maybe
>>> that's the wrong approach. If that is the case, what is a low
>>> CPU/bandwidth solution to this problem?
>>>
>>> Thanks for your assistance!
>>> Nathaniel Kofalt
>>
>> Anyone have an idea for this?
>>
> Check out the Allow/Deny directives in the documentation. I'm still
> learning too, this is what i'm doing:
>
> This matches my default doc root...
>
>
> Options Indexes FollowSymLinks MultiViews
> AllowOverride None
> Order Deny,Allow
>
> ## International Spammers
>
> # amsterdam spammers
> Deny from 194.8.74
> Deny from 194.8.75
>
> # korea spammers
> Deny from 125.60.28
> Deny from 125.135.222
> Deny from 125.141.225
>
> # thailand spammers
> Deny from 202.149
> Deny from 118.175
>
> # argentina spammers
> Deny from 200.43.234
>
> # czech republic spanmmers
> Deny from 81.91
>
> # china spammers
> Deny from 114.255
> Deny from 61.187
> Deny from 202.120.38
>
> # ukraine spammers
> Deny from 212.3
>
> # italy spammers
> Deny from 85.42
>
> # france spammers
> Deny from 91.121.85
>
> # moldova republic spammers
> Deny from 87.248
>
> # india spammers
> Deny from 122.165
>
> # brasil spammers
> Deny from 189.72
>
> # japan spammers
> Deny from 163.221.116
> Deny from 203.140.76
>
> # taiwan spammers
> Deny from 210.69.23
>
> # africa spammers
> Deny from 196.12.220
>
>
> ## United States Spammers
>
> # florida
> Deny from 64.29.148
>
>
>
>
Interesting! Obviously, this has to be configured manually, but perhaps
I could give this a shot.
I was hoping for something more set & forget...

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org