Using CAR to mitigate SMURF attack

September 8, 2008 at 3:31 pm | In QoS, Security | Leave a Comment

Configuration (Modular QoS)

R4#

access-list 100 permit icmp any any echo-reply

class-map match-all SMURF_TRAFFIC
match access-group 100
!
!
policy-map SMURF_MITIGATION
class SMURF_TRAFFIC
police cir 64000 bc 8000 be 4000

interface Serial0/1
service-policy input SMURF_MITIGATION

interface Serial0/0.1 point-to-point
service-policy input SMURF_MITIGATION

Verification

R4#sh policy-map interface s0/1
Serial0/1

Service-policy input: SMURF_MITIGATION

Class-map: SMURF_TRAFFIC (match-all)
1860 packets, 2597440 bytes
30 second offered rate 61000 bps, drop rate 4000 bps
Match: access-group 100
police:
cir 64000 bps, bc 8000 bytes
conformed 1699 packets, 2355296 bytes; actions:
transmit
exceeded 161 packets, 242144 bytes; actions:
drop
conformed 54000 bps, exceed 4000 bps

Class-map: class-default (match-any)
72 packets, 6084 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

Configuration (Legacy QoS)

R4#
access-list 100 permit icmp any any echo-reply
interface Serial0/0.1 point-to-point
rate-limit input access-group 100 64000 8000 12000 conform-action transmit exceed-action drop
!
interface Serial0/1
rate-limit input access-group 100 64000 8000 12000 conform-action transmit exceed-action drop

Verification

R4#sh access-list 100
Extended IP access list 100
10 permit icmp any any echo-reply (278 matches)

R4#sh interface s0/1 rate-limit
Serial0/1
Input
matches: access-group 100
params:  64000 bps, 8000 limit, 12000 extended limit
conformed 130 packets, 195520 bytes; action: transmit
exceeded 12 packets, 18048 bytes; action: drop
last packet: 324ms ago, current burst: 3776 bytes
last cleared 00:01:10 ago, conformed 22000 bps, exceeded 2000 bps

Doc CD Navigation

There’s not a dedicated “configuration guide” or “command reference” specific for this.

Smurf attack is a general term describing one type of DoS attacks. The perpetrator launches many ICMP directed broadcast pings to many “proxy attacking networks” with spoof source address of the victim. The victim then is under a storm of return echo-reply traffic from “proxy attacking networks”.

To prevents the network from “attacking” other networks, or better said, taking part in a Smurf attack, we should disable directed broadcast, and drop packets with spoofed source IP (no ip unicast)

interface s0/1
 ip verify unicast reverse-path
interface e0/0
 no ip directed-broadcast

To minimize the effect of Smurf attack, just rate limit the Echo-Reply traffic (MQC and Legacy configuration at the top of this post).

For additional info, below is a security white paper

Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks

General Smurf attack description can be found outside Cisco website, e.g. wikipedia

http://en.wikipedia.org/wiki/Smurf_attack

The Smurf attack is a way of generating a lot of computer network traffic to a victim host. That is, it is a type of denial-of-service attack. Specifically, it floods a target system via spoofed broadcast ping messages.

In such an attack, a perpetrator sends a large amount of ICMP echo requests (ping) traffic to IP broadcast addresses, all of it having a spoofed source address of the intended victim. If the routing device delivering traffic to those broadcast addresses delivers the IP broadcast to all hosts (for example via a layer 2 broadcast), most hosts on that IP network will take the ICMP echo request and reply to it with an echo reply, multiplying the traffic by the number of hosts responding. On a multi-access broadcast network, hundreds of machines might reply to each packet.[1]

In the late 1990s, many IP networks would participate in Smurf attacks (that is, they would respond to pings to broadcast addresses). Today, thanks largely to the ease with which administrators can make a network immune to this abuse, very few networks remain vulnerable to Smurf attacks.[2]

