Implied rules

[net-harry]

Hi,

I have two questions related to implied rules:

1. We historically have tried to avoid using implied rules to have better control of the traffic. What is the best practice regarding this?
2. When viewing the implied rules they all seem to have action Accept (or Encrypt&Continue). However, in the logs there is traffic dropped on implied rule (rule 0). What is the explanation for this?

We are running R80.20 JHA 183.

Thanks for your help!

Best regards,

Harry

[G_W_Albrecht]

1. I would assume to use the implied rules is the best practice - but also other considerations are valid. To  replace an implied rule by a manually created one changes logging only...

2. Drops on implied rule (rule 0) can be caused by (Core) IPS Protections, like protocol handlers, that are checked before rulebase (see sk136392, sk155152 for examples).

[PhoneBoy]

The implied rules you can set via Global Properties are largely a “horses for courses” discussion as far as whether you use them or not.
There are some implied rules that aren’t in the UI…for good reason.
SIC and/or VPN-related traffic are good examples of this.
There are ways of modifying these rules if you absolutely must do it, but it is not recommended.

Likewise, there are several sanity checks done on packets, some of which cannot (easily) be disabled.
Anti-spoofing is something you can effect the configuration of.
There are also a handful of IPS “Core” protections (actually enforced in the firewall) that may also apply. 

[net-harry]

Thank you very much @G_W_Albrecht and @PhoneBoy  for the information and help!

[net-harry]

@PhoneBoy,  do I understand correctly that we could safely disable all configuration options in SmartConsole for implied rules (including "Accept control connections") as long as we have the required rules in the rule base?

Thanks again for your help!

[G_W_Albrecht]

That is my personal experience - i know of such configurations and they work. But the only need would be to if certain traffic should be dropped that the implied rule would accept.

[RBP]

Allowing the traffic from internet to gateway with port 264 and 500, Vendor suggested to uncheck "Accept Control Connections" from implied global configuration. Is there any additional rule need to create in the explicit policy in order to communicate with management server and gateway or vise-versa.

[PhoneBoy]

Should you wish to disable implied rules and go with explicitly configured rules, please see the following SK for guidance: https://support.checkpoint.com/results/sk/sk179346 

[_Val_]

@net-harry technically yes. In practice, this is very cumbersome approach, and it is hard to manage

[MarkWeber]

HI @net-harry ,

See sk43401: 

Check Point does not support replacing implied rules with explicit rules.

Warning: If the predefined implied rules are disabled, policy installation could fail on managed Security Gateways, even if explicit rules are defined in place of the predefined implied rules.

Important Note: If you choose to disable all Implied Rules, you will need to manually configure the explicit rules required for the proper operation and communication of managed Security Gateways with the Security Management Server.

[Bob_Zimmerman]

Ish. Disabling implied rules gives you quite a few ways to shoot yourself in the foot quite impressively. Among other things, implied rules don't go over VPNs. I have personally seen situations (multiple times!) where somebody disabled implied rules in favor of explicit rules, then they lost the ability to push policy to any of their remote firewalls. All the remote firewalls expected the management server to reach them over a VPN now, but they couldn't negotiate the VPN because they couldn't get the CRL from the management server, because the VPN needed to be up for them to be able to get to the management. It was very time-consuming to fix, because they didn't have technical staff at these sites all the time, and it took hands on the firewall to unload the policy and get things working again.

Unless you are willing to accept the risk of things being down for several days when (not if) you make a mistake in your explicit rules, this is a bad idea.

[net-harry]

Thank you very much @G_W_Albrecht, @_Val_, @MarkWeber and @Bob_Zimmerman for your feedback!

Looks like the recommendation is to have implied rules enabled. Is enabling "Accept control connections" enough or are additional implied rules also recommended?

Which are actually enabled by default?

Thanks again for your help!

Harry

[_Val_]

This is how default looks:

[John_Fleming]

That being said it sure would be nice if you didn't have to hack things to get ldap or cprid over ipsec.

[Paul_Hagyard]

There are some very good reasons why controlling with specific rules is preferable - such as using updatable objects to restrict VPN RAS access to specific countries. However, with more recent versions it appears that the implied rules continue to work regardless of disabling the implied rules and configuring specific rules. I've been unable to restrict either Mobile Access or traditional IPsec VPN RAS using traditional firewall rules with R80.40. There are also reliability issues - if you disable the implied rules and add a specific rule for 4500/UDP inbound for VPN RAS you also need to allow traffic from the gateway out to UDP high ports because intermittently the gateway drops IKE NAT T replies - hence the rule to permit out of state. Have had SRs open for this to no avail. Previously we used to set the source port for this out of state rule to 4500/UDP, but after R80.20 that causes SecureXL to disable templates from that rule.

If you want to control access to your firewall you need a firewall in front of your firewall!