All,
>Reverse-proxy situations are not good architectures because they
>essentially allow users to connect directly to internal hosts.
This statement depends on your definition of "essentially". From a strict
technical sense, there is not a direct IP or TCP-level connection. And as
far as application-level data goes, user requests can be sanitized before
being passed on to the back-end webservers (for example, you could strip
out PUT commands, pipe characters and other junk). Of course, your
webservers still might be susceptible to CGI attacks...
>Users then bypass the DMZ-type network entirely so if the webserver they
are
>accessing gets compromised, it's game over--the attacker is now not
>confined to a DMZ-type network but is on your internal LAN! Fun, fun,
fun.
True, but a proper reverse-proxy architecture should have some security at
the back-end as well. Bolt down your webservers as if they WERE on the DMZ.
Put them on their own isolated network, and use router ACLs to permit
inbound connections from the reverse proxy. Permit outbound traffic only to
the reverse proxy, and deny everything else.
Of course, webservers can't live in a vacuum; content will need to be
changed, or perhaps your webserver uses CORBA to talk to a back-back-end
database. You can usually minimize such risks with strong authentication,
more ACLs, IIOP and some other acronyms.
Regards,
Christopher Zarcone
Network Security Consultant
RPM Consulting, Inc.
#include <std.disclaimer.h>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
