Checkpoint Firewall 1 (CCSA)

[darren77uk]

I've recently done my CCSA and failed, there is one particular question that I was trying to find an answer too which was related to TCP and UDP timeout, what is the command line syntax for this?

on the exam it had something like
FW tcp_exptimeout #%
FW tcp_extendtimeout #%
FW udp_expandtimeout #%

something along those lines, if anyone has any idea or can give me some pointers on what areas or what questions might come up again, please let me know. I would be most thankful.

Regards,
Darren

 

[Guest_imported]

This is the help text that should answer your question. That command was referring to the timeout period for TCP and UDP connections and is setup in the Global Properties tab under Stateful Inspection.

Hope this helps.

Joe Hayes
joe@joehayes.net

~~~~~HELP TEXT~~~~
VPN-1/FireWall-1 inspects all IP packets against the Security Policy. The first packet of each TCP connection or UDP session is checked against the Rule Base. If the first packet is accepted, VPN-1/FireWall-1 adds the connection to an internal table of open connections (the connections table), in the format:


<src-addr,src-port,dst-addr,dst-port,ip-p;enc-key,type,flags>
Subsequent packets of an established TCP connection (or UDP session) are checked against the table rather than against the Rule Base.
VPN-1/FireWall-1 considers a packet to be part of an established TCP connection if it is not a SYN/NO-ACK packet, that is, if it is not the first packet of a TCP connections.
You can see the connections table by typing the following on the FireWalled gateway:


fw tab -t connections -u
One of the first things VPN-1/FireWall-1 does for each packet is to determine whether the packet’s TCP connection (or UDP session) is listed in the connections table. If it is, the packet is immediately accepted (and possibly encrypted or decrypted).
There are several advantages to using this method:

1. VPN-1/FireWall-1 needs some way of accepting replies to valid TCP connections.

Suppose the Rule Base allows connections from A to B, but rejects connections from B to A. If A initiates a connection to B, the replies to that connection must be accepted even though connections from B to A are rejected. By using the connections table, VPN-1/FireWall-1 is able to differentiate between replies to the original A to B connection (which are allowed to pass) and B to A connections (which are rejected).

2. It is very inefficient to scan each packet against the entire Rule Base. It is much more efficient to accept all packets of previously approved connections.

Entries are removed from the connections table when one of the following happens:

TCP connections

50 seconds after VPN- 1/FireWall- 1 sees FIN packets in both directions or a RST packet, or
after the connection is idle for more than TCP_TIMEOUT seconds

UDP sessions

after the connection is idle for more than UDP_TIMEOUT seconds

These values are set by the user in the FireWall-1 Implied Rules page of the Global Properties window.

In addition, the connections table is cleared when a Security Policy is reloaded. The new Security Policy is then enforced on the already active connections and sessions.

It may happen that an entry for an open connection is removed, either because the connection was idle for a long time and has been re-activated, or because a new Security Policy was loaded.

For example, suppose your Security Policy accepts allows connections from A to B, but rejects connections from B to A, and you do the following:

1. Telnet from A to B.
2. Type the command:

sleep 100; echo &quot;hello&quot;
3. Reload the same Security Policy.

After 100 seconds, a packet returns from B to A, carrying the word &quot;hello&quot;. Although this packet is part of a valid connection,
VPN-1/FireWall-1 rejects it.

To solve this problem, VPN-1/FireWall-1 drops TCP packets that claim to belong to established TCP connections (that is, non-SYN and ACK packets) in a special way. The packet is not actually dropped, but instead all the data is removed from the packet, leaving only the IP and TCP headers, which renders the packet harmless. In addition, the TCP header’s SEQ number is mangled (that is, the SEQ number is replaced by invalid data).

When A receives the mangled packet, A immediately responds, because of the mangled SEQ number. If the connection is still valid, this response is matched against the Rule Base, and the connection is re-recorded in the connections table. If the Rule Base indicates that the connection is to be logged, then the packet is logged if Log Established TCP Packets in the Log and Alert page of the Global Properties window is checked. VPN-1/FireWall-1 then restarts the timeout clock.

If the connection has become invalid, the packet is dropped. VPN-1/FireWall-1 notices that it is dropping a reply to a mangled TCP packet and so does not mangle it again but drops it for good.

In rare cases, VPN-1/FireWall-1 logs the mangled packets if the rule that dropped the packet specified a log action. This means that even if a connection is legal, you might see a drop log entry even though the connection continues. To eliminate these spurious log entries, uncheck Log Established TCP Packets in the Log and Alert page of the Global Properties window and reload the Security Policy.

Example

Suppose the Rule Base allows host A to initiate an FTP connection with host B, and specifies that the connection be logged. The log then shows an entry for the first packet, but not for subsequent packets (because the Rule Base is checked only for the first packet). Suppose also that the connection times out.

If the First Packet After the Timeout is Sent by A - If the first packet after the timeout is sent by A, it is handled as though it were the first packet of the connection. The packet is accepted and the timeout clock is restarted. If the Rule Base specifies logging, the packet is logged.

If the First Packet After the Timeout is Sent by B - If the first packet after the timeout is sent by B, VPN-1/FireWall-1 checks the Rule Base. Even if the Rule Base specifies that the packet be dropped or rejected, VPN-1/FireWall-1 mangles the packet and passes it to A. This forces A to request a re-transmission, upon which the Rule Base is checked again as described above.

Logging a Re-Established TCP Connections

Log Established
TCP Packets first packet after timeout sent by A first packet after timeout sent by B
checked packet is logged only if specified by Rule Base - packet is handled exactly as the connection’s first packet was handled packet is logged only if specified by Rule Base (possibly under last &quot;None of the Above&quot; rule)
not checked packet is not logged packet is not logged