Every few days I see in the logwatch on my Centos-5.5 web-server what seems like a rather feeble break-in attempt. Eg today I see --------------------------- 403 Forbidden /phpMyAdmin/scripts/setup.php: 2 Time(s) /phpmyadmin/scripts/setup.php: 2 Time(s) 404 Not Found /PMA2005/scripts/setup.php: 1 Time(s) /TRAD_files/datestamp.js: 1 Time(s) ... --------------------------- followed by dozens of similar lines.
As far as I can see, the IP of the person making the attempt (if there was an attempt) is not given.
I'm not at all sure what if anything I should do about this.
In fact, I'm not clear how one should deal with logwatch entries in general. Is there any document giving advice on this?
On Wed, Sep 08, 2010 at 01:33:18PM +0100, Timothy Murphy wrote:
Every few days I see in the logwatch on my Centos-5.5 web-server what seems like a rather feeble break-in attempt.
That is what it is, and since it's so feeble, it's barely helpful to know about it.
In fact, I'm not clear how one should deal with logwatch entries in general.
Sigh and wish there were a better tool, I think.
Every few days I see in the logwatch on my Centos-5.5 web-server what
seems
like a rather feeble break-in attempt. Eg today I see
403 Forbidden /phpMyAdmin/scripts/setup.php: 2 Time(s) /phpmyadmin/scripts/setup.php: 2 Time(s) 404 Not Found /PMA2005/scripts/setup.php: 1 Time(s) /TRAD_files/datestamp.js: 1 Time(s) ...
followed by dozens of similar lines.
As far as I can see, the IP of the person making the attempt (if there was an attempt) is not given.
I'm not at all sure what if anything I should do about this.
Logwatch is just an automated tool that runs a few checks on your log files. The source IP is in your apache log files.
If you are concerned, you should check your log files to check for that IP and then run a check on whether that IP appears elsewhere in any of your logfiles.
The likelihood is that someone ran a vulnerability scanner against all your available services, logwatch found evidence of that vulnerability scan, and you should check whether any other vulnerabilities were scanned for and perhaps found...
To do that you should manually check your log files or use a better tool.
Giles Coochey wrote:
The likelihood is that someone ran a vulnerability scanner against all your available services, logwatch found evidence of that vulnerability scan, and you should check whether any other vulnerabilities were scanned for and perhaps found...
To do that you should manually check your log files or use a better tool.
Such as ...
On Wed, Sep 08, 2010, Timothy Murphy wrote:
Giles Coochey wrote:
The likelihood is that someone ran a vulnerability scanner against all your available services, logwatch found evidence of that vulnerability scan, and you should check whether any other vulnerabilities were scanned for and perhaps found...
To do that you should manually check your log files or use a better tool.
Such as ...
While fail2ban and swatch are good tools, apache mod_security is probably better for dealing with this type of thing as it is designed to minimize attacks on web services.
I think it's a mistake to discount any attacks involving php as the vast majority of the systems I have had to clean up after cracks have been compromised through php vulnerabilities, usually in conjunction with weak user level passwords.
IHMO, admin tools like phpMyAdmin, webmin, and usermin should be carefully restricted, preferably only accessible via a private LAN, not from the public internet. Use a VPN to access from the public internet if necessary. We don't install usermin in most cases as I have seen it used to exploit security bugs on old SuSE systems that permit root access.
Bill
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Bill Campbell Sent: Wednesday, September 08, 2010 12:17 PM To: centos@centos.org Subject: Re: [CentOS] Interpreting logwatch
While fail2ban and swatch are good tools, apache mod_security is probably better for dealing with this type of thing as it is designed to minimize attacks on web services.
I think it's a mistake to discount any attacks involving php as the vast majority of the systems I have had to clean up after cracks have been compromised through php vulnerabilities, usually in conjunction with weak user level passwords.
IHMO, admin tools like phpMyAdmin, webmin, and usermin should be carefully restricted, preferably only accessible via a private LAN, not from the public internet.
This lurker is running a family pictures website, and got tired of that nonsense, so I have a bunch of entries like these in my .htaccess file:
Redirect permanent /phpMyAdmin/ http://127.0.0.1/ Redirect permanent /PMA2005/ http://127.0.0.1/ ...
The Perishable Press blog has other .htaccess methods to deal with such things.
I also block access from all Amazon EC2 IPs, that reduced the amount of port and application scans by about half.
Al -- I yam Popeye of the Borg. Prepares ta beez askimiligrated.
On Wed, Sep 8, 2010 at 6:17 PM, Bill Campbell centos@celestial.com wrote:
I think it's a mistake to discount any attacks involving php as the vast majority of the systems I have had to clean up after cracks have been compromised through php vulnerabilities, usually in conjunction with weak user level passwords.
IHMO, admin tools like phpMyAdmin, webmin, and usermin should be carefully restricted, preferably only accessible via a private LAN, not from the public internet. Use a VPN to access from the public internet if necessary. We don't install usermin in most cases as I have seen it used to exploit security bugs on old SuSE systems that permit root access.
Last time I checked, webmin and usermin were written in Perl ;-), no php there.
If you're running a web app with a known vulnerability and it's available from the internet, then you're in trouble, that's for sure.
-- natxo
On Thu, Sep 09, 2010, Natxo Asenjo wrote:
On Wed, Sep 8, 2010 at 6:17 PM, Bill Campbell centos@celestial.com wrote:
I think it's a mistake to discount any attacks involving php as the vast majority of the systems I have had to clean up after cracks have been compromised through php vulnerabilities, usually in conjunction with weak user level passwords.
IHMO, admin tools like phpMyAdmin, webmin, and usermin should be carefully restricted, preferably only accessible via a private LAN, not from the public internet. Use a VPN to access from the public internet if necessary. We don't install usermin in most cases as I have seen it used to exploit security bugs on old SuSE systems that permit root access.
Last time I checked, webmin and usermin were written in Perl ;-), no php there.
True enough (although very ugly perl without adequate paramter checkind in come cases :-) should have said different topic.
If you're running a web app with a known vulnerability and it's available from the internet, then you're in trouble, that's for sure.
Even if it doesn't have known vulnrabilities, running admin applications that may have root capabilities without guarding against unauthorized access is a recipe for trouble.
Bill
Timothy Murphy wrote:
Every few days I see in the logwatch on my Centos-5.5 web-server what seems like a rather feeble break-in attempt. Eg today I see
403 Forbidden /phpMyAdmin/scripts/setup.php: 2 Time(s) /phpmyadmin/scripts/setup.php: 2 Time(s) 404 Not Found /PMA2005/scripts/setup.php: 1 Time(s) /TRAD_files/datestamp.js: 1 Time(s)...
followed by dozens of similar lines.
As far as I can see, the IP of the person making the attempt (if there was an attempt) is not given.
I'm not at all sure what if anything I should do about this.
In fact, I'm not clear how one should deal with logwatch entries in general. Is there any document giving advice on this?
We run fail2ban. It blocks a given IP for so long after so many (3? 5?) failed attempts to break in. It also does a whois on the IP, which is a little more info.
mark, wondering if the Chinese Railway is trying again today
m.roth@5-cent.us wrote:
Every few days I see in the logwatch on my Centos-5.5 web-server what seems like a rather feeble break-in attempt.
In fact, I'm not clear how one should deal with logwatch entries in general. Is there any document giving advice on this?
We run fail2ban. It blocks a given IP for so long after so many (3? 5?) failed attempts to break in. It also does a whois on the IP, which is a little more info.
Thanks, I'll try that. I had heard of fail2ban , but was slightly put off by the strange name; what exactly is the name meant to convey?
On Wed, Sep 08, 2010 at 02:47:46PM +0100, Timothy Murphy wrote:
Thanks, I'll try that. I had heard of fail2ban , but was slightly put off by the strange name; what exactly is the name meant to convey?
"to" as in the sense of "moving to", or "converting to". Failures (login failures normally, but other errors or log patterns can be used) cause the triggering IP address to be banned. (Or another action to be taken.)
This is excellent for preventing brute-force ssh attacks.
On 9/8/2010 9:52 AM, Matthew Miller wrote:
On Wed, Sep 08, 2010 at 02:47:46PM +0100, Timothy Murphy wrote:
Thanks, I'll try that. I had heard of fail2ban , but was slightly put off by the strange name; what exactly is the name meant to convey?
"to" as in the sense of "moving to", or "converting to". Failures (login failures normally, but other errors or log patterns can be used) cause the triggering IP address to be banned. (Or another action to be taken.)
This is excellent for preventing brute-force ssh attacks.
I've never used fail2ban, but from the wide community support, I'm sure it is more than just a viable option.
Not to discount any of the good advice given here, but I've had great successes with Advanced Policy Firewall (apf) [1] as a front-end to iptables, and an adjunct program, Brute Force Detection (bfd)[2].
Very flexible and easy-to-adjust settings, with global settings easily overridden on a service-by-service level.
My .02. YMMV, of course.
HTH, -Ray
[1] http://www.rfxn.com/projects/advanced-policy-firewall/ Note: I've always installed from the rfxn.com site directly, but there appears to be an RPM available at rpmforge: http://www.rpmfind.net/linux/RPM/dag/redhat/el5/i386/apf-9.7_1-1.el5.rf.noar...
Timothy Murphy wrote:
m.roth@5-cent.us wrote:
Every few days I see in the logwatch on my Centos-5.5 web-server what seems like a rather feeble break-in attempt.
In fact, I'm not clear how one should deal with logwatch entries in general. Is there any document giving advice on this?
We run fail2ban. It blocks a given IP for so long after so many (3? 5?) failed attempts to break in. It also does a whois on the IP, which is a little more info.
Thanks, I'll try that. I had heard of fail2ban , but was slightly put off by the strange name; what exactly is the name meant to convey?
They fail to log in successfully enough times, they're banned by firewall rules.
*heh* If odd names put you off, you probably shouldn't be playing with any version of *Nix.... <g> fail2ban is pretty self-explanatory, compared to, say, bonobo, or anaconda, or gnome....
mark "I know awk, sed, cp, rm, and dozens of other 2 and 3 letter commands, and I'm not afraid to use them!"
-
Albert McCann -
Bill Campbell -
Giles Coochey -
m.roth＠5-cent.us -
Matthew Miller -
Natxo Asenjo -
Ray Leventhal -
Timothy Murphy