RPC Traffic between domain controllers dropped

[David_C1]

We have domain controllers that live in different data centers that are having issues performing replication of sysvol and netlogon shares. This replication is done via RPC. I have a rule to allow traffic between the domain controllers using the ALL_DCE_RPC service object. TCP/135 is being allowed, subsequent high port traffic for this replication is being dropped. Other RPC traffic between the domain controllers is being allowed by this rule.

Above this rule, I created a new rule for traffic between the domain controllers, but in this rule, I used the application object "DCE-RPC Protocol". Replication then succeeded, RPC traffic is allowed by this rule (Application Names listed as "MS-DFS-R" and "DCE-RPC Protocol" in the logs).

Questions:

Anyone else see this behavior for replication traffic?

What are the pros/cons to using the application object "DCE-RPC Protocol" instead of the service object "ALL_DCE_RPC"?

Relevant information: gateways are running R80.40 with JHFA Take 180.

Thanks,

Dave

[PhoneBoy]

ALL_DCE_RPC can be used with only Firewall blade active.
However, this is one of the few services that still disables SecureXL templating in the Access Policy.
It will be processed in the Firewall (slow) path. 

"DCE-RPC Protocol" requires App Control and is processed in Medium Path, which means performance should be better.
Due to how App Control works, this will allow (at least briefly) TCP connections on any port between the hosts/networks specified in the policy.
To understand why, see: https://phoneboy.org/2016/12/14/which-comes-first-the-ports-or-the-application-id/ and the application definition here:

I don't believe ALL_DCE_RPC has the same issue.

[David_C1]

Thanks PhoneBoy,

Still figuring out the best way to solve this issue. From a performance standpoint, using the application object "DCE-RPC-Protocol" may be better (and the fact that in my case, the RPC traffic is actually allowed, this is better). From a security standpoint, not sure which is better. FWIW, I have seen traffic which should be allowed by the service object ALL_DCE_RPC temporarily blocked (on the negotiated high port) and then allowed a second or two later. So it seems using this object can have the opposite effect.

I guess it comes down to this question - which item, the service object ALL_DCE_RPC or the application object DCE-RPC Protocol more accurately can identify RPC traffic and then appropriately allow it.  This is a specific instance of a general question - which is better (secure, accurate in Check Point's world), using traditional services, or where available, application objects for traffic control?

Dave

[Lesley]

The third option is allow the use of TCP range 1024 and up > 

By default, RPC uses ports in the ephemeral port range (1024-5000) when it assigns ports to RPC applications that have to listen on a TCP endpoint.

This does not affect SecureXL as stated before. 

[David_C1]

To me that is the least attractive option, in fact we moved away from that for RPC traffic because I did not like allowing tcp high ports in this manner. For the most part, the service object ALL_DCE_RPC does what it should, but there are certain instances where it is not allowing RPC traffic, and at least in one case, replacing it with the application object DCE-RPC Protocol fixed the issue.

Dave

[PhoneBoy]

The ALL_DCE_RPC service was created well before SecureXL existed, much less Application Control.
As it involves a specific INSPECT handler in the kernel, the only way it can be updated is through a JHF or a version upgrade.
I suspect some of the behavior you're seeing with the service is related to changes made to the architecture of SecureXL back in R80.20.

That leaves DCE-RPC Protocol (the App Control signature), which is inspected in a SecureXL friendly way.
If it happens to not be accurate, it can be updated via a signature update.

As to which one is more accurate, I don't know enough to comment one way or the other.
However, there are use cases for both.

[the_rock]

Interesting read @PhoneBoy . You started working with CP in 1996? I think that was the time when Ipso was called Ipsilon? 🙂

[PhoneBoy]

I started working for a Check Point reseller back in 1996...back in the FireWall-1 2.x days.
Nokia bought a company called Ipsilon at the end of 1997.
Their operating system (IPSO) was originally purpose-built for networking (specifically as an ATM switch).
By the time I joined Nokia in 1999, IPSO 3.0 was released and its primary focus was running Check Point FireWall-1.

What does IPSO stand for?
I believe it is IP Switching OS.

[the_rock]

Ipso 3.0...was that not the version with this sort of green-ish web GUI? 🙂

[PhoneBoy]

Sounds about right 🙂