Sophos UTM: Securing Web Application Firewall (WAF)

My experience with WAF has been disappointing.   I have had so many false positives that about all I can reliably enforce is Site Path Routing.   I have found no documentation that provides "hints and tricks" to minimize problems and maximize success.  Level 1 support simply advises that if a feature causes problems, turn it off.

During the sales cycle, Forms Hardening seemed conceptually easy to implement with full transparency.  WAF simply needs to ensure that the returned form has the same field names as the one sent out, that the max_length parameter is observed on all returned fields, and that the returned character set is consistent with the requested character set.   In practice, I have never had a site which did not throw Form Hardening errors.

Form Hardening and Cookie Hardening have to be used together, so Cookie Hardening fails because Form Hardening fails.

Strict rules throw false positives so I add them to the ignore list without really understanding the implications of the exception, then I hit a wall because I have what appears to be a false positive on an infrastructure rule which should never be disabled.   So instead I disable Strict Rules.

Bad Client checking uses the email RBLs.  The email RBLs include residential IP addresses in their blocklists because residential users on dynamic IPs should not be running mail servers (but might be running mail-sending malware).  I don't want to abandon those RBLs for email protection, so I have turned Bad Client checking off for WAF protection.   (One person in this forum points out the Bad Client checking can be enabled without the RBL lookup, which performs some undocumented filtering based on GEO-IP.)

Of course, it is difficult to know during testing whether the tests have been extensive enough to expose all of the needed WAF exceptions.   Once the site is in production, it is extremely difficult to know whether a log entry represents a false positive or not.   The logs are obscure, but even after studying them carefully, it seems impossible to know how to respond to them.

Has anyone figured out how to make Form Hardening work, or figured out whether certain development practices that can either cause it to fail or allow it to succeed?

Do we even know whether WAF supports both HTML4 and HTML5?   Are there different limitations based on the HTML version?

Does anyone have any advice for making the other features useful?

Parents
  • One of the issues in my original post was, "After I go into production, how do I know if an alarm is a true attack or merely a false positive that was not exposed during testing?"

    This is the approach I am taking right now:

    • One site requires a WAF login.   If an alarm is detected on an IP address that successfully completed a WAF login, I am assuming that the user is not hostile and the alarm is a false positive.   This requires matching the UTM-format log entries (which provide username and IP address) with the ModSecurity-format log files (which have the alarm information and IP address.)
    • On another site, login is not required but the number of source IP addresses is very small.   Some of the IP addresses I recognized as a known business partner.   The other IP address was not immediately recognized, but from the UTM-format log entries I could determine that the IP address went through a full transaction sequence to the confirmation page.   Based on completing a normal transaction, I concluded that the traffic was not hostile and alarms could be treated as false positives.
  • I have recently discovered these resources, which I am only beginning to digest:

    The ModSecurity Handbook.   Available online in HTML format.   Available as a PDF download if  you create a (free) account on the site.   I have also signed up for their SSL/TLS newsletter.

    https://www.feistyduck.com/library/modsecurity-handbook-2ed-free/

    OWASP Best Practice Recommendations for WAF

    https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls

     

  • Neither of the previous documents have the information that I wanted.

    I found this page with the ModSecurity reference manuals for both v2 and v3.   I have not yet determined which version is in my UTM firmware.

    https://github.com/SpiderLabs/ModSecurity/wiki

    When I do a web search for ModSecurity and hardending, most of the links are to this forum.   

    I cannot find anything that explains when the three hardening methods (URL, Form, Cookie) will definitely work, when they will definitely fail, or how to predict when they might fail.   With all three disabled, it seems like I have lost a lot of protection.   But I do not seem to have a safe way to even find out if they are usable, because I cannot assume that Monitor mode is non-disruptive.

     

Reply
  • Neither of the previous documents have the information that I wanted.

    I found this page with the ModSecurity reference manuals for both v2 and v3.   I have not yet determined which version is in my UTM firmware.

    https://github.com/SpiderLabs/ModSecurity/wiki

    When I do a web search for ModSecurity and hardending, most of the links are to this forum.   

    I cannot find anything that explains when the three hardening methods (URL, Form, Cookie) will definitely work, when they will definitely fail, or how to predict when they might fail.   With all three disabled, it seems like I have lost a lot of protection.   But I do not seem to have a safe way to even find out if they are usable, because I cannot assume that Monitor mode is non-disruptive.

     

Children
  • I have determined that every log entry with a rule ID will have tokens for the file and line number which define the rule.   An example:

    • Rule ID 96009 is from /usr/apache/conf/waf/modsecurity_crs_protocol_anomalies.conf, line 66

    The path is actually truncated.   Full path is /var/chroot-reverseproxy/usr/apache/conf/waf/modsecurity_crs_protocol_anomalies.conf

    There are other file types in that folder, but all of the WAF log entries refer to one of the *.conf files.

    I looked at one of those files to see if i could parse it to build a reference list of the form:   Rule Category, Rule ID, Rule Description

    Unfortunately, the rule definitions use a complex syntax which would be non-trivial to parse.   However, this does allow us to see that specific GUI options can be presumed to enable or disable specific *.conf files, as follows:

    Presumed relationships betwen Common Threat Filter Categories and *.conf files
    modsecurity_crs_protocol_violations.conf, Protocol Violations
    modsecurity_crs_protocol_anomalies.conf, Protocol Anomalies
    modsecurity_crs_request_limits.conf, Request Limits
    modsecurity_crs_http_policy.conf, HTTP Policy
    modsecurity_crs_bad_robots.conf, Bad Robots
    modsecurity_crs_generic_attacks.conf, Generic Attacks
    modsecurity_crs_sql_injection_attacks.conf, SQL Injection Attacks
    modsecurity_crs_xss_attacks.conf, XSS Attacks
    modsecurity_crs_tight_security.conf, Tight Security
    modsecurity_crs_trojans.conf, Trojans
    modsecurity_crs_outbound.conf, Outbound

    Presumed relationship between other options and *.conf files
    10-REQUEST-IP-REPUTATION.conf, Block Clients with Bad Reputation,Filtering

    Other *.conf files, purpose not investigated
    base.conf
    modsecurity_crs_common_exceptions.conf
    modsecurity_crs_correlation.conf,
    modsecurity_crs_inbound_blocking.conf
    modsecurity_crs_outbound_blocking.conf