Join Log in
Score:1
avatar Server

IIS stop bogus API

in flag
Jefferson

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)
140
1 + 2
iis
Lex Li avatar
vn flag
Lex Li
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.
1
Reply
in flag
Jefferson
what about Reverse Proxy using IIS Rewrite would only pass the traffic that's setup?
0
Reply
Score:0
avatar Server
cn flag
Peter Hahndorf

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.

0 + 2
in flag
Jefferson
How do I know the position of the application vs iis position?
0
Reply
cn flag
Peter Hahndorf
The positions I mentioned are the ones in the IIS Failed Request Tracing Logs which list all the different steps in the pipeline.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.