[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 11:07:09 -0500
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:
