RE: NTLM authentication from DMZ

["Noonan, Wesley" <Wesley_Noonan () bmc com>]

Perhaps I am oversimplifying here, but I guess I don't see the "big huge
deal" with OWA.

When I have implemented it (and seen it implemented), the first thing is
that the OWA server itself is hardened and monitored very closely. Most
sites have IDS now, and they watch the traffic passing back and forth,
looking for things like file share access. Second, the access for the OWA
server is actually minimal to the internal network. Here is a section of a
PIX config where the DC was an Exchange server (it is from a rather old
config):

conduit permit udp host 172.16.1.1 eq netbios-ns host 10.100.0.10 
conduit permit udp host 172.16.1.1 eq netbios-dgm host 10.100.0.10 
conduit permit tcp host 172.16.1.1 eq 139 host 10.100.0.10 
conduit permit udp host 172.16.1.1 eq 139 host 10.100.0.10 
conduit permit tcp host 172.16.1.1 eq 135 host 10.100.0.10

5 lines, and quite frankly I don't recall it needing 135 or the TCP 139 (or
maybe it was the UDP 139, either way...) which were turned off (the config I
have still shows them, but they were turned off in a later config). If
someone can compromise the OWA box (sure, that is always a possibility, but
it is sitting on a DMZ protected by the PIX doing ingress and egress
filtering and as mentioned, one should be using SSL anyway, IOW it is pretty
well hardened and protected), then they could get access to the DC, but that
is an awful lot of work, and even then they don't have free range on the
internal network yet. This is where one's security policy comes into play
anyway. Someone should be monitoring these boxes, and for the amount of time
that it would take to get this far, I would hope that any decent security
admin would be onto it by now (there would be an audit trail a mile long in
the IDS and event logs).

If you really wanted to get paranoid though, you can always dual home the
OWA box onto separate DMZ and outright unbind services and filter ports to
get an even more hardened box (the external interface does TCP443 and
nothing else, the internal interface is the only one running NETBIOS, etc.).

Again, maybe I am oversimplifying here, but I have never really seen the big
deal on this particular issue (OWA). It is far better than any alternative I
have seen (both in terms of function and security). If I am wrong, I am open
to some edumication :-)

Wes Noonan, MCSE/CCNA/CCDA/NNCSS
Senior QA Rep.
BMC Software, Inc.
(713) 918-2412
wnoonan () bmc com
http://www.bmc.com


> -----Original Message-----
> From: Mikael Olsson [mailto:mikael.olsson () clavister com]
> Sent: Friday, September 20, 2002 09:32
> To: Jan van Rensburg
> Cc: firewall-wizards () honor icsalabs com
> Subject: Re: [fw-wiz] NTLM authentication from DMZ
>
>
>
> Jan van Rensburg wrote:
> > A related question I've sometimes wondered about, is where is the best
> > place to put a company's Exchange server. Let us assume that the
> > Exchange server is part of the normal company domain, so that you only
> > have one authentication database to deal with. The second assumption is
> > that people will access their Exchange mail remotely from the Internet.
> > Now the obvious answer to this is a VPN, but lets assume that this is
> > not possible.
>
> I've been over this I don't know HOW many times on different mailing
> lists, and I've never managed to come up with an easy answer.
>
> The basic problem is that you need to allow _A LOT_ of traffic between
> the OWA box and the Exchange server and DC. So much in fact that there's
> almost no point in putting in it a separate segment.
>
> The only point remaining for putting it in a separate segment is that
> you can restrict access to only the above mentioned machines, and
> spend LOTS of time hardening them. (Including such non-obvious things
> as fixing the broken default permissions in the registry and so on).
>
>
> My first recommendation would probably be: stick something in front
> of the OWA box that does SSL and authentication. If someone gets to
> the OWA box, it's more or less game over; if nothing else because
> of all the sensitive stuff that is usually available in people's
> inboxes, public folders, etc etc.
>
> The "something" in front of the OWA box can/should probably use a
> different means of authentication. SecurID comes to mind; it's not
> _that_ expensive to implement and maintain, and still enables
> people on the road to check their mail from internet cafés.
> (Whether or not they should be allowed to _do_ that is another
> question altogether. Probably, the answer is "no", but that's never
> stopped a user from doing dumb things.)
>
>
> --
> Mikael Olsson, Clavister AB
> Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
> Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
> Fax: +46 (0)660 122 50       WWW: http://www.clavister.com
>
> "Senex semper diu dormit"
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards () honor icsalabs com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards