GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: RE: pix, nat, and OWA [7:19152] posted 09/11/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


Hi,

You don't need statics if you disable nat....still need ACLs or conduits
(don't use conduits)

With OWA specifics:

1.  OWA must reside in same domain or in separate domain with trust -
therefore, yes NBT must flow...
2.  If OWA is on a IIS-only box (no Exchange) you MUST hardcode (well almost
must) the MSExchange Directory Service and Information Store RPC ports (this
is done by adding two registry parameters - see Technet).  This means that
when the MAPI client on OWA needs to talk to the Exchange server, it first
connects to the port mapper service on port 135, which always returns the
SAME ports for connecting to the directory service and information store,
and makes the ACLs easy to configure.
3.  OWA is definitely a big security hole, as the Exchange Service Account
Credentials are used by the OWA service.  Hence a compromise of OWA (how
easy is that?!?) could have extremely serious consequences.  My
recommendation is to run OWA with SSL, and use client-side certificates for
authentication as well as user authentication.


Regards

Justin Menga  CCIE #6640  
Network Solutions Architect
Wireless & E-Infrastructure
Compaq Computer New Zealand
DDI: +64-9-918-9381   Mobile:  +64-21-349-599
mailto: justin.menga@xxxxxxxxxx
web: http://www.compaq.co.nz


-----Original Message-----
From: Price, Jamie [mailto:JPrice@xxxxxxxxxxx] 
Sent: Tuesday, 11 September 2001 3:33 p.m.
To: Menga, Justin; 'Bill Carter'; Ccielab@xxxxxxxxxxx Com; Gordon White
Subject: OT:RE: pix, nat, and OWA [7:19152]


I may be wrong here, and more than likely as I usually do I may have misread
the requirement :),  but for OWA to run in a DMZ you're gonna need statics
and conduits for OWA to hit the Exchange box.  Nat would work for Exchange
wishing to talk to OWA but when users hit OWA then OWA is going to initiate
a conversation to the inside.  Higher security interface to lower security
level interface = statics/conduits (or ACL's if you prefer) not NAT.

Some other things you may want to consider with this:

In most cases I believe OWA needs to be in the same domain as the Exchange
server....in which case you'll need to open up a number of conduits to allow
synchronization from the DMZ server to the inside server (ports 137,138,139
- dangerous ports to have open - and also whatever port OWA requires to talk
to the Exchange box).  Doing this sort of makes the DMZ a pointless
exercise.  Sure, by putting it in the DMZ it'd be harder to use the OWA box
to break into the inside than if the OWA box was on the inside, but if
someone can hack it on port 80 then it wouldn't be impossible because of the
conduits needed for synchronization (and you can be assured that if they can
hack port 80 then they can also utilize/are familiar with 137,138,139).

I understand that you can run OWA in it's own domain but then you still need
to set up a trust with the Exchange domain - which again = conduits from the
DMZ to the inside.

I also believe that you can "tweak" OWA to talk to the Exchange server on
specific ports but I've heard this is a hassle.

I'd really put some effort into evaluating whether or not it is a worthy
exercise to put the OWA box into a DMZ.

Jamie

-----Original Message-----
From: Menga, Justin [mailto:Justin.Menga@xxxxxxxxxx]
Sent: Monday, September 10, 2001 9:42 PM
To: 'Bill Carter'; Ccielab@xxxxxxxxxxx Com; Gordon White
Subject: RE: pix, nat, and OWA [7:19152]


Just use the nat 0 command - configure your ACL for each traffic flow you
DON'T want to NAT

E.g.

Inside host = 192.168.1.10, DMZ host = 192.168.2.10


!  This disables NAT for any connections INITIATED from host 192.168.1.10 to
host 192.168.2.10 nat (inside) 0 access-list NO_NAT_INSIDE access-list
NO_NAT_INSIDE permit ip host 192.168.1.10 host 192.168.2.10

!  This disables NAT for any connections INITIATED from host 192.168.2.10 to
host 192.168.1.10 nat (dmz) 0 access-list NO_NAT_DMZ access-list NO_NAT_DMZ
permit ip host 192.168.2.10 host 192.168.1.10


Regards

Justin Menga  CCIE #6640  
Network Solutions Architect
Wireless & E-Infrastructure
Compaq Computer New Zealand
DDI: +64-9-918-9381   Mobile:  +64-21-349-599
mailto: justin.menga@xxxxxxxxxx
web: http://www.compaq.co.nz


-----Original Message-----
From: Bill Carter [mailto:bcarter@xxxxxxxxxxxxxx] 
Sent: Tuesday, 11 September 2001 2:54 a.m.
To: Ccielab@xxxxxxxxxxx Com; Gordon White
Subject: RE: pix, nat, and OWA [7:19152]


You could address the DMZ servers with public IP addresses.  Then 1 static
commands to tell the PIX not to translate the DMZ addresses

global (outside) 1 y.y.y.100 netmask 255.255.255.128
nat (inside) 1 192.168.1.0 255.255.255.0 0 0

static (DMZ,outside) x.x.x.0 x.x.x.0 netmask 255.255.255.0

Read this link for building the access-list controlling traffic between the
DMZ and the Inside.

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_v51/config/mse
xchng.htm


^-^-^-^-^-^-^-^-^-^-^
Bill Carter
CCIE 5022
^-^-^-^-^-^-^-^-^-^-^


-----Original Message-----
From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx]On Behalf Of
Gordon White
Sent: Saturday, September 08, 2001 10:41 PM
To: cisco@xxxxxxxxxxxxxx
Subject: pix, nat, and OWA [7:19152]


our pix is running nat, and i want to put an outlook web access server on a
dmz interface.  however, all the netbios communication to the domain
controllers and exchange servers seems like it is going to require a whole
lot of static/conduits and a serious lmhosts file.

bottom line: is there a way to enable nat just for inside addresses going
outside?  it seems that nat is an all or nothing set up.  i'd like to run
nat just on the internet interface.

thanks,
gordon
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
_______________________________________________________
To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab