So I have this nice, simple web server up running. Its purpose is to allow me external testing with HIP, and to provide some files for external distribution. Of course, there it is sitting on port 80 and the attacks are coming in per logwatch report. Examples from the report include:
Requests with error response codes 404 Not Found //phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /muieblackcat: 1 Time(s) /myadmin/scripts/setup.php: 2 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 2 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s)
Now these are only a few, though I am probably not being hit as hard as others out there.
My question is:
Is there a way to shut this nonsense down? Or because I am sending the 404, I am doing all that is reasonable to do?
I am wondering that if this list starts getting long, that is a lot of logging and I probably don't need to log 404s?
Il 06/03/2013 14:17, Robert Moskowitz ha scritto:
So I have this nice, simple web server up running. Its purpose is to allow me external testing with HIP, and to provide some files for external distribution. Of course, there it is sitting on port 80 and the attacks are coming in per logwatch report. Examples from the report include:
Requests with error response codes 404 Not Found //phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /muieblackcat: 1 Time(s) /myadmin/scripts/setup.php: 2 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 2 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s)
Now these are only a few, though I am probably not being hit as hard as others out there.
My question is:
Is there a way to shut this nonsense down? Or because I am sending the 404, I am doing all that is reasonable to do?
You could use fail2ban to reduce the load on the server; here is my config:
cat /etc/fail2ban/filter.d/apache-errorcode.conf
# Fail2Ban configuration file # # Author: Lorenzo Quatrini # # $Revision: 1 $ #
[Definition]
errorcode = 400|403|404
# Option: failregex # Notes.: Regexp to catch bad request # Values: TEXT # failregex = ^<HOST> -.*"(GET|POST).*HTTP.*" (?:%(errorcode)s)
# Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
I am wondering that if this list starts getting long, that is a lot of logging and I probably don't need to log 404s?
The "downside" of using fail2ban is that you will start receiving email about banned hosts; but that is configurable, as is the number of failed attempts before being banned. Also you can have "trusted" hosts that never get banned... but the manual explains this better that I can do.
Regards Lorenzo
On 03/06/2013 05:25 AM, Lorenzo Quatrini wrote:
The "downside" of using fail2ban is that you will start receiving email about banned hosts; but that is configurable, as is the number of failed attempts before being banned.
The other down side is that if you set up a new virtual host and don't put a favicon.ico file in its root, you'll ban every visitor with the configuration that you shared.
You'll also ban everyone that tries to visit a section of any site that's protected with HTTP authentication, regardless of whether or not they are a legitimate user.
404s are not uncommon, and should not be used as the sole basis for blocking.
Rule processing can become very CPU intensive if the list becomes long. Using fail2ban for HTTP will work on relatively unknown servers, but once a server has been running long enough to be frequently scanned, you probably will find that your kernel spends a lot of time checking the firewall for every new TCP connection.
The best way to defend an HTTP server is to serve only static content. If you have non-static content, protect it with HTTP AUTH. If you have non-static content that must be publicly accessible, keep it up to date and consider the use of an external IDS like Snort. It's $500/year for the intrusion definitions IIRC, and well worth that.
On 03/06/2013 07:17 AM, Robert Moskowitz wrote:
So I have this nice, simple web server up running. Its purpose is to allow me external testing with HIP, and to provide some files for external distribution. Of course, there it is sitting on port 80 and the attacks are coming in per logwatch report. Examples from the report include:
Requests with error response codes 404 Not Found //phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /muieblackcat: 1 Time(s) /myadmin/scripts/setup.php: 2 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 2 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s)
Now these are only a few, though I am probably not being hit as hard as others out there.
My question is:
Is there a way to shut this nonsense down? Or because I am sending the 404, I am doing all that is reasonable to do?
I am wondering that if this list starts getting long, that is a lot of logging and I probably don't need to log 404s?
There is also mod_security ...
http://people.centos.org/hughesjr/mod_security/
You can read about what it is here:
2013/3/6 Johnny Hughes johnny@centos.org:
On 03/06/2013 07:17 AM, Robert Moskowitz wrote:
So I have this nice, simple web server up running. Its purpose is to allow me external testing with HIP, and to provide some files for external distribution. Of course, there it is sitting on port 80 and the attacks are coming in per logwatch report. Examples from the report include:
Requests with error response codes 404 Not Found //phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /muieblackcat: 1 Time(s) /myadmin/scripts/setup.php: 2 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 2 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s)
Now these are only a few, though I am probably not being hit as hard as others out there.
My question is:
Is there a way to shut this nonsense down? Or because I am sending the 404, I am doing all that is reasonable to do?
I am wondering that if this list starts getting long, that is a lot of logging and I probably don't need to log 404s?
There is also mod_security ...
http://people.centos.org/hughesjr/mod_security/
You can read about what it is here:
ossec also blocks this kind of web scanners with active response enabled.
-- Eero
Am 06.03.2013 14:17, schrieb Robert Moskowitz:
So I have this nice, simple web server up running. [...] the attacks are coming in per logwatch report. Examples from the report include:
Requests with error response codes 404 Not Found //phpMyAdmin-2.5.1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.4/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-pl1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc1/scripts/setup.php: 1 Time(s) //phpMyAdmin-2.5.5-rc2/scripts/setup.php: 1 Time(s) /muieblackcat: 1 Time(s) /myadmin/scripts/setup.php: 2 Time(s) /mysql-admin/scripts/setup.php: 1 Time(s) /mysql/scripts/setup.php: 1 Time(s) /mysqladmin/scripts/setup.php: 2 Time(s) /mysqlmanager/scripts/setup.php: 1 Time(s)
That's the normal background noise of the Internet. Scans for known security holes. Hardly worth a bother. If it bothers you, set up fail2ban as Lorenzo proposed. Apart from that, take it as a reminder to keep up to date with the software you use to close known security holes as quickly as possible.
My question is:
Is there a way to shut this nonsense down? Or because I am sending the 404, I am doing all that is reasonable to do?
I am wondering that if this list starts getting long, that is a lot of logging and I probably don't need to log 404s?
I wouldn't disable 404 logging. Even on my hardest-hit webservers the volume is not so big that it gets anywhere near causing an actual problem. And it's nice to be kept up to date about the latest exploits in your daily logwatch mail so if the hits are getting closer you can take evasive action. :-)
-
Eero Volotinen -
Gordon Messmer -
Johnny Hughes -
Lorenzo Quatrini -
Robert Moskowitz -
Tilman Schmidt