IIS stop bogus API

Question

In IIS can it stop bogus API calls? Yesterday I got flooded with something that was trying to see if a page is on the site. They got the 404 but the application still had to check to see if that was a good page in the application. Can IIS stop this or will the web application need to process it and stop it. Is there a section in IIS where I can add the bogus path to to stop this? would this help https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/denyurlsequences/ or Reverse Proxy using IIS Rewrite It would only pass the traffic that's setup?

Bogus API calls

 The controller for path '/bitrix/admin/' was not found
    The controller for path '/cgi-bin/webcm'
    The controller for path '/admin' was not found
    The controller for path '/system/login'
    The controller for path '/typo3/phpmyadmin/'

App Log file

 2021-08-17 15:05:28,382 [16] ERROR HTI.LogServices.Implementation.Log4NetHelper - [undefined]: Unhandled Exception (System.Web.HttpException (0x80004005): The controller for path '/admin' was not found or does not implement IController.
       at System.Web.Mvc.DefaultControllerFactory.GetControllerInstance(RequestContext requestContext, Type controllerType)

By opening your web server to the internet, effectively attackers use common vulnerabilities to exploit your system. Those requests on the paths are typical ones to detect server type (CGI and PHP) and then further attacks come. IIS won't be able to help you much, and you need an enterprise level firewall (not Windows Firewall) to filter them out, or third party solutions like Cloudflare. — Lex Li, Aug 20 '21 at 03:21
what about Reverse Proxy using IIS Rewrite would only pass the traffic that's setup? — Jefferson, Aug 20 '21 at 13:27

score 0 · Accepted Answer · answered Aug 22 '21 at 18:28

As you already mentioned, IIS's Request Filtering should be able to help you.

You are using an asp.net MVC site, so any requested URL is checked against all configured routes. This means your application layer is used to respond with a 404 to the request.

Ideally you want a 404 earlier in your request pipeline before your application layer is invoked.

There are several options:

 <system.webServer>
    <security>
        <requestFiltering>
            <denyUrlSequences>
                <add sequence="/system/login" />
            </denyUrlSequences>
            <hiddenSegments>
                <add segment="system" />
            </hiddenSegments>
            <filteringRules>
                <filteringRule name="systemLogin" scanUrl="true" scanQueryString="false">
                    <denyStrings>
                        <add string="system/login" />
                    </denyStrings>
                </filteringRule>
            </filteringRules>
        </requestFiltering>
    </security>    
</system.webServer>

You should just play around which one works best for you and doesn't affect your own application.

If you enable Failed Request Tracing, you can see where in the pipeline the 404 response was created. In my test using no request filtering, the 404 was created at position 232 in the pipeling, using request filtering it was created at position 72 so much earlier and before your application layer is invoked.

Yes, an web firewall in front of your IIS server would be even better but lacking that IIS can detect these requests before they get to your application.

Make sure your custom error pages are configured correctly and don't say anything else but 404.

How do I know the position of the application vs iis position? — Jefferson, Aug 23 '21 at 00:57
The positions I mentioned are the ones in the IIS Failed Request Tracing Logs which list all the different steps in the pipeline. — Peter Hahndorf, Aug 23 '21 at 10:41

IIS stop bogus API

1 Answers1