What is Check Point's solution for RPC traffic on Internal firewall?

[William_Chang]

We are using Check Point firewall appliance running in R80.10 as the gateway for vlans to manage the east-west traffic internally. We are looking for a solution to move to software define approach like vSEC.

However, the real world software define solution is not the same as most demo showed in the conference with simple 3 tiers: Web->App->DB. One thing most people will encounter is the Windows RPC traffic.

Check Point has a layer 4 protocol called "ALL_DCE_RPC" which covers all RPC traffic. However, using that protocol in your rule will disable the SecureXL acceleration for all the rules after that rule (Although I still don't have an answer from my Diamond about if use this rule in the inline layer, whether it will just disable the SecureXL for the rules within the inline layer or it will disable all the rules after the inline layer as well).

Check Point has an application called "DCE-RPC Protocol" using that, you will not see "xxx disables template offloads from rule yyy" message when you run "fwaccel stat". However, when you run "fwaccel stats -s", you still see majority of your traffic either in "F2Fed" or "PXL" categories. In order to use this application, you will need to turn on the application control blade.

If you read sk32578, a lot of traffic are not accelerated when you turn on advanced blades like application/URL filtering.

Check Point market R80.10 "unified rules" as their answer to Palo Alto. My question here is what's Check Point answer for utilization vSEC to control the traffic like RPC without greatly impact the performance?

[PhoneBoy]

Proper inspection of DEC-RPC can't be done at the SecureXL level, particularly if the traffic uses random ports.

If you are particularly concerned about performance, you can create simple TCP services for the necessary ports and use those in your policy instead (though this is less secure).

However, if you're also doing IPS or other threat prevention, most of your traffic is going to be at the PXL level anyway, just as it would be by enabling Application Control.

I'll have to do a little research on your question about disabling connection templates and inline layers.

[William_Chang]

Dameon,

Thanks for the information. However, it still doesn't answer my main question:

What's Check Point's layer 7 solution for the RPC traffic?

As you mentioned, the nature of the RPC traffic using random ports at layer 4 posted a challenge to NGFW. As Check Point pushing customers to adopt next-gen firewall features, it still lack of the intelligence and performance to address the dynamic traffic as the RPC at layer 7 even with the new R80.10.

This will be even more significant weakness when vSEC is fully adopted to the entire vCenter, where a log of guests will have these type of east-west traffic. Check Point seems still stuck in the mode of a perimeter firewall vendor, where the so called "applications" are most for web 2.0, not for internal enterprise traffic.

RPC is just one of the sample. The reality is there are more dynamic east-west traffic, like exchange traffic, voice traffic are very hard to write firewall policy using layer 4 protocols and lack of layer 7 application definition.

[PhoneBoy]

Layer 7 inspection of RPC traffic has been supported in some form or another since the product was called FireWall-1 (i.e. a VERY long time).

DCE-RPC in particular (the kind Microsoft uses) has been supported since version 4.0.

They are listed as Services of type DCE-RPC, not Applications. 

For instance, Exchange:

If we don't have the DCE-RPC service pre-defined, if you know the UUID, you can define it yourself as a service very easily:

 

All the caveats about SecureXL acceleration with DCE-RPC still apply, 

[Hugo_vd_Kooij]

So far I have used this only once. But if a programmer gives you the UUID then you can match it as described above.

[William_Chang]

You can't  claim Check Point does  layer 7 inspection on RPC traffic because the UUID is mapped to the TCP layer4 header.  It is not true application awareness when the firewall can't detect the dynamic port information derived from tcp/135 and dynamically permit/deny the related RPC traffic.

Yes, I have been using the Check Point since version 4. I know those exchange DCE services. Have you personally used these DCE services for the exchange? I have. I tried in R77, R80 and now R80-10. None of them work properly. In fact those DCE protocols are so old (you can tell by their name: MSExchange-2000, MSExchange_2007), it is laughable and embarrassment for Check Point still lists them here. Any companies which are still using those versions of exchange servers would not have any concerns about security.

The bottom line is as I mentioned, if firewall vendor like Check Point really wants to move from perimeter focused to Software Define focused to fend off not only traditional competitor like PAN but also new comers like NSX, ACI, creating vSEC firewall is not enough, who ever can come up with the innovations to truly provide solution to permit/deny east-west traffic based on enterprise applications (not just Web 2.0 traffic like facebook applications) will win the market. Palo Alto has some lead there. From my experience running R80.10 since June this year, Check Point still has a lot of works to catch up.  

[Norbert_Bohusch]

With R80.10 and the use of inline layers, you can move the SexureXL degradation for such protocols to such inline layer.

Just use any service in parent rule and allow only needed services (incl. DCE-RPC) in inline layer.

[Timothy_Hall]

Good recommendation for inline layers, if using ordered layers try to move rules allowing DCE-RPC services as far down as possible in the rulebase.  DCE-RPC is one of the few situations that can still halt rulebase templating in R80.10 gateway.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[PhoneBoy]

I just confirmed with R&D that if you have a rule that stops SecureXL templates, it only affects rules in that layer.

So, for example, if rule 2.5 uses DCE-RPC, rules 2.6-2.n will not have an acceleration template, BUT rules 3-X will (assuming they use services that are SecureXL friendly).

[Norbert_Bohusch]

I know this, was not only a guess 😉

[PhoneBoy]

I'd put the question into R&D before you posted... always nice to have double confirmation

[Timothy_Hall]

Makes sense, thanks for the clarification Dameon.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[William_Chang]

Dameon,

Thanks for providing the information about the DCE affect for in-line layer.