RE: [fw-wiz] PIX -> ISA -> OWA Configuration

From: Paul Melson (
Date: 05/05/05

  • Next message: Vin McLellan: "[fw-wiz] InfoSec's Waterloo and it's implications"
    To: <>
    Date: Thu, 5 May 2005 15:20:51 -0400

    Bring on the logic...

    while [ "$horse" = "dead" ]; do
            beat $horse

    At the end of the day, everybody that expresses the opinion that #1 < #2 has
    missed the point of what a firewall can actually do for them. Perhaps they
    are wise to mistrust IIS, but not if it means trusting a larger number of
    other native Windows services. Let's break it down, and then I've gotta get
    off this thread because nobody pays me to worry about OWA/Exchange
    infrastructure anymore.

    PIX Firewalls offer access control at layer 3. This mitigates risk by
    reducing the number of possible attack vectors against a given system by
    only permitting that traffic which is necessary.

    An ISA Server, an OWA server, an Exchange server, and an AD domain
    controller all run on similar platforms, having similar numbers and types of
    attack vectors, give or take a few.

    If my OWA presence consists of an ISA Server doing reverse proxy to an OWA
    server, and like most organizations, my Exchange server is part of my
    production AD environment, then I can create a list that looks like this:

    ISA Attack Vectors OWA Attack Vectors AD Attack Vectors
    Total Attack Vectors
    ------------------ ------------------ -----------------
                    35 30 Exchange 26
    AD DC 25

    I am using an arbitrary number (25) assigned to Windows boxes in an AD
    domain, but you could calculate this with a quick nmap of your production
    boxes. I'm then adding 10 proxy ports to ISA, 5 ports for IIS (ftp, http/s,
    smtp, etc.), and 1 port for Exchange (SMTP). In this case, I select to
    define an attack vector as allowed communication from network of lower
    "trust" to a network of higher "trust" (per the PIX interface model) - for
    example, traffic allowed from the Internet to the ISA Server is an attack
    vector, but traffic from the OWA server to the ISA Server is not. Then I
    subtract the attack vectors from my table and add them up, like so:

    ISA (#1) OWA (#1) AD (#1) Total (#1)
    -------- -------- ------- ----------
             1 1 26 53

    ISA (#1) OWA (#1) AD (#1) Total (#1)
    -------- -------- ------- ----------
             1 30 21 72

    Now you can get fancy with weighting your attack vector charts, perhaps
    using your risk assessment and mitigation policy to do so, and you can use
    the actual number of listening ports on your production systems, but you'll
    still come out with the same conclusion: #1 reduces the exposure of your
    ISA/OWA implementation more than #2 does.


    PS - How come nobody's come back with, "The most secure option is to not use
    OWA at all and make people check their e-mail from the office like normal
    human beings." ? If you apply that option to the risk valuation I use
    above, you get a sum of 0. Clearly better than the rest.

    -----Original Message-----
    Subject: [fw-wiz] PIX -> ISA -> OWA Configuration

    Option #1 would have to be the worst option for security, all you have to do
    is re-read Ben Nagy's response and think about it for a few more minutes.
    When you place the OWA server directly into your internal network without
    controls, you have no controls unless of course you truely believe that a
    Microsoft product is not considered a "Hackable device" and in this case we
    are talking about two Microsoft products - ISA Proxy Server and OWA.....
    [spaghetti] --> [hackable box] --> [hackable box] --> [pot of gold]

    Option #2 is the better solution since there is atleast on additional contol
    added in the diagram.

    firewall-wizards mailing list

  • Next message: Vin McLellan: "[fw-wiz] InfoSec's Waterloo and it's implications"