IIS7 - Security

Re: Request filtering fileExtensions and default document issue

davide marzucco — Mon, 27 Apr 2009 09:03:05 GMT

That's it!! You're the one Lex!!! Thank you sooooooooooooo much!!

I tried many other possibilities, setting "/", or "", but with no luck (and indeed I was trying to have luck!!)

The "." (dot) is the obvious solution, but I was not aware of that.

Now I'm happy and feel secure!!

This solution should be offered as a guide or how-to for locking down IIS with request filtering based on a need-to-have principle. I started from here and probably this guide could include this solution!

This is the Site for IIS resources!

Regards,
Davide

Re: Request filtering fileExtensions and default document issue

lextm — Mon, 27 Apr 2009 08:50:47 GMT

Hi Davide,

Don't be upset. I just noticed that there is a way to allow "/". This requires you to add an extra Allow rule.

1. Click "Allow File Name Extension..."

2. Type "." (a dot) in the dialog and click OK.

Then you can access http://localhost/ to test if it works also on your box.

In this way, other unknown extensions are still being blocked.

Regards,

Re: Request filtering fileExtensions and default document issue

davide marzucco — Mon, 27 Apr 2009 07:46:31 GMT

Hi Lex, thank you again for your reply. I was afraid of this conclusion. We can't get the server secure and user-friendly at the same time! What's your opinion on having a company site unreachable at www.company.com ? We'll have to tell everybody to type www.company.com/default.aspx to reach the homepage...

I agree with you, enabling that feature, I asked IIS not to serve /, but I suppose that having the default document feature be overridden by the request filtering, is not so reasonable.

I'm looking further for some workaround, keeping the famous allowUnlisted=true option.

Regards,
Davide

Re: Request filtering fileExtensions and default document issue

lextm — Sat, 25 Apr 2009 12:04:58 GMT

Hi Davide,

I can understand your concern about security.

But if you configure allowUnlisted=false, you are telling IIS to block everything unlisted. That of course includes "/" which contains no extension information at all.

This behavior is reasonable IMO.

Re: Request filtering fileExtensions and default document issue

davide marzucco — Sat, 25 Apr 2009 10:04:01 GMT

Thank you lextm for your reply, but unfortunately I found no news on the issue. You're right, surfing that URL on the local server, I can see the detailed IIS error code, which is 404.7, that is a file extension denied. But I already knew this, as I wrote, changing allowUnlisted="true" the problem is not issued anymore.

The real question is: which fileExtension has to be allowed explicitly to allow the request to / resource ?

Only when I set no filter on the fileExtension, IIS serves the / resource, and after that, the redirection to the defaul document occurs.

Hope you can understand my concern.

Anyway, thank you.

Re: Request filtering fileExtensions and default document issue

lextm — Sat, 25 Apr 2009 05:02:03 GMT

If you received a 404 status code when allowUnlisted = false, then please follow this KB article to know which sub status code occurs.

http://support.microsoft.com/kb/943891

Once you know the sub status code, it is easy to know which request filtering rule needs to be tuned.

Request filtering fileExtensions and default document issue

davide marzucco — Thu, 23 Apr 2009 16:30:37 GMT

Hi all, I'm just working on locking down IIS7 with request filtering.
To avoid any misunderstanding here it is the requestFiltering node from my applicationHost.config file:

Setting allowUnlisted="false" in the fileExtensions node, causes my root site not to serve anymore the default document. That is, if I browse for http://www.mysite.com I receive a 404 not found, being the request for / blocked by the request filtering file extensions rule, although I configured the default document to default.aspx.
Despite, browsing for http://www.mysite.com/default.aspx everything works fine.
Confirmation comes when changing just allowUnlisted="true" in the fileExtensions node: in this case the default document is served by IIS, according to the configuration.

I'm thinking this could be solved with some particular entry in the fileExtensions section. Can someone help me on this please?

You should agree that for end-users using a short url (www.mysite.com) is much more confortable and user-friendly than having to type a "complex" URL with the home document.

Thank you in advance,
Regards,
Davide