Develop > Application Configuration > CML Tutorial 2 - Create a template of a web server configuration file

CML Tutorial 2 - Create a template of a web server configuration file

This tutorial explains how to use the Configuration Modeling Language (CML) to make a configuration template based upon the Microsoft Internet Information Services (IIS) Web server configuration file named UrlScan.ini. You will use the CML language to create a template file based on this file so it can be managed on a managed server.

While this tutorial will not teach you everything about CML, creating a CML template from UrlScan.ini will help you gain a fundamental understanding of CML and the process of creating a configuration template from a configuration file.

A sample of the UrlScan.ini file is listed in Sample UrlScan.ini file. The complete CML file is listed in Complete url_scan_ini.tpl CML template.

To complete this tutorial you should have the following.

  • Documentation for UrlScan.ini. This is available with the Microsoft IIS documentation.
  • The UrlScan.ini file.
  • A text editor for creating a CML file.

1. Analyzing the native configuration file and documentation

Once you have identified an application configuration file you want to manage, the first thing to do is to analyze the native configuration file and its documentation. Make sure that you understand the purpose of the configuration file, all the elements in the file and the kinds of data the configuration file manages.

This tutorial uses the UrlScan.ini file. A sample is listed in Sample UrlScan.ini file. The file UrlScan.ini enables systems administrators to configure Microsoft Internet Information Services (IIS) web server. The UrlScan.ini file consists of several sections, such as [Options], [AllowVerbs], [DenyVerbs], [DenyHeaders], [AllowExtensions], and [DenyExtensions]. Each section allows the IIS administrator to set different configurations to either allow or disallow certain kinds of HTTP requests on the IIS server. These sections do not need to be in any specific order. However, the information inside each section must be ordered. For example, the [AllowVerbs] section must be followed by specific HTTP requests that are allowed to access the web site.

UrlScan.ini contains lists of strings, such as lists of verbs and file extensions, and options that take a Boolean value of “1” for True or “2” for False.

2. Creating a CML comment block

A CML template is a simple text file named with the .tpl file extension. Use a text editor to create a new text file named Url_Scan_ini.tpl. The .tpl extension is the typical (but optional) file extension used by SA for CML templates.

Create a CML comment block at the top of the file with information about the template as follows:

@#############################################
# \system32\inetsrv\urlscan.ini (Windows)    #
# Version 1.0                                #
# Joe Author (joe_author@your_company.com)   #
##############################################@

The CML comment tag uses the following syntax:

@# <one line comment>

Or

@## <comments spanning multiple lines> 
	<comments spanning multiple lines> #@

3. Creating CML setup instructions

The setup section instructs the parser how to interpret the CML file. The namespace, filename-key and filename-default instructions are required for all CML files. The other instructions shown below are optional. These instructions define whitespace handling, Boolean values, comment formats and ordering rules.

To create the basic setup section, enter the following information after the comment block in the CML template:

@!namespace=/security/@
@!filename-key="/test";filename-default="/c/UrlScan.ini"@ 
@!optional-whitespace@
@!boolean-yes-format="1";boolean-no-format="0"@
@!line-comment-is-semicolon@
@!unordered-lines@

Notice that each CML instruction tag starts with the characters “@!” and ends with the character “@”.

The following line combines two CML instructions on one line:

@!filename-key="/test";filename-default="/c/UrlScan.ini"@

This line could also be written as two separate lines as follows:

@!filename-key="/test"@
@!filename-default="/c/UrlScan.ini"@

Setup instructions

The following figure explains setup instructions.

CML template setup instructions

CML Tag

Description

@!namespace=/security/@

The @!namespace instruction defines the name space that will be used by this CML template. This defines where in the database the values used by this CML template will be stored. Each CML template should use its own name space so names do not collide with other template.

In this example, the name space is /security. All value sets will be stored in this name space.

@!filename-key="/files/urlscan_ini";filename-default="/c/urlscan.ini"@

The @!filename-key instruction defines the location in the name space where the file name will stored. If the value starts with a “/”, it defines a separate name space. If the value does not start with a “/”, it will be appended to the name space defined by the @!namespace instruction.

