tonimargiotta
asked on
How much value is an application proxy ?
Greetings
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Here is another point that many miss: Proxies ensure that there are 2 TCP connections and the packet that reaches your internal servers (in the inbound traffic scenario) is built with the IP stack of the _firewall_, not some hacked out Linux box. So, in addition to any protocol interrogation features, even a dumb proxy will protect against fragmentation attacks and other "irregular IP packet" anomalies.
Just my 2 cents.
Just my 2 cents.
id agree with DVB, in that it really depends on the application (protocol) you are thinking of proxying. Of course the IIS attack worked, it would have worked w/o the proxy, because it is sent via valid http. but someone that is not using a tunnel and tries to use that port, maybe ssh to port 80, would not go through the proxy.
i guess what im trying to say is sure, there are ways around anything. put up a fence, and ppl can climb over the fence. but thats not an argument for not putting up a fence.
a problem w/ proxies, of course, can be the load they have to handle, opening two network connections for each proxied connection.
i guess what im trying to say is sure, there are ways around anything. put up a fence, and ppl can climb over the fence. but thats not an argument for not putting up a fence.
a problem w/ proxies, of course, can be the load they have to handle, opening two network connections for each proxied connection.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
hmm, the comments/suggestion end up in my very first comment, nothing new added ...
tonimargiotta, are you still listening?
tonimargiotta, are you still listening?
Hey people,
No comment has been added in roughly 1 year, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question
be PAQ'd and pts be awarded to ahoffman.
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Zenlion420
EE Page Editor
No comment has been added in roughly 1 year, so it's time to clean up this TA.
I will leave a recommendation in the Cleanup topic area that this question
be PAQ'd and pts be awarded to ahoffman.
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
Zenlion420
EE Page Editor
Thanks for closing.
j
j
Most of the older protocols have been designed without the requirement of security in mind. A good protocol which can be defended by a proxy is SMTP, where the protocol itself has relatively few holes (the primary one being lack of authentication, leading to lots of open relays). A bad example is http, where almost anything can be tunneled in. If you know the exact format of the data you are expecting, you can write a custom proxy to handle those requests, but otherwise, it is tough to defend against an attack that runs over http. Your best solution is to use a proxy to grab attacks like nimda et al which have specific signatures and run a secure http server along with paranoid application writers.
Defense in depth is a good strategy when it comes to security.