How do I ensure that X-HTTP-Method headers are ignored?

I'm currently applying security fixes for a vulnerability which was found by a third party software. This is the issue (Often Misused: HTTP Method Override vulnerability).

The request from the software was similar to:

POST /Home/ViewProfile HTTP/1.1
Referer: https://somesite.com/Home/ViewProfile?qrystr=blahblah
[...]
X-HTTP-METHOD: PUT
X-HTTP-Method-Override: PUT
X-METHOD-OVERRIDE: PUT
[...] 

And the response was:

HTTP/1.1 200 OK
[...]

The web application is not a RESTful API, it's just a an ASP.NET MVC site which only has GET and POST actions.

I have a few questions:

1. Is this a false positive given the type of app?
2. By default, does ASP.NET do anything with these headers X-HTTP-Method, X-HTTP-Method-Override, X-METHOD-OVERRIDE if not explicitly told to do so such as in this example?
3. Regarding the first linked issue above, what is the best way to go about achieving the recommended remediations if they're necessary/applicable based on my case:
   "Ensure that only the required headers are allowed, and that the allowed headers are properly configured."
   and
   "Ensure that no workarounds are implemented to bypass security measures implemented by user-agents, frameworks, or web servers."

Another thing to note is I don't have access to modify IIS settings, but I can modify the Web.Config.

I had the same problem with a scan from my security team. What I did was limiting the size of those requests to zero (0) in the web.config. The server then returns a "HTTP Error 431.0 - Request Header Fields Too Large", effectively blocking the overrides.

 </system.webServer>
    ...
 <security>
      <requestFiltering>
        <requestLimits>
          <headerLimits>
            <add header="X-Http-Method-Override" sizeLimit="0" />
            <add header="X-Method-Override" sizeLimit="0" />
            <add header="X-HTTP-Method" sizeLimit="0" />
          </headerLimits>
        </requestLimits>
        ...
      </requestFiltering>
    </security>
   ...
  </system.webServer>

However, I haven't checked yet if this effectively cancels the alert by the security scanner. I suspect it might still show, but I'm ready to report back as a false positive because the server is blocking all calls with those headers. I'll let you know as soon as I get a response from the security team.