I am at present evaluating whether I want an application proxy as part of my perimiter defences, in addition to packet filtering. If you had asked me last week, I would have said definitely yes.
The ability to ensure that packets conform to application level protocols ought to ensure that if a server is compromised then the narrow channel of communication via the application protocol ought to compartmentalise the breach. I have seen this view supported in multiple expert quarters, used as a sales pitch, and have been given the same view by experienced penetration testers who all say that an application proxy alway makes it harder to leverage an exploit.
My comfort in this line of thinking, safe behind my proxy firewall, is disturbed by the discovery that netcat comes in a version that will operate as a http server.
My engineers tested a scenario where a buffer overflow exploit in IIS established netcat on port 80 passing all traffic straight through a http proxy. Ugggh.
Now I know that we need to keep up to date on patches, we are using URLScan so the exploit would not actually have worked on production servers, we know about shield technologies such as Appshield and Ubizen, We know about tripwire etc, we know about hardening ACLs etcs. We may put in strong authentication at the border firewalls in the future.
The question is, if we do all of the above, does an application proxy short of shield technology really add any value?
Additional points for anyone who can tell me anthing I don't already know.