RE: [fw-wiz] NTLM authentication from DMZ

From: Ben Nagy (ben@iagu.net)
Date: 09/20/02 

From: "Ben Nagy" <ben@iagu.net>
To: "'Frank Knobbe'" <fknobbe@knobbeits.com>
Date: Fri Sep 20 07:59:01 2002

> -----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

Relevant Pages

  • Re: Open Ports required for RFC over HTTP
    ... We are using a cert issued by Geotrust. ... issued our cert, it was issued for the Cname, and worked fine. ... I asked them what ports they block, ... we can successfully connect to the exchange server. ...
    (microsoft.public.exchange.setup)
  • Re: Exchange connectivity through Firewall
    ... Considering the connections from Org A to Org B network will always ... will firewall forward rules to a target ... Exchange server will only see the external interface of the firewall as the ... I understand that Exchange 2000 services can be hard coded to certain ports ...
    (microsoft.public.exchange2000.connectivity)
  • RE: Mail connectors and pdf size limit?
    ... attachmenys mentioned in the second document were also disabled for incoming. ... and added the ports into the reservered ports restarting the server ... If you are using SBS 2003 server, please rerun the CEICW wizard which will specify e-mail attachments to be removed from incoming Internet e-mail. ... it should not be Exchange server issue but more related to your ISP or installed firewall or anti-spam software etc. ...
    (microsoft.public.windows.server.sbs)