Web application firewall

What is WAF?

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as cross-site scripting (XSS) and SQL injection. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified

Why WAF?

WAFs are designed to protect web applications/servers from web-based attacks that Network Firewall cannot prevent. They sit in-line and monitor traffic to and from web applications/servers. WAFs interrogate the behavior and logic of what is requested and returned. WAFs protect against web application threats like SQL injection, cross-site scripting, session hijacking, parameter or URL tampering and buffer overflows. They do so by analyzing the contents of each incoming and outgoing packet.

WAFs are typically deployed in some sort of proxy fashion just in front of the web applications, so they do not see all traffic on our networks. By monitoring the traffic before it reaches the web application, WAFs can analyze requests before passing them on. This is what gives them such an advantage.

WAFs not only detect attacks that are known to occur in web application environments, they also detect (and can prevent) new unknown types of attacks. By watching for unusual or unexpected patterns in the traffic they can alert and/or defend against unknown attacks. For example- if a WAF detects that the application is returning much more data than it is expected to, the WAF can block it and send alert.

Security Model

A WAF typically follows either a positive or negative security model when it comes to developing security policies for your applications.  A positive security model only allows traffic to pass which is known to be good, all other traffic is blocked.  A negative security model allows all traffic and attempts to block that which is malicious.  Some WAF implementations attempt to use both models, but generally products use one or the other. A WAF using a positive security model typically requires more configurations and tuning, while a WAF with a negative security model will rely more on behavioural learning capabilities.

Why WAF in trusted domain?

  • By configuring more aggressive rules in the internal WAF, we can eliminate the burden of re-authentication and re-creating security patterns through the processing tree.
  • Provides a central WAF rules repository.
  • If the web server is under attack from the outside, it can further compromise internal machines. This is a quite common scenario we saw in incident response.
  • If users are allowed at some point to upload/modify content hosted on the web server: that content has to be secured/checked. For instance, malicious content may be inserted into the web server content (like links to exploitation codes, etc.), and then be transparently/automatically accessed by any clients browsing the web server.
  • Critical servers can be closely monitored when they are isolated behind an internal WAF. Any malicious activity would be much easier to detect.
  • Added security to the internal machines, connected through VPN. For example, a laptop pc from the airport accessing the Internet might VPN into our Enterprise as well.
  • Malicious Insider

    WAF Selection criteria:

    • Protection against OWASP top ten
    • Very few false positives (i.e., should NEVER disallow an authorized request)
    • Strength of default (out-of-the-box) defenses
    • Power and ease of learn mode
    • Types of vulnerabilities it can prevent
    • Detects disclosure and unauthorized content in outbound reply messages, such as credit-card and Social Security numbers
    • Both positive and negative security model support
    • Simplified and intuitive user interface
    • Cluster mode support
    • High performance (milliseconds latency)
    • Complete alerting, forensics, reporting capabilities
    • Web services\XML support
    • Brute force protection
    • Ability to active (block and log), passive (log only) and bypass the web traffic
    • Ability to keep individual users constrained to exactly what they have seen in the current session
    • Ability to be configured to prevent ANY specific problem (e.g., emergency patches)
    • Form factor: software vs. hardware (hardware generally preferred)



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s