Firewall Wizards: RE: PIX -> ISA -> OWA Configuration

[Frank Knobbe <frank () knobbe us>]

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. 
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 say
> via buffer overflow, then there is no protection for the internal AD domain,
> 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  ----------------------------   =  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....

Regards,
Frank

Attachment: signature.asc
Description: This is a digitally signed message part