Should I block visitors who seem to be probing my site?

As a rule, the returns on this type of defense are nearly zero. There are exceptions, but even then this technique may offer only a small amount of security.

Exhaustive vulnerability scans of randomly-chosen hosts offer extremely low returns on scanning resources. Instead, successful attackers generally choose one of the following two options to increase their odds:

1. Check for a very small number of vulnerabilities over a large number of hosts
   This includes bad passwords for common services such as SSH, POP3, cPanel, Wordpress, Joomla, and the like. If your root password is "root" or your site admin password is "admin", you can expect to get caught in one of these drift nets surprisingly quickly.

2. Starting with a single known vulnerability, use a search technique to narrow down your target list to only the most likely victims.
   Usually this starts on one of the common vulnerability databases. He finds a recent candidate and identifies some string that would be common on vulnerable hosts. This is often a "Powered by" line or a login link or a specific URL pattern. Then, using his favorite search engine he retrieves a list of sites that follow that pattern.

The important point is that in neither of these cases does the attacker make more than a few attempts at a given site. Either they're successful immediately, or they move on.

That's not to say that you won't see the occasional persistent attacker. There's always some misguidedly optimistic individual running Nessus against a /16, but such attacks are by their very nature self-limiting and very rarely successful, since the vast majority of the attacks target software that a given server doesn't even run.

Could such an attack be successful? Yes. Does it ever happen? I deal on the average with several compromised servers per day, and so far I have yet to see even one come from nessus-style full-spectrum scans. But the probability isn't exactly zero. And in the world of random attacks, statistics and probability matter quite a great deal.

The exception is when the attack is not random. If you run a high-value or high-visibility site, you'll attract a lot of direct attacks against you in particular. Sites like Facebook, Twitter, Hotmail, etc., see an extraordinary amount of attack traffic. If you deal in this type of site, you probably already take security very seriously and aren't looking for advice.

A note about SQL injection: This type of attack does take some refinement; after catching an SQL error message in a cursory scan, an attacker may send several dozen queries to a given server to get the bits centered right. So theoretically a clamp-down response may prevent such an attack... but probably not, since he'll probably just return using a different IP. Since he's already alerted on your server, he won't be deterred by a blacklist. Better advice is don't run crappy software. There's no excuse for using non-parameterized queries today.

Arguments in favor of blacklisting: Might as well make the attacker's life harder. While this is not a strong defense, it might give a little bit of additional time to investigate the attack and put in place stronger defenses.

Arguments against blacklisting: In the case dynamic IP addresses, blacklisting them may end up blocking other benign users. You might never know that you are blocking other benign users, or it might lead to hard-to-diagnose errors in the future. In addition, there is some potential configuration complexity to managing a blacklist.

If the attacker is attempting to disrupt the site by overloading it (to mount a denial-of-service attack), then blocking the IP address might be the right answer. A temporary block might be enough.

If the attacker is just probing or scanning, I would be less inclined to blacklist their IP address, but you can take the tradeoffs into account in each situation and make an informed decision about what makes the most sense.

Edit: This answer does not consider login brute-forcing, just attacks which attempt to exploit system vulnerabilities. Of course it seems legit to me to temporarily ban an IP which attempts 30 logins in 5 minutes. /edit.

If you don't have an automatic system in place to check and block requests, don't ban IP addresses that attempt to hack your service. If you block them, they can't make anymore requests, and you won't know if there is a leak. Attacks are going on day and night, and more often than not, you won't be watching the log while an attack is attempted. Block an attack now, and some day someone else will find the leak.

Of course, blocking attacking IPs is a precautionary measure which will help your security. It is not real security, but it might just ward of an attack while giving you early warning.

Doing this in an automated manner might have an advantage when you give a default response back (like a HTTP-200 response) so that automated tools won't detect the block. If you keep logging the requests, you can later check if any of the attempts would have been successful.

There are some problems with this though:

• Attacks may come from a botnet, hacked server, or dynamic IP. Sooner or later, you're going to block a benign user. At least just temporarily ban the IP until you've made sure that the attack would not have been successful.
• It is a lot of work to check all requests from detected attacks, especially since there are so many automated attack tools that make hundreds of requests.
• You will probably start to rely on the detection system in some way. This kind of precaution will make you feel safer, and thus make you think less about security while configuring the system (or writing code).
• You still have to check log files from time to time to make sure your detection system didn't miss anything.
• False positives may occur. A simple example is when detecting apostrophes in POST-data (which an attack tool might attempt to detect SQL-injections), you could block a user who is trying to use an apostrophe in their password. This may be solved with a captcha, but targeted attacks will also solve the captcha.

Overall, I would not block any attempted attacks. There may be situations where this is a good idea (perhaps in high-security environments, like for a bank or website with millions of visitors), but in general I don't think it will really help, or may even give you a false sense of security.

The only exception is a DoS attack. Here is no security risk, the only thing being exploited is processing time or bandwidth, so there is no reason not to block this. Though even then, only temporarily ratelimit or ban: these attacks are likely done from a botnet, thus making you block user's IPs.