From: Victor Cappuccio (vcappuccio@ccbootcamp.com)
Date: Fri Aug 03 2007 - 19:17:11 ART
Hi Guys,
The 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 :P "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)
R4#
Just my 2 Cents
thanks,
Victor Cappuccio.-
- CCSI# 31452
CCBOOTCAMP - A Cisco Sponsored Organization (SO)
email: vcappuccio@ccbootcamp.com
Toll Free: 877-654-2243
Direct: +1-702-968-5100 = Outside the USA
FAX: +1-702-446-8012
YES! We take Cisco Learning Credits!
Training And Remote Racks: http://www.ccbootcamp.com
Register to win a free iPhone! http://www.ccbootcamp.com/iphone.html
-----Original Message-----
From: nobody@groupstudy.com on behalf of Gary Duncanson
Sent: Fri 03-Aug-07 1:53 PM
To: Guyler, Rik
Cc: ccielab@groupstudy.com
Subject: Re: TCP Intercept
Never used it in anger. I reckon you could do that though. Found these words
of advice on the web..
'If TCP Intercept is enabled, two concerns come to the fore.
First, do not use black hole routes. TCP Intercept is coded to handle a
SYN/ACK or RST, not silence. A simple DOS is possible if the router proxies
the TCP sockets and no one is there to answer the call on the other side.
Second, when paired with a firewall, ensure that the firewall will issue a
RST for denied services. The same reasoning as noted above applies here.'
www.cymru.com offer this advice concerning the secure IOS template.
http://www.cymru.com/Documents/secure-ios-template.htm
sic 'Black hole routes. Do not combine this with TCP Intercept;
in fact, don't use TCP Intercept at all'.
----- Original Message -----
From: "Guyler, Rik" <rguyler@shp-dayton.org>
To: <cisco@groupstudy.com>; <ccielab@groupstudy.com>
Sent: Friday, August 03, 2007 7:41 PM
Subject: OT: TCP Intercept
> Just an OT question for the collective: are BGP routers a suitable
> location
> to run TCP Intercept?
>
> I would think that the edge of my network is a perfect place to try to
> defend against DOS attacks but I don't know what negative side effects
> might
> appear (if any) by doing this.
>
> ---
> Rik
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:09 ART