Apologies for this long post. I’m trying to teach myself good use of Request Filtering. From not a particularly technical background, but I want to gain a good understanding of its use a second line of defence against SQLi.<br>
<br>
I started with this document – which explained the basic setup: https://docs.microsoft.com/en-us/iis/manage/configuring-security/configure-request-filtering-in-iis<br>
<br>
This post was useful: https://blogs.iis.net/peterviola/blocking-sql-injection-with-iis-request-filtering
<br>
<br>
But I still have various unanswered questions, and I wondered if I might ask them here.<br>
<br>
Thanks,<br>
Les<br>
<br>
—<br>
<br>
1, Request Filtering – Rules, or separate URL and Query Strings entries<br>
<br>
In Request Filtering we can deny (or allow) a string from a URL or a query string from the specific tabs for these. Or we can create a Rule, to block the same string from one or both.<br>
<br>
Is the effect of this exactly the same?<br>
<br>
If so, then I guess this allows us to create a machine level Rule then over-ride it at site level with URL or query string entries?
<br>
<br>
2, Request Filtering – Multiple strings in a rule, or multiple rules?<br>
<br>
In the Peter Viola blog example he created separate Rules, each containing one deny string. Is this better than creating a single Rule containing multiple strings? Or does it make no difference.<br>
<br>
3, Request Filtering – File Extensions in Rules & case specific<br>
<br>
Am I right in thinking that if you don’t add a file extension when creating a Rule then the Rule applies to all file extensions? Is there any negative to doing this – server loading for example? Rather than, for example, limiting a Rule to .asp and .aspx<br>
<br>
Are the strings in Rules case specific? I’ve seen people cite examples like Connect( or (SeLeCt – are these handled differently to connect( CONNECT( or (select etc?<br>
<br>
4, Request Filtering – Feature Settings<br>
<br>
Maximum URL – only the part before the ? or the whole URL including the query string?<br>
<br>
The defaults for this and the Maximum QueryString seemed to be huge, can’t see a reason for query string over 250 characters apart from occasional things like encrypted callbacks?<br>
<br>
Allow unlisted verbs – I guess this is the same as the old UseAllowVerbs=0/1 in URLScan?<br>
<br>
5, Request Filtering – Verbs<br>
<br>
On the subject of verbs, is there any reason on a regular web server to accept anything other than GET, POST and HEAD?<br>
What does HEAD actually do? I have test run a bunch of sites with only GET and POST accepted and all seems to work correctly.<br>
<br>
6, Request Filtering – Headers<br>
<br>
The old URLScan configuration had ScanHeaders=Cookie: with a bunch of strings to block. Easy enough to replicate. But if creating a rule for the header “Cookie:” does checking either the “Scan URL” or “Scan query string” have any effect? Or if they are checked
do those strings then apply to headers, URLs and query strings. Or in other words, if creating header specifuc rules don’t check the boxes for “Scan URL” or “Scan query string”.<br>
<br>
7, Request Filtering – POST data<br>
<br>
Currently running Request Filtering and URLScan, and I see entries like this in my URLScan log:<br>
<br>
2018-01-06 00:04:11 zzz.zzz.zzz.zzz 36 POST /wp-content/plugins/dzs-videogallery/admin/upload.php Rejected disallowed+header request+headers transfer-encoding: -<br>
<br>
I understand that Request Filtering & URLScan do not scan POST data, so how is this being blocked? I see no URL or querysting that matches any deny strings?<br>
<br>
Also, if running Request Filtering and URLScan, and having URLScan at the bottom of the list of ISAPI Filters, Request Filtering ought to run first because it is built in. Reason for asking is I have created Rules to block the strings wp-admin and wp-content
in Request Filtering; and as this ought to run before URLScan this should have been blocked by Request Filtering before it hits URLScan?<br>
<br>
8, Dot in . path<br>
<br>
URLScan used to have a yes/no for allow / deny . in path. This would have been nice to enable, but caused endless issues with things like javascript files having names like jquery.scriptname.js.<br>
<br>
I am guessing a Deny rule for . in the querystring for .asp / .aspx would be a reasonable compromise here?
<br>
<br>
9, Request Filtering and URLScan together<br>
<br>
I’ve read articles and posts from people running both. I’m familiar with URLScan, but not yet with Request Filtering. I also find the URLScan logs very easy to read.<br>
<br>
I’m inclined to leave both running, and slowly build my knowledge with Request Filtering, and only remove URLScan where is has logged – over a long period – no malicious traffic.<br>
<br>
Other than the complications of making sure some settings are the same (maximum request length being a good example) are there any reasons against this?