Not necessarily a bad idea, but unless OWA access is limited to a corp intranet, I would think that SSL would be the only viable option for a FE OWA server .
-----Original Message----- From: Rob Ellis [mailto:[EMAIL PROTECTED]] Sent: Monday, June 10, 2002 8:18 AM To: Exchange Discussions Subject: RE: lesser of the evils - ssl or smtp Or maybe use IPSec? Rob Ellis -----Original Message----- From: Myles, Damian [mailto:[EMAIL PROTECTED]] Sent: 10 June 2002 13:08 To: Exchange Discussions Subject: RE: lesser of the evils - ssl or smtp Soooo.... 80 TCP (HTTP) 389 TCP/UDP (LDAP) 88 TCP/UDP (Kerberos) 53 TCP/UDP (DNS) 135 TCP (RPC Endpoint) 3268 TCP (GC LDAP) 445 TCP (NETLOGON) Plus a static port for RPC >1024 Plus Registry change on DC's for lookups OR 443 TCP (SSL) Hmmmm.. choices choices. -----Original Message----- From: Roger Seielstad [mailto:[EMAIL PROTECTED]] Sent: 10 June 2002 13:36 To: Exchange Discussions Subject: RE: lesser of the evils - ssl or smtp The point, which you're missing, is for OWA (or a FE server) to work in the DMZ, you're punching a few dozen holes in the firewall to begin with, so you've already given that box significant internal reign, in addition to having opened a few dozen ports on the firewall that potentially give other access as well. Or you open on port for ssl only. ------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Peregrine Systems Atlanta, GA > -----Original Message----- > From: Ragar, Russell [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 6:21 PM > To: Exchange Discussions > Subject: RE: lesser of the evils - ssl or smtp > > > Okay, your specific point is that having a FE server in the internal > network is as good as having one in the DMZ? > > Well, if the FE server in the internal network is compromised it has > open access to all of your internal network. So, there would be be no > difference if all of the hosts and workstations within your internal > network were hardened to the security level provided by the firewall > between the DMZ and your internal network. But, practically, > I've never > found that to be a possibility. I suppose if I personally > created every > internal system I could achieve this, but I'd be swamped trying to do > this with more than a few dozen machines. Minimally, you'd need a > software firewall on all your internal hosts and workstations (which > admittedly is where technology seems to be heading). I suppose you > could put a router access-control list between your FE server and the > rest of your internal network, but really that would just be a way of > recreating a DMZ. But this path will become more elaborate than > deploying the DMZ. > > What is your fear of implementing a DMZ? It's no more > complicated than > the initial firewall deployment and often can be done with the same > hardware/software used for that firewall. > > My assumption is that you have an internal network. I > suppose if there > wasn't one, then my arguments might be tenuous. > > Regarding costs, you can't really design without attention to costs > (hardware, software, technician time, user disruption/training). Yes, > you can build rather than buy to some extent (open source firewalls, > intrusion detection scripts you design yourself, etc) but that would > just push up the technician time and expertise requirements to save > hardware and software costs. It might be entertaining to totally > disregard costs in an engineering solution, but it has almost no > practical value. Ultimately, resource allocation is the primary > limiting factor in all engineering designs, so I can't ignore costs in > proposing any solution. > > Russell Ragar, MCSE+I, CNE, CCNA > Senior Network Engineer > PowerTV, Inc. > > -----Original Message----- > From: Chris Scharff [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 07, 2002 2:37 PM > To: Exchange Discussions > Subject: RE: lesser of the evils - ssl or smtp > > > > -----Original Message----- > Regarding Outlook Web Access deployments, particularly with Exchange > 2000, I can see a large benefit to deploying a front end server in the > DMZ which communicates to the Internet client using SSL and > the backend > mailbox servers over HTTP. > > CS: Specifically over a FE server on the internal network? > > Not only is there off-loading of the > encryption processing, > > CS: Apparently not over a FE server on the internal network. I too can > compare apples and pears and claim an apple is a woefully inadequate > pear. > > but it provides you a location for containing > external attacks. > > CS: How specifically are they contained when between my FE > server and my > other E2K servers/AD/DNS servers there are a host of ports open, > including quite possibly the ports which you used to run your original > exploit. > > Yes, in a sense, all servers in the DMZ are > sacrificial victims. The theory is that you keep your sacrificial > victims in a contained area so they can be monitored carefully and you > fall back and reformat them as soon as they are compromised. > > CS: What are we using to monitor this box specifically and > what exploit > did we use to access the box in the first place (any Exchange version > 443 based > exploit) that our IDS is going to detect the behavior and alert us? > > Obviously > you need both intrusion detection and host-based firewalling with the > DMZ (to prevent compromise of the DMZ from host to host). If > there were > no front-end server (direct OWA access on the mailbox server) you > couldn't possibly monitor it as well since it is performing many more > functions. > > CS: This post began with the question of what is the advantage of a > particular server in a DMZ. Changing the equation to say 'if we add > this, that and the other, and implement a DMZ we'll be more > secure than > if we just publish our password on the internet' is silly. > > Also, you certainly couldn't scrub it easily if it were compromised. > > CS: IBID > > If you were running a front-end server internally > (no-DMZ), if that box were compromised it could be used as a staging > area for an attack on all your internal systems. > > CS: And the FE server in my DMZ couldn't? Puhleese. > > So, yes, the > assumption is that all machines in your DMZ will eventually be > compromised and they are suspect. > > Okay, given my recommended configuration, the essential > problem is that > the front-end server has to have access to some key internal > services in > order to function. The trick would appear to be to lock down those > internal services as much as possible and to get a really > good intrusion > detection system that will allow you to shutdown your front-end server > access to internal services as quickly as possible. > > CS: And I couldn't harden my FE server on the internal network in the > exact same way? What would be the net increased risk if I > were to do so? > > Okay, there is a cost associated with providing this type of set up. > > CS: Ignore cost, it's a red herring thrown up to say... if I > spend more > money than you, I can design a more secure system then you. If I spend > the same amount of $ and have the same basic config except my > FE server > is in my internal network specifically and demonstrably how am I less > secure? > > You can't run a front-end server on Exchange 2000 Standard, > you'll need > Enterprise. You'll need a good firewall. You'll need good virus > protection, host-based firewalls, and an intrusion detection system > (network defenses without intrusion detection is like a city wall with > no night watch). None of this is cheap, but that's the price of using > OWA on the Internet. If you don't have the money to do it securely, > don't provide the service. > > CS: I'm using OWA on the internet and am quite content with my current > configuration/ risks. I don't see how simply placing my OWA server in > the DMZ will make it more secure and your post, while interesting in a > 'it's redundant because it's been covered ad infinitum in the > archives' > kind of way is purely theoretical and demonstrates no intrinsic value > gained specifically from the placement of the Exchange server in a DMZ > in my mind. > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > > _________________________________________________________________ > List posting FAQ: http://www.swinc.com/resource/exch_faq.htm > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe: mailto:[EMAIL PROTECTED] > Exchange List admin: [EMAIL PROTECTED] > _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] ------------------------------------------------------------------------------ The information contained in this email message is privileged and confidential information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copy of this message is strictly prohibited. If you have received this email in error, please immediately notify Veronis Suhler Stevenson by telephone (212)935-4990, fax (212)381-8168, or email ([EMAIL PROTECTED]) and delete the message. Thank you. ============================================================================== _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED]