The fix is twofold:

  • Configure individual hosts and routers not to respond to ping requests to broadcast addresses,[1] and
  • Configure routers not to forward packets directed to broadcast addresses. Until 1999, standards required routers to forward such packets by default, but in that year, the standard was changed to require the default to be not to forward.[3]

Another proposed solution, to fix this as well as other problems, is network ingress filtering which rejects the attacking packets on the basis of the forged source address.[4

Configuring Application Port-Mapping with CBAC

September 8, 2008 at 1:15 pm | In Security | Leave a Comment

Configuration

ip access-list extended INSIDE
deny   ip any any

access-list 99 permit 10.0.0.0 0.0.0.255

ip port-map telnet port tcp 1023 list 99
ip port-map telnet port tcp 6023 list 99

ip inspect name INSPECT_TELNET telnet
!

interface Ethernet0/0
ip address 10.0.0.4 255.255.255.0
ip access-group INSIDE in

interface Serial0/0.1 point-to-point
ip inspect INSPECT_TELNET in
!
interface Serial0/1
ip inspect INSPECT_TELNET in

Verification

Before creating Port Map, the CBAC does allows telnet traffic to pass through, but the inspect session does not show up.  After the Port Map, we do see the sessions, similar as normal CBAC.

R5#telnet 150.1.4.4 1023
Trying 150.1.4.4, 1023 … Open

R4#sh ip inspect sessions
Established Sessions
Session 6555F098 (155.1.45.5:13547)=>(10.0.0.1:23) telnet SIS_OPEN

R5#telnet 150.1.4.4 6023
Trying 150.1.4.4, 6023 … Open

R4#sh ip inspect sessions
Established Sessions
Session 6555F098 (155.1.45.5:13547)=>(10.0.0.1:23) telnet SIS_OPEN
Session 6555EE18 (155.1.45.5:56852)=>(10.0.0.6:23) telnet SIS_OPEN


DOC CD Navigation

Side note

Remember the port-map command does not have NBAR keyword. The one with NBAR does not have ACL option, and is used for QoS purpose.

[QoS] ip nbar port-map

To configure network-based application recognition (NBAR) to search for a protocol or protocol name using a port number other than the well-known port, use the ip nbar port-map command in global configuration mode. To look for the protocol name using only the well-known port number, use the no form of this command.

ip nbar port-map protocol-name [tcp | udp] port-number


[Security] ip port-map

To establish port-to-application mapping (PAM), use the ip port-map command in global configuration mode. To delete user-defined PAM entries, use the no form of this command.

ip port-map appl-name port [tcp | udp] [ port_num | from begin_port_num to end_port_num] [list acl-num] [description description_string]

DoS Attacks Prevention with CBAC

September 8, 2008 at 11:16 am | In Security | Leave a Comment

onfiguration
R4#sh run
ip inspect max-incomplete high 1200
ip inspect max-incomplete low 1000
ip inspect one-minute low 100
ip inspect one-minute high 300
ip inspect tcp max-incomplete host 50 block-time 5
ip inspect name DOS_MITIGATION tcp
interface Ethernet0/0
ip inspect DOS_MITIGATION out

Verification

R4#sh ip inspect all
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [100:300] connections
max-incomplete sessions thresholds are [1000:1200]
max-incomplete tcp connections per host is 50. Block-time 5 minutes.
tcp synwait-time is 30 sec — tcp finwait-time is 5 sec
tcp idle-time is 3600 sec — udp idle-time is 30 sec
dns-timeout is 5 sec
Inspection Rule Configuration
Inspection name DOS_MITIGATION
tcp alert is on audit-trail is off timeout 3600

Interface Configuration
Interface Ethernet0/0
Inbound inspection rule is not set
Outgoing inspection rule is DOS_MITIGATION
tcp alert is on audit-trail is off timeout 3600
Inbound access list is not set
Outgoing access list is not set

Established Sessions
Session 6555F098 (155.1.45.5:18166)=>(10.0.0.1:23) tcp SIS_OPEN

! Try generating TCp traffic from outside
R5#telnet 10.0.0.1
Trying 10.0.0.1 … Open

R4#debug ip inspect tcp
INSPECT TCP Inspection debugging is on
R4#debug ip inspect events
INSPECT special events debugging is on
R5#debug ip tcp transactions
TCP special event debugging is on

R5#telnet 10.0.0.1
Trying 10.0.0.1 …
*Apr  7 02:37:15.439: TCP: Random local port generated 19679
*Apr  7 02:37:15.443: TCB64ECDAF0 created
*Apr  7 02:37:15.443: TCB64ECDAF0 setting property TCP_TOS (11) 658277D8
*Apr  7 02:37:15.443: TCB64ECDAF0 bound to UNKNOWN.19679
*Apr  7 02:37:15.443: TCP: sending SYN, seq 3882602081, ack 0
*Apr  7 02:37:15.443: TCP0: Connection to 10.0.0.1:23, advertising MSS 536
*Apr  7 02:37:15.447: TCP0: state was CLOSED -> SYNSENT [19679 -> 10.0.0.1(23)]
*Apr  7 02:37:17.443: 155.1.45.5:19679 <—> 10.0.0.1:23   congestion window changes
*Apr  7 02:37:17.443: cwnd from 536 to 536, ssthresh from 65535 to 1072
*Apr  7 02:37:17.443: TCP0: timeout #1 – timeout is 3000 ms, seq 3882602081
% Connection timed out; remote host not responding
*Apr  7 02:37:20.443: TCP0: state was SYNSENT -> CLOSED [19679 -> 10.0.0.1(23)]
*Apr  7 02:37:20.443: TCB 0×64ECDAF0 destroyed

R4#
*Apr  7 11:53:54.727: CBAC sis 6555F098 pak 65322FBC SIS_CLOSED/LISTEN TCP SYN SEQ 3882602081 LEN 0 (155.1.45.5:19679) => (10.0.0.1:23)
*Apr  7 11:53:56.723: CBAC sis 6555F098 pak 64E422BC SIS_OPENING/SYNSENT TCP SYN SEQ 3882602081 LEN 0 (155.1.45.5:19679) => (10.0.0.1:23)
*Apr  7 11:53:56.723: CBAC sis 6555F098 L4 inspect result: SKIP packet 64E422BC (155.1.45.5:19679) (10.0.0.1:23) bytes 0 ErrStr = Retransmitted Segment tcp
*Apr  7 11:54:24.727: CBAC sent a TCP pkt (10.0.0.1:23) tcp flag:0×4 -> 155.1.45.5:19679 seq 0 ack 0 wnd 4128
*Apr  7 11:54:24.727: CBAC sent a TCP pkt (155.1.45.5:19679) tcp flag:0×4 -> 10.0.0.1:23 seq 3882602082 ack 0 wnd 0

DOC CD Navigation

You can configure TCP and UDP inspection to permit TCP and UDP packets to enter the internal network through the firewall, even if the application-layer protocol is not configured to be inspected. However, TCP and UDP inspection do not recognize application-specific commands, and therefore might not permit all return packets for an application, particularly if the return packets have a different port number than the previous exiting packet.

Any application-layer protocol that is inspected will take precedence over the TCP or UDP packet inspection. For example, if inspection is configured for FTP, all control channel information will be recorded in the state table, and all FTP traffic will be permitted back through the firewall if the control channel information is valid for the state of the FTP session. The fact that TCP inspection is configured is irrelevant to the FTP state information.

With TCP and UDP inspection, packets entering the network must exactly match the corresponding packet that previously exited the network. The entering packets must have the same source/destination addresses and source/destination port numbers as the exiting packet (but reversed); otherwise, the entering packets will be blocked at the interface. Also, all TCP packets with a sequence number outside of the window are dropped.

Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.