You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by ko...@umn.edu on 2009/11/14 16:24:35 UTC
[users@httpd] 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 <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
Re: [users@httpd] Re: Dynamically block certain requests on trigger?
Posted by Nathaniel Kofalt <ko...@umn.edu>.
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
Re: [users@httpd] Re: Dynamically block certain requests on trigger?
Posted by Norman Peelman <np...@cfl.rr.com>.
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>
--
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 <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
[users@httpd] Re: Dynamically block certain requests on trigger?
Posted by Nathaniel Kofalt <ko...@umn.edu>.
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 <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
[users@httpd] Re: Dynamically block certain requests on trigger?
Posted by LuKreme <kr...@kreme.com>.
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:
<http://eportfolio.research.iat.sfu.ca/wiki/index.php?title=HOWTO_Setup_fail2ban>
--
'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 <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