Working in Expert View
While the Enforcement Level and Logging Level options that are available in Standard View encapsulate the most common configuration choices that the average user of SDVP will face, there may still be occasions when you need more granular access to the SDVP configuration settings. To do that, you will need to switch from Standard View to Expert View. This is done by pressing the Expert View button at the bottom of the Settings Manager:
This will replace the Enforcement Level and Logging Level slider controls with a strip of buttons, each of which affords access to a tab group containing several tabs worth of detailed configuration settings. Notice that the Expert View button also changes, becoming a Standard View button that you can use to change back to Standard View at any time:
The five additional tab groups you have access to in Expert View are as follows:
- Request Management
- Response Management
- Session Management
- Error Management
- Administrative Options
In addition, the Configuration Wizard also runs in a more granular mode when you are in Expert View, affording you more detailed configuration choices than it would when running in Standard View. It is also automatically launched more frequently--not just at install time, but as well when switching between modes (OFF, LOG ONLY, ON).
The following sections of the documentation cover the Expert Mode of the Configuration Wizard, and the options available in each of the five additional tab groups.
Configuration Wizard in Expert Mode
As we saw when looking at how the Configuration Wizard runs automatically immediately after installing SDVP, the wizard itself has two modes: a Standard Mode for the typical user, and an Expert Mode for those already familiar enough with SDVP to undertake a fair amount of detailed configuration up front.
While you have the option of running the Expert Mode of the Configuration Wizard when you first install SDVP, it is far more likely that you will want to take advantage of this mode of the wizard later on, after SDVP has had a chance to collect some data of its own, to supplement what it finds in your IIS logs.
To do this, make sure you are in Expert Mode and then select the Configuration Wizard menu option from the Configure menu in the SDVP Settings Manager:
When running the Configuration Wizard in Standard Mode, several configuration options are grouped together onto a single screen for convenience, under the assumption that changes to the default settings will be the exception. In Expert Mode, this summary screen is still shown, but first you will be presented with a dedicated screen for each individual configuration option:
Profiles - A Profile is an overall set of configuration options tailored to sites of a certain type. All sites that are not customized will inherit the Default Profile, which is General Public Site. There are, however, other built-in Profiles to choose from. To change a site's Profile to one more appropriate for the site, click into the Profile column, and select the alternative Profile from the pull down menu:
Optimization - This option lets SDVP optimize performance by ignoring requests for static resources like images. Applying security checks to such requests can slow down performance. Yet such files rarely pose any danger to a Web application, because by default IIS serves them up without executing any server-side code:
File Uploads - Check this option for any of your sites that need to support file uploads. If checked, SDVP will still restrict the types of files that can be uploaded to that site, but it won't categorically block all uploads, as it does by default.
404 Handling - By default, SDVP takes over 404 error handling for all sites. It does this in order to better identify and trap unfriendly robots. This means it serves its own specially-designed 404 error template, which you can customize with your site's look and feel.
Note: Some sites use custom 404 handling to run custom code (for example, to do URL rewriting). If this applies to any of your sites, be sure to uncheck this option, so that SDVP will not break the site's custom error handling mechanism.
IIS Logging - Extended IIS logging is not turned on by default in IIS. However we strongly suggest that you enable it, and thus it is enabled by default for all sites in the Advanced Mode of the Configuration Wizard. Extended IIS logging allows SDVP to better determine if anomalous requests are part of a malicious pattern, or not.
The next several screens are equivalent to those that are shown when the Configuration Wizard is run in Standard Mode, so we won't duplicate them here. In Expert Mode, however, three to four additional screens will be shown, as follows:
Methods - This screen lists the HTTP Methods that were found to be in the logs for each site, and gives a Count indicating their frequency. Disallow an individual method by clearing its checkbox:
File Types - This screen lists the File Types (by file extension) that were found to be in the logs for each site, and gives a Count indicating their frequency. Disallow individual file types by clearing their checkboxes:
Input Exceptions - This screen will only appear once SDVP has begun accumulating log data of its own. The requests listed here are those that SDVP has flagged as SQL Injections, XSS attacks, or Input Validation violations. This screen gives you an opportunity to review these security events and create Input Exceptions for any that you know to be false positives.
For an in-depth discussion of Input Exceptions, see the detailed discussion under the Contextual Exceptions topic in the LogViewer section of this document.
URL Exceptions - This screen lists URLs that are likely either innocent 404s (such as broken links) or else that represent RSS or similar feeds. Ideally, SDVP should be set to ignore such URLs since they do not present a security threat under normal circumstances. Clear the checkboxes for any of the listed URLs that you do not recognize as a legitimate feed or broken link.
The Request Management Tab Group
Input Validation | Buffer Overflow | Resources | Methods | URLs | File Uploads | Exceptions
The Request Management tab group controls all aspects of inbound HTTP traffic such as defining acceptable and unacceptable user inputs and controlling what may or may not be accessed by end-users.
- This tab controls both threat-specific and generic input sanitization features.
- The Common Threats area controls sanitization for specific threats such as SQL Injection and XSS.
- It is not recommended to disable any checks in this area that are enabled by default.
- Use Contextual Input Exceptions to prevent false positives instead.
- Note the option under XSS to allow sanitized (encoded) HTML tags by default. You may strengthen the default anti-XSS policy further by disabling this option if user input containing HTML does not need to be supported.
- The Generic Input Sanitization features add further protection by sanitizing inputs that do not fall under the rubric of any specific threat.
- The set of characters to be sanitized can be expanded using the radio buttons.
- The sanitization action can be adjusted by clicking the Change button. The options are:
- Deny the entire request contain the any characters to be sanitized (the Default option).
- Permit the request but strip out the offending characters.
- Permit the request but transform the offending characters into whitespace.
- Permit the request but transform the offending characters into their equivalent HTML entities.
- Buffer overflow protection blocks requests that contain fields in excess of the specified size limits.
- You may limit the total size of the request URL, as well as the maximum size of individual header fields subject to overflow.
- The post data limit is configured separately and should be set large enough to accommodate the largest legitimate POSTs that must be supported.
* Since such resources are typically served only by the IIS static file handler, without server-side execution of 3rd party code, excluding them from security checks can be a safe way to minimize SDVP's impact on server resources and hence performance. Use caution however if 3rd party ISAPI Filters or Wildcard Extensions are in use, as these may execute code even when processing static files.
- This tab allows restriction of the resources that can be requested based file name. Attempts to request a disallowed resource will be blocked.
- The * wildcard expression can be used to disallow entire categories of resources based on file extension.
- You can choose to specify either a Denied List of resources or else an Allowed List.
- Requests for resources not on the Denied List will be permitted by default (blacklist logic).
- Requests for resources not on the Allowed List will be blocked by default (whitelist logic).
- The Inactive Resources list is a repository of resources that have not been assigned to a Denied or Allowed list. Use the move/select controls to add these resources to a Denied or Allowed list.
- You can add resources to the Inactive Resources list by using the text box and the Add button.
- The Resource Exclusion Policy allows you to exclude from SDVP security checks all resources that are not mapped to executable handlers (DLLs or EXEs) via the IIS Application Mappings. Excluding such resources can in many cases improve site performance.*
- This tab allows restriction of the HTTP Methods that can used to request resources. These include both core HTTP Methods such as GET, HEAD and POST, as well as Extension Methods like PROPFIND and others used in Distributed Authoring (WEBDAV). Attempts to request a resource using a disallowed HTTP Method will be blocked.
- You can choose to specify either a Denied List of HTTP Methods or else an Allowed List.
- Requests made with methods not on the Denied List will be permitted by default (blacklist logic).
- Requests made with methods not on the Allowed List will be blocked by default (whitelist logic).
- The Inactive Methods list is a repository of HTTP Methods that have not been assigned to a Denied or Allowed list. Use the move/select controls to add these resources to a Denied or Allowed list.
- This tab allows rule-based restriction of the URLs that can be requested. Attempts to request a disallowed URL will be blocked.
- Within each rule, HTTP Method and Query String restrictions can optionally be applied to specific URLs.
- The * wildcard expression can be used to cover multiple URLs (or Methods or Query Strings) with a single rule.
- You can choose to specify either a Denied List of URLs or else an Allowed List.
- Requests for URLs not on the Denied List will be permitted by default (blacklist logic).
- Requests for URLs not on the Allowed List will be blocked by default (whitelist logic).
- To add a new URL rule to the list, click the Add button. To edit an existing URL rule, select it and click the Edit button. Both actions bring up the Add/Edit Denied URLs dialog.
- To remove a URL rule entirely, select it and click the Delete button. Use the Delete All button to clear the list completely.
- This tab allows rule-based restriction of file uploads that use POST and multipart/form-data encoding. Attempts to upload a disallowed file type will be blocked.
- File uploads are disallowed by default. To enable them, must select the Yes radio button.
- The Global Limit restricts the size of any given upload, regardless of type.
- The restriction rules for particular file types are based not only on file extension but also on direct examination of the uploaded content.
- You can choose to specify either a Denied List of File Types or else an Allowed List.
- Uploads containing File Types not on the Denied List will be permitted by default (blacklist logic).
- Uploads containing File Types not on the Allowed List will be blocked by default (whitelist logic).
- To add a preconfigured File Type to the Denied or Allowed list, click the Add button to bring up the File Upload Types dialog, then select the preconfigured File Type to add from the drop-down list.
- To add a new File Type to the Denied or Allowed list, click the Add New button on the File Upload Types dialog, or select an existing File Type from the list and click the Edit button. Either action brings up the Define New File Type dialog. Use this dialog to name the new File Type and designate its extension.
- To remove a File Type from the Denied or Allowed list entirely, select it and click the Delete button. Use the Delete All button to clear the list completely.
- This tab provides a listing of the currently-active User Input Exceptions.
- Individual Exceptions may be added, edited or deleted, using the appropriate buttons.
- The process of configuring individual Input Exceptions is covered extensively in the Contextual Exceptions section of this documentation.
- In particular, the Add/Edit Input Exception dialog that comes up after clicking the Add and Edit buttons is the same one that is used to configure Input Exceptions within LogViewer:
The Response Management Tab Group
Directory Browsing |
The Request Management tab group controls certain aspects of outbound HTTP traffic that may have security implications.
The Directory Browsing tab allows directory browsing to be disabled globally and then exceptions created for specific URL paths.
URL paths for which directory browsing should be permitted can be added to, edit in, and deleted from the list, using the appropriate buttons:
The Other Options tab provides miscellaneous outbound security controls.
- The Prevent HTTP Response Splitting option addresses a particular Web vulnerability that depends upon user input having programmatic access to outbound HTTP headers. You need only employ this option if such access is provided by your Web application code.
- The Block Verbose HTTP 500 Errors option suppresses inadvertent information leakage through Web application layer and/or database layer errors.
- Such errors typically have an HTTP Response Code in the 500 range.
- Provoking such errors, in order to get such information, is a primary reconnaissance tactic used by would-be attackers.
- It is highly advisable to allow SDVP to handle these errors, suppressing any details that might otherwise fall into the wrong hands.
The Session Management Tab Group
Session Policy |
Session Expiration |
IP Policy |
The Session Management tab group manages the stateful or session-based aspects SDVP's Web application security controls. These have to do with such matters as the security of application sessions, cookies, and the control of unwanted bot (automated request) traffic.
The Session Policy tab provides advanced options for further strengthening SDVP's built-in session hardening features.
- Note: Before being employed in ON Mode, all of the options on this tab should evaluated for potential false positives while in LOG ONLY mode.
- To require the user's IP address to remain the same throughout their entire browser session, check the box labeled Enforce Single IP per Session.
- To require the User-Agent header in the user's browser to remain the same throughout their entire browser session, check the box labeled Check User-Agent
- To require a same-domain Referer header, check the box labeled Check Referer.
- Use the radio buttons to scope this rule to all requests or only those issued under SSL. The latter option is less likely to result in false positives.
As part of hardening sessions against hijacking, SDVP enforces proper session expiration. The Session Expiration tab controls how this is done.
- Use the Session Timeout field to specify the maximum length of time (in seconds) that a session can remain idle and still be considered active (that is, how long a user may wait between requests and still remain logged in to the application).
- Use the radio buttons under Session Timeout Action to specify what SDVP should do when expiring a user's session:
- Use the Minimum option to expire only the user's SDVP cookie (to which their session is bound).
- Use the Extended option to also expire any cookies for which there is not an explicit Cookie Exception.
- Use the Paranoid option to expire all cookies submitted by the user's browser.
- Cookie Tampering Protection is enabled globally by default. It may be disabled by clearing the Enable Cookie Tampering Protection checkbox.
- With Cookie Tampering Protection enabled, requests are in general blocked if they contain a cookie of which SDVP was previously aware, the value of which was changed between requests.
- The Cookie Acceptance Policy governs how new cookies are dealt with by SDVP.
- New cookies are defined as those that SDVP did not observe being set originally.
- By default, such cookies are stripped from the request, but the request itself is permitted to pass through.
- Use the pull-down to select an alternative policy, such as allowing all such cookies through without modification, or rejecting the requests that contain such cookies.
- In addition to the Cookie Acceptance Policy, you can also use this tab to configure Cookie Exceptions.
- To launch the Add/Edit Cookie Exception dialog, click the Add button or select an existing Cookie Exception from the list and click Edit. This is identical to the dialog used when configuring Cookie Exceptions in LogViewer.
- The process of configuring individual Cookie Exceptions is covered extensively in the Contextual Exceptions section of this documentation.
- To remove an individual Cookie Exception list entirely, select it and click the Delete button. Use the Delete All button to remove all Cookie Exceptions.
- This tab allows for restriction of the IP addresses from which HTTP requests will be accepted. Attempts to request any resource from a disallowed IP address will be blocked at the kernel (HTTP.SYS) level.
- Use the Choose Policy Type pull-down to specify either a Denied List (blacklist) or an Allowed List (whitelist) for your IP addresses.
- If using the Denied List, requests from IP addresses on the list will be blocked, but all others will be permitted.
- If using the Allowed List, only requests from IP addresses on the Allowed List will be permitted, while all others will be blocked.
- When adding IP addresses to the Denied (or Allowed) list, you have four options. Depending on your selection, different fields will appear to be filled in with the appropriate data:
- To add a single IP address to the list, select Single IP Address from the drop-down menu and fill in the IP address.
- To add a range of IP addresses to the list, select IP Range from the drop-down menu and fill in the starting and ending IP addresses of the desired range.
- To add a CIDR block to the list, select CIDR Range from the drop-down menu and fill in the beginning IP address and its associated routing prefix.
- To add all IP addresses for a given country, select the Country option and then, from the second pull-down menu, the desired country name.
- Once the appropriate data for the new list item has been entered or selected, simply click Add to add it to the list.
- To edit or delete an IP address, range or country from the list, select it and click Edit or Delete, as desired.
This tab provides an overview of SDVP's policy for control of automated user-agents (bots).
- The bot policy settings themselves are global and so must be changed in Global Settings. To access these settings, click the Configure button. This will launch the Global Settings dialog and display its Bot Policy tab.
- You can also click the View Blacklist button to see a quick summary of the currently-blacklisted bots (these are bots that will be categorically blocked by User-Agent, regardless of their behavioral characteristics).
The Error Management Tab Group
Error Classification |
Error Blocking |
Error Templates |
Status Codes |
404 Exceptions |
The Error Management tab group is concerned primarily with how SDVP handles errors generated as a result of violations of its security controls, and secondarily with how the site or application's native errors are handled.
This tab controls how certain low severity errors are identified and handled.
- 404 errors may or may not indicate malicious activity. ServerDefender attempts to distinguish between Suspect and Presumed Innocent 404s, so that the former can be treated as possible security threats, while allowing the latter to be handled normally.
- 404s are treated as Suspect by default. The several criteria listed on this tab can be used to classify them as Presumed Innocent instead.
- By default, 404 errors are reclassified as Presumed Innocent if any of the specified criteria are met. For enhanced security, however, you can require that all specified criteria must be met before such reclassification occurs.
- 404 errors that have been reclassified as Presumed Innocent are demoted from Medium Severity to Low Severity. By default, Low Severity errors do not increase the chances of an IP address being temporarily blocked by SDVP.
- Regardless of the above settings, you can make the treatment of all low severity errors much more strict by clearing the checkbox labeled "Exclude LOW severity errors from error counts."
- Note that this will increase false positive risk for temporarily blocked IPs (i.e., the chance of innocent IPs being mistakenly blocked).
- Errors that are purely informational (severity = INFO) are never included in error counts.
Error throttling and blocking are session-oriented security controls. Rapid accumulation of errors indicates likely malicious/undesirable activity, including attacks that depend on brute forcing or error-based reconnaissance.
- The errors that count for the purposes of these controls include both those raised by SDVP as well as native HTTP error states (e.g., 500s, suspect 404s).
- The error throttling feature progressively slows down the rate of response to users who accumulate several errors within a single session.
- The first field under Error Throttling controls how many errors are permitted within a given user's session before the response rate will begin to be decreased for that user.
- The second field under Error Throttling controls the interval (in seconds) by which the response rate will be decreased with each new error.
- If a given user continues to accumulate errors, even after having their request rate throttled back, the error blocking feature will temporarily block that user's IP address.
- The first field under Error Blocking controls how many errors are permitted within a given user's session before their IP addresses will be blocked.
- The second field under Error Blocking controls the interval (in seconds) for which the IP address will remain blocked.
- When an IP address is temporarily blocked, it is added to the Blocked IPs tab, from where it may be unblocked at any time.
This tab contains the paths to the various error templates used by SDVP. There are four such templates, each of which is used for error states of a different type. All four may be customized at will, including on a per-site basis. The four templates are as follows:
- General Error Template: Used in all cases not covered by one of the other templates mentioned below.
- 404 Error Template: Used in the case of native 404 errors (i.e., 404s that would have occurred without any intervention by SDVP).
- Note the option to "Handle 404 error template content for bot/crawler defense".
- When engaged (and provided the 404 template contains the default tokens) this option causes SDVP to inject misleading content and links into 404 responses.
- This additional measure is designed to cause malicious/unfriendly bots to more quickly entrap themselves in the Error Blocking security controls.
- Session Expiry Template for LOG ONLY Mode: Used to refresh expired sessions in LOG ONLY mode. Not normally visible to ordinary users.
- Session Expiry Template for ON Mode: Used to refresh expired sessions in ON mode. Not normally visible to ordinary users.
This tab controls the status codes returned by SDVP for various types of error conditions.
- Successful attacks can be built on nothing more than subtle differences in the error states with which a Web application will respond to various "blind" exploit attempts.
- For this reason, SDVP will by default return the 404 status code not only for 404 errors but also for all native 4xx, and 5xx errors raised by a Web application. This is the optimal security policy.
- Using the radio buttons you can instead elect to allow the application's native error status codes to be passed through unchanged. Unless you have specific functionality that depends on it, this is not recommended.
- The status code returned by SDVP itself can be changed by clicking the Configure button. This will launch the Global Settings dialog and bring up its Error Handling tab.
- By default, SDVP treats requests that raise 404 errors as untrusted traffic.
- Sometimes, however, such errors may be entirely innocent, as in the case of a broken image link that appears on nearly every page of a site, but has yet to be repaired.
- For such cases, the 404 Exceptions tab can be used to configure exceptions to the default treatment of 404 errors.
- The process of adding 404 Exceptions is covered in detail in the Contextual Exceptions section of this document.
The Error Messages tab allows you to configure the strings that will be displayed for given Error Categories on SDVP's various Error Templates.
The Admin Options Tab Group
Log Management |
Log Privacy |
Remote Reporting |
URL Exceptions |
The Admin Options tab group is used to configure certain logging and reporting options, as well as the Global Bypass Exceptions that allow for selective bypassing all security controls.
The Log Management tab exposes a number of logging configuration options:
- The Log Directory field allows for relocation of the SDVP log directory for each site.
- The two "Log all events..." checkboxes allow SDVP errors to be logged to an external logging provider.
- This option differs from Alerting in that all errors are automatically logged to the external provider, not just those for which Alerts happen to be configured.
- Both Windows Event Log and SYSLOG-NG may be used as external logging providers.
- Since this feature makes use of the Alerting mechanism, you must verify the configuration of each provider by clicking the Configure button to bring up the Alert Settings dialog.
- The Verbose Logs options allow you to control the amount of data that will be accumulated in the SDVP logs and therefore displayed by default when you examine those logs in LogViewer.
- Certain error Categories that tend to be highly repetitive are provided with options allowing them to be disabled and/or limited to single log entries per session.
The Log Privacy tab provides a feature that is essential for many enterprises facing regulatory compliance issues, namely the ability to preemptively suppressed the logging of sensitive data, such as social security numbers, patience information, and the like. The controls on this tab allow you to:
- Disable the logging of all POST data (an extreme remedy that is not recommended under ordinary circumstances).
- Continue robust logging but selectively mask the log data for specific fields on specific URLs only (the preferred method of achieving log privacy).
- With the latter option you may also supply the Mask String that will be used to replace the sensitive log data.
- Use the Add, Edit, Delete, and Delete All buttons to manage entries on the list of URL/field combinations to mask.
The Remote Reporting tab controls remote access to SDVP's Web Summary Reports.
- To change the relative URLs used to access both global and site-level Web Summary Reports, click one of the Configure buttons. This will launch the Global Settings dialog and display the Report Settings tab of that dialog, where these settings may be configured.
- Use the IP Address numeric field and the Allow button to add IP addresses to the list of those allowed to view the Web Summary Reports.
- While SDVP attempts to allow local access to the reports by prepopulating this list with machine-local IP addresses, if any of the reports are not displaying correctly on the local system, the IPs listed here should be checked for accuracy.
This tab controls the Exceptions that allow requests for certain URLs to bypass all security checks. These exceptions are covered in detail in the Global Bypass Exceptions section of this document.
This tab controls the Exceptions that allow requests from certain IP addresses to bypass all security checks. These exceptions are covered in detail in the Global Bypass Exceptions section of this document.
Next: Advanced Global Settings »