Is it possible to serve specific pages based on IP address?

Solution 1:

Just install fail2ban with the appropriate jail and be done with it. Don't bother to give a custom response, as it's most likely that it will never be seen.

Solution 2:

There is a possibility, and we did it quite a lot, to reverse possible attacks. Use iptables to redirect the cloud provider (address range) to a different port - and there serve the attacker a response, even in plain headers.

In Apache you can modify headers by example:

Header set GetOut "Better luck next time!"

Solution 3:

This is very easy with ModSecurity which is a third-party WAF module for Apache. Though it does involve learning its rule language syntax.

You can also use ModSecurity to just drop the connection rather than respond at all.

Saying that, installing ModSecurity just for this, when, as others have suggested, it's likely the responses will be ignored may well be overkill.

Solution 4:

I'd go with fail2ban and dropping requests from known abuse locations. And if you feel that the attacker's service provider is not to blame, report the attacks to their abuse email address.

If you want to spend time making something that will slow down the attacker, you might want to try making a tarpit. First you must of course know where the attacks come from. Then you could use apache to redirect the request from the ip (range?) to a specific script. This might do the trick although I haven't tried it myself. Then just implement a script that, for example, prints out a dot (or something from /dev/null) every 15 seconds to keep the attacker's connection open indefinitely.

Since the attacker is most likely using scripts to attack your site, it might take time to notice that the attacks have stalled, since the connections are all seemingly active, there will be no timeout and the request isn't denied on the spot.

The problem is that you devote you time and resources to something that probably won't be as helpful as the more important concern: securing your login. It's hard to attack when you don't know where to attack. Consider some of the following:

• restrict access to the login page (only your intranet? ip range? vpn? other?).
• add reCaptcha or other verification question to login.
• use Multi-factor authentication.
• hide your login page. If possible, don't link to it from your main page and don't use /login or other obvious location.