5

I have IPs attempting to probe our web server trying to find open URLs. The two known methods are attempting to find specific nodes on our drupal site, or attempting the ../../../../ trick to try and access the root of the web server.

Both tricks don't do anything against us, but LogWatch sometimes returns that the probing may have been successful returning a 200 HTTP request.

Is there any measures I should be taking to counter this?

Improve this question

3 Answers 3

Reset to default
8

The simple answer is that if somebody is doing obvious probing, drop them. phpMyAdmin, for example, is a tell-tale that is never legitimately requested unless you installed it for your own private use. I suggest a 15 minute "drop all packets" response, or ICMP unreachable by admin response if you feel particularly verbose. You can trigger this with Apache rewrite rules, security modules, fail2ban and regular logs, or an application firewall system.

I personally use type 3, code 13 for misbehaving NTP clients (just the application, not taking out the whole host), 9 for killing them at the network, and 10 if the system in question only has 1 IP. Not many folks pay attention to those, but I consider them my "Bad Internet Citizen" flags.

Improve this answer
1
  • Thanks again for the answer Jeff. We've been playing with Fail2Ban more and getting really strict with the rules that we have set, and we're blocking a lot more, but it seems as though it has increased in intensity. Are we pissing off the script kiddies?
    – Anthony Miller
    Dec 6, 2011 at 18:41
2

You can use phpids as IPS or suhosin

Improve this answer
2
  • PHPIDS is not an IPS. Suhosin is intended to address shortcomings in the underlying PHP code but these are mostly difficult to exploit compared with bad scripting.
    – symcbean
    Nov 22, 2011 at 11:22
  • @vizzdoom - can you expand your answer please. As it stands it is of low value and likely to be deleted.
    – Rory Alsop ♦
    Nov 23, 2011 at 11:44
1

Mostly stuff you see in your logs is where your security is working as you planned - but there is a case for looking at IPS.

PHPids ships with rules to detect a lot of attacks - but does not pro-actively change the behaviour of your system for protection. OTOH fail2ban does pro-actively block detected attacks - but doesn't come pre-configured with tests for detecting attacks against PHP sites. It wouldn't take a lot of work to drive fail2ban from phpids.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .