Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Looking through my 404 logs I noticed the following two URLs, both of which occurred once:




The page in question, library.php, requires a type variable with a half-dozen different acceptable values, and then an id variable. So a valid URL might be


and the ids are all run through mysql_real_escape_string before being used to query the database.

I'm a rookie, but it seems to me that both of these links are simple attacks against the webroot?

1) How best to protect against these sorts of things besides a 404?

2) Should I permaban the IP(s) responsible?

EDIT: also just noticed this one


EDIT 2: The offending IP for all 3 attacks was which traces to an ISP called Lunar Pages located just outside of Los Angeles.

EDIT 3: I've decided to call the ISP Friday morning local time and discuss the issue with whoever I can get on the phone. I'll post the results here in 24 hours or so.

EDIT 4: I ended up emailing their admins and they responded first that "they were looking into it" and then a day later with "this issue should be resolved now." No further details, sadly.

share|improve this question

migrated from Aug 27 '10 at 4:52

This question came from our site for professional and enthusiast programmers.

Adnrew, am I get it right that this /library.php script do not include anything from query string? In this case you are safe – Col. Shrapnel Aug 27 '10 at 4:10
library.php handles links generated by my own site. The type tells the script which include to use (though through an IF $_GET['type'] == 'thing') {} ESLE..., not as a direct link like include 'type.php') and the id is run through mysql_real_escape_string and that is used for queries. Knowing that, am I still safe? – Andrew Heath Aug 27 '10 at 4:32
Can somebody explain what exactly the attacker is trying to find out? A short summary in the question of all answers would be great. – bzero Jun 2 '14 at 7:48
up vote 19 down vote accepted

0) Yes. At the very least, it's a systematic probe against your site trying to discover if it's vulnerable.

1) Other than making sure that your code is clean, there's not a lot you can do but run your own tests against your host to make sure it's safe. Google Skipfish is one of the many tools to help you there.

2) I would.

share|improve this answer
Regarding 0) notation: nice!! I'd never have thought of that. – polygenelubricants Aug 27 '10 at 3:12
@polygenelubricants I bet you wouldn't have thought of -1) or 0.5) or π) or 2 + 3i) notation either. :P – Mateen Ulhaq Oct 19 '11 at 0:31

This is an attack, it is very much explained here.

share|improve this answer

As said by others: yes, it is an hack attempt. Please be aware that in addition to this possibly hand-made attempt there are lots and lots of automated ones ran by botnets. Generally those kind of attacks are attempting to sneak through ages-old vulnerabilities and/or some typical coding flaws, such as failure to validate user input leading to SQL injection, system or file leakage, or similar.

Banning those botnets by hand is most likely impossible, since botnets can use up to thousands of unique IP addresses so if you want to ban them, you'll have to use some kind of automated ban program. fail2ban comes to my mind; make it to react to mod_security events or some other log entries.

If your code is clean and server hardened, those hack attempts are only annoying log pollution. But it's better to take precautionary steps and consider some or all of the following, depending on your needs:

  • mod_security is an Apache module filtering out all kinds of typical hacking attempts. It can also restrict outbound traffic (the page your server would be sending to a client) if it sees suspicious JavaScript etc.

  • Suhosin for hardening PHP itself.

  • Run your PHP scripts as a user who owns the script; things like suphp and php-fpm makes that possible.

  • Mount your webroot and PHP temporary directory as noexec,nosuid,nodev.

  • Disable unneeded PHP functions, such as system and passthru.

  • Disable unneeded PHP modules. For example, if you don't need IMAP support, do not enable it.

  • Keep your server up to date.

  • Keep your eye on logs.

  • Make sure you have backups.

  • Have a plan what to do if someone hacks you or some other disaster hits you.

That's a good start. Then there are even more extreme measures such as Snort and Prelude, but they can be very overkill for most setups.

share|improve this answer

It's entirely likely that the machine that's making those queries is a botnet zombie. If you're getting those requests from multiple IPs, it's probably not worth banning them, because you'd have to ban half the internet for it to be effective.

share|improve this answer

As already said - it's an attempt to acces the /proc/self/environ file to get more informations.

I assume it's a linux machine:

You should use

  • suhosin ( - Protects php scripts
  • use php openbasedir restriction
  • fail2ban

You can block the ip of an attacking server, but you should consider that it can be non attacking in the feature.

I used to block some services when my server is under attack: http/https/pop/imap/ssh but leave smtp open, that you can be notified if you made a mistake.

share|improve this answer
Why wait till you've got a failed attack before changing your security? Why do anything when you know the attack is failing? Yes, the OP might consider some temporary tweaks to cut down on the noise and wasted bandwidth - but there are implications to applying the changes you suggest which you've not addressed – symcbean Aug 27 '10 at 10:16
There are always implications. Leave it as it is and you might get hacked. Secure your server and face the problems caused by security programs. But anyhow - security is a major concern on a web accessible system! – Andreas Rehm Aug 27 '10 at 11:55

Yes it's an intrusion attempt. You should definitely put a ban on the IP. If you determine that the IP is out of country, you may just want to ban the entire subnet it belongs to. This is less a code issue than it is a server issue. Look this particular intrusion up and make sure your hosting provider is not vulnerable to it or similar script kiddie attempts (which is what this one looks like).

share|improve this answer

This is an attempt to exploit a potential arbitrary local file inclusion vulnerabilty in server-side scripts accessible via your web server. On a vulnerable linux system /proc/self/environ can be abused to execute arbitrary code server-side.

share|improve this answer

As recommended by Janne Pikkarainen:

Keep your eye on logs.

Make sure you have backups.

As part of these logs it is important to monitor changes of any of your files, including your website, as part of an intrusion detection system. An example is OpenBSD that does this by default for the config files. I bring this up because:

  • For Cloud Sites there was subtle modifications to PHP files on a custom built website (this was just outputting a non-standard tag but maybe a part of a test to measure the magnitude of the exploit).
  • For one coworker there was subtle redirects within the their WordPress .htaccess file (only referrers from Google search results).
  • For another coworker there were subtle modifications to their Joomla config file (can't remember what, I think it was a redirect under certain conditions as well).
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.