Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-05-03 at 09:06 -0400, Paul Melson wrote:
> Definitely.

I'd say definitely not. But oh, well, to each his own...

> In #1, if the ISA server is configured via the OWA publishing
> wizard, it will create ACL's that prevent requests that don't match
> /exchange/* from being passed to IIS.=20

That's fine. There were (and perhaps still are) holes in script
beyond /exchange that can be exploited....

> In #2, the same thing applies, but should the ISA server be compromised s=

> via buffer overflow, then there is no protection for the internal AD doma=

> since those holes must be punched straight through the firewall (and they
> are BIG holes).

How is that different from when the OWA server gets hacked sitting right
on the inside? At least you have *some* constraints you can enforce.
while AD related ports are open, an attacker can not... say... scan for
and exploit vulnerable FTP servers. Or attack any system other than your
AD servers, like worming it's way through vulnerable workstations.

I think you put way too much trust in ISA server.

Why is that when we don't trust an application (OWA), we don't try to
secure that, but instead add *another* application (ISA) server in
attempts to secure the first app? The strength of a chain is determined
by the weakest link. So why do we keep on adding links, increasing the
risk of reduction of strength?

layers of security number of chains
---------------------- X ---------------------------- =3D some
security index
layers of complexity number or links in a chain

If you firmly believe in solution 1, than please do as Ben suggested and
buy one of them shiny red boxes and put that in the same rack....


Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

Version: GnuPG v1.4.0 (FreeBSD)

iD8DBQBCd/4PwBQKb2zelzoRAiThAJ9lIwQ3mNf4w4AvNYJd6lTCRrEtKACd Gdgo


firewall-wizards mailing list