Entries Tagged as ''

IP Packets Spoofing Prevention

Cisco IOS provides two features to prevent IP packets spoofing. One is called uRPF (Unicast Reverse Path Forwarding), which is handled on Layer 3 (Network Layer). The other is called IP Source Guard, which is handled on Layer 2 (Data Link Layer), consequently, it applies to LAN Switches.

uRPF is the concept of verifying the routing path for the source IP address found in an IP packet. As we have known, packets arrive on the interfaces that are on the shortest path to the source of the packets. However, with IP spoofing attacks, a malicious user may inject packets with IP address not belonging to its segment or network. Under uRPF check, such packets may appera on the interfaces not on the shortest path to their source. This feature has two modes

- Strict Mode: ip verify unicast source reachable-via rx command. The source IP address must match an explicit IP route in the routing table, and, the most important, the next hop for this entry should point out of the interface the packet was received from.

- Loose mode: ip verify unicast source reachable-via any. It just checks that it has an IP route matching the source address in the packet. It doesn’t matter whether the next hop for this route points out the receiving interface or not.

IP Source Guard is intended to prevent IP packet spoofing at Layer 2. When you enable IP Source Guard on a port, the switch applies a Layer 3 filter to this port, only accepting the packets with source IP addresses matching DHCP snooping bindings created for the port. Enabling DHCP snooping is a prerequisite. As soon as you enable IP Source Guard, the switch only permits IP packets that match the DHCP snooping database or static IP to MAC addresses and port bindings. The switch also allows ingress DHCP packets for hosts to obtain IP addresses.

interface FastEthernet 0/1
ip verify source port-security
switchport port-security maximum 1
switchport port-security

Three Ways to Implement Traffic Shapping

There are three ways to implement traffic shaping.

  • Generic Traffic Shapping (GTS)
  • Frame Relay Traffic Shapping (FRTS)
  • Class-based Traffic Shapping (MQC-S)

Generic Traffic Shaping (GTS) was the first feature to limit the outbound traffic rate of an interface introduced into IOS. With GTS all traffic leaving an interface/subinterface can be shaped, or a subset of traffic can be classified using an access-list. The syntax is as follows.

traffic-shape rate <CIR> <Bc> <Be> <QueueLimit>
traffic-shape group <ACL> <CIR> <Bc> <Be> <QueueLimit>

access-list 101 permit tcp any any eq www
!
interface fa0/0
traffic-shap group 101 10000000

FRTS supports four types of adaptive shaping, 1) BECN adapt, 2) FECN reflection, 3) queue depth monitoring, and 4) a proprietary method called ForeSight.

map-class frame-relay TO->R1
frame-relay cir 512000
frame-relay mincir 256000
frame-relay bc 5120
frame-relay be 0
frame-relay adaptive-shaping becn
frame-relay adaptive-shaping interface-congestion 10
!

interface s0/0
frame-relay traffic-shapping //Switch on FRTS
frame-relay class TO->R1

MQC based traffic-shaping allows Generic Traffic Shaping to be applied to any traffic class. This makes traffic-shaping’s configuration modular and unified, without special variants for encapsulations like Frame Relay. Class-based GTS is similar to legacy GTS, but allows shaping based on class-maps, as opposed to access-list classification with legacy GTS, thus allowing any MQC classification options, such as NBAR, to define shaped traffic. Additionally MQC based shaping allows the shaping queue to be tuned, while legacy GTS supports just simple WFQ with no option to tune it.

policy-map SHAPE
class class-default
shape average 384000 7680
!
interface fa0/0
service-policy output SHAPE

Two Ways of Frame Relay DE Set

DE bit set means Eligible for Discarding during periods of traffic congestion of frame relay network. It is congestion avoidance mechanism in FR. Obviously, DE bit set is for out-bound traffic of a router to FR switch. There are three ways to set DE bit.

1. FR DE List

Step 1: Classifier traffic by ACL

Step 2: Apply DE List

Step 3: Map DE List to DLCI

! Classifier
access-list 101 permit tcp any any eq www
! Mark
frame-relay de-list 1 protocol ip list 101
! Mapping
interface s0/0
frame-realy de-group 1 101

2. MQC

Step 1: Define Class-map

Step 2: Define Policy-map

Step 3: Apply to out-bound traffic

class-map WWW
match ip address 101
!
policy-map WWW_PO
class WWW
set fr-de
!
interface s0/0
service-policy output WWW_PO
!
access-list 101 permit tcp any any eq www
!
ip cef

3. FRTS

Step 1: Switch on Frame Relay Traffic Shapping on the interface level. Then, DE is set automatically.

interface s0/0
frame-relay traffic-shapping