Verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
The following is a list of verifications
performed by VPN-1/FireWall-1 NG on an "any any any accept" configuration, when
all SmartDefense features that can be disabled via the SmartDefense GUI are
deactivated. The list is relevant for VPN-1/FireWall-1 NG FP3 (HF2 and above),
and VPN-1/FireWall-1 NG with Application Intelligence. To view a specific topic,
click the appropriate link below:
1) TCP State Verification
2) TCP flags sanity
3) Fragments reassembly
4) TCP/UDP port 0
5) Stateful ICMP
6) Server-to-client old packets
7) ICMP redirect packets
8) Source equals destination
9) Cluster member Ping
10) Packet-length sanity
11) Teardrop, Ping of death, and land attack
12) FTP
13) Anti-spoofing
14) X11
15) DCE-RPC
16) Violation of unidirectional connections
17) Reply from any port link flooding
TCP State verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on TCP State
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
TCP State Verification
======================
a. Make sure first packet is a SYN. This check can be overridden by clearing the
"Drop out of state TCP" checkbox under Global Properties -> Stateful inspection.
However, disabling this enforcement can result in bad consequences. When the
Policy is "any any any accept," it should generally work. But even in this case,
it is not recommended when NAT is involved.
When the feature is enabled, it should not cause any connectivity problems,
unless:
(1) Configuration is asymmetric, and VPN-1/FireWall-1 encounters only a portion
of connection’s packets.
(2) Long idle connections are involved. In this case, it is recommended to
increase the time-out of the relevant services.
In both cases, it is possible to refine the behavior of the feature for specific
services/gateways, etc.
b. TCP handshake verification; VPN-1/FireWall-1 rejects any server-to-client ACK
packet that is a direct response to a previous SYN. This should not affect
connectivity of non-encrypted connections. To turn this verification off, set
kernel global parameter fw_allow_out_of_state_syn_resp to "1".
c. SYN packet on established connection; in some cases VPN-1/FireWall-1 may
encounter a SYN packet that appears to belong to an already established
connection. VPN-1/FireWall-1 NG with AI resolves the actual state of both sides,
and solves the conflict. However, in prior versions, the SYN packet is dropped.
This may happen due to a previous RST packet that was not trusted by
VPN-1/FireWall-1. In this case, set kernel global parameter fw_trust_rst_on_port
to "–1", or to a specific destination port that specifies the service.
There is no workaround for versions prior to NG with AI.
d. SYN-ACK on closing connection; VPN-1/FireWall-1 drops (and logs) a SYN-ACK
packet that arrives after a client-to-sever RST. While this scenario is
generally not expected, it can happen when the server is a Linux 2.4.18 machine
(as a result of a bug in Linux TCP stacks), regardless of the platform of the
VPN-1/FireWall-1 machine. This check cannot be overridden. It doesn't affect
connectivity, but drop logs are generated.
TCP flags sanity verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information about TCP flags sanity
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
TCP flags sanity
================
VPN-1/Firewall-1 verifies that TCP flags are compliant with the RFC. In general,
this means each packet (except for SYN and RST) must have the ACK flag set, and
a SYN packet is not accompanied by illegal flags (such as RST and FIN). This
check cannot be overridden. There is one exception, where VPN-1/Firewall-1
allows SYN-RST packets. But this is reserved for certain non-RFC compliant IBM
printers.
Fragments reassembly verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on fragments
reassembly verification performed by VPN-1/FireWall-1 NG on an "any any any
accept" configuration, when all SmartDefense features that can be disabled via
the SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Fragments reassembly
====================
VPN-1/Firewall-1 reassembles all IP fragments of a certain packet before
processing it. Once a fragment is encountered, there is a certain time-out, in
which additional fragments are allowed for the same packet. Once time-out is
exceeded and one or more fragments of a certain packet are missing, the held
fragments are dropped. This check cannot be overridden. In NG with AI, the
time-out and maximal number of concurrent fragments can be configured via the
SmartDefense GUI (IP and ICMP -> IP Fragments).
TCP/UDP port 0 verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on TCP/UDP port 0
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
TCP/UDP port 0
==============
Packets with either destination or source port 0 are dropped. There are some
applications that use this port, but this problem is only rarely encountered. If
such traffic is required, the check can be overridden, by setting the kernel
global parameter fw_allow_udp_port0 and fw_allow_tcp_port0 to 1.
Stateful ICMP verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on Stateful ICMP
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Stateful ICMP
=============
VPN-1/Firewall-1 makes sure each ICMP reply matches a previous request, and that
each ICMP error matches an existing connection. Out-of-state ICMP packets are
dropped and logged. In NG FP3 HF2, there is no way to override this check. This
may affect connectivity if there is some kind of asymmetric routing, or when
Pinging broadcast addresses. In NG with AI, it is possible to disable state
checks for ICMP replies, by clearing the “Drop out of state ICMP” check box in
Global Properties dialog -> Stateful inspection.
Server-to-client old packet verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on server-to-client
old packet verification performed by VPN-1/FireWall-1 NG on an "any any any
accept" configuration, when all SmartDefense features that can be disabled via
the SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Server-to-client old packets
============================
Once Security Policy is reinstalled, all connections are marked as "old". A
server-to-client non-TCP packet that matches an old connection is dropped. This
is true for UDP connections, and for ICMP replies/errors. This behavior can be
overridden for specific services, by checking the “Keep connections open after
policy has been installed” box within the service dialog. It is also possible to
keep all connections active after Policy installation, by choosing “keep all
connections” within the Gateway properties' dialog box > Advanced > Connection
persistency.
ICMP redirect packets verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on ICMP redirect
packets verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
ICMP redirect packets
=====================
ICMP redirect packets are not allowed by default. To enable ICMP redirects, set
Firewall-1 kernel global parameter fw_icmp_redirects to "1".
Cluster-member Ping verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on cluster-member Ping
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Cluster-member Ping
===================
VPN-1/Firewall-1 does not allow Pinging a cluster virtual IP and a real IP of
one of the cluster members simultaneously. Several tools perform such
simultaneous Pings. There is a support solution for this matter (available since
HFA 315), which can be enabled by setting the kernel global parameter
fw_allow_simultaneous_ping to "1".
Packet-length sanity verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on packet-length
sanity verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Packet-length sanity
====================
VPN-1/Firewall-1 makes sure that each IP packet has a length of at least 20
bytes for TCP/UDP, and 8 additional bytes for ICMP. This check cannot be
overridden.
Teardrop, Ping-of-death, and land-attack verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on teardrop,
Ping-of-death, and land-attack verification performed by VPN-1/FireWall-1 NG on
an "any any any accept" configuration, when all SmartDefense features that can
be disabled via the SmartDefense GUI are deactivated. The information is
relevant for VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG
with Application Intelligence.
Teardrop, Ping of death, and land attack
========================================
Details about these attacks can be found in SmartDefense GUI (under "denial of
service"). In general, these attacks have very specific characteristics, and
enforcing them should not cause connectivity problems for legitimate traffic.
These checks cannot be overridden.
FTP verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on FTP verification
performed by VPN-1/FireWall-1 NG on an "any any any accept" configuration, when
all SmartDefense features that can be disabled via the SmartDefense GUI are
deactivated. The information is relevant for VPN-1/FireWall-1 NG FP3 (HF2 and
above), and VPN-1/FireWall-1 NG with Application Intelligence.
FTP
===
VPN-1/Firewall-1 makes sure that an FTP port command contains the IP of the
command's sender. It also makes sure that each FTP command terminates with a
new-line character. The latter verification may possibly cause connectivity
problems.
The simplest way to disable all FTP checks is by clearing the “Match for ‘Any’”
box from the FTP service advanced dialog. This will not work if NAT is involved.
In this case, the checks can be overridden as follows:
In NG FP3:
To disable FTP new-line character checks, edit $FWDIR/lib/base.def file (located
on the SmartCenter Server) and change three lines:
1) Comment out the following line:
#define FTPPORT(match) (call KFUNC_FTPPORT <0x1|(match)>)
The result should look like:
// #define FTPPORT(match) (call KFUNC_FTPPORT <0x1|(match)>)
2) Uncomment the following line:
// #define FTPPORT(match) (call KFUNC_FTPPORT <(match)>)
Result:
#define FTPPORT(match) (call KFUNC_FTPPORT <(match)>)
3) Comment out the following line:
#define FTP_ENFORCE_NL
Result:
// #define FTP_ENFORCE_NL
As for the bounce-attack verification, it should not affect connectivity of
legitimate FTP traffic. It can still be disabled by changing section 2 above
into the following line:
#define FTPPORT(match) (call KFUNC_FTPPORT <0>)
In NG with AI:
1) Create a new service and associate it with protocol type FTP_BASIC. This
solution has security disadvantages.
2) Change the security algorithm of FTP (and other FTP services, ftp-bidir, ftp-pasv,
ftp-port), by removing the comment from the following INSPECT line in the
base.def file (located under $FWDIR/lib in the SmartCenter machine):
// #define FTP_CHECK_PACKET
This solution is more secure.
Anti-spoofing verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on anti-spoofing
verification performed by VPN-1/FireWall-1 NG on an "any any any accept"
configuration, when all SmartDefense features that can be disabled via the
SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Anti-spoofing
=============
Once topology is defined, VPN-1/Firewall-1 performs anti-spoofing checks. To
disable anti-spoofing checks, set Firewall-1 kernel global parameter
fw_anti-spoofing_enabled to "0".
There are some additional anti-spoofing checks:
a) Local interface anti-spoofing; VPN-1/Firewall-1 verifies that no packet on
the inbound chain has a source IP that matches one of the Gateway's IP
addresses. This can be overridden by setting the kernel global parameter
fw_local_interface_anti_spoofing to "0". Local interface anti-spoofing may
affect connectivity specifically on Windows and Linux platforms.
b) Loopback interface anti-spoofing; VPN-1/Firewall-1 makes sure no packet
arrives on a non-loopback interface with the loopback address. This verification
should not cause connectivity problems for legitimate traffic, and cannot be
overridden.
c) Cluster ttl anti-spoofing checks introduced in NG with AI; this feature
verifies that broadcast packets between cluster members are not spoofed. The
feature can be disabled by setting Firewall-1 kernel global parameter
fw_ttl_check to "0".
X11 verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on X11 verification
performed by VPN-1/FireWall-1 NG on an "any any any accept" configuration, when
all SmartDefense features that can be disabled via the SmartDefense GUI are
deactivated. The information is relevant for VPN-1/FireWall-1 NG FP3 (HF2 and
above), and VPN-1/FireWall-1 NG with Application Intelligence.
X11
===
X11 connections are not allowed through service “Any”. In order to allow X11
connections, either add a rule that explicitly allows X11 connections, or use
db_edit tool to set the value of the attribute reject_x11_in_any to "0".
Violation of unidirectional connections verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on violation of
unidirectional connections verification performed by VPN-1/FireWall-1 NG on an
"any any any accept" configuration, when all SmartDefense features that can be
disabled via the SmartDefense GUI are deactivated. The information is relevant
for VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Violation of unidirectional connections
=======================================
In NG FP3 (and earlier), every UDP service that is defined as "other" (e.g.,
traceroute) is considered unidirectional, regardless of the "accept replies"
checkbox in the "advanced" dialogue of the service properties. This behavior may
cause connectivity problems to all connections that are associated to such UDP
"other" services. This also results in log messages indicating "Violated
unidirectional connection".
Note that traceroute specifically is an "other" service, which is defined as a
high-port UDP with an IP ttl value under 30. This definition can match reply
packets of various UDP services, such as DNS. Consequently, if a DNS reply
doesn't match a previous request, for example, it may be associated to the "traceroute"
service. Consecutive DNS requests from the same source port to the same server
are considered a unidirectional connection violation.
The problem has been fixed in NG with AI. In previous versions, if traceroute is
not being used, it can be refined or deleted, together with any other UDP
"other" service to which UDP bidirectional connections can be associated.
Reply from any port link-flooding verifications performed by VPN-1/FireWall-1 NG with "any any any accept" rule
Following is information on reply from any port
link-flooding verification performed by VPN-1/FireWall-1 NG on an "any any any
accept" configuration, when all SmartDefense features that can be disabled via
the SmartDefense GUI are deactivated. The information is relevant for
VPN-1/FireWall-1 NG FP3 (HF2 and above), and VPN-1/FireWall-1 NG with
Application Intelligence.
Reply from any port link flooding
=================================
When configuring a certain UDP service (or all unknown UDP services) to accept
replies from any port, VPN-1/Firewall-1 inserts four additional connection links
for each server port it associates to the same connection. There is no limit
upon the number of links, and they are all kept as long as the connection lives.
This means if the server starts scanning ports, the number of links increases
considerably, and consumes memory.
The problem of link flooding may specifically occur when a certain reply to a
known service is considered a first packet of a new connection, instead of
matching a previous request. For instance, if a DNS reply does not match a
previous request, it may be considered an unknown service, or match another
reply-from-any-port service. When this happens, all consecutive requests from
the client to the same server port (e.g. all DNS requests) are considered
"replies from any port," and an additional four links are inserted per each
client source port.
A workaround for this problem is:
a) The "reply from any port" solution should be enabled only in special cases,
where the service requires it (for instance, TFTP). It should not be used as a
generic solution for connectivity problems, such as violation of unidirectional
connections, etc.
b) An alternate solution for the "reply from any port" is to define a rule that
is based on an access list. In this case, each server port is associated to
another connection, and ports that are not being used are released from the
table.