I’ve received a teeny amount of “I agree, but…” feedback for last night’s posting; in this case from two fellow geeks whom I respect deeply.
Their criticism – singular, shared – is this:
“There are times when having a WAF around can be handy! Sometimes there’s a 0-day announced and you can use the WAF to mitigate it before the vendor releases a patch! It’s another potential extra layer in a complete defence-in-depth security breakfast!”
They – we – are all both right and wrong in this; and interestingly both commenters come largely from the attacker/pentesting side of the security industry, where I come largely from the defender/ops side, which I think is relevant to perspective.
Certainly a WAF – if installed – can be used in the manner described, as the off switch filter for a selected bunch of URLs which are suddenly dangerous to be exposed to the internet.
What is the cost of this off-switch?
increasing the cost of the deployment
More hardware and software to install and deploy; in a serious deployment the WAF must be capable of wire-speed throughput and not significantly impact throughput latency, connection setup time or maximum-number-of-concurrent-sessions; finding something which satisfies all four of these metrics used to be a major challenge in the world of network load-balancing – let alone application filtering.
doubling (or worse) architectural complexity
Everything comes in through the WAF, everything leaves via the WAF; this is what we call a chokepoint.
doubling (or worse) management complexity
Two sets of software to configure and update and manage, perfectly; the WAF will have a configurational relationship with every webserver in your datacentre, and conversely they will have to be configured not to talk to anyone but it.
doubling (or worse) the attack surface
There is now a new, critical device which can be attacked in order to bring down your entire network; it had better be at least as robust as your perimeter router.
impact on end-to-end security
I mentioned decapsulating SSL in the previous article.
laziness
If you deploy a WAF then some day you risk a member of staff using it to “fix” a appserver vulnerability – ie: block access to it – and never address the root cause; eventually this will bite you.
There is precedent here from the old world too, where “I only need to switch on Telnet for the afternoon to get into the server”, and someone forgets to switch it off; then one day someone finds a way to bounce TCP connections off another server and into the Telnet daemon…
Summary
So yes – you could deploy a WAF for occasional use in your network, especially if you are not a major-league, high-uptime service; but combined with the above, and from where I am coming, the security risk that it is being deployed to mitigate is better addressed by:
- not letting unauthenticated users at the “bad” URLs, or
- using the other kind of off-switch until you have a patch
This strikes me as simpler.
final thought
There probably are some systems where this cost-of-a-WAF is worthwhile.
I try not to deploy them.
Written by: Alec Muffett