Implementing rules for RPC traffic

[Maik]

Hello guys,

I have a small question regarding the implementation for RPC traffic. Until a few weeks ago I barerly dealed with this topic. But now I need to make a configuration to allow some Oracle/Sun servers to get accessed via RPC.

I would summarize the general function of RPC like this:

- the client initiates a connection to the destination via a standard tcp handshake via a portmapper, TCP 111 for Oracle based systems/services and TCP port 135 for Micrsoft based systems/services.

- with the forth packet the client requests the uuid of the specific application from the server

- the port mapper answers with the related service as well as an acknowledgement and the connection is initialized

- now client is able to communicate to the related server process and receive the necessary information. It's also possible for the client to receive further information via the port mapper.

...

- after all the necessary data has been exchanged the connection is brought down via the the standard fin/ack procedure

Now my questions are:

- Is my assumption to this point correct?

- Do I just need to allow the port mapper port as well as the related RPC service (with its UUID) in order to bring up a RPC connection via a firewall?

- What exactly is the security gateway doing with the uuid information? What does the uuid mean for it - is it just a pointer where the gateway should look within the port mapper communication?

(I know that SecureXL is being disabled from the point where a RPC rule is implemented in my rulebase.)

Thank you in advance for possible answers and hints!

I'd also really appreciate it, if you should have any further RPC (and firewall, as a combination) related information besides answers to my questions.

Best regards,

Maik

[PhoneBoy]

You're more or less correct.

Basically if we see the relevant UDID with the request, the firewall will open the necessary ports communicated as part of the RPC session.

Otherwise, the firewall will not open the necessary ports and the application's attempt to communicate will be blocked.

[Dor_Marcovitch]

Rpc like ftp it has "control channel" and "data channel".

Basicaly you will connect to the portmapper port to ask to connect to a service.. The service is identified by the uuid your are sending. As an answer to that connection request the server will tell the client to.which port to open a new connection in order to connect to.this service. 

The job if the fw in this scenario is to listen to.the session and dynamicly open a rule to allow the communication. In checkpoint scenario you can also decide to which uuid you want to allow the connection for... But to be honost in 8 years i have never seen a customer enforcing it.. And alowing all uuid.

[Maik]

Thanks for your answers!

Now the question that comes into my mind is... what is the actual difference between RPC and DCE-RPC Services? DCE-RPC Services allow the configuration of the previously mentioned UUID which seems to be linked to a specific service on the destination/server side. The "standard", or only, RPC services without the pre standing DCE, allows the specification of a "program number". Is this also directly linked to a specific service on the destination side?

What is the difference between both? Do I need to specify the port mapper as well as the related DCE-RPC and RPC service within a rule to allow such traffic? Sorry if these questions appear to be weird, but I was not able to find a definitive explanation via the research I did.

[Dor_Marcovitch]

The difderent should be the enforcement of the uuid.. I use all-dce-rpc one since i dont care about anforcing the uuid.

Use the relevant if its windows or linux.

You SHOULD NOT specify or configure the port mapper port on the dashbord.. Use only the default ones. (Dont create tcp service of port 135) just use the dce service on the relevant rule. When the fw try to match the policy if it reaches a rule with the rpc service it will trigger the alg (application layer gw) feature to listen to the rpc traffic and open the relevant oorts for the next session as sent be the server. Just like ftp traffic.

Creating a custom port for example for pot tcp 135 messes up with the alg fubctionality.

If the traffic is not rpc traffic it might be dropped by the fw, you can edit a file to allow non rpc traffic on port 135.

There is a lot of documentation about it on the knowledge base.

[Maik]

Ah great, didn't know this!  

Does this also mean I need to re-specify my "port mapper port", as the Oracle servers are using TCP 111 instead of 135 which seems to be the default one? I saw a SK that mentioned a config file which included the port mapper information. Unfortunately I am not able to find it now.

[PhoneBoy]

I think you mean: DCE-RPC Interface UUID do not pass through Security Gateway, despite the rulebase that allows such t... 

But it may also be worth a TAC ticket.

[Yaniv_Atia]

Hi and thanks for the usefull explanation. I have another issue concern tcp/111 sunrpc. 

I see accept log from clients x to server y on port tcp/111 and next to it reject log from the fw interface ip address to the same server y.

does it make sense?

Thanks