My website has a blacklist of IP addresses. The web application, in some way, detects all invalid, suspicious influences to it and remembers IP address and denies any requests from that IP address.
So my question is: Is it a good practice, way to prevent attacks in this way?
SUMMARY (ADDED):
I want to summarize all answers, as possible:
I would say not to bother blacklisting IP's too much:
I would suggest a "gray-list" of IP addresses, i.e. if you recognize bad traffic you "keep an eye" on those addresses.
An IP blacklist can help, but don't rely on it as your sole means of security.
You'll also want to be very careful about banning IP blocks or search engine bots. You may want to also maintain a whitelist of IPs that are false positives for your suspicious influences.
As long as suspicious influences aren't too strict. You don't want to block a good user.
In principle can be good.
However depends how long you block the IP addresses for. Also you should consider that some users such as ones using AOL if I remember right come through proxy servers so a lot of users will be sharing the same IP address and as a result you could be block a lot of people. Another consideration is that Office, Universities, etc. May also have many computers sharing the same IP and that's another wide range of people you could end up blocking for one users actions.
You could perhaps block either for a short period of time or block by a combination of user agent and IP address to limit the blocks effect.
It depends. If your application is a SMTP server, you could safely assume that all incoming traffic should come from static IP's, that is if message comes from dynamic IP, it is probably spam or virus sent from some kind of botnet. In such case it is really good idea to prevent them from connecting and I believe it is a good practice.
In general I'd say yep it can be a pretty effective control. One problem you could get is users coming through a proxy, which may all seem to come from one IP address, blocking one could block them all. Sometimes you can use the X-Forwarded-For header to differentiate requests from one source IP address, but that's not present necessarily on all proxied requests.
Be careful of server configurations where for example on Rackspace, the _SERVER[ REMOTE_IP ] which is usually the users IP address, is actually a load bearing proxy server.
However the REMOTE_IP header is really the only non-spoofable header in terms of the users real ip.
HTTP_X_CLUSTER_CLIENT_IP and HTTP_X_FORWARDED_FOR ( to name a few ) for example can all be spoofed by an attacker/attack system.
Many of the CMS addon security plugins I have looked at that attempt to filter inputs using a cascade approach of potential headers then ban the IP address of bad requests, tend to stack most of the common client or proxy sent headers first, the REMOTE_ADDR being the last on the list, this for an attacker is trivial to bypass, so in effect the entire application then becomes pointless since a new client ip address can be potentially sent with each rogue request.
Banning the wrong IP address in a clustered configuration could result in your website becoming banned, and allowing spoofed IPs to be banned can allow an attacker to send a spoofed IP of the webserver or an upline proxy to the webserver which results in the same effect.
Or where whitelisted IPs are used, the attacker could also send the rogue requests with the whitelisted IP.
The best method I have come up with in these situations is: Where there are other headers present other than the REMOTE_IP, rule number one is always filter them to make sure those headers actually contain an IP address, then yes use those to determine the users IP address, however disable ip banning ( if it is being employed ) in that instance, and just go with a 403 header and page die() call to block an actual rogue request rather than actually ban the ip address.
Afterall it is the rogue request you are wanting to prevent completing more than anything else. Banning IP addresses is more of an issue where an attacker is hammering your site via multiple anonymous proxy servers in order to create a denial of service.
