We see a lot of requests for non-existent setup.php files in our access logs (see below). For some of our clients that use rewrite rules each of these requests will cause a PHP script to be executed, causing considerable slowdown on the server and generating unnecessary traffic.

Is it possible to quickly deny these kind of requests? I was thinking of specifying a general deny rule that denies all setup.php related queries, but that might not be the right approach. Any suggestions? - - [17/Nov/2010:09:13:35 +0100] "GET /PHPMYADMIN/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu" - - [17/Nov/2010:09:13:35 +0100] "GET /PMA/scripts/setup.php HTTP/1.1" 404 2444 "-" "ZmEu" - - [17/Nov/2010:09:13:39 +0100] "GET /PMA2005/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu" - - [17/Nov/2010:09:13:47 +0100] "GET /SSLMySQLAdmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu" - - [17/Nov/2010:09:13:42 +0100] "GET /SQL/scripts/setup.php HTTP/1.1" 404 2446 "-" "ZmEu" - - [17/Nov/2010:09:13:49 +0100] "GET /admin/phpmyadmin/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu" - - [17/Nov/2010:09:13:58 +0100] "GET /admin/scripts/setup.php HTTP/1.1" 404 2442 "-" "ZmEu" - - [17/Nov/2010:09:14:00 +0100] "GET /bbs/data/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu" - - [17/Nov/2010:09:14:01 +0100] "GET /cpadmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu" - - [17/Nov/2010:09:14:03 +0100] "GET /cpadmindb/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu" - - [17/Nov/2010:09:13:53 +0100] "GET /admin/pma/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu" - - [17/Nov/2010:09:14:05 +0100] "GET /cpanelmysql/scripts/setup.php HTTP/1.1" 404 2450 "-" "ZmEu" - - [17/Nov/2010:09:14:11 +0100] "GET /cpanelphpmyadmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu" - - [17/Nov/2010:09:14:13 +0100] "GET /cpanelsql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu" - - [17/Nov/2010:09:14:23 +0100] "GET /cpphpmyadmin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu" - - [17/Nov/2010:09:14:25 +0100] "GET /db/scripts/setup.php HTTP/1.1" 404 2441 "-" "ZmEu" - - [17/Nov/2010:09:14:26 +0100] "GET /dbadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu" - - [17/Nov/2010:09:14:28 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu" - - [17/Nov/2010:09:14:29 +0100] "GET /mysql-admin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu" - - [17/Nov/2010:09:14:32 +0100] "GET /mysql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu" - - [17/Nov/2010:09:14:33 +0100] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu" - - [17/Nov/2010:09:14:35 +0100] "GET /mysqladminconfig/scripts/setup.php HTTP/1.1" 404 2453 "-" "ZmEu" - - [17/Nov/2010:09:14:36 +0100] "GET /mysqlmanager/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"

4 Answers 4


Still relevant almost 4 years later.

Since presumably mod_rewrite is handling the bona fide traffic, these scripts are not going to add much more to the load. But yes, they may cause lag momentarily. In general you are not going to be able to prevent these entirely.

The mods and plugins to mitigate this tend to focus on frequencies and rates prior to blocking the ip at the local firewall (iptables). A better approach should include signatures such as fragments of the (bogus in normal use) directory names. Then it has to be considered how reactive this needs to be. One could adapt parts of the "denyhosts" package (a product to protect against similar issues for SSH password logins) to read behind the log and identify the "signatures" to add the ip addresses to /etc/hosts.deny.

As a rule these people don't come back from the same host, so we might want something quicker. The beauty of open source is that we can tweak it. mod_evasive seems OK, but what if your server is queried by scripts legitimately (curl, wget, and the like). Hence no CAPTCHA, and the need for whitelists or a reset by POST or GET parms.

For those of you worried about the risk of the attack (the OP was not, the OP was bothered by resource consumption), if you actually have phpmyadmin then:

Use per-directory directives.

ALLOW FROM *safe places*

Seriously, very few people should have access. Unless they are a DBA, what justifies the risk? During an incident Apache can be reconfigured on demand to open the door from a single address. If you are away, then VPN in to a VNC/RDP desktop on the same network or use a proxy.

Their script will still hit you for 404's (and at least one 403). Leaving dummy folders and config code for them to find just encourages them. I just use grep -v to filter out the directory names.

  • .. and of course now the directives format has changed...
    – mckenzm
    Mar 29, 2015 at 2:32

start with not serving any content from the default vhost so bots that attack you blindly based just on an ip address have less chance of making a request that will trigger any 'heavyweight' action on your side.

then you can use fail2ban and check content of your logs + block ips from which blind scans came.

  • Thanks for the fail2ban suggestion. The attacks are not directed at the server IP but at specific domains on the server. The log I posted is from the log file of one specific domain. Nov 17, 2010 at 9:36

I am now using @mod_evasive@, which is turning out to be a great solution.


Make sure PHPMyAdmin is up to date. Hide it, put it in a directory they won't be scanning for, like /padmin32.

  • I am already doing all this. It is not a real solution to the problem since the scanning will continue, the server load will remain. Nov 18, 2010 at 10:35
  • 1
    @Ton van den Heuvel no the "real problem" is getting hacked.
    – Rook
    Nov 18, 2010 at 16:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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