RE: NTLM authentication from DMZ

["Ben Nagy" <ben () iagu net>]

> -----Original Message-----
> From: firewall-wizards-admin () honor icsalabs com 
> [mailto:firewall-wizards-admin () honor icsalabs com] On Behalf 
> Of Frank Knobbe
> Sent: Thursday, September 19, 2002 10:24 PM
> To: Ben Nagy
> Cc: 'Jan van Rensburg'; firewall-wizards () honor icsalabs com
> Subject: RE: [fw-wiz] NTLM authentication from DMZ
>
>
> On Thu, 2002-09-19 at 02:13, Ben Nagy wrote:
> > The key threat is that someone will hack your IIS box and 
> then sit on 
> > it gathering valid password pairs for the LAN domain, and then just 
> > access C$ on whatever box they like as soon as anyone in the Domain 
> > Admins group checks their mail. We could argue about 
> countermeasures 
> > to that [so let's do so...]
>
> Doesn't have to be that way. The OutlookWebAccess box only 
> needs to have access to the Exchange server and domain 
> controllers. You could use a DC in a third DMZ segment and 
> only allow the OWA box to validate accounts against it. That 
> box in turn can talk to internal DC's. That way you limit 
> access from the OWA box to internal DC's. Yeah, doesn't 
> prevent password cracking, but it is still much harder to 
> poke through to the LAN.

Well, according to the MS docs [1], you need to open the works to get
the domain and trust thing to work. Note that the MSKB article also says
that the OWA box needs to be in the same domain as the Exchange server
[2](I can't believe that's true - can anyone confirm it doesn't work
with trusts?). 

Are you saying that you can block nb-session and have everything still
work? If that's so we're much better off, but I'm not sure I see much
benefit in this isolated DC in another segment; if not then there's just
a trivial two step attack via nb-session as soon as a good enough
password turns up. The only way to stop that would be to have a firewall
that knew enough about MS NBT to stop file sharing but allow whatever
else is supposed to run over tcp/139. In theory I know that you
shouldn't need nb-session at all, but I have distant memories of the
solution barfing without it - it has, however, been a good few years
since I was involved in one of these. 

I guess that's all out of date now anyway, since Exchange 2000 uses
different ports altogether. I'm no Win2K guru, but SMB over TCP (port
445) is on the list of required ports for the 2K solution [3], and
that's used for accessing SMB shares "without the extra layer of NBT"
[4]. Presumably you'd need to be able to block that to get this thing to
work securely with an Exchange 2000 box.

> RPC (and the two 'fixed' Exchange services) only need to be 
> available to the Exchange server not the whole network.
>
> So the statement 'then just access C$ on whatever box they 
> like' is only valid if you drop the ball in the firewall 
> config. Neatly tightened, there is no c$ access.

So how much can you tighten it and still have a working solution? Do you
have a more accurate list of which ports are required for the NT and
2000 solutions than Microsoft's? (I'm NOT being facetious here - my
recollections are based on distant memory and theory, and I know for a
fact that MS are loath to explain how to minimize services.)

> I agree with the rest, such as:
[...]
> Frank

Cheers,

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;Q179442
[2] http://support.microsoft.com/default.aspx?scid=kb;en-us;Q259240
[3] http://support.microsoft.com/default.aspx?scid=KB;EN-US;q280132&;
[4] http://support.microsoft.com/default.aspx?scid=kb;en-us;Q289241
--
Ben Nagy
Network Security Specialist
Mb: +41792504687  PGP Key ID: 0x1A86E304 

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards