kofal002 at umn
Nov 19, 2009, 2:13 PM
Post #5 of 5
(519 views)
Permalink
|
|
Re: Re: Dynamically block certain requests on trigger?
[In reply to]
|
|
Norman Peelman wrote:
> Nathaniel Kofalt wrote:
>> kofal002 [at] umn 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...
>
> <Directory /var/www>
> 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
> </Directory>
>
>
>
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 <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe [at] httpd
" from the digest: users-digest-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd
|
