This section provides a primer on how to review firewall rulesets from three vendors: Cisco, Check Point, and Palo Alto.
An access control list (ACL) is used to filter network traffic. For an ACL to take effect, it must be bound to an interface on the device. Packets are then matched against the ACLs bound to that interface to determine whether to forward or drop a packet. A MAC, IPv4 and IPv6 ACL can be bound to each interface. Multiple ACL of the same protocol cannot be bound to the same interface, they must be combined to accomplish the desired effect.
Object Groups for ACLs lets you classify users, devices, or protocols into groups and apply those groups to access control lists (ACLs) to create access control policies for those groups. This lets you use object groups instead of individual IP addresses, protocols, and ports, which are used in conventional ACLs.
The image below helps depict the interaction between Object Groups, Access Groups, Rules and Interfaces.
The Object Groups, Access Groups, Rules and Interfaces. are combined into a configuration file as shown below:
NP-View reads device configuration files and can be used to review and verify the ruleset configuration using the Access Rules feature. An example is below:
Check Point segments security management into multiple virtual domains. Security policies can be created and privately maintained per Domain. The image below helps depict the high level interaction between domains and the domain server.
Some security rules can be enforced for all Domains. Global policies can serve as security templates with rules that are applied to many Domains, and their individualized security policies. The Security Gateway is the engine that enforces the organization\’s security policy, is an entry point to the LAN, and is managed by the Security Management Server.
The interaction between domain policies, global policies and the security gateway is depicted below. Note that Global Domain rules can be run before the local Domain rules or after the local Domain rules as cleanup.
NP-View reads device configuration files and can be used to review and verify the ruleset configuration using the Access Rules feature. An example is below:
Device groups enables grouping based on network segmentation, geographic location, organizational function, or any other common aspect of firewalls that require similar policy configurations. Using device groups, the user can configure policy rules and the objects they reference. Devices can be organized hierarchically, with shared rules and objects at the top, and device group-specific rules and objects at subsequent levels. This enables the creation of a hierarchy of rules that enforce how firewalls handle traffic. The image below depicts the high level interaction between device groups, subgroups and firewalls.
This can be further broken down into the virtual system. A virtual system is an independent (virtual) firewall instance that can be separately managed within a physical firewall with its own Security policy, interfaces, and administrators.
Device Groups on Panorama allow you to centrally manage firewall policies. You create policies on Panorama either as Pre Rules or Post Rules; Pre Rules and Post Rules allow you to create a layered approach for implementing policy. You can define Pre rules and Post rules in a shared context, as shared policies for all managed firewalls, or in a device group context, to make the rules specific to a device group. Because you define Pre rules and Post Rules on Panorama and then push them from Panorama to the managed firewalls, you are able to view the rules on the managed firewalls but you can edit the Pre Rules and Post Rules only in Panorama.
NP-View reads device configuration files and can be used to review and verify the ruleset configuration using the Access Rules feature. An example is below:
