Cisco TCP intercept

TCP intercept feature implements software to protect TCP servers from TCP
SYN-flooding attacks, which are a type of denial-of-service attack

by

http://www.cert.org/tech_tips/denial_of_service.html

A “denial-of-service” attack is characterized by an explicit attempt by
attackers to prevent legitimate users of a service from using that service.
Examples include

* attempts to “flood” a network, thereby preventing legitimate network
traffic
* attempts to disrupt connections between two machines, thereby preventing
access to a service
* attempts to prevent a particular individual from accessing a service
* attempts to disrupt service to a specific system or person

so lets do a DOS ūüėõ¬† “just 4 education purpose”

Having this topology

R2 — R1 — R4 — BB2
|
R5

R2#traceroute 212.2.12.254

Type escape sequence to abort.
Tracing the route to 212.2.12.254

1 192.168.12.1 0 msec 0 msec 4 msec
2 192.168.134.4 28 msec 32 msec 28 msec
3 212.2.12.254 28 msec *  28 msec
R2#

R5#traceroute 212.2.12.254

Type escape sequence to abort.
Tracing the route to 212.2.12.254

1 192.168.45.4 28 msec 28 msec 28 msec
2  *
212.2.12.254 28 msec *
R5#

R1#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#do show ip int brief  | ex una
Interface                  IP-Address      OK? Method Status
Protocol
FastEthernet0/0            192.168.173.1   YES NVRAM  up                    up
Serial0/0/0                192.168.134.1   YES manual up                    up
Serial0/0/1                192.168.12.1    YES NVRAM  up                    up
Loopback0                  110.110.1.1     YES NVRAM  up                    up
R1(config)#

So the packets in R1 goes like this

*Aug  3 21:53:58.896: IP: s=212.2.12.254 (Serial0/0/0), d=192.168.12.0
(Serial0/0/1), g=192.168.12.0, len 100, forward

lets modify a little bit the process

R1#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int s0/0/1
R1(config-if)#ip nat in
R1(config-if)#exit
*Aug  3 21:39:00.928: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0,
changed state to up
R1(config)#int s0/0/0
R1(config-if)#ip nat out
R1(config-if)#exit
R1(config)#ip nat inside source static 192.168.12.0 192.168.45.5
R1(config)#
*Aug  3 22:01:05.580: ipnat_add_static_cfg: id 6, flag 6
*Aug  3 22:01:05.580: id 6, flags 0, domain 0, lookup 0, from_addr C0A80C00,
from_mask FFFFFFFF, from_port 0, to_addr C0A82D05, to_port 0 to_mask FFFFFFFF,
proto 0
*Aug  3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug  3 22:01:05.600: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8516]
*Aug  3 22:01:05.600: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8516]
R1(config)#
*Aug  3 22:01:07.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8517]
*Aug  3 22:01:07.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8517]
R1(config)#do u
*Aug  3 22:01:09.596: NAT*: i: icmp (192.168.12.0, 10) -> (212.2.12.254, 10)
[8518]
*Aug  3 22:01:09.596: NAT*: s=192.168.12.0->192.168.45.5, d=212.2.12.254
[8518]
R1(config)#do u all
All possible debugging has been turned off
R1(config)#

So we are now translating the thing ūüôā

Now BB2 thinks that the thing comes from R5

*Aug  3 22:36:29.904: IP: tableid=0, s=192.168.45.5 (FastEthernet0/0),
d=212.2.12.254 (FastEthernet0/0), routed via RIB
*Aug  3 22:36:29.904: IP: s=192.168.45.5 (FastEthernet0/0), d=212.2.12.254
(FastEthernet0/0), len 100, rcvd 3
*Aug  3 22:36:29.904: IP: tableid=0, s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), routed via FIB
*Aug  3 22:36:29.904: IP: s=212.2.12.254 (local), d=192.168.45.5
(FastEthernet0/0), len 100, sending
BB2#

hehehe

now lets configure the TCP intercept to see how it works

again in this cisco link
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur
_c/scprt3/scddenl.htm

A SYN-flooding attack occurs when a hacker floods a server with a barrage of
requests for connection. Because these messages have unreachable return
addresses, the connections cannot be established. The resulting volume of
unresolved open connections eventually overwhelms the server and can cause it
to deny service to valid requests, thereby preventing legitimate users from
connecting to a web site, accessing e-mail, using FTP service, and so on.

Page 27 http://www.faqs.org/rfcs/rfc793.html

The synchronization requires each side to send it’s own initial
sequence number and to receive a confirmation of it in acknowledgment
from the other side.¬† Each side must also receive the other side’s
initial sequence number and send a confirming acknowledgment.

1) A –> B¬† SYN my sequence number is X
2) A <РB  ACK your sequence number is X
3) A <РB  SYN my sequence number is Y
4) A –> B¬† ACK your sequence number is Y

so lets try this on R2, BB1 and see what is the deal

BB2#debug ip tcp pac
TCP Packet debugging is on
BB2#
rack8>2
[Resuming connection 2 to R2 … ]

R2#telnet 212.2.12.254
Trying 212.2.12.254 …
rack8>11
[Resuming connection 11 to bb2 … ]

*Aug  3 22:40:28.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN  WIN 4128
*Aug  3 22:40:28.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1347870184
OPTS 4 ACK 1721243965 SYN  WIN 4128
*Aug  3 22:40:28.884: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST  WIN 0
BB2#
*Aug  3 22:40:30.852: tcp0: I LISTEN 192.168.45.5:17199 212.2.12.254:23 seq
1721243964
OPTS 4 SYN  WIN 4128
*Aug  3 22:40:30.852: tcp0: O SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1849125975
OPTS 4 ACK 1721243965 SYN  WIN 4128
*Aug  3 22:40:30.880: tcp0: I SYNRCVD 192.168.45.5:17199 212.2.12.254:23 seq
1721243965
RST  WIN 0
BB2#
rack8>

So BB3 thinks that I comes from R5 :S

So lets configure R4 with this access-list

ip tcp intercept list 102
ip tcp intercept watch-timeout 15
ip tcp intercept mode watch
access-list 102 permit tcp any 212.2.12.0 0.0.0.255

R4#show tcp intercept  statistics
Watching new connections using access-list 102
1 incomplete, 0 established connections (total 1)
2 connection requests per minute
R4#
*Aug  3 22:13:40.019: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:55622 <- 212.2.12.254:23)
*Aug  3 22:13:41.019: INTERCEPT: SYNRCVD timing out (192.168.45.5:55622 <->
212.2.12.254:23)
*Aug  3 22:13:41.019: INTERCEPT(*): (192.168.45.5:55622 RST ->
212.2.12.254:23)

or we can modify watch time to see the thing faster ūüôā

R4#conf ter
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#no ip tcp intercept watch-timeout 15
R4(config)#ip tcp intercept watch-timeout 5
command accepted, interfaces with mls configured might cause inconsistent
behavior

R4(config)#^Z
R4#show run
*Aug  3 22:15:21.359: %SYS-5-CONFIG_I: Configured from console by console
R4#show run | in intercept
ip tcp intercept list 102
ip tcp intercept watch-timeout 5
ip tcp intercept mode watch
R4#
rack8>2
[Resuming connection 2 to R2 … ]

% Connection timed out; remote host not responding

R2#
R2#telnet 212.2.12.254
Trying 212.2.12.254 …
rack8>4
[Resuming connection 4 to R4 … ]

R4#
R4#
*Aug  3 22:15:33.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug  3 22:15:33.731: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show run | in inter
*Aug  3 22:15:35.727: INTERCEPT: server packet passed in SYNRCVD
(192.168.45.5:46993 <- 212.2.12.254:23)
R4#show tcp intercept  connections
Incomplete:
Client                Server                State    Create   Timeout  Mode

Established:
Client                Server                State    Create   Timeout  Mode
R4#
*Aug  3 22:15:38.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:38.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
*Aug  3 22:15:39.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
R4#
*Aug  3 22:15:39.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#show tcp intercept  connections
Incomplete:
Client                Server                State    Create   Timeout  Mode
192.168.45.5:46993    212.2.12.254:23       SYNRCVD  00:00:03 00:00:01 W

Established:
Client                Server                State    Create   Timeout  Mode
R4#
*Aug  3 22:15:44.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:44.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)
R4#
*Aug  3 22:15:47.727: INTERCEPT: new connection (192.168.45.5:46993 SYN ->
212.2.12.254:23)
*Aug  3 22:15:47.727: INTERCEPT: (192.168.45.5:46993 <- ACK+SYN
212.2.12.254:23)
R4#
*Aug  3 22:15:52.727: INTERCEPT: SYNRCVD timing out (192.168.45.5:46993 <->
212.2.12.254:23)
*Aug  3 22:15:52.727: INTERCEPT(*): (192.168.45.5:46993 RST ->
212.2.12.254:23)

A Networker Blog

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s