Configuring DNS on Cisco IOS routers

September 6, 2008 at 11:56 pm | In IOS services | Leave a Comment

Configuration

Client R1#
----------

ip name-server 2.2.2.2
! ip domain-lookup is enabled by default
ip domain-lookup

Server R2#
----------

ip dns server
! ip domain-lookup is enabled by default
ip domain-lookup

ip host R2 2.2.2.2
ip host R1 1.1.1.1
! We can point to another DNS server
ip name-server 61.8.8.8

! but DO NOT point name-server to itself
! NO ip name-server 2.2.2.2

Verification

R1#ping R2

Translating “R2″…domain server (2.2.2.2) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms
R1#
*Apr  7 11:35:07.163: Domain: query for R2 type 1 to 2.2.2.2
*Apr  7 11:35:07.195: DOM: dom2cache: hostname is R2, RR type=1, class=1, ttl=1, n=4Reply received ok

R2#debug domain
Domain Name System debugging is on
R2#
*Apr  7 02:18:27.683: DNS: Incoming UDP query (id#2)
*Apr  7 02:18:27.683: DNS: Type 1 DNS query (id#2) for host ‘R2′ from 12.0.0.1(58198)
*Apr  7 02:18:27.683: DNS: Query for my own hostname: R2
*Apr  7 02:18:27.683: DNS: Spoofing reply to query (id#2)
*Apr  7 02:18:27.683: DNS: Finished processing query (id#2) in 0.004 secs

REPRODUCE ROUTER CRASH

Router may crash if we configure it as a DNS server, and also point “ip name-server” to itself.

R2#c
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip name-server 2.2.2.2
R2(config)#
R2#
R2#
R2#

!
! The R2 successfully serves the DNS queuries
! for valid hostnames (When “ping R2″ is issued on R1 router)

R1#ping R2

Translating “R2″…domain server (2.2.2.2) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/58/60 ms

*Apr  7 11:35:58.539: Domain: query for R2 type 1 to 2.2.2.2
*Apr  7 11:35:58.571: DOM: dom2cache: hostname is R2, RR type=1, class=1, ttl=1, n=4Reply received ok

R2#
*Apr  7 02:19:19.059: DNS: Incoming UDP query (id#3)
*Apr  7 02:19:19.059: DNS: Type 1 DNS query (id#3) for host ‘R2′ from 12.0.0.1(54174)
*Apr  7 02:19:19.059: DNS: Query for my own hostname: R2
*Apr  7 02:19:19.059: DNS: Spoofing reply to query (id#3)
*Apr  7 02:19:19.059: DNS: Finished processing query (id#3) in 0.000 secs
R2#
R2#

! The R2 crashes when “ping R3″ is issued on R1 router

R1#ping R3

Translating “R3″…domain server (2.2.2.2)
*Apr  7 11:36:22.991: Domain: query for R3 type 1 to 2.2.2.2
% Unrecognized host or address, or protocol not running.

timed out

*Apr  7 11:36:55.459: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1, changed state to down
*Apr  7 11:36:55.459: %OSPF-5-ADJCHG: Process 1, Nbr 12.0.0.2 on Serial0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

! As R2 cannot resolve IP for hostname R3, it tries to forward the queury to
! the next DNS server with IP address of itself. And the request keeps

! looping within R2.
!
!

R2#

DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
DNS: Type 1 DNS query (id#4) for host ‘R3′ from 2.2.2.2(53)
DNS: Re-sending DNS query (type 1, id#4) to 2.2.2.2
DNS: Incoming UDP query (id#4)
Doc CD Navigation

TCP Intercept

September 6, 2008 at 3:20 pm | In Security | 1 Comment

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

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.

The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an extended access list. The software establishes a connection with the client on behalf of the destination server, and if successful, establishes the connection with the server on behalf of the client and knits the two half-connections together transparently. Thus, connection attempts from unreachable hosts will never reach the server. The software continues to intercept and forward packets throughout the duration of the connection. The number of SYNs per second and the number of concurrent connections proxied depends on the platform, memory, processor, and other factors.

In the case of illegitimate requests, the software’s aggressive timeouts on half-open connections and its thresholds on TCP connection requests protect destination servers while still allowing valid requests.

You can choose to operate TCP intercept in watch mode, as opposed to intercept mode. In watch mode, the software passively watches the connection requests flowing through the router. If a connection fails to get established in a configurable interval, the software intervenes and terminates the connection attempt.

Configuration

R4#sh run | in tcp
ip tcp intercept list 199
ip tcp intercept connection-timeout 3600
ip tcp intercept max-incomplete low 1200
ip tcp intercept max-incomplete high 1500
ip tcp intercept drop-mode random
access-list 199 permit tcp any 150.1.4.0 0.0.0.255 eq www

! Turn off CEF and Fast Switching to be able to see Debug IP TCP intercept

interface Ethernet0/0
 no ip route-cache

interface Serial0/0.1 point-to-point
 no ip route-cache

interface Serial0/1
 no ip route-cache

Verification

R4#debug ip tcp intercept
TCP intercept debugging is on

R4#
*Apr  7 11:17:29.051: INTERCEPT: new connection (155.1.45.5:34600 SYN -> 150.1.4.100:80)
*Apr  7 11:17:29.051: INTERCEPT(*): (155.1.45.5:34600 <- ACK+SYN 150.1.4.100:80)
*Apr  7 11:17:29.067: INTERCEPT: 1st half of connection is established (155.1.45.5:34600 ACK -> 150.1.4.100:80)
*Apr  7 11:17:29.067: INTERCEPT(*): (155.1.45.5:34600 SYN -> 150.1.4.100:80)
*Apr  7 11:17:29.071: INTERCEPT: client packet dropped in SYNSENT (155.1.45.5:34600 -> 150.1.4.100:80)
*Apr  7 11:17:29.075: INTERCEPT: client packet dropped in SYNSENT (155.1.45.5:34600 -> 150.1.4.100:80)
*Apr  7 11:17:30.067: INTERCEPT(*): SYNSENT retransmit 1 (155.1.45.5:34600 SYN -> 150.1.4.100:80)
*Apr  7 11:17:30.067: INTERCEPT: client packet dropped in SYNSENT (155.1.45.5:34600 -> 150.1.4.100:80)

*Apr  7 11:18:00.067: INTERCEPT: SYNSENT retransmitting too long (155.1.45.5:34600 <-> 150.1.4.100:80)
*Apr  7 11:18:00.067: INTERCEPT(*): (155.1.45.5:34600 <- RST 150.1.4.100:80)

One side note with debugging ip tcp intercept is that we have to turn the CEF or Fast Switching off, similar to when you want to see output of debug ip packet for those that transit the router. If we do not have “no ip route-cache” interface command, we will not see transit IP packets. Same applied for tcp intercept sessions.

Doc CD Navigation

  • Cisco IOS Security Configuration Guide, Release 12.4
  • Traffic Filtering, Firewalls, and Virus Detection
  • Configuring TCP Intercept (Preventing Denial-of-Service Attacks)
  • TCP Intercept Configuration Task List

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