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?


I want to summarize all answers, as possible:

  • white-list (trusted locations)
  • grey-list (high attention list)
  • temporary blocking
  • static, dynamic address detection
  • smart, flexible detection
  • 2
    there are several commercial services that exist to give you IP geolocation intelligence (including static/dynamic, line speed, + more) quova.com (now Neustar) & digital element are the premium providers digitalelement.com Nov 15, 2010 at 4:08

7 Answers 7


I would say not to bother blacklisting IP's too much:

  • There are too many False Positives, since there are many situations of shared IP's - proxies, workplace, ISP's using roving DHCP, etc.
  • It is too easy to get around it. A real bad guy will just get a different IP, if she really wants to attack you.

I would suggest a "gray-list" of IP addresses, i.e. if you recognize bad traffic you "keep an eye" on those addresses.

  • +1 grey-list is a soft and human-involved solution, but it is more flexible. any way it's a good point. thanks
    – garik
    Nov 11, 2010 at 23:30
  • 3
    Btw, @igor, gray-list doesnt need to be human-involved - it can be to put additional checks on requests, throttling / quota, etc
    – AviD
    Nov 20, 2010 at 16:14

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.

  • unless, of course, (s)he, it does not do influences so long. :)
    – garik
    Nov 11, 2010 at 23:03

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.

  • Pawel, how to detect that the address is static or dynamic?
    – garik
    Nov 11, 2010 at 23:14
  • 1
    @Igor: That's the problem. Actually, I was referring to my experience (that's how I secured mail server few years ago) and I simply knew that i.e. Neostrada's (Largest Polish ISP service) IPs are dynamically assigned. Some black listing sites seem to know which IPs are dynamic, i.e. this site: cbl.abuseat.org somehow knew that my IP is dynamic... Nov 11, 2010 at 23:27
  • +1 agreed. at least this information can be found from the public sources, I hope.
    – garik
    Nov 11, 2010 at 23:33

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.

  • Is it possible that IP address can be UNKNOWN (empty)? What does it mean (if yes)?
    – garik
    Nov 11, 2010 at 23:11
  • Also, if you are relying on X-Forwarded-For instead of the direct connecting IP - whats to stop the attacker from impersonating a proxy, and just adding that header with random IPs each time?
    – AviD
    Nov 16, 2010 at 5:33

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .