Re: Reverse Proxy on DMZ

["Perry E. Metzger" <perry () piermont com>]

"Matt McClung, CCSA/CCSE" <mmcclung () ndwcorp com> writes:
> > > .  What you need to do is a couple things:
> > >
> > >   1. Harden your proxy server (I used Novell's BorderManager which made
> it
> > > harder in the 1st place)
> >
> > Useless. The proxy isn't what you are going to break into. It is the
> > cgi on the destination machine.
>
> Hardly useless, unless you feel not protecting all pieces of your network is
> not neccessary.

The point is not that you shouldn't make all exterior machines strong
against attack. The point is that in the stated design, the exterior
machine is explicitly being set up to permit connections to a web
server inside your network. In doing so, you have eliminated almost
all the benefit associated with the firewall. At that point, the work
done in securing the external proxy machine becomes almost useless.

> > >   2. Verify you security from the inside and outside (scan both sides,
> > > audit, review)
> >
> > Useless. Again, this doesn't prevent the attacker from hitting the
> > thing they are attacking. They have legitimate access to the point of
> > attack, so no amount of scanning will tell you anything.
>
> Assuming of course that any hacker could get to the web server to attack it.

You are setting up a reverse proxy SPECIFICALLY so that outsiders can
get to this web server. The fact that you've architected something so
that legitimate users on the outside can get to a web server on the
inside and execute CGI on it means that you've given hackers the best
possible opportunity to attack an inside machine.

> > >   3. Require strong authentication - 1 time passwords etc.
> > Not particularly foolproof. This will not prevent attacks from
> > "legitimate" users or attacks based on session stealing.
>
> 1 time password are not fullproof - true - but with one time pwds and secure
> communications I don't you'll break into a session before it ends.  This has
> yet to be proven ineffective.

You don't read bugtraq, do you? The script kiddies have plenty of
software already for hijacking sessions.

> > >   5. Make sure your proxy server has the ability to limit where the users
> > > can go...policy based
> >
> > Again, you are letting them go, by design, into the single most
> > dangerous part of your network.
>
> Again, when you create a relationship with a partnering business you are
> creating a trust relationship.  You are assuming some risk in order to be
> able to perform business functions.

That's not true.

When you build these things properly, it is not necessary to trust the 
security of the remote site. I know it can be done because I've done
it and so have most other people. The fact that you are advocating
this makes me think you are not a competent security professional.

It is easy enough to use far more secure mechanisms to move data into
and out of an untrusted external web server and avoid this entire
class of security problems. No reasonable professional would advocate
to a client with any significant security concerns that they trusting
a trading partner with, in effect, free access to their entire
network, especially when it is utterly unnecessary.

> > You appear to be holding yourself out as a security professional. I
> > hate to say this, but I fear for your clients.
>
> Rather than dignify a personal response I say this:  You obviously have no
> clue as to my experience and/or background

I don't need any such information. I've seen what you say in public
and it is dangerous enough that I have no need to know what your
credentials are. Knowing that a surgeon graduated from Harvard is
unimportant once you see him stumbling around drunk looking for his
scalpel. His credentials become meaningless in the face of visible
gross incompetence. I needn't know whether you worked for the best in
the business to know, based on your comments, that you are likely a
danger to your clients.

Perry