Re: Reverse Proxy on DMZ

["Matt McClung, CCSA/CCSE" <mmcclung () ndwcorp com>]

My replies are in between quoted text.

-----Original Message-----
From: Perry E. Metzger <perry () piermont com>
To: Matt McClung, CCSA/CCSE <mmcclung () ndwcorp com>
Cc: Joel Snider <joel_snider () yahoo com>; firewall-wizards () nfr net
<firewall-wizards () nfr net>
Date: Wednesday, January 13, 1999 9:20 AM
Subject: Re: Reverse Proxy on DMZ


> "Matt McClung, CCSA/CCSE" <mmcclung () ndwcorp com> writes:
> > I would disagree.  I have had to setup a proxy on a seperate DMZ off the
> > firewall that I allowed to access an inside web server.  There was a need
> > for this setup (outside developers for web app needed access to dev.
server)
> > .  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.  Securing your web servers is also part of the process,
however, that was not the intention of this point.

> >   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.
Verifying your perimeter is one function, evaluating from the inside
provides yet another level of auditing to make sure that the server is not
'as' vulernable to inside attacks.

If you do not know your vulnerabilities you as as good as dead.  One thing
to keep in mind is that you take all steps together not just one and hope
its the cure all.

> >   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.  Architecurally it is a sound addition to the
security policy enforced.


> >   4. Make sure you have good audit trails and logs.
>
> That won't prevent people from breaking in to your soft chewy middle
> via CGI bugs and nuking you, either.


That is not th point of this particular step.
> >   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.  A company is obvisouly not going to
provide a blanket trust which is why you apply the mentioned precautions.
The same would be true if you brought your partners into your network, you
assume risk by allowing them into the building and connecting to your local
network.

Each security implementation must evaluate risks against benefits, apply the
best method of securing the methods, providing monitoring/auditing and have
an adequate response plan.

> > With these steps, good design and following general security practices on
> > your web server you should have a good solution.
>
> That is totally untrue. Indeed, that is highly irresponsible of you to
> be saying. You seem to have totally missed the point of what the
> security analysis needs to be worried about.


Ah, I think you missed the question originally asked.  My response was
certainly NOT an attempt to outline his complete security model.  Addesssing
the question about putting a Reverse proxy server on the DMZ and is it
possible I believe was asked.  Security analysis was not the issue.  As a
security professional you would realize that there is not a '10 Steps to
information security' that can be broadly applied.


> 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 therefore it is out of line for a
'fellow' security professional (or any professional) to make such a
statement.

Matt McClung
Network Security Engineer
mmcclung () ndwcorp com
801-595-6200