Dynamic IP Restrictions Beta 2 released!

Yes, it has been a while since Beta was released, but Beta 2 is finally released! You can download Dynamic IP Restrictions Beta 2 from the links below.

Dynamic IP Restrictions 1.0  Beta 2 – x86

Dynamic IP Restrictions 1.0 Beta 2 – x64

For more details on the release make sure you check out the updated article on using Dynamic IP Restrictions. I will take the time to mark the distinctions between Beta and Beta2 versions in this post.

 

Splitting dynamic and static IP restrictions

Well, in Beta we were experimenting with the codebase and possible restructuring of features by combining static and dynamic IP Restrictions. This caused a bunch of setup issues and didn’t buy us much in terms of ease of use and configuration. So we have decided to let static and dynamic IP restrictions each live in their own module and configuration space for Beta 2 and this will remain as such moving forward to RTW. What this means is that:

  1. You will need to uninstall the Beta version of Dynamic IP restriction before you can install Beta 2. Make sure to backup configuration before doing this!
  2. Since static IP restrictions module was uninstalled during the installation of dynamic IP restrictions Beta, you will now have to re-install (re-enable) static IP restrictions module (IP and Domain Restrictions).

Negligible runtime performance impact

The other change, that will be invisible to the end user, is a complete rewrite of the code to make the runtime performance impact of the module almost 0, even if you are just serving static files from your web server. We feel that every web server should have this feature installed and enabled and this way we ensure that the dynamic IP restrictions module will have no performance impact on your server.

 

Removal of RSCA interface

In Beta, you could use our RSCA interface to see currently blocked IP addresses, but this is not much more than eye candy. The data presented through this is not really actionable, since this list is going to be highly dynamic by nature. This module has been designed as a security defense tool and keeping that in mind the right action to perform is to detect repeat offenders and block them using either the static IP restriction or the firewall. To do this you would need historic data and not just a snapshot of what is happening right now. We had strong feedback from Beta that mining the logs was much more meaningful.

 

Proxy mode

Requests coming to the web server from a proxy or firewall server usually has the IP address of the firewall or proxy server as the client IP address. This defeats the usability of dynamic IP restrictions module because client IP address to actual clients is now a many to one mapping. We now have a configuration option that will enable the module to use the first IP address in the X-Forwarded-For request header as the client IP address. This header is used as the de-facto mechanism of reporting originating IP address.

 

Server and site level configuration only

One of the main changes we had to make in the module to make it extremely performant is to restrict configuring this module to server and site level only. If you host multiple applications with extremely different request-response characteristics on the same site, you should move them to different sites on the same server to increase the effectiveness of the module.

 

I will have a blog/article on using LogParser to mine data from log output of dynamic IP restrictions soon.

4 Comments

  • Nazim, any idea if this will ever see the light of day? or is it a shelved project for now? Thanks.

  • This feature is currently being worked into the next version of Windows and will then be released as an out-of band on DLC as well. We can't talk much about it since things are hush-hush about the next version of Windows.

  • Hi Nazim, would you know how long the offending IP Address gets banned for?

  • @invulnarable27: How long an offending IP Address is banned for is configured by the time period (in Beta2 denyByRequestRate\requestIntervalInMilliseconds)

Comments have been disabled for this content.