Edge-Level Protection

Previous Section
Next Section

Edge-Level Protection

Edge, or network, level protection brings with it many appealing factors, not the least of which are:

  • A solution that protects multiple back-end target applications

  • A solution without having to engage the dangers of touching legacy code, foreign code, or messing with production systems

Web Application Firewalls

Web Application Firewalls (WAF) are also Reverse Proxy servers. They are fast becoming the choice method for offering deep application security. They come in the form of hardware appliances (with embedded code) or software. As of late some are even integrated with Web application accelerator appliances and load balancers as well. The Reverse Proxy aspect of these devices is critical because it means that sockets from the Internet cannot be directly established to the true web server host. That, in and of itself, is a level of protection.

WAFs are intrusive in that they inspect every request and response flowing through them. They generally focus on the following:

  • HTTP(S)

  • Web services

    • SOAP

    • XML-RPC

Some WAF products look for very specific “attack signatures” to try to identify attacks. Others work on the anomaly model looking for abnormal behavior that deviates from some pattern.

Evaluation Criteria

When analyzing WAF products, an excellent source of criteria is the Web Application Firewall Evaluation Criteria (WAFEC) donated to the public through the Web Application Security Consortium. You can find the latest version at http://www.webappsec.org/projects/wafec/. It is a thorough document that is the production of some of the greatest minds in the industry. You can use the data as a checklist to evaluate any products you are interested in.


Ivan Ristic’s ModSecurity is an open source WAF. It is flexible in that it can operate as an Apache HTTPD module or as a stand-alone entity. Moreover, it does not care about the platform on the back end — it will protect based on the given ruleset. The purpose of this WAF is to increase Web application security, protecting Web applications from known and unknown attacks. So if your target is an Apache shop, you may want to implement something like this for a serious enhancement on the Web app side. If they are not you could always consider running this software as a Reverse Proxy server. There is an excellent article explaining this at http://www.securityfocus.com/infocus/1739.

The documentation is excellent and you can find it at http://www.modsecurity.org/documentation/. You would do well to become familiar with this very powerful piece of software. It represents a seamless approach to remediation in which you may not have to touch troubled code. The software follows the following workflow to achieve its goal:

  1. Parses all requests flowing through it

  2. Performs canonicalization, built-in checks and anti-evasion functionality

  3. Executes input filtering against the data in the rulesets

  4. Executes output rules and logs any relevant data

The software uses Regular Expressions (regex) in its rule definitions and comes with some pre-built sets. Some generic rulesets are also being developed — you can see them at http://www.modsecurity.org/projects/rules/index.html. Here is a taste of the type of protective measures that can be achieved by using the built-in ruleset with the ModSecurity software:

# Catch commonly used non-browser clients
SecFilterSelective HTTP_User-Agent "(libwhisker|paros|wget|libwww|perl|curl|java)"
## -- XSS Attacks --------------------------------------------------------
SecFilterSignatureAction "log,pass,msg:'XSS attack'"

SecFilterSelective ARGS "alert[[:space:]]*\("
SecFilterSelective ARGS "&#[[0-9a-fA-F]]{2}"
SecFilterSelective ARGS "eval[[:space:]]*\("
SecFilterSelective ARGS "onKeyUp"
SecFilterSelective ARGS "\x5cx[0-9a-fA-F]{2}"
SecFilterSelective ARGS "fromCharCode"
SecFilterSelective ARGS "&\{.+\}"

SecFilterSelective ARGS "<.+>"
SecFilterSelective ARGS "javascript:"
SecFilterSelective ARGS "vbscript:"

SecFilterSelective ARGS_VALUES "jsessionid"
SecFilterSelective ARGS_VALUES "phpsessid"
## -- Command execution --------------------------------------------------
SecFilterSignatureAction "log,pass,msg:'Command execution attack'"

#SecFilterSelective ARGS_VALUES "^(uname|id|ls|cat|rm|kill|mail)"
#SecFilterSelective ARGS_VALUES "^(ls|id|pwd|wget)"
SecFilterSelective ARGS_VALUES ";[[:space:]]*(ls|id|pwd|wget)"

## -- LDAP injection -----------------------------------------------------
SecFilterSignatureAction "log,pass,msg:'LDAP injection attack'"

SecFilterSelective ARGS "objectClass"
SecFilterSelective ARGS "objectCategory"
SecFilterSelective ARGS "\)\(\|"
SecFilterSelective ARGS "\)\(!"
SecFilterSelective ARGS "\)\(&"

If you focus, for instance, on LDAP Injection or XSS attack sections in the preceding snippet you will see the criteria that ModSecurity will use to determine if any malicious activity is taking place. Take that same data with you and cross-check it against some of the attack signatures in Appendix D and you will see how just the built-in ruleset of this software starts to provide instant protection or at least detection. When coupled with the filtering engine, every incoming request is intercepted and analyzed against the rules before a handling decision is made. Whenever there is a positive match, action is taken.

You can work tightly with the target app and build out a ruleset to provide custom protection. For example, say your target uses a query string parameter that you verify can only handle data that is alphanumeric and 32 characters long. You could then write a custom filter rule as follows:

SecFilterSelective QUERY_STRING "!^[0-9a-fA-F]{1,32}$" "deny,log,status:406"

This line would also set the action (specific to this individual rule) to deny any request that triggers a hit on this rule, log it, and send back a status code 406 response (HTTP_NOT_ACCEPTABLE). Obviously you would be constructing your rules and action base along with your target client. You can also set a default action for an entire block of rules. For example, say you want to use the action from the custom rule for multiple rules then set the following before the rules:

SecFilterDefaultAction "deny,log,status:406"

