I have been working on a client’s MVC project for last couple of months which was hosted as Azure Website. There I have implemented DIPR (Dynamic IP Restriction) in order to protect the site against malicious scripts (i.e. DoS and DDoS attack) that worked fine but the client also informed me that they are continuously getting spams on all over their forms and this has to be stopped as soon as possible. This might seems a hard task that has to be implemented on that particular site from client’s end. But I am lucky enough this time. With Azure many benefits come just out of the box and blocking IP addresses are just one of them.
If you have followed my DIPR post you know this snippet was the extension of our earlier snippet. Inside the Web.Config file add ipSecurity section (Under security node) and amend allowUnlisted property. Setting its value to false means that only those individual address or address ranges (explicitly specified by a developer) will be allowed to make HTTP requests to that particular site. Then set the allowed attribute to true in the child node and also set value to ipAddress.
To blacklist specific IP addresses/domains set allowUnlisted to true and ‘allowed’ attribute to ‘false’.
Along with the ipAddress we can also provide subnetMask like this.
Like DIPR its also possible to change the restriction code return by it. For this set the denyAction parameter with the appropriate value.
Now if a request came to the server from an address outside of the allowed IP address/address range, then HTTP 401 Unauthorized will be returned to that user.
In addition, it also let you provide domainName instead of ipAddress.
Heads Up :
Enabling the reverse DNS lookup will slow down requests and use up more resources, so think twice before you use it for production sites.
Once you setup this configuration in your web.config file you will not be allowed to run your website locally. If you tried then you will get an error saying “This configuration section cannot be used at this path. This happens when the section is locked at a parent level”
Good Practice :
If you only require the whitelisting/blacklisting when deployed, then you can get around this by adding the configuration to the
web.config.release transformation file instead of the
web.config. This way the configuration will not be included when running locally in debug mode, but will automatically be added to the release configuration when deploying to Azure Websites.