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]
