This chapter is from the book

This chapter is from the book

Global Properties

The global properties of the policy can be accessed from the Policy, Global
Properties menu. This brings up a dialog showing all the property sections,
along with their values. The important ones will be examined in more detail.

NOTE

None of the changes to the global properties takes effect until the policy is
pushed to the enforcement point.

FireWall-1 Implied Rules

The options under the FireWall-1 Implied Rules section are shown in Figure
3.5.

The changes to these settings add implicit rules into the rule base. If an
option is enabled, you have three choices of where it will be placed in the rule
base:

The significance of the Before Last option is that it doesn’t interfere
with the cleanup rule, which drops all traffic. If you have a cleanup rule and
place the implicit rule in the last position, it will never be consulted.

The choice of First versus Last/Before Last has to do with your rule base.
Again, an incorrect choice may cause your stealth rules to block packets that
the implicit rule would otherwise allow.

TIP

Rules that govern packets coming in to the firewall (for example, RIP and
DHCP) are probably best placed first in the rule base. The other rules should
probably go through the rule base first, and thus be placed before last. The
exception to this would be if you want the behavior to occur regardless of your
rule base. Because you will almost always have a cleanup rule, you will rarely
select Last.

The options in the FireWall-1 implied rules cover basic behavior of the
firewall itself:

By default, control connections, CPRID, DHCP, and packets originating from
the gateway itself are accepted.

Note that it is possible to lock yourself out of the firewall by pushing
control connections to the end of the policy, or disallowing them entirely.
After this point, you will not be able to push a policy to fix it!

Security Servers

Check Point security servers provide deeper inspection of some protocols by
taking over part of the connection for popular services. The properties here
control the welcome messages that the services provide, any upstream HTTP
proxies, and HTTP servers to protect.

Much of the functionality is now available under SmartDefense, but you will
be expected to know where this configuration is.

Stateful Inspection Properties

Stateful Inspection relies heavily on tracking connections that pass through
the firewall. To avoid running out of memory from too many connections, the
firewall must know when to stale out older ones. Also, the firewall must know
how to deal with protocols that don’t have intrinsic state, such as UDP
and other IP protocols.

The Default Session Timeouts control how long state table entries will be
held. Those called "virtual sessions" do not have intrinsic state in the
protocol, but Stateful Inspection tracks state nonetheless. For example, if a
host sends an ICMP packet to another host, Stateful Inspection will open a state
table entry watching for reply packets.

Likewise, with UDP protocols, replies are tracked based on source and
destination address and ports, called Stateful UDP. Where a UDP protocol is
defined as a service in the objects tree, replies can be accepted by checking
the Accept Replies option in the advanced properties of the service itself.
Where there is no service defined, this global property sets the behavior. If
the reply is on a different port, the Any Port option must be checked to accept
the packet.

For Stateful ICMP, replies to echo-requests are accepted if the Replies box
is checked. The Errors box controls whether ICMP error messages are allowed. If
an upper-layer connection was permitted by the rule base but resulted in an ICMP
error message from the remote host, this option will allow it through.

As with the Stateful UDP options, you have the option of allowing response
packets in unknown services to be accepted.

One of the benefits of tracking every facet of the conversations flowing
through the firewall is that you know the state of the connection on both ends,
and can drop anything that is out of the ordinary. For example, in a TCP
connection, if the firewall sees a packet for an established connection, but
knows the connection doesn’t exist, it will drop it if the Drop Out of
State TCP Packets option is checked.

Log and Alert

The Log and Alert properties control the tracking type of some internal
events. For example, the VPN Successful Key Exchange property dictates how you
are notified when a VPN connection is made. The options you have in this page
are the same tracking options you have in the rule base.

Alert Commands is a related set of properties that controls how some of the
events are actually run. For example, if an alert is set to email, this page
defines how the email is sent. This is also where the user-defined alerts are
defined.