[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 11:11:35 -0500
Unless it's about liquers. ;)
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Monday, June 26, 2006 11:09 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RPC filter and ISA port stealing -
> limitation???
>
> Tom was right; I was answering in a caffeine-deprived state.
> If I get some time, I'll play with this and see if there's
> anything that can be done; but be warned - I rarely find
> myself in opposition to Tom's observations...
>
> -------------------------------------------------------
> Jim Harrison
> MCP(NT4, W2K), A+, Network+, PCG
> http://isaserver.org/Jim_Harrison/
> http://isatools.org
> Read the help / books / articles!
> -------------------------------------------------------
>
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> Sent: Monday, June 26, 2006 06:50
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RPC filter and ISA port stealing -
> limitation???
>
> Hi Jim,
>
> Yep, I appreciate the need for routing as opposed to NAT.
> Maybe I haven't explained myself very well...
>
> As you are aware, when server publishing services that are
> routed, it is necessary to define the published server by its
> actual IP address and therefore cannot bind to external
> interface listeners for different services. In this scenario,
> ISA has to listen for requests and "port steal" in order to
> server publish correctly. I am basing this on what I am
> seeing and also Tom's article, please correct me if I am wrong...
>
> So, assuming we have both AD and Exchange behind ISA, in
> separate ISA networks, with a route relationship between
> external and each ISA network, can we achieve the following:
>
> * Use the RPC filter with defined Exchange UUIDs to ensure
> only Exchange related RPC is used (e.g. Secure Exchange RPC
> publishing)
>
> * Use the RPC filter generically to protect DC against
> malicious RPC (e.g. standard RPC publishing not limiting UUIDs)
>
> * Or even better, use the RPC filter with defined UUIDs to
> ensure only AD related RPC is used. (e.g. secure AD RPC publishing)
>
> I know that these can be achieved individually, the crux of
> my question is *** can they be achieved at the same time? ***
>
> Tom's article seems to suggest this is not possible, but I
> was hoping to get some additional feedback after discussing
> it offline with Tom.
>
> Thanks
>
> JJ
>
>
> ________________________________
>
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: 26 June 2006 14:23
> To: isapros@xxxxxxxxxxxxx; isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RPC filter and ISA port stealing -
> limitation???
>
>
> If you use ISA to separate AD members, you *must* have a
> routed relationship between them.
> If you use NAT, you break ~half of the protocols used.
> "Port stealing" isn't the issue.
>
> ________________________________
>
> From: isapros-bounce@xxxxxxxxxxxxx on behalf of Jason Jones
> Sent: Mon 6/26/2006 5:05 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: RPC filter and ISA port stealing -
> limitation???
>
>
> No takers?
>
> Jason Jones | Silversands Limited | T: 01202 360489 | M:
> 07971 500312 | F: 01202 360900 | E:
> jason.jones@xxxxxxxxxxxxxxxxx <mailto:jason.jones@xxxxxxxxxxxxxxxxx>
>
>
>
> ________________________________
>
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
> Sent: 22 June 2006 15:17
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] RPC filter and ISA port stealing - limitation???
>
>
>
> Hi,
>
> In some of Tom's older articles, he has talked about problems
> that can occur when you are using the RPC filter to protect
> *both* domain controllers and Exchange servers behind the
> same ISA array. This problem seem to occur due to the nature
> of ISA performing "port stealing" in order to listen for
> incoming RPC connections and map port accordingly. An example
> quote from Tom's article may explain this a little better (see below).
>
> A lot of our solution designs are starting to place all
> Microsoft services behind ISA in untrusted environments (e.g.
> universities) and hence the need for the RPC filter to
> provides limited UUIDs for Exchange and also to allow all or
> limited UUIDs for AD is starting to become more and more
> apparent. Up until now it hasn't been much of an issue as
> people have been reluctant to place AD servers behind ISA
> (mainly due to complexity and ISA dependency) or Exchange has
> been able to use the DSproxy process to allow Exchange
> clients with proxied indirect directory access.
>
> Is this still a known problem with 2k4 SP2 code or has it
> been fixed? Does ISA2k6 have anything to combat this problem?
>
> Cheers
>
> JJ
>
> "Because we are using a Route relationship instead of a NAT
> relationship between the source and destination Network, we
> can't bind a specific IP address to the listener used in the
> Server Publishing Rule. When you use a Route relationship,
> the Server Publishing Rule listens on all addresses bound to
> the external interface using a feature known internally as
> port stealing. Because both the Secure Exchange RPC server
> Server Publishing Rule and the RPC (all interfaces) component
> of the intradomain communications Access Rule are listening
> for similar communications, we end up with a conflict that
> prevents Outlook MAPI clients from connecting to Directory services.
>
> If there were a NAT relationship between the Corpnet and the
> network services segment, we could bind multiple IP addresses
> to the external interface of the network services perimeter
> ISA firewall. Then we could create two rules: one for Secure
> Exchange RPC publishing and the other for RPC (all
> interfaces) and use a different listening address for each of
> the rules. Machines on the Corpnet ISA firewall Network then
> connect to Secure Exchange RPC services or RPC (all
> interfaces) services using the IP address used for their
> respective rule's listener. This works because connections
> are made to the IP addresses on the ISA firewall's external
> interface when you have a NAT relationship between the
> network services segment and the Corpnet ISA firewall Network.
>
> It doesn't work when there is a Route relationship between
> the network services segment and the Corpnet ISA firewall
> Network because hosts on the Corpnet ISA firewall Network
> connect to the Exchange server using the actual IP address of
> the Exchange Server. Since the hosts are connecting to the IP
> address of the Exchange Server itself and not an IP address
> on the external interface of the ISA firewall, the ISA
> firewall's port stealing mechanism must listen and intercept
> RPC communications on all IP address of the external
> interface. This breaks the granularity required to allow both
> a Secure Exchange RPC Server Publishing Rule and a RPC (all
> interfaces) Access Rule on the same ISA firewall when there
> is a Route relationship between the source and destination
> ISA firewall Networks.
>
> You can confirm this by creating both a secure Exchange RPC
> Server Publishing Rule in the scenario used in this article
> series. Then attempt to make a connection to the Exchange
> Server from the full Outlook MAPI client using RPC (don't use
> RPC/HTTP, since the inbound connection is HTTP, so the ISA
> firewall doesn't see the RPC communications tunneled in the
> HTTP header). You'll that the connection seems to establish
> successfully, but if you open the Connection Status window in
> Outlook 2003, you'll find that the RPC connections are
> successful only to the Exchange Server's Mail Services. No
> connection is established to Directory Services. "
>
>
> All mail to and from this domain is GFI-scanned.
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
Other related posts:
