Why do you need a reason _other_ than it's best practice? 8) In my experience, proxy vendors always seem keen to have their device exempted from the firewall - yet another special exemption, just for them, because they usually have outrageous performance lies to try and justify.
Even if the proxy server is perfectly hardened against an outside attack, you should also remember that it probably significantly weakens your security policy for traffic from inside to outside. Take a look at the recent Cisco vulnerability - internal users were using the HTTPS port redirction of the devices to send spam to outside hosts in a pretty much undetectable fashion (as far as inside admins were concerned). I'm happy to bet lunch that they aren't the only cache implementor to make this "mistake" in the default configuration. After all, caching devices are all about speed, not security, right? The same vulnerability could obviously be used to make any TCP connection - UCE is just the one that came up. Bill also makes a couple of other excellent points about traffic policing and inspection which I won't go over again. If the device supports any "intelligent" caching that should ring alarm bells as well - because now it's probably starting to go out and pre-cache things by itself, and who knows what could go wrong with that process. This is assuming that the cache appliance is as hardened as it says it is. As you've already mentioned, a port scan and a vulnerability websearch aren't a complete testing regime. If I were testing it for this kind of role I'd start by sending lots of evil packets of the usual kind (overlapping fragments, bad length, bad checksums blah blah blah) all aimed at port 80 and all spoofed to come from google.com, to a mix of inside and the proxy server's address, while it was in service. Then check if it knows its inside addresses from its outside ones, then... I'm not really a vuln-dev person, though. I'm sure there are other interesting possibilities. In short, this is an example of pure expediency. "It's not fast enough through the firewall, let's just put it straight on the net." If you have a firewall performance issue, fix it, or get a faster one. Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Kent Hundley Sent: Tuesday, May 21, 2002 12:06 AM To: [EMAIL PROTECTED] Subject: Opinions on netcache security I'm looking for opinions on the relative security of installing a netcache caching proxy in parallel with a firewall. I have always considered "best practices" to be that few, if any, devices should be installed in parallel to a firewall unless there is a compelling justification for doing so. (less attack vectors, simplicity, etc) However, my client is being told by Network Appliance that they should install their netcache proxies in parallel with their firewalls for performance reasons. They are also being told that the netcache proxies are "hardened" and do no support any outside to inside initiated connections and that a large number of their clients install their netcache proxies in parallel with their firewalls. Some preliminary testing I have done did not reveal any available ports on the netcache when scanned from the outside and a search in the ICAT returned only 2 vuln's recorded for the netcache appliances. (one of which was related to allowing HTTP tunnels in the default config) Given this, and given that there have been firewall performance concerns by my client, I need a good reason not to install the netcache's in parallel with the firewalls other than "it's not best practice". Does anyone have specific reasons why the netcache proxies should not be installed in parallel with the firewall? In particular, any experiences with a netcache being compromised would be very helpful. Regards, Kent _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls