[isapros] Re: RPC filter and ISA port stealing - limitation???
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Mon, 26 Jun 2006 11:19:51 -0500
Good point. I'd like to hogtie the RPC filter dev and interview him for
an hour so that we could get a definitive white paper on how the RPC
filter works. :)
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 Jim Harrison
Sent: Monday, June 26, 2006 11:13 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: RPC filter and ISA port stealing -
limitation???
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:
