This section
describes how to prevent IP spoofing, allow full fragment reassembly, and
override the default fragment setting set for at the device level in
Platform Settings .
Anti-Spoofing
This section lets
you enable Unicast Reverse Path Forwarding on an interface. Unicast RPF guards
against IP spoofing (a packet uses an incorrect source IP address to obscure
its true source) by ensuring that all packets have a source IP address that
matches the correct source interface according to the routing table.
Normally, the
Firepower Threat Defense
device only looks at the destination address when determining where to forward
the packet. Unicast RPF instructs the device to also look at the source
address; this is why it is called Reverse Path Forwarding. For any traffic that
you want to allow through the
Firepower Threat Defense
device, the device routing table must include a route back to the source
address. See RFC 2267 for more information.
For outside traffic,
for example, the
Firepower Threat Defense
device can use the default route to satisfy the Unicast RPF protection. If
traffic enters from an outside interface, and the source address is not known
to the routing table, the device uses the default route to correctly identify
the outside interface as the source interface.
If traffic enters
the outside interface from an address that is known to the routing table, but
is associated with the inside interface, then the
Firepower Threat Defense
device drops the packet. Similarly, if traffic enters the inside interface from
an unknown source address, the device drops the packet because the matching
route (the default route) indicates the outside interface.
Unicast RPF is
implemented as follows:
-
ICMP packets
have no session, so each packet is checked.
-
UDP and TCP have
sessions, so the initial packet requires a reverse route lookup. Subsequent
packets arriving during the session are checked using an existing state
maintained as part of the session. Non-initial packets are checked to ensure
they arrived on the same interface used by the initial packet.
Fragment per Packet
By default, the
Firepower Threat Defense
device allows up to 24 fragments per IP packet, and up to 200 fragments
awaiting reassembly. You might need to let fragments on your network if you
have an application that routinely fragments packets, such as NFS over UDP.
However, if you do not have an application that fragments traffic, we recommend
that you do not allow fragments through the
Firepower Threat Defense
device. Fragmented packets are often used as DoS attacks.
Fragment Reassembly
The
Firepower Threat Defense
device performs the following fragment reassembly processes:
-
IP fragments are
collected until a fragment set is formed or until a timeout interval has
elapsed.
-
If a fragment
set is formed, integrity checks are performed on the set. These checks include
no overlapping, no tail overflow, and no chain overflow.
-
IP fragments
that terminate at the
Firepower Threat Defense
device are always fully reassembled.
-
If
Full
Fragment Reassembly is disabled (the default), the fragment set is
forwarded to the transport layer for further processing.
-
If
Full
Fragment Reassembly is enabled, the fragment set is first coalesced
into a single IP packet. The single IP packet is then forwarded to the
transport layer for further processing.