[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 09:13:10 -0700
interesting stuff; but the RPC filter is the one responsible for recognizing &
accommodating the secondary connections.
You should note that it acts very differently for access rules vs. publishing
rules, though.
-------------------------------------------------------
Jim Harrison
MCP(NT4, W2K), A+, Network+, PCG
http://isaserver.org/Jim_Harrison/ <http://isaserver.org/Jim_Harrison/>
http://isatools.org <http://isatools.org/>
Read the help / books / articles!
-------------------------------------------------------
________________________________
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx] On
Behalf Of Thomas W Shinder
Sent: Monday, June 26, 2006 09:07
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: RPC filter and ISA port stealing - limitation???
Hi Jason,
Joern Wettern shared some interesting information re: the RPC filter with me
the other day. Check this out:
OK, here are the details:
For RPC connections Local Host --> Internal or Internal --> Local Host
(i.e ISA acting either as the RPC client or the RPC server):
Some RPC traffic flows correctly. But, after the RPC server returns the
secondary port for certain operations (always at the same point of the
overall communications sequence), the client establishes the connection
to the secondary port. ISA Server detects these secondary connections as
an entirely new connection attempt, identifies them as new connections
and blocks them based on the Default Rule I checked this in NetMon and
compared it to a successful direct connection (not involving ISA in any
way), and it is indeed the secondary connection that is blocked, not
something else.
Once I create a new rule to allow "All network traffic between Local
Host and Internal (or vice versa, depending on the direction of the
connection), ISA still identifies the secondary connection as a new
connection and labels the protocol as "unknown." However, now this
connection is allowed because of the new rule I created.
Yesterday I had a different issue that showed the expected behavior with
traffic going *through* ISA. In this case I had an existing rule to
allow "All network traffic" between "VPN Clients" and "Internal."
However, connections over port 1719 were blocked based on the Default
Rule. Once I created a protocol definition for port 1719, ISA started
allowing the traffic.
BTW, an unrelated surprise I ran into when dealing with the client issue
was the following: The H.323 protocol definition exists in the
Enterprise and has the H.323 app filter associated with it. I had to
re-define this so it wouldn't use the app filter, so I deselected the
checkmark in the enterprise protocol definitions. However, it turned out
that when I looked at this in the array, the connection was still there.
After some experimenting it turned out that: 1. If an app filter linkage
exist in the enterprise, this gets enforced at the array. If you disable
it in the enterprise, you can then choose whether the protocol
definition in the array is associated with the app filter or not. Policy
enforcement will depend on the setting that you select in the array. I
always thought that the default protocol definitions that appear in the
array Toolbox are simply pointers to the Enterprise definitions.
However, this doesn't seem to be accurate, either.
And just another FYI. The app I configured was Avaya IP Traveler, an app
that exchanges control information with the PBX but does no actual voice
communications. For example, you can use it to redirect your extension
to a different phone number and get alerted on your screen as calls
arrive--but you still have to pick up the phone associated with the
number. This app uses the H.323 TCP port 1720 but the communications are
apparently not H.323 compliant, so the filter chokes on it and has to be
disabled. This just in case you ever have to deal with this particular
app.
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7>
MVP -- ISA Firewalls
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
Sent: Monday, June 26, 2006 8:50 AM
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.
Other related posts:
