WAF vs IPS (or Four Things Your IPS Can’t Do)

I see this often and I am always amused at the topic. I have worked with IDS/IPS for 8 years, so I know IPS when it was just a flavor of IDS that no one wanted to enable for fear of blocking access to users and customers. I chuckle at the thought of WAF being a glorified IPS. My how times have changed.
Here are four things that your WAF can do that your IPS can’t. I tried to keep this vendor agnostic.

Please feel free to pile on or comment, just no flames please!

WAF vs IPS?
Web Application Firewalls, as the name implies, work with web applications almost exclusively. Most WAF are often not best-of-breed traditional firewalls, and should not be implemented in place of a traditional network firewall. Typical WAF deployments feature SSL decryption of web application traffic and blocking of web-based threats after the WAF reassembles each web session. This is possible because the WAF operates at the application layer where HTML, XML, Cookies, Javascript, ActiveX, Client requests, and Server responses live.

Intrusion Prevention Systems, as the name implies, inspect packets in an attempt to prevent attacks and therefore intrusions. IPS, which evolved from Intrusion Detection Systems, are packet inspection systems that analyze traffic for signatures or policy violations. These all-purpose devices typically do not decrypt encrypted traffic but instead apply a predefined policy or signature set across all network traffic presented to the IPS.

Four Key Differences
As packets are inspected by an IPS, they are often discarded to improve performance. This is a key differentiator, because a WAF must retain packets in order to keep the context of a client web request and the subsequent server response. Thus you could say that IPS’s deal with packets, while WAF’s work within sessions.

WAFs must understand not just protocol behavior, like HTTP GET, POST, HEAD, etc, but also JavaScript, SQL, HTML, XML, Cookies, etc. This application layer logic is fundamental to the operation of a WAF but not required for IPS functionality, and therefore not typically implemented on an IPS.

Baselining is available on IPS and WAF, but the similarity stops with the name. IPS baselining consists of statistical deviations in throughput and traffic flows. WAF baselining involves URL, Parameter, HTTP Method, Session, and Cookie mapping. A WAF knows no concept of bandwidth utilization for baselining, just an IPS doesn’t know if a given URL is supposed to accept HTTP POSTs or GETs.

IPS signatures are looked at by companies as a means to virtually patch their PC’s ahead of an actual being patch or update being available or fully rolled out. This level of protection isn’t available on an IPS when specific application-layer vulnerabilities exist or when custom written web-application code has some new vulnerability. This is where the WAF provides a measure of protection not available on an IPS, due to the application-awareness of the WAF.

Wrap Up
WAF deployments are focused on web applications and web application traffic, while IPS deployments are typically done at the network level inspecting all packets. I’ll grant you that there are Host-based protections are blur the lines of IPS and WAF, but these don’t qualify as IPS or WAF and probably won’t be living in large multi-OS datacenters or deployed across the tiers of your n-tiered applications.

These are complimentary technologies, just as traditional firewalls and IPS compliment one-another. See Akamai announcement of new WAF service that compliments existing IPS features.

Thoughts?

About these ads

