index_199
UNCLASSIFIED
Testing and Security Validation
Version 1.0g
UNCLASSIFIED
199
legitimate internal addresses. (Note that the internal network may be using one of the
RFC1918 reserved addresses with NAT performed at the router; in this case, the
access list on the internal interface will recognize such an address as legitimate. The
goal here is to catch packets with a source address of an external network or a
reserved address that is not being used by the internal network.) This check will
prevent the internal network from being used as a launch point for a source IP
spoofing attack. To verify the anti-spoofing configuration, send a series of packets
with modified source addresses to the external interface. The packets should test the
ability of the router to detect both internal addresses and reserved addresses that
should not arrive at an external port. The router should drop these packets at the
perimeter and log the events. To verify outbound anti-spoofing, send packets to the
router’s internal interface with source addresses that are not legitimate internal
addresses; the router should again drop the packets and log the events. RFC 2267
discusses network ingress filtering and defeating DoS attacks which employee IP
source address spoofing. For an in-depth discussion of TCP flooding and IP spoofing,
consult [7].
There is a Cisco syslog vulnerability that may cause the IOS software to crash if an
invalid user datagram protocol (UDP) packet is received on the syslog port (port
514). This vulnerability affects unpatched versions of IOS 11.3AA, 11.3DB and
early (non-GD) releases of 12.0. Some vulnerable IOS devices will “hang” and must
be manually restarted by reset or power cycle; it might require an administrator to
physically visit the attacked device to restore service. At least one commonly
available internet scanning tool can generate these UDP packets. By sending such
packets continuously, an attacker might be able to completely disable a Cisco IOS
device until the affected device is reconfigured to drop the problem traffic. This
problem can be prevented by applying the appropriate input access list to all
interfaces that might receive these packets. This input access list must block traffic
destined for UDP port 514 at any of the Cisco IOS device’s own IP addresses, as well
as at any broadcast or multicast addresses on which the device may be listening. If a
specific interface is not expected to forward legitimate syslog traffic, an alternative
fix would be to deny all syslog traffic arriving on that interface. The following
example shows an access list to block the port 514 UDP traffic.
! Deny all multicasts and all unspecified broadcasts to port 514
access-list 101 deny udp any 224.0.0.0 31.255.255.255 eq 514
! Deny old-style unspecified net broadcasts
access-list 101 deny udp any host 0.0.0.0 eq 514
! Deny network specific broadcasts, in this example, the 14.2.0.0
! network behind router North (both old-style and new broadcasts)
access-list 101 deny udp any 14.2.0.255 0.0.255.0 eq 514
access-list 101 deny udp any 14.2.0.0 0.0.255.0 eq 514
! Deny packets addressed to router interface
access-list 101 deny udp any host 14.2.0.20 eq 514
! Apply to input interface of router North
interface eth0
ip access-group 101 in