The "Match on any" is for defined services that are in conflict.
e.g. ssh and ssh_v2; an "any" rule matches "ssh"
If "any" was not "all ports and protocols" the "any any any drop" rule wouldn't work.
I've posted this before, but I can't find it right now.
The following is from Check Point Development
Quote:
“Any” service means every port (known, defined, unknown, or undefined) when used in the rulebase. Otherwise, “any, any, any, any, drop” rule would be completely worthless.
However, there are various reasons why a packet may get dropped despite having a single any,any,any,any,accept rule in the rulebase. These reasons vary from version to version and hotfix to hotfix primarily because these versions can include new deep-level application inspect (service dropped by SmartDefense protocol enforcement such as SIP drop when encapsulated in http).
Some common reasons for drop packets despite “any-accept” rule:
- Protocol enforcement (i.e. port 80 really is http traffic)
- IP Options flags exist on the IP header and is dropped before rulebase (i.e. PIM multicast traffic in version 4.1)
- (Rare) Limitation in Firewall, Acceleration, QOS, or Clustering implementation that see the traffic as invalid (usually quickly fixed in a later HFA or SHF)
- TCP out of state (asymmetric routing problems or long delays that allow tcp start timeout to expire before syn-ack)
- UDP or undefined service out of state caused by bi-directional data traffic
- Complex code required for NAT and other functions but proper inspect is not being called by “any” rule (mentioned by Adam)
o this can happen when more than one service of a specific port # is defined with “match for any” checked
o or, if “match for any” checkbox was removed from an important service definition and other duplicate service objects exist with less complex inspect code calls
o or, if a new service was defined and selected as “match for any” which negates the inspect code of other pre-defined services. An example of this would be manually creating a tcp service for port 135 and configuring it for “match for any”. This would potentially prevent the portmap service from properly matching the dce-rpc code uuid’s defined in the dce-rpc pre-defined services.
In short, because the list of reasons is dynamic from one version to the next and can be very specific to unpredictable customer mis-configurations, it is not practical to try to compile a complete list and keep it up-to-date.
I hope that the above information helps you respond effectively short of providing a simple list. |