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.
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:
- 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!
- 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.
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.