Small PMTU
PMTU stands for Path Maximum Transmission Unit. Each hop between the client and server may have a different maximum packet size. PMTU is a method for a server to discover what the smallest MTU is when communicating with a client. Once the client discovers the smallest MTU of any hop along the path between client and server, all packets can be made small enough so that they do not need to be fragmented in transit. Enabling this option prevents ICMP messages requesting an excessively small MTU (determined by you) from reaching the server.This attack works by fooling the server into the thinking that the MTU is small enough that any normal packet is broken into a large number of fragments. When sending small-sized fragments, you use more bandwidth, because the header size is the same for every packet, no matter how much data follows. So, if the server is incorrectly sending lots of small packets, the header information will use a larger percentage of bandwidth. If the minimum PMTU is set too small, an attack will not be prevented, and if the minimum MTU is set too large, the firewall may drop the wrong traffic.
Sequence Verifier
Every packet in a TCP session contains a sequence number in the TCP header information. The sequence number is important because it is the mechanism used to allow reliable communications between hosts. The sequence number identifies each chunk of data so the receiving host can reassemble the stream in the correct order and can acknowledge each individual packet as it is received. If a sequence number is not acknowledged within the set period of time, the sender knows to retransmit the unacknowledged packet. In the case that a retransmission and the acknowledgement pass each other on the network, the receiving host will know to discard the duplicate packet because it has already seen the sequence number.
In FireWall-1 NG FP3, the Sequence Verifier was moved from the Global Policy settings to the SmartDefense configuration.This feature watches all traffic flows going through the gateway and keeps track of the sequence numbers in the packets. If it sees a packet is received with an incorrect sequence number, the EP will consider the packet out of state and drop the packet.
You have the option of turning off this feature, since it is not currently supported in certain configurations, such as firewall clusters using asymmetric routing. When this feature is disabled, the firewall changes some of its behavior with respect to certain TCP packets. For example, the RST flag is not trusted, and instead of removing a session from the state table when a RST is encountered, it sets a 50-second timeout on the connection before it considers it closed. This can cause problems if the client, within the 50-second window, tries to reconnect with the same source port because the firewall will consider the SYN flag an out-of-state packet and drop it.
When the sequence verifier is enabled, you are given three different tracking options when deciding what sorts of problems you want to receive alerts/logs on.These options are shown in Figure 11.14 and include the following:
■ Every This option will take the selected tracking option for every out-of-state packet that is dropped by the gateway.
■ Anomalous This tracking option is less sensitive than the previous one, because it will only track out-of-sequence packets that suggest some sort of communication problem may exist.
■ Suspicious When this option is selected, the gateway will only track out-of-state packets that the gateway thinks may be part of an attack.
Figure 11.14 Sequence Verifier Configuration Settings
DNS
When this feature is enabled, the enforcement point will perform sanity checks on all DNS packets to verify that they have been formatted to comply with the standard DNS format as described in RFC 1035. More specifically, the enforcement point will inspect all UDP packets flowing over port 53 to verify that they are DNS packets and formatted properly. As of FP3, SmartDefense will only inspect UDP DNS packets, so any TCP DNS traffic, such as zone transfers, will not be checked for DNS packet integrity.
If you are running a Windows 2000 Active Directory domain, you will want to perform extensive testing before using this feature in your network. According to the FP3 release notes, DNS protocol enforcement will drop DNS communications made to AD domain controllers. If you have any hosts that communicate with a domain controller through the firewall, you will likely not be able to use DNS protocol enforcement.
No other configurable options related to DNS protocol enforcement exist for UDP packets.The only decision you have to make is if you want to enable the feature. If you would like to use the strict DNS checks, make sure to check the UDP protocol enforcement box, shown in Figure 11.15, and select the type of tracking for malformed DNS packets.
Figure 11.15 DNS Protocol Enforcement
Warning
According to the release notes, this feature currently does not recognize Active Directory DNS traffic as being valid. If you have hosts that need to send AD traffic through the firewall (that is, hosts and domain controllers are on separate networks), you will not be able to use this feature.
FTP
This section of SmartDefense protects against attacks using the File Transfer Protocol (FTP). No options apply to the entire FTP category, and all other settings are under their individual categories.
Note
Security Server alerts (FTP, HTTP, and SMTP) are reported in the logs as coming from FW-1/VPN-1, instead of SmartDefense, because you are making changes to the Security Server that are invoked when filtering a protocol with resources and not directly to SmartDefense.
FTP Bounce Attack
An easy way to hide the source of an attack is to exploit a design flaw in the FTP protocol that allows the client to specify the IP address and port number the FTP server should attach to for a data connection. All the attacker needs is anonymous write access to a directory on a vulnerable FTP server, where he can upload a file containing the data stream that is going to be sent to the target machine. The attacker can then exploit the flaw by asking the FTP server to send the file to an arbitrary IP address and port number. For example, the file could contain a malformed HTTP request and the attacker could have the FTP server open a connection to port 80 on the target machine and send the malformed request. As far as the Web server can tell, the connection came from the IP address of the FTP server, not the IP address of the attacker.The attacker is effectively "bouncing" the attack off the FTP server, and the victim will not be able to discover the source of the attack without the help of the administrator of the vulnerable FTP site.
Check Point has added a check to all FTP traffic to prevent this attack. When the PORT command is seen passing through the firewall, it will verify that the address specified in the PORT command is the same address as the machine requesting the file transfer.This will force all FTP data transfers to go only to the originating IP address and prevent an attacker from initiating a connection to a different machine.
FTP Security Servers
The options listed here are extra configurable options that apply to the FTP Security Server built into Firewall-1. By default, these options will not affect any traffic unless you have already configured your FTP rules to use an FTP resource, as shown in Figure 11.16. If you want the FTP Security Server to be invoked for every FTP connection that flows through your firewall, you have the option of changing the behavior in this section. If you have large amounts of traffic flowing through your enforcement points, this option may cause performance problems on your gateways.
Figure 11.16 FTP Security Server Settings
Note
Selecting Configurations apply to all connections will make the firewall call the security server for every FTP connection on port 21, no matter which direction the traffic flows. This setting works exactly the same for HTTP and SMTP security servers. If you have a high throughput through your gateway, the additional overhead could cause some performance problems. Also, when this option is selected, it will not apply to FTP traffic on nonstandard ports, even if the service is configured with a protocol type of FTP (under advanced configuration for a service).
To better illustrate how rules with FTP, HTTP, or SMTP resources are used, Figure 11.17 shows two rules that use HTTP resources. Please note the SERVICE column for rules 30 and 42 to see an HTTP rule which uses an HTTP resource (Security Server) to apply additional restrictions to particular traffic flows.To view or define new resources, you can go to Manage | Resources in the main menu.
For those FTP connections that do go through the Check Point Security Server (whether you have configured it for all FTP, or only FTP resources), you have the ability to choose individual commands that you want to allow. By selecting the Allowed FTP Commands menu, you will see two lists in the configuration area of the SmartDefense window.This list on the left displays all the commands that are allowed; the list on the right is all the commands that will be blocked. By default all commands are enabled, but you can easily disallow the use of a command by highlighting it in the allowed list and clicking Add. If you decide later that you want to move a command back into the accepted list, just highlight the command and click Remove.
Figure 11.17 Rules with Resources
Note
The Allowed FTP Commands configuration is shown in Figure 11.18. Please keep in mind that this figure represents random commands moved into the blocked category and does not reflect an appropriate way to protect your FTP server.
Figure 11.18 Allowed FTP Commands
Two other additional measure are automatically enabled when using the FTP Security Server.These two options are called Prevent Known Ports Checking and Prevent Port Overflow Checking.The known ports check is in place to prevent an FTP PORT connection from requesting a connection to a known port (for example, port 80 for HTTP). If you would like to disable this feature and allow data transfers to be sent to a well-known port, place a check mark in the box.
The other feature, called port overflow checking, keeps track of the PORT commands that have been issued and will drop multiple PORT requests to the same destination port. Again, this feature can be disabled by placing a check mark in the box labeled Prevent Port Overflow Checking.
