RE: Ye Olde OWA Topic (Was RE: Website inside or outside domain)

From: shannong (shannong@texas.net)
Date: 02/15/03

  • Next message: Erik Birkholz: "RE: website inside or outside the domain?" 
    From: "shannong" <shannong@texas.net>
To: "'Henry Sieff'" <hsieff@orthodon.com>, <focus-ms@securityfocus.com>
Date: Sat, 15 Feb 2003 12:08:40 -0600

    Of course, if you're using a VPN device then there's no need to deal
    with any DMZs or any other separation of OWA from your inside network.
    You just VPN to the network and then connect to OWA/Exchange which
    resides "next" to Exchange. This of course requires client side
    software and configuration.

    I'm working for a customer right now where we are deploying a
    reverse-proxy that does authentication of the users on the Internet
    before allowing them access to any inside web servers. All requests are
    re-written to look as though they came from the proxy. This is probably
    the best method to deploy web servers to the Internet securely.

    Of use your firewall to authenticate. Although users still access the
    servers directly, the firewall can authenticate the user before allowing
    them to access the services. Checkpoint and Pix firewalls can do this.
    In Pix 6.3 due out in March, the Pix will be able to do secure
    authentication for HTTP and HTTPS before allowing access.

    -----Original Message-----
    From: Henry Sieff [mailto:hsieff@orthodon.com]
    Sent: Thursday, February 13, 2003 10:24 AM
    To: 'KEITH KOOYMAN'; focus-ms@securityfocus.com
    Subject: Ye Olde OWA Topic (Was RE: Website inside or outside domain)

    > -----Original Message-----
    > From: KEITH KOOYMAN [mailto:pcsolutions101@hotmail.com]
    > Sent: Wednesday, February 12, 2003 3:00 PM
    > To: focus-ms@securityfocus.com
    > Subject: RE: Website inside or outside domain
    >
    >
    > As I have followed this thread I have noticed that no one has
    > addressed the
    > similarities between this situation and OWA. Essentially,
    > this is much the
    > same scenario, where a public web server is in the DMZ and
    > the question is:
    > How do I allow access to the back-end Exchange Server?

    The same logic applies: IF you must do ANY of these, then you have to
    establish some sort of control over access to the OWA server itself; it
    can't just be a public web server. You can do this through a VPN, with
    the
    OWA server being at one end and your pre-approved clients being at the
    other
    end. Put the OWA server on its own segement with whatever VPN device you
    choose, and then you can open up holes between OWA and the backend,
    since
    you have established a reasonable level of assurance that the only
    traffic
    coming into that segment is legit.

     
    > You can:
    > 1. Put a firewall between the DMX and the LAN (many firewalls have a
    > preconfigured DMZ so a second firewall is not needed) and
    > open up so many
    > ports from the DMZ to the LAN that the firewall is useless =
    > the official
    > Microsoft solution

    Bad (but mitigated by the suggestion above).

    > 2. You can leave the front-end in the DMZ and use pass-through
    > authentication which takes web traffic straight to your
    > back-end = not
    > desireable

    Might as well not even use OWA at that point; I mean, its not like the
    interface is that great.

    > 3. Multi-home the front-end public web server, use TCP/IP
    > filters, IPSEC
    > and firewall rules to filter, authenticate and encrypt
    > traffic going to the
    > back-end; a good idea but time consuming and difficult to set up

    Horrible horrible horrible. At that point, you are essentially putting
    ALL
    of your faith in the integrity of the software and in your ability to
    manage
    the rule sets. All it takes is one mistaken mouse-click and presto, your
    web
    server is now routing from your DMZ to your LAN. And, you are also
    implying
    that your public web server can be hardenend enough to make it a
    firewall
    (that is, a device enforcing a boundary between different trust levels);
    it
    can't be done.

    > 4. Move the front-end public web server to the LAN = not desirable

    Again, why not just move the Exchange server to the DMZ and ditch OWA;
    same
    level of security, better interface, less moving parts.

    > 5. Use a third party hybrid solution = expensive

    Depends what you mean. Add an additional leg to your network, throw in a
    vpn
    device (and I think you can probably even use PPTP running on a hardened
    Win2K server and get away with it; at least you get some benefit) and
    your
    basically done. You can do it all on *BSD too. Doesn't have to be
    expensive,
    although the judging factor is how much the security is worth to you.

    Relevant Pages

    • RE: [fw-wiz] Single Exchange/OWA on LAN with Internet Access - a good
      ... The ISA acting as a proxy in the DMZ is a good option I think ... because ISA is designed to work with OWA or is it the other way round. ... in the DMZ or an ISA Server. ...
      (Firewall-Wizards)
    • Re: Unable to join AD domain from DMZ network
      ... To me that points to something outside the machine (Firewall most likely culprit) ... > the captured traffic between the server in DMZ to the DC from internal ... >>> authentication from DMZ to 2003 AD internal network. ...
      (microsoft.public.windows.server.active_directory)
    • Re: Best practice to setup a DMZ? (hyperV and guests)
      ... this time with an edge server (its my understanding that the ... So my goal here is to setup this edge server for OCS and setup exchange 2010 ... correctly dmz wise (not clear on how that would be yet.. ... The most common setup is the back to back firewall model, where you have one firewall between the Internet and the DMZ and another between the DMZ and the LAN. ...
      (microsoft.public.windows.server.networking)
    • Re: OWA Issues w/ small Bus. 2003 server
      ... I know your suggesting to bypass the firewall but i had cisco engineers ... any thing else on the OWA / SBS2003 Side that may be the culprit? ... you only have 1 NIC in your SBS Server? ... firewall to users on the Internet: ...
      (microsoft.public.exchange.admin)
    • Re: Member Server Login Slow DMZ-Internal Subnet
      ... But did I mention that the firewall log showed a successful port 53 ... connection to each DC from the DMZ machine? ... the DMZ machine is the closest AD DC DNS. ... Member Server which was originally installed in the internal subnet ...
      (microsoft.public.win2000.security)