The installation of this software is fully dependent on your choices and your target. Due to this highly subjective fact it is not covered here. The documentation of the product is excellent and you will find everything you need there. Moreover, there are some binary packages you may find beneficial depending on your goal. They are at http://www.modsecurity.org/download/index.html.

Rules for ModSecurity are starting to show up and some people are doing some solid work in building some of these. You can find a great selection at http://www.gotroot.com/tiki-index.php?page=mod_security+rules. And you can also get some online assistance generating your own rules at http://leavesrustle.com/tools/modsecurity/.

One last note on this amazing gem of free software: in the current tarball (version 1.9.2) there is a directory called “util.” There you will find an awesome little set of tools that you may want to put to use. Their usage is once again dependent on your goals and your target, but look through them. There are, for example, Perl scripts there that convert Snort rules and Nessus plug-ins (.nasl) into the mod_security rule format. Depending on your target this could prove to be very beneficial and you can use them in working closely with your target’s security team to provide a very deep level of protection specific to them.


UrlScan (http://www.microsoft.com/technet/security/tools/urlscan.mspx) is an IIS-specific product (ISAPI filter) created by Microsoft. This ISAPI filter basically runs on an IIS server and allows it to reject requests that don’t meet some criteria defined in the urlscan.ini file. Now, if your target environment is IIS 4 or 5 based you need to seriously look into implementing UrlScan. Prior to version 6, IIS data parsing wasn’t as strong as it should have been. UrlScan features such as NormalizeURLBeforeScan, VerifyNormalization, and AllowDotInPath give the older IIS versions some ability to protect themselves from some exploits. IIS 6 comes with a completely overhauled data-parsing engine, which focuses on stronger enforcement of HTTP protocol standards. Consequently, you don’t need to use UrlScan to protect IIS 6 servers from some of the weaknesses in the version 4 and 5 families. But UrlScan does still bring about some extra protective measures such as filtering out certain URL character sequences and HTTP verbs and the removal of the web server banner. Use your judgment and knowledge of your target to determine if it would be a good fit.

An example of its usage is the locking down of supported HTTP verbs. This is accomplished in the referenced .ini file as follows:


UrlScan enforces these based on the value of the UseAllowVerbs option in the [Options] section (this section describes general options). If this value is set to 1, only the verbs that are listed in the [AllowVerbs] section are allowed. If this value is set to 0, UrlScan denies requests that use verbs that are explicitly listed in another section called [DenyVerbs], which uses the same syntax you just saw for its allow counterpart. Any requests that use verbs that do not appear in this section are permitted. In either case, the counterpart section is ignored.

Some other important sections within the .ini file are as follows:

  • [DenyHeaders] — This section lists the HTTP headers that are not permitted in requests processed on the hosting server.

  • [AllowExtensions] and [DenyExtensions] — This section defines the filename extensions that UrlScan permits.

  • [DenyURLSequences] — This section sets forth strings that are not permitted in HTTP requests processed on the hosting server.

You can find excellent documentation on UrlScan implementation and configuration at the following locations:

Commercial Products

The WAF commercial market is starting to pick up with multiple vendors now playing in this space. Here are some good starting points for your research:

Web Services

As you should clearly know by this stage of the book, Web services and XML content have unique protection needs. To meet these needs there has been the birth of the XML Firewall or Gateway. These devices or elements of software tend to focus on similar protective stacks:

  • Protection against XML-driven DoS

  • Access Control

  • Service abstraction and virtualization

  • Policy-based enforcement

  • Schema enforcement/validation

  • Granular XML encryption support

  • Protocol-level filtering and routing

  • XML Security, including support for Digital Signatures, SAML, WS-Security, XACML

  • Compliance with AAA services

  • SSL/TLS acceleration (typical hardware based)


Shreeraj Shah put together an excellent paper on using ModSecurity for the platform-agnostic defense of Web services. The protection takes place on the Apache HTTPS level through ModSecurity so this can even potentially be extended to operate at the Proxy level. You can find it at the Infosec Writers site: http://www.infosecwriters.com/text_resources/pdf/Defending-web-services.pdf. It is an important text because it goes into great detail about the customizations of ModSecurity not only to the protected target but also to a target’s Web services. You must get and absorb the data in that document. As a highlight here is a snippet from the section where Shreeraj goes into the filtering of dangerous meta-characters:

SecFilterSelective POST_PAYLOAD "<\s*id[^>]*>.+['\"%][^<]*</\s*id\s*>"

The regex depicted in this snippet will filter POST requests if the payload has in it any of the following meta-characters: ' or " or %. The document is full of excellent examples that you should study to further your knowledge in this arena. But the takeaway here is that ModSecurity has the very powerful ability of filtering POST payloads using the POST_PAYLOAD directive. Moreover, it can provide this tremendous advantage while not forcing the touching of Web service source code.


Though net-square’s wsRook (http://net-square.com/wschess/wschess_1.5.zip — it is part of the wsChess suite) is a prototype and is an IIS (Windows) specific solution, it deserves mention here. To drive a point home, it represents a regex-based filtering solution with great potential for .NET environments. Its use is based on regex filtering; the regex strings are stored in a file called wsrook.ini, which must be placed in c:\winnt\system32\wsrook\wsrook\ on the IIS server. This file holds regex strings such as this one to block SQL Injection attack strings against SQL Server.


The next step to use wsRook is the creation of a “bin” directory in the directory where your Web services will reside. Inside bin you will place the file called wsRook.dll. It is this file that will read the data from the .ini file and enforce those rules. The last step after that is to modify your web.config file so that wsRook loads at the time when the server does. Add the following data:

   <add type="wsRook.wsShield, wsRook" name="wsShield" />

Commercial Products

The commercial product space for Web services security is also blooming rapidly. Here is a foundation list for your research:

Previous Section
Next Section

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows