httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathaniel Kofalt <kofal...@umn.edu>
Subject Re: [users@httpd] Re: Dynamically block certain requests on trigger?
Date Thu, 19 Nov 2009 22:13:36 GMT
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...
>
> <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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message