Skip to main content

Basic Rules of Checkpoint Firewall

Managing the Firewall Rule Base:

Explicit and Implied Rules

These are the types of rules in the Rule Base:
Explicit rules - Rules that you create to configure which connections the Firewall allows
Implied rules - Rules that are based on settings in the Global Properties menu
Implied rules allow connections for different services that the Security Gateway uses.
For example, the Accept Control Connections option allows packets that control these services:
·         Installing the security policy on a Security Gateway
·         Sending logs from a Security Gateway to the Security Management server
·         Connecting to third party applications, such as RADIUS and TACACS authentication servers


Order of Rule Enforcement:



Make sure that you understand the importance of the order of rule enforcement to maximize the security of the Firewall. The Firewall always enforces the first rule that matches a connection. It does not enforce later rules that can be more applicable.
This is the order that rules are enforced:

1. First Implied Rule: You cannot edit or delete this rule and no explicit rules can be placed before it.
2. Explicit Rules: These are rules that you create.
3. Before Last Implied Rules: These implied rules are applied before the last explicit rule.
4. Last Explicit Rule: We recommend that you use the Cleanup rule as the last explicit rule.
5. Last Implied Rules: Implied rules that are configured as Last in Global Properties.
6. Implied Drop Rule: Drops all packets without logging.

These are basic access control rules we recommend for all Rule Bases:
·        Stealth rule that prevents direct access to the Security Gateway.
·        Cleanup rule that drops all traffic that is not allowed by the earlier rules.
There is also an implied rule that drops all traffic, but you can use the Cleanup rule to log the traffic

Sample Firewall Rule Base:


 


1. Stealth - All traffic that is NOT from the internal company network to one of the Security Gateways is dropped. When a connection matches the Stealth rule, an alert window opens in SmartView Monitor.
2. Critical subnet - Traffic from the internal network to the specified resources is logged. This rule defines three subnets as critical resources: Finance, HR, and RnD.
3. Tech support - Allows the Technical Support server to access the Remote-1 web server which is behind the Remote-1 Security Gateway. Only HTTP traffic is allowed. When a packet matches the Tech support rule, the Alert action is done.
4. DNS server - Allows UDP traffic to the external DNS server. This traffic is not logged.
5. Mail and Web servers - Allows incoming traffic to the mail and web servers that are located in the DMZ. HTTP, HTTPS, and SMTP traffic is allowed.
6. SMTP - Allows outgoing SMTP connections to the mail server. Does not allow SMTP connections to the internal network, to protect against a compromised mail server.
7. DMZ and Internet - Allows traffic from the internal network to the DMZ and Internet.
8. Clean up rule - Drops all traffic. All traffic that is allowed matched one of the earlier rules.



Comments

Popular posts from this blog

ASA TCP Connection Flags

When troubleshooting TCP connections through the ASA, the connection flags shown for each TCP connection provide a wealth of information about the state of TCP connections to the ASA. This information can be used to troubleshoot problems with the ASA, as well as problems elsewhere in the network. Here is the output of the show conn protocol tcp command, which shows the state of all TCP connections through the ASA. These connections can also be seen with the show conn command. ASA# show conn protocol tcp 101 in use, 5589 most used TCP outside 10.23.232.59:5223 inside 192.168.1.3:52419, idle 0:00:11, bytes 0, flags saA TCP outside 192.168.3.5:80 dmz 172.16.103.221:57646, idle 0:00:29, bytes 2176, flags UIO TCP outside 10.23.232.217:443 inside 192.168.1.3:52427, idle 0:01:02, bytes 4504, flags TCP outside 10.23.232.217:5223 inside 192.168.1.3:52425, idle 0:00:10, bytes 0, flags saAUIO TCP outside 10.23.232.57:5223 inside 192.168.1.3:52412, idle 0:00:23, bytes 0, flag

How to Set Up an IPSec Tunnel On PAN-OS - Palo Alto Firewalls

Set Up an IPSec Tunnel  The IPSec tunnel configuration allows you to authenticate and/or encrypt the data (IP packet) as it traverses across the tunnel.  If you are setting up the Palo Alto Networks firewall to work with a peer that supports policy-based VPN, you must define Proxy IDs. Devices that support policy-based VPN use specific security rules/policies or access-lists (source addresses, destination addresses and ports) for permitting interesting traffic through an IPSec tunnel. These rules are referenced during quick mode/IKE phase 2 negotiation, and are exchanged as Proxy-IDs in the first or the second message of the process. So, if you are configuring the Palo Alto Networks firewall to work with a policy-based VPN peer, for a successful phase 2 negotiation you must define the Proxy-ID so that the setting on both peers is identical. If the Proxy-ID is not configured, because the Palo Alto Networks firewall supports route-based VPN, the default values used as Proxy-ID are source