What other types of RPC traffic would a company typically secure in this manner? I can see Outlook 2003 and Exchange but what else?
The following article describes the RPC dependant services:
[URL=http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/Resources/Documentation/windowsserv/2003/all/techref/en-us/w2k3tr_rpc_what .asp]What Is RPC?[/URL]
I've tried to use it to secure authentication traffic:
A terminal server in one domain authenticates users from a child domain - and therefore has to communicate with the DCs in the child domain over the ISA Firewall.
The authentication process involves RPC traffic among other things. Everything is great when I use the default "RPC (all interfaces)" definition in my Access Rule, but I would like to restrict the allowed RPC interfaces a bit further, so I've created a custom RPC protocol definition comprising the UUIDs, I see in my Ethereal network trace, which are:
An answer for PaulCyr...
I can give you 2 examples about this kind of infrastructure.
Example 1: I recently worked on an AD design for a company with 50 sites in the world. Part of these sites were the result of mergers, and so no fully 'managed and trusted'. So we wanted to make sure that AD replication from these sites to the 'corporate servers' were secured. With a layer 3 firewall, the only option is to force all the RPC service to use specific ports... with ISA 2004 as a firewall we just had to filter UUIDs... On site was located in Asia and this site was trusted. We wanted to authorize the local IT team to manage a few servers at corporate site (I mean run a few MMCs). With a layer 3 firewall no way. With ISA I implemented exactly what I describe in the article.
Example 2 : suppose that a small company ask another company to manage the server (create users, exchange mailboxes, ...). This external company works via VPN. If you want to limit what this company can see from their site, RPC filtering is perfect. (of course if you give TSE you are bad).
What is you experience and comments about the article ? and the need of filtering RPC ?
hi i want to ask something I have new ISA2004 SERVER and i have internal,DMZ and external networks
i have a MOM server in the DMZ ,and i have the MOM agent (client) in the internal network, i think RPC is used to enable there communication
now,how should i enable such comunication??
---------------- another question:
Suppose i have an exchange in the DMZ and iam in the internal network,now i will first contact to port 135 to the exchange to specify the high port of the target service i want to connect to ,the out of the BOX ISA would monitor the traffic by default?? and then he would see the return port that i will use to connect to the exchange and thus he would allow the connection?? or should i create a rule to allow 135 port from internal to DMZ??
Like everyone else here, I have had nothing but trouble with this RPC filter, and have become extremely skeptical, especially of the ISA MMC example used. Ethereal shows that the ISA MMC NEVER makes any request on 135 - it always uses the MS Firewall Control port as configured in the Protocol definitions on 3847. Other RPC apps call first of all of couse to EPMAP, the expected 135.
The access rule / inbound setting is curious also - set to inbound, the rule is completely ignored, which explains why everything is denied by the default rule, because the traffic is not recognised as fulfilling the criteria of that rule. Changing the direction to Outbound results in the traffic being recorded under the Access Rule - but this removes the Interfaces tab from the protocol properties. And in any case the access is still denied - the initial RPC call to 135 is allowed but the subsequent high-port traffic is denied. Using a server publishing rule, which is what would be expected on an Inbound protocol, the traffic is identified as RPC (all interfaces), and is permitted, but then the client sends the OXID Resolver interface, not the one attached to the app, and communication continues on 135 only. Now given that the OXID Resolver uses DCOM protocols, this can never work with ISA because you can't access the Configure RPC Protocol option to uncheck "Enforce strict RPC compliance" when the protocol is used in a Publishing rule - only in an Access Rule can you select this.
One further interesting thing: If I create an access rule allowing the MS Firewall Control protocol, and then use the ISA RPC protocol in a publishing rule, it will allow the client MMC to connect. I have disabled the System Policy Rule that allows Remote Management. When I disable the publishing rule again the client connects but will not allow any changes. In the live logging I see denied RPC (all interfaces) connections. Ethereal continues to report that the communication is being attempted over the UUID interface specified in the [now disabled] RPC protocol.
So, I am at a loss, as it would seem is everybody else here, to see how this RPC filter is supposed to work. Any input is mooooore than welcome. Does ANYBODY actually have a working RPC filter?
< Message edited by a13antichrist -- 13.Jan.2006 1:11:59 AM >
I am having the same problems as the others have mentioned. I can only get the RPC to work if it is set to outbound, and open a range of ports. I need to be able to filter bu UUID, but I haven't been able to get this to work. Monitoring the logging in ISA 2004 it shows the RPC(All Interfaces) as denied. If I switch this protocol to outbound, or create a new protocol on port 135 as outbound, then the request on 135 is allowed, but the subsequent calls on the dynamic port are blocked...
If somebody has an actual working configuration could they post the xml export file so I can import it and see how it works.