In this example, the default file name will be stored in the database under the name space “/file/urlscan-ini”.

The @!filename-default instruction defines the default path where the native configuration file will be saved on the server. This path can be changed using the SA Client.

In this example, when the configuration file is pushed to a managed server, it will be placed in /c/urlscan.ini.

Note that the path names use only forward slashes.

@!optional-whitespace@

This instruction indicates that whitespace is optional between items in the configuration file. For example, either of the following entries would be valid if this option is set:

Key = "value"

Key="value"

@!boolean-yes-format="1";boolean-no-format="0"@

This instruction defines the allowable Boolean values in the configuration file. In this case, true is indicated with the character 1, and false is indicated with a 0. Any other values for Booleans will not be allowed.

@!line-comment-is-semicolon@

Instructs the parser to ignore anything that follows a semicolon in the configuration file. This allows comments in the native configuration file using the semicolon before each comment.

@!unordered-lines@

Instructs the parser that the sections in the configuration file can be in any order. If you used ordered-lines, then the configuration file would have to conform to the order of the template.

4. Defining the [Options] section — Opening blocks

Now you are ready to add CML instructions to the template. The first section of the UrlScan.ini file you will model in CML is the [Options] section, which contains several options for the configuration file.

In CML, if a section of information in a configuration file has more than one kind of data (data that needs to be read differently by the CML parser), you can open “blocks” to handle each section of information separately. Typically, you open a block in CML to define special parser rules for a section of the CML file. The [Options] section has two “blocks” of information: the title of the section which is just “[Options]” and all the options in that section. Since these blocks belong together, you will set them at different levels, the first block (the title of the section) at level one, and the second block (the contents of the section) at level two. Nesting the blocks in this manner keeps the sections within the block together when read by the parser.

  1. To define the [Options] section, enter the following lines:

    @1[;optional;ordered-lines@
[Options]
@2[;unordered-lines@
  2. In the UrlScan.ini file the [Options] section contains a list of key-value pairs. Use the block tag ([) set at two levels because there are two kinds of data in this section: a heading and a list of key-value pairs. The first level block handles the text string “[Options]” while the second level block handles all of the key-value pairs in that section.

The following table explains how to open two block levels for the [Options] section.

Marking up the start of the [Options] section

CML tag

Description

@1[;optional;ordered-lines@

The number 1 sets the first level of the multiline block.

[
The square bracket opens a new block.

optional
Indicates that this entire block is optional in the configuration file.

ordered-lines
Indicates that whatever follows this tag (the string [Options]) must come first in the native UrlScan.ini configuration file. In other words, the title [Options] must appear before the actual options.

[Options]

The string that names the section in the native configuration file. This string will appear in the configuration file.

@2[;unordered-lines@

The number 2 sets the second level of the block.

[
The square bracket opens a new block, in this case a level 2 block, nested within the previous level 1 block.

unordered lines
Indicates that the lines that follow [Options] within the block can be in any order in the configuration file. That is, all the key-value pairs in the [Options] section can be in any order.

Next, you will define all the options that can appear in the [Options] section of the configuration file. Most of these entries use the CML replace tag, because they are simple key-value pairs that allow you to replace a single value. The following table explains the CML for each option.

Marked up key-value pairs from UrlScan.ini [Options] section

CML Tag

Description

AllowDotInPath = @allow_dot_in_path;boolean@

Note: All of the key-value pairs use some variation of the following syntax (unless otherwise indicated):

string literal = @source;type@

The string literal defines the actual option name that will appear in the configuration file. The source is the location in the database where the value will be stored in the value set. The type is the type of data that will be stored in the value set.

@allow_dot_in_path
This string defines the name space path in which to store this value. In this example, the name space is relative, which means that it will be appended to the name space that you defined in the header of the template (@!namespace=/security/@) and will store the value in that name space location. That is, the value will be stored in the database at the key /security/allow_dot_in_path.

You could also write this tag as follows:
AllowDotInPath = @/security/allow_dot_in_path;boolean@

boolean

Since the key-value pair type is Boolean, the CML type: boolean is used. Note that since the header of this template defined the Boolean true value as 1, when the IIS administrator sets the value set, they would need to enter a 1 to allow dots in the path of the IIS server.

AllowHighBitCharacters = @allow_high_bit_characters;boolean@

Similar to the previous example, AllowHighBitCharacters is the option that appears in the configuration file, allow_high_bit_characters is the relative name space path, and boolean is the data type.

This IIS option allows users to choose whether or not high bit characters are acceptable in a URL, indicated by a 1 for true and 0 for false in the configuration file.

AllowLateScanning = @allow_late_scanning;boolean@

Allows the IIS administrator to choose whether or not late scanning of a URL is acceptable. Defines a name space location to store the value. boolean indicates this key can be 1 for true and 0 for false in the configuration file.

AlternateServerName = @alternate_servername@

Defines a name space location where an alternate server name can be stored when entered by the user or read in from a configuration file. Since no type is specified, the default is a string type.

EnableLogging = @enable_logging;boolean@

Allows users to turn on logging, indicated by 1 for true and 0 for false in the configuration file.

LoggingDirectory = @logging_directory;dir@

Allows users to choose a directory to store log files, if logging has been turned on. The type dir indicates a directory.

LogLongURLs = @log_long_urls;boolean@

Allows users to choose whether or not to log URLs that access the server, specified by 1 for true and 0 for false in the configuration file.

NormalizeUrlBeforeScan = @normalize_url_before_scan;boolean@

Allows users to choose whether or not to normalize the URL before it is read by the server, indicated by 1 for true and 0 for false in the configuration file.

PerDayLogging = @per_day_logging;boolean@

Allows users to choose to turn on per day logging, indicated by 1 for true and 0 for false in the configuration file.

PerProcessLogging = @per_process_logging;boolean@

Allows users to turn on or off per process logging, indicated by 1 for true and 0 for false in the configuration file.

RejectResponseUrl =

@reject_response_url;string;r”(HTTP_URLSCAN_STATUS_HEADER)|(HTTP_URLSCAN_ORIGINAL_VERB)|(HTTP_URLSCAN_ORIGINAL_URL)”;optional@

Syntax:

string literal = @source;type;r”regular expression”;option@

reject response
String literal that defines the path where the strings will be stored in the name space.

string
Indicates that the data type for the reject URL request is a string.

r”
This is a string range specifier that introduces a regular expression. In this case, a range of string literals.

(HTTP_URLSCAN_STATUS_HEADER)|(HTTP_URLSCAN_ORIGINAL_VERB)|(HTTP_URLSCAN_ORIGINAL_URL)”
The string literals (rejected URL responses) to be read by the parser: the status header, original verb, and original URL.

optional
Indicates that this value is optional. That is, the RejectResponseUrl option may be omitted from the UrlScan.ini file.

RemoveServerHeader = @remove_server_header;boolean@

Allows users to turn on or off the RemoveServerHeading feature. When activated (set to 1), the reject response sent to the client will remove the server header in the message. This setting is indicated by 1 for true and 0 for false in the configuration file.

UseAllowVerbs = @use_allow_verbs;boolean@

Allows users to turn on or off the UseAllowVerbs feature. When activated (set to 1), the server will reject any request to the server that contains an HTTP verb that is not explicitly listed in the AllowVerbs section of the UrlScan.ini file. Indicated by 1 for true and 0 for false in the configuration file.

UseAllowExtensions = @use_allow_extensions;boolean@

Allows users to turn on or off the UseAllowExtension feature. When activated (set to 1), the server will reject any request to the server that contains a file extension that is not explicitly listed in the AllowExtension section of the UrlScan.ini file. Indicated by 1 for true and 0 for false in the configuration file.

UseFastPathReject = @use_fast_path_reject;boolean@

Allows users to turn on or off the UseFastPathReject feature. When activated (set to 1), the server ignores the RejectResponseUrl option and returns a short 404 response to the client when a URL is rejected. Indicated by 1 for true and 0 for false in the configuration file.

VerifyNormalization = @verify_normalization;boolean@

Allows users to turn on or off normalization of all URLs scanned by UrlScan.ini. When activated (set to 1), the URL is normalized before being scanned. Indicated by 1 for true and 0 for false in the configuration file.

5. Defining the [AllowExtensions] section - Closing a block by opening a new block

Now that you have defined all of the options in the [Options] section of the UrlScan.ini file, you are ready to start defining the next section, [AllowExtensions]. Remember that to start the [Options] section you had to open a two-level block to account for two levels of information — the title of the [Options] section and its contents.

Before you can start defining the [AllowExtensions] section, you need to close the previous section by closing the CML block. With CML, you can close a block explicitly with the “]” tag, or by opening a new block at a higher level (specified by a lower number) or at an equal level. In this task, you will open the new block for the [AllowExtensions] the same way you opened a block for the [Options] section, by starting a new level 1 block. This automatically closes the blocks opened by the [Options] section.

To open a new block and define the [AllowExtensions] section:

  1. After the last line of the [Options] section, enter the following to open the new block for the [AllowExtensions] section: 

    @1[;optional;ordered-lines@
[AllowExtensions]
@2[;unordered-lines@

     

    The following table explains how opening a new two level block closes the previous block.

    Starting a New Block for the [AllowExtensions] Section

    CML Tag

    Description

    @1[;optional;ordered-lines@

    The number 1 opens a new level one block. Because it is a number 1 level block, which is at a higher level than the previous block (a level two block for the key-value pairs in the [Options] section) and equal to the level 1 block before that, it will close the two blocks that came before it.

    Note that you can explicitly close a block by using the close block tag. For example:
    @2]@

    [
    CML block tag that opens a new block.

    optional
    Indicates that this entire block is optional and not required to be in the configuration file.

    ordered-lines
    Indicates that whatever follows this tag (the string [AllowExtensions] has to come first in the native UrlScan.ini configuration file. In other words, you could not list all the options in the native file and then the title. [AllowExtensions] has to come first. In CML, the ordered-line element determines this order.

    [AllowExtensions]

    The literal string that names the section in the native configuration file.

    @2[;unordered-lines@

    The number 2 sets the second level of the block.

    [

    CML block symbol that opens a new block.

    unordered lines
    Indicates that all the lines that follow [AllowExtensions] within the block can be in any order in the configuration file. That is, all the key-value pairs in the [AllowExtensions] section can be in any order.

  2. Next, because the [AllowExtensions] section of the UrlScan.ini file can contain any list of file extensions entered by the user, you will use a CML loop and loop target tag to instruct the parser to read the information in this section one line at a time. Immediately after the last @2[;unordered-lines@ text from the last step, enter the following text: 

    @*allow_extension;unordered-string-set@
.@.@

    The following table explains the how the loop and loop target CML tags work:

    Loop and loop target CML tags

    CML tag

    Description

    @*allow_extension;unordered-string-set@

    Syntax

    @<level><tag type><name>;<data type>;<options>@

    The loop tag (*) will loop and read over the unordered string set listed in the [AllowExtensions] section.

    allow_extension
    String that defines the path where the strings will be stored in the name space.

    unordered-string-set
    Indicates that the list of strings do not have to be in any specific order.

    .@.@

    First ( . )

    In this section, this unordered string set that the parser reads is a list of file extensions listed in the [AllowExtensions] section that start with a ( . ) character.

    @.@

    Loop target tag ( . ) instructs the parser to read everything in this list that starts with a period character.
  3. Save the file.

6. Defining the [DenyExtensions] section

Next you define the [DenyExtensions] section of the UrlScan.ini file the same way you defined the [AllowExtensions] section. You will open a new level one block, which closes the previous block from the [AllowExtensions] section. Then you will open a level two block from which you will instruct the parser to read an unordered list of all file extensions beginning with a (.) that you want to block using UrlScan.ini.

The CML for the [DenyExtensions] section looks like this:

@1[;optional;ordered-lines@
[DenyExtensions]
@2[;unordered-lines@
@*deny_extension;unordered-string-set@
.@.@

7. Defining the [AllowVerbs] and [DenyVerbs] sections

The next two sections of the UrlScan.ini file follow the same CML you used for [DenyExtensions] in the previous sections. You open a first level block to close the previous block, which will also parse the following text as an ordered line.

Then you open a second level block that reads the following list of unordered strings — in other words, a list of verbs. In these two sections, the string instructs the parser to read the list of verbs you want to allow into your web site and a list of verbs you want to deny access to your web site.

The CML for both of these sections is as follows: 

@1[;optional;ordered-lines@
[AllowVerbs]
@2[;unordered-lines@
@*allow_verb;unordered-string-set@
@.@

@1[;optional;ordered-lines@
[DenyVerbs]
@2[;unordered-lines@
@*deny_verb;unordered-string-set@
@.@
 

8. Defining the [DenyHeaders] section

Next you define the [DenyHeaders] section of the UrlScan.ini file, which allows you to configure IIS to deny specific HTTP request headers.

This section is similar to the previous sections in that you open two blocks for strings. However, you will separate the list of HTTP headers listed in the UrlScan.ini file by a colon, using a CML sequence delimiter. Since HTTP request headers contain a colon (:), you need to use a sequence delimiter to tell the parser to read each line in the section so when it encounters a colon (:), it will move on to the next entry.

For example, the list of HTTP headers to be denied listed in the UrlScan.ini file might read:

Translate:
If:
Lock-Token:

Because each header request listed in the configuration file ends with a (:), you need to instruct the parser to recognize the (:) as the end of an entry.

  1. To define the [DenyHeaders] section, after the last line of the [DenyVerbs] section, enter the following text to open the new block for the [DenyHeaders] section:

    @1[;optional;ordered-lines@
    [DenyHeaders]
    @2[;unordered-lines@

    As in previous sections, these tags open a level one block to be read as an ordered line, then they open a second level block to be read as unordered lines.

  2. Next enter the following CML loop and loop target tags to instruct the parser to read through the list of header requests:

    @*deny_header;unordered-string-set;;sequence-delimiter=":"@
    @.@:

    The following table describes the syntax of these two tags.

    Loop and Loop Target Tags for the [DenyHeaders] Section

    CML tag

    Description

    @*deny_header;unordered-string-set;;sequence-delimiter=":"@

    *
    Indicates a loop CML tag that will read through the list of strings.

    deny_header
    String literal that defines the path where the strings will be stored in name spacename space.

    unordered-string-set
    Indicates that the list of strings can be listed in any order.

    ;
    The first semicolon separates the two sections of the tag.

    ;
    The second semicolon allows you to enter the following colon ( : ) sequence delimeter without it being interpreted as a range.

    sequence-delimiter=":"
    Instructs the parser to read a colon ( : ) as part of the string and the point at which to move on to the next entry.

    @.@

    Loop target tag instructs the parser to store these values into the deny_header name space location. For example: /security/deny_header.

    :

    The final colon (:) tells the parser that each item in this list will be followed by a colon. That is, this character will be stored as a part of the entry for a denied header.

  3. Save the file.

9. Defining the [DenyURLSequences] section

Define the [DenyUrlSequence] similar to the [DenyHeader] section. Open two blocks that will be read for order and unordered strings. However, for this section you will separate the list of URL sequences in the template with a field delimiter. The field delimiter used here will be an end of line element which instructs the parser to stop reading an entry when it encounters the end of a line.

To define the [DenyUrlSequence] section:

  1. After the last line of the [DenyUrlSequence] section, enter the following text to open the new block for the [DenyUrlSequence] section:

    @1[;optional;ordered-lines@
    [DenyUrlSequence]
    @2[;unordered-lines@

    As in previous sections, these tags open a level one block to be read as an ordered line, then they open a second level block to be read as unordered lines.

  2. Next type the following CML loop and loop target tags to instruct the parser to read through the list of URL sequences to be denied:
    @*deny_url_sequence;unordered-string-set;;field-delimiter-is-eol@
    @.@

    The following table describes the syntax of these tags.

    TLoop and Loop Target Tags for the [DenyUrlSequence] Section

    CML Tag

    Description

    @*deny_url_sequence;unordered-string-set;;field-delimiter-is-eol@

    *
    Indicates a loop CML tag that reads through the list of strings.

    deny_url_sequence
    String literal that defines the path where the string will be stored in the name space.

    unordered-string-set
    Indicates that the list of strings can be listed in any order.

    ;
    The first semicolon separates the two sections of the tag.

    ;
    The second semicolon allows you to enter the following field delimeter without it being interpreted as a range.

    field-delimiter-is-eol
    Instructs the parser to read the next entry up to the end of the line.

    @.@

    Loop target tag instructs the parser to store these values into the deny_url_sequence name space location. For example: /security/deny_url_sequence.

  3. Save the file.

10. Defining the [RequestLimits] section

Defining the [RequestsLimits] is very similar to the way you defined the [DenyUrlSequence] section. Open two blocks that will be read for order and unordered strings. But for this section, after you open both blocks, you will use the CML replace tag to define three key-value pairs.

To define the [RequestsLimits] section:

  1. After the last line of the [RequestsLimits] section, enter the following text to open the new block for the [RequestsLimits] section:

    @1[;optional;ordered-lines@
    [RequestsLimits]
    @2[;unordered-lines@

    As in previous sections, these tags open a level one block to be read as an ordered line, then open a second level block to be read as unordered lines. Recall that by starting the new first level block, you are closing the previous second level block from the {DenyUrlSequence] section.

  2. Next, type the following CML replace tags to define the three key-value pairs found in the [RequestsLimits] section:

    MaxAllowedContentLength = @max_allowed_content_length;int@
    MaxUrl = @max_url;int@
    MaxQueryString = @max_query_string;int@
    @1]@

    The following table describes the syntax of these tags.

    Loop and loop target tags for the [DenyUrlSequence] section

    CML Tag

    Description

    MaxAllowedContentLength = @max_allowed_content_length;int@

    MaxAllowedContentLength
    Request limit parameter string from the configuration file.

    max_allowed_content_length
    String literal that defines the path where the value will be stored in the name space.

    int
    Indicates that the value to be stored is an integer.

    MaxUrl = @max_url;int@

    MaxUrl
    Request limit parameter string from the configuration file.

    max_url
    String literal that defines the path where the value will be stored in the name space.

    int
    Indicates that the value to be stored is an integer.

    MaxQueryString = @max_query_string;int@

    MaxQueryString
    Request limit parameter string from the configuration file.

    max_query_string
    String literal that defines the path where the value will be stored in the name space.

    int
    Indicates that the value to be stored is an integer.

    @1]@

    This level one block tag closes the block.

  3. Save the file.

11. Placing the template in an Application Configuration

Now that you have created the CML template for UrlScan.ini and saved it as url_scan_ini.tpl, you are ready to do the following tasks:

These steps are described in CML Tutorial 1 - Create an Application Configuration for a simple web app server.

Sample UrlScan.ini file

Below is a sample UrlScan.ini file.

[Options]
UseAllowVerbs=1                ; If 1, use [AllowVerbs] section, else use the
                               ; [DenyVerbs] section.   The default is 1.
 
UseAllowExtensions=0           ; If 1, use [AllowExtensions] section, else
                               ; use the [DenyExtensions] section. The
                               ; default is 0.
 
NormalizeUrlBeforeScan=1       ; If 1, canonicalize URL before processing.
                               ; The default is 1. Note that setting this
                               ; to 0 will make checks based on extensions,
                               ; and the URL unreliable and is therefore not
                               ; recommend other than for testing.
 
VerifyNormalization=1          ; If 1, canonicalize URL twice and reject
                               ; request if a change occurs. The default
                               ; is 1.
 
AllowHighBitCharacters=0       ; If 1, allow high bit (ie. UTF8 or MBCS)
                               ; characters in URL. The default is 0.
 
AllowDotInPath=0               ; If 1, allow dots that are not file
                               ; extensions. The default is 0. Note that
                               ; setting this property to 1 will make checks
                               ; based on extensions unreliable and is
                               ; therefore not recommended other than for
                               ; testing.
 
RemoveServerHeader=1           ; If 1, remove the 'Server' header from
                               ; response. The default is 0.
 
EnableLogging=1                ; If 1, log UrlScan activity. The
                               ; default is 1. Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.
 
PerProcessLogging=0            ; This property is deprecated for UrlScan
                               ; 3.0 and later. UrlScan 3.0 and later can
                               ; safely log output from multiple processes
                               ; to the same log file. Changes to this
                               ; property will not take effect until
                               ; UrlScan is restarted.
 
AllowLateScanning=0            ; If 1, then UrlScan will load as a low
                               ; priority filter. The default is 0. Note
                               ; that this setting should only be used in
                               ; the case where there another installed
                               ; filter is modifying the URL and you wish
                               ; to have UrlScan apply its rules to the
                               ; rewritten URL. Changes to this property
                               ; will not take effect until UrlScan is
                               ; restarted.
 
PerDayLogging=1                ; If 1, UrlScan will produce a new log each
                               ; day with activity in the form
                               ; 'UrlScan.010101.log'. If 0, UrlScan will
                               ; log activity to urlscan.log. The default
                               ; is 1. Changes to this setting will not
                               ; take effect until UrlScan is restarted.
 
UseFastPathReject=0            ; If 1, then UrlScan will not use the
                               ; RejectResponseUrl. On IIS versions less
                               ; than 6.0, this will also prevent IIS
                               ; from writing rejected requests to the
                               ; W3SVC log. UrlScan will log rejected
                               ; requests regardless of this setting. The
                               ; default is 0.
 
LogLongUrls=0                  ; This property is deprecated for UrlScan 3.0
                               ; and later. UrlScan 3.0 and later will
                               ; always include the complete URL in its log
                               ; file.
 
UnescapeQueryString=1          ; If 1, UrlScan will perform two passes on
                               ; each query string scan, once with the raw
                               ; query string and once after unescaping it.
                               ; If 0, UrlScan will only look at the raw
                               ; query string as sent by the client. The
                               ; default is 1. Note that if this property is
                               ; set to 0, then checks based on the query
                               ; string will be unreliable.
 
RejectResponseUrl=
 
LoggingDirectory=Logs
 
[AllowVerbs]
 
;
; The verbs (aka HTTP methods) listed here are those commonly
; processed by a typical IIS server.
;
; Note that these entries are effective if "UseAllowVerbs=1"
; is set in the [Options] section above.
;
 
GET
HEAD
POST
 
[DenyVerbs]
 
;
; The verbs (aka HTTP methods) listed here are used for publishing
; content to an IIS server via WebDAV.
;
; Note that these entries are effective if "UseAllowVerbs=0"
; is set in the [Options] section above.
;
 
PROPFIND
PROPPATCH
MKCOL
DELETE
PUT
COPY
MOVE
LOCK
UNLOCK
OPTIONS
SEARCH
 
[DenyHeaders]
 
;
; The following request headers alter processing of a
; request by causing the server to process the request
; as if it were intended to be a WebDAV request, instead
; of a request to retrieve a resource.
;
 
Translate:
If:
Lock-Token:
Transfer-Encoding:
 
[AllowExtensions]
 
;
; Extensions listed here are commonly used on a typical IIS server.
;
; Note that these entries are effective if "UseAllowExtensions=1"
; is set in the [Options] section above.
;
 
.htm
.html
.txt
.png
.png
.png
 
[DenyExtensions]
 
;
; Extensions listed here either run code directly on the server,
; are processed as scripts, or are static files that are
; generally not intended to be served out.
;
; Note that these entries are effective if "UseAllowExtensions=0"
; is set in the [Options] section above.
;
; Also note that ASP scripts are denied with the below
; settings. If you wish to enable ASP, remove the
; following extensions from this list:
;    .asp
;    .cer
;    .cdx
;    .asa
;
 
; Deny executables that could run on the server
.exe
.bat
.cmd
.com
 
; Deny infrequently used scripts
.htw     ; Maps to webhits.dll, part of Index Server
.ida     ; Maps to idq.dll, part of Index Server
.idq     ; Maps to idq.dll, part of Index Server
.htr     ; Maps to ism.dll, a legacy administrative tool
.idc     ; Maps to httpodbc.dll, a legacy database access tool
.shtm    ; Maps to ssinc.dll, for Server Side Includes
.shtml   ; Maps to ssinc.dll, for Server Side Includes
.stm     ; Maps to ssinc.dll, for Server Side Includes
.printer ; Maps to msw3prt.dll, for Internet Printing Services
 
; Deny various static files
.ini     ; Configuration files
.log     ; Log files
.pol     ; Policy files
.dat     ; Configuration files
.config  ; Configuration files
 
[DenyUrlSequences]
;
; If any character sequences listed here appear in the URL for
; any request, that request will be rejected.
;
 
..  ; Don't allow directory traversals
./  ; Don't allow trailing dot on a directory name
\   ; Don't allow backslashes in URL
:   ; Don't allow alternate stream access
%   ; Don't allow escaping after normalization
&   ; Don't allow multiple CGI processes to run on a single request
 

Complete url_scan_ini.tpl CML template

Below is the complete url_Scan_ini.tpl template.

@#############################################
# \system32\inetsrv\urlscan.ini (Windows)    #
# Version 1.0                                #
# Joe Author (joe_author@your_company.com)   #
##############################################@

@!namespace=/security/@
@!filename-key="/test";filename-default="/c/UrlScan.ini"@ 
@!optional-whitespace@
@!boolean-yes-format="1";boolean-no-format="0"@
@!line-comment-is-semicolon@
@!unordered-lines@

@###########################################
# Begin data                               #
###########################################@

@1[;optional;ordered-lines@
[Options]
@2[;unordered-lines@
AllowDotInPath = @allow_dot_in_path;boolean@
AllowHighBitCharacters = @allow_high_bit_characters;boolean@
AllowLateScanning = @allow_late_scanning;boolean@
AlternateServerName = @alternate_servername@
EnableLogging = @enable_logging;boolean@
LoggingDirectory = @logging_directory;dir@
LogLongURLs = @log_long_urls;boolean@
NormalizeUrlBeforeScan = @normalize_url_before_scan;boolean@
PerDayLogging = @per_day_logging;boolean@
PerProcessLogging = @per_process_logging;boolean@
RejectResponseUrl =
@reject_response_url;string;r”(HTTP_URLSCAN_STATUS_HEADER)|(HTTP_URLSCAN
_ORIGINAL_VERB)|(HTTP_URLSCAN_ORIGINAL_URL)”;optional@
RemoveServerHeader = @remove_server_header;boolean@
UnescapeQueryString = @unescape_query_string;boolean@
UseAllowVerbs = @use_allow_verbs;boolean@
UseAllowExtensions = @use_allow_extensions;boolean@
UseFastPathReject = @use_fast_path_reject;boolean@
VerifyNormalization = @verify_normalization;boolean@

@1[;optional;ordered-lines@
[AllowExtensions]
@2[;unordered-lines@
@*allow_extension;unordered-string-set@
.@.@

@1[;optional;ordered-lines@
[DenyExtensions]
@2[;unordered-lines@
@*deny_extension;unordered-string-set@
.@.@

@1[;optional;ordered-lines@
[AllowVerbs]
@2[;unordered-lines@
@*allow_verb;unordered-string-set@
@.@

@1[;optional;ordered-lines@
[DenyVerbs]
@2[;unordered-lines@
@*deny_verb;unordered-string-set@
@.@

@1[;optional;ordered-lines@
[DenyHeaders]
@2[;unordered-lines@
@*deny_header;unordered-string-set;;sequence-delimiter=":"@
@.@:

@1[;optional;ordered-lines@
[DenyURLSequences]
@2[;unordered-lines@
@*deny_url_sequence;unordered-string-set;;field-delimiter-is-eol@
@.@

@1[;optional;ordered-lines@
[RequestLimits]
@2[;unordered-lines@
MaxAllowedContentLength = @max_allowed_content_length;int@
MaxUrl = @max_url;int@
MaxQueryString = @max_query_string;int@
@1]@

 

Send Help Center feedback