Posted on December 28, 2009, in Security / Risk, Security Management and tagged , , , , . Bookmark the permalink. 10 Comments.

  1. Thanks. I’m looking for this kind of post for quite a while.
    You input above are true. However, I do believe that next generation of IPS will have at least some functionalities of WAF.

    Take for example, SSL inspection, some IPS (for example McAfee and Juniper IPS) have the capability to inspect SSL inspection.

    Well, sometimes, it is very hard to justify to customer to purchase both technologies (IPS and WAF). Usually, their management will ask IT department to decide whether IPS or WAF. This is due to they do not have clear understanding between IPS and WAF.

  2. I agree with you, it is often challenging making technology and product selections. This is even more true in the current economy where literally every penny counts.

    Couple of additional points to consider…

    The problem with an IPS taking on the role of a WAF one of performance implications that could lead to security implications. This becomes increasingly difficult and expensive as traffic volume and sessions increase.

    For example, the IPS has to not only process signatures at the packet level for the broadest array of attack / vulnerabilities at wire-speed, but the IPS has to also look at the entire “conversation” between the web client and the web application while inspecting EVERY packet.

    Please be careful with IPS solutions that “inspect SSL” as it’s important to distinguish between IPS’ that integrate with SSL VPN solutions and IPS’ that interrogate SSL communications. SSL VPN integration does not provide WAF capability, it merely screens VPN users.

  3. A few more differentiators… (Disclaimer – I work for a WAF vendor…)
    1. Many of the problems in web applications happen with requests that look completely valid, think about a parameter value that someone changed on the client side, or a cookie value that was changed on the client side, now, no one said this is illegal to do, in fact there are applications that this is legal to do, a good WAF will be able to detect these changes and per paramater/cookie decide weather to allow that or not, IPSs don’t have that intelligence today.
    2. The ability to mitigate brute force attacks and DOS attacks at layer 7. An IPS provides a single way to mitigate that, limiting the number of requests/packets from a single source IP, what if the attacker is using a mega-proxy? would you want to block the AOL proxy just because one behind the proxy is trying to brute force or performs a L7DOS? A modern WAF will be able to mitigate that at the application layer
    3. Full HTTP request logging (URI, query string, header, body) logging is a very important to be able to understand what has really happened, it also serves many times as an input to the dev team, helping them in troubleshooting
    4. WAFs have much more than signatures to offer, they have the ability to “whitelist” the entire application, providing a better protection for known and unknown attacks
    5. Granularity is probably the most important difference. When you turn off a signature that is causing false positives in an IPS for an application/traffic , you basically turn it off for the entire application(s), in a WAF, you can turn off a signature just for a single parameter, while keeping the same signature available on the other hundreds or thousands parameters of that application
    Another difference that demonstrates the advantages of WAFs is that most WAFs today are deployed in blocking mode while more IPS are deployed in transparent mode (IDS mode)

  4. Ido those are some great points – thank you for responding!

    I tried to focus on a core set of reasons that are vendor agnostic, but I agree granularity is an excellent example of where an IDS/IPS applied policy exception is going to be different than how a WAF is able to exempt (and apply) security protections. Granularity at this level is not only something not seen on most IDS/IPS products, but it also a reason why we won’t see WAF’s converge with IPS’ anytime soon.

    I also agree that logging is a deal breaker for using an IPS in place of a WAF. I mention that in my post on Why IPS and WAF won’t converge anytime soon.

    The DoS capability of the F5 ASM product is a welcome feature. No matter which WAF product is selected, I think most WAF vendors implement some flavor of Brute Force protection.

    Along the lines of your first comment about learning parameters, I like the Imperva WAF’s capability to automagically block specific special characters that are not normally found on a learned parameter.

  5. Good thought. I love it. Appreciate your sharing

  6. Good points and good conversation. Today’s blended threats and mutations make it difficult for the present list based systems to stay effective. Second, I would like to insert that each component or point solution (ie FW, IDS/IDP, WAF, etc.) has its place and role when it comes to inspection, detection, and blocking. The ability to remember, learn, correlate, and share from ALL 7 OSI LAYERS in near real time is missing. Barrier1, thebarriergroup, does just that. The onboard learning engine learns from these components and uses math in near real time. Testing has been done against every one of the well known security manufactures.

    Just something to think about.

  7. I really appreciated this excellent article. I would hope for an update reflecting the current situation. It would be also interesting to have sort of an analysis showing how well or bad a IPS and a WAF are with the OWASP10 list, to what extent and with what approach they could provide support and where they fail.

  1. Pingback: Three reasons why IPS and WAF won’t converge anytime soon « Practical Tactics

  2. Pingback: IPS vs WAF (or Four Things Your WAF Can’t Do) « An alchemists view from the bar

  3. Pingback: WAF vs IPS : 弯曲评论

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: