Does a Web Application Firewall (WAF) that is protecting application layer 7, as well protect other layers of the The Open Systems Interconnection (OSI) model?
1 Answer
Due to architectural necessity, Web Application Firewalls (WAFs) protect against attacks at other layers as well. However, these protections are largely incidental and not comprehensive. Let me illustrate this with some examples:
Presentation Layer - let's assume that the application to be protected uses TLS. If so, the WAF device must by definition* terminate the client TLS connection in order to decrypt the application data and apply its Application Firewall logic to it.
What this means in practice is that a potential attacker never interacts with the TLS stack on the target (Application) host. And while the backend may be running one of any number of Application Frameworks, all of which have their own TLS implementation with its own quirks, the WAF will generally be built and sold by someone who realized TLS is a big deal to get right. (In my experience, F5 is pretty good about updating their TLS as necessary).
So the WAF provides protection at the Presentation Layer, in fact (if not as a sales bullet).
Session Layer - a WAF will often inject its own tracking cookies to help detect and prevent people playing games with the session endpoint data. This is partially because the WAF needs to protect [any] application on the backend, but nicely complements the fact that "for [random(any)] application, assume it was written without any reasonable session protections."
Transport Layer - Like TLS, TCP will be terminated at the WAF, thereby exempting the Application server from interacting with the client directly. Any hand-tuned tweaks to packets, any overlapping fragments, any state violation games are going to break against the WAF and not the Application server. Will the WAF be better able to handle them? Hard to say, but the attacker will still be short of their goal.
Network Layer - again, by terminating connections and opening new ones to the Application server, the WAF will insulate the Application server from IP-layer attacks... For example, it'll wait until the outer (client) 3-Way Handshake (3WHS) is complete before initiating the inner (Server) 3WHS, thus mitigating synfloods.
These protections are generally incidental and not designed. The WAF maker isn't putting the Stateful Inspection capacity of, say, a CheckPoint into their WAF; they're just waiting to have a valid stateful outer connection before opening the inner connection. The WAF may use the OpenSSL TLS stack, just like the Application Server does, and they're both vulnerable to the same issues... but the WAF is one step removed from the useful data on the Application that the attacker wants to get to.
* The definition I'm using here is "modern TLS prefers ephemeral key ciphers which remove the ability of a passive listener to decrypt traffic, so let's just assume anything with TLS these days is going to need to be terminated to be decrypted."