Catalyst Dot1x Port-based authentication

October 2, 2008 at 5:32 pm | Posted in Security, Switching | Leave a comment

Doc CD Navigation

Configuration

aaa new-model
!
aaa authentication login LINE_VTY line
aaa authentication dot1x default group radius
aaa authorization network default group radius 
!
radius-server host 1.2.3.4 
radius-server key cisco
!
interface fa0/1
 description Connection to R1
 switchport mode access
 switchport access vlan 135
 dot1x port-control force-authorized 

interface range fa0/5-10
 description Ports with Dot1X authentication
 switchport mode access
 switchport access vlan 135
 dot1x port-control auto

Using CAR to mitigate SMURF attack

September 8, 2008 at 3:31 pm | Posted 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 | Posted 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 | Posted 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 0x64ECDAF0 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:0x4 -> 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:0x4 -> 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.

TCP Intercept

September 6, 2008 at 3:20 pm | Posted 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

NBAR confusion – usage of “match protocol http url”

September 5, 2008 at 5:04 pm | Posted in Blogroll, QoS, Security | 2 Comments

Doing IE WB1, Section Security – Task Using NBAR to Filter Traffic. I am confused by the solution guide . The tasks is to drop HTTP IMAGE requests from Client to Server.

HTTP Client ------- R4 ------- Server HTTP
                       S0/1

Solution creates a policy that match images using match http url, but the policy is applied INBOUND on the WAN interfaces (S0/1) ! I believe that this policy should be applied OUTBOUND to stop HTTP Requests.

However, that is not my main concern. I used to believe that “match protocol http url” can only be used to match HTTP REQUESTS, and not to match HTTP RESPONSES (IMAGE data) from server. To match IMAGE data themselves, I thought that  match MIME type should be used. But it seems I may be WRONG!

“match protocol http url” seems to be able to match HTTP RESPONSE from Servers as well.

I tried snipping (using Wireshark) a real HTTP session. I could see the reference to URL in the GET request, but I do not see any reference to that URL in the data response from the server!

Below is config and verification to show that both HTTP requests for Images and Image return data can be matched by using “match protocol http url”.

Configuration:

R4#

class-map match-any IMAGES
 match protocol http url "*.gif"
 match protocol http url "*.jpeg|*.jpg"
!
!
! HTTP_REQUEST policy is my additional config for matching illustration policy-map HTTP_REQUEST  class IMAGES

policy-map DROP_IMAGES
 class IMAGES
   drop

interface Serial0/1
 service-policy input DROP_IMAGES
 service-policy output HTTP_REQUEST

Verification:

Try to generate HTTP get request from inside (R1) to outside 150.1.5.5 (HTTP Server)

R1#copy http://150.1.5.5/test.jpg null:
%Error opening http://150.1.5.5/test.jpg (I/O error)

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

  Service-policy input: DROP_IMAGES

    Class-map: IMAGES (match-any)
      8 packets, 1657 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*.gif"
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: protocol http url "*.jpeg|*.jpg"
        8 packets, 1657 bytes
        5 minute rate 0 bps
      drop

    Class-map: class-default (match-any)
      18 packets, 1530 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any 

  Service-policy output: HTTP_REQUEST

    Class-map: IMAGES (match-any)
      5 packets, 708 bytes
      5 minute offered rate 0 bps
      Match: protocol http url "*.gif"
        0 packets, 0 bytes
        5 minute rate 0 bps
      Match: protocol http url "*.jpeg|*.jpg"
        5 packets, 708 bytes
        5 minute rate 0 bps

    Class-map: class-default (match-any)
      27 packets, 1936 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
Wireshark view of HTTP GET request

Wireshark view of HTTP GET request

Wireshark view of return IMAGE DATA

Wireshark view of return IMAGE DATA

Lock & Key

September 5, 2008 at 1:04 pm | Posted in Security | Leave a comment

Configuration

R4#
ip access-list extended INBOUND
 permit ospf any any
 permit tcp any any eq bgp
 permit tcp any eq bgp any
 permit tcp any host 150.1.4.4 eq telnet
 dynamic ACCESS timeout 10 permit ip any any
 deny   ip any any log

interface Serial0/0.1 point-to-point
 ip access-group INBOUND in 
!
interface Serial0/1
 ip access-group INBOUND in

username DYNACL password 0 CISCO
username DYNACL autocommand access-enable host timeout 5

line vty 0 4
 login local

The first 3 access-list entry allow routing traffic to pass through, which is not subject to lock & key. The forth command only Telnet into the router. The fifth access-list entry is always ignored until lock-and-key is triggered.

In the access-list command, the timeout is the absolute timeout. In this example, the lifetime of the ACCESS ACL is 10 minutes; that is, when a user logs in and enable the access-enable command, a dynamic ACL is created for 10 minutes (the maximum absolute time). The session is closed after 10 minutes, whether or not anyone is using it.

In the autocommand command, the timeout is the idle timeout. In this example, each time the user logs in or authenticates there is a 5-minute session. If there is no activity, the session closes in 5 minutes and the user has to reauthenticate. If the user uses the connection, the absolute time takes affect and the session closes in 10 minutes.

After a user opens a Telnet session into the router, the router will attempt to authenticate the user. If authentication is successful, the autocommand executes and the Telnet session terminates. The autocommand creates a temporary inbound access list entry at the S0/0.1 and S0/1 interfaces, based on the fifth access-list entry (ACCESS). This temporary entry will expire after 5 minutes of inactivity, as specified by the timeout.

Verification

R5#telnet 150.1.4.1
Trying 150.1.4.1 ...
% Destination unreachable; gateway or host down

R5#telnet 150.1.4.6
Trying 150.1.4.6 ...
% Destination unreachable; gateway or host down

R4#
Sep  5 11:47:07.695: %SEC-6-IPACCESSLOGP: list INBOUND denied tcp 155.1.45.5(55291) -> 150.1.4.1(23), 1 packet
Sep  5 11:47:09.091: %SEC-6-IPACCESSLOGP: list INBOUND denied tcp 155.1.45.5(59072) -> 150.1.4.6(23), 1 packet 

R5#telnet 150.1.4.4
Trying 150.1.4.4 ... Open

User Access Verification

Username: DYNACL
Password:
[Connection to 150.1.4.4 closed by foreign host]
R5#telnet 150.1.4.1
Trying 150.1.4.1 ... Open

R1#exit

[Connection to 150.1.4.1 closed by foreign host]
R5#telnet 150.1.4.6
Trying 150.1.4.6 ... Open

R4#sh access-lists
Extended IP access list INBOUND
    10 permit ospf any any (92 matches)
    20 permit tcp any any eq bgp
    30 permit tcp any eq bgp any (21 matches)
    35 permit tcp any host 150.1.4.4 eq telnet (297 matches)
    40 Dynamic ACCESS permit ip any any
       permit ip host 155.1.45.5 any (36 matches) (time left 287)
    50 deny ip any any log (8 matches)

R5#telnet 150.1.4.6 /source-interface Serial0/0.1
Trying 150.1.4.6 ...
% Destination unreachable; gateway or host down

R5#telnet 150.1.4.4 /source-interface Serial0/0.1
Trying 150.1.4.4 ... Open

User Access Verification

Username: DYNACL
Password:
[Connection to 150.1.4.4 closed by foreign host]
R5#telnet 150.1.4.6 /source-interface Serial0/0.1
Trying 150.1.4.6 ... Open

R6#exit

[Connection to 150.1.4.6 closed by foreign host]

Doc CD Navigation

  • Cisco IOS Security Configuration Guide, Release 12.4
  • Traffic Filtering, Firewalls, and Virus Detection
  • Configuring Lock-and-Key Security (Dynamic Access Lists)
  • Lock-and-Key Configuration Examples
  • Lock-and-Key with Local Authentication Example

IOS Firewall – CBAC

September 4, 2008 at 3:23 pm | Posted in Security | Leave a comment

Configuration

R4#
ip inspect name INSPECT tcp router-traffic
ip inspect name INSPECT icmp router-traffic
ip inspect name INSPECT ftp 

ip access-list extended INBOUND
 permit ospf any any
 permit tcp any any eq bgp
 deny   ip any any
!
interface Serial1/1
 ip access-group INBOUND in
 ip inspect INSPECT out

Verification

Try telneting from R6 and from R4 to R5 150.1.5.5

R4#sh ip inspect config
Session audit trail is disabled
Session alert is enabled
one-minute (sampling period) thresholds are [unlimited : unlimited] connections
max-incomplete sessions thresholds are [unlimited : unlimited]
max-incomplete tcp connections per host is unlimited. Block-time 0 minute.
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 INSPECT
    tcp alert is on audit-trail is off timeout 3600
 inspection of router local traffic is enabled
    icmp alert is on audit-trail is off timeout 10
 inspection of router local traffic is enabled

R4#sh access-list INBOUND
Extended IP access list INBOUND
    40 permit ospf any any (143 matches)
    60 deny ip any any (126 matches)  

R4#sh ip inspect sessions
Established Sessions
 Session 64BEE6B4 (155.1.45.4:24211)=>(150.1.5.5:23) tcp SIS_OPEN
 Session 64BEE434 (10.0.0.6:39785)=>(150.1.5.5:23) tcp SIS_OPEN
 Session 64BEE934 (150.1.4.4:15035)=>(150.1.5.5:179) tcp SIS_OPEN

Doc CD Navigation

  • Cisco IOS Security Configuration Guide, Release 12.4
  • Traffic Filtering, Firewalls, and Virus Detection
  • Context-Based Access Control
  • Configuring Context-based Access Control
  • CBAC Configuration Examples
  • Ethernet Interface Configuration Example

Reflexive ACL

September 3, 2008 at 12:02 pm | Posted in Security | Leave a comment

Sample Configuration

R4#
ip access-list extended OUTBOUND
 permit tcp any any eq telnet reflect MIRROR
 permit tcp any any eq www reflect MIRROR
 permit icmp any any echo reflect MIRROR
 permit tcp any any eq bgp reflect MIRROR

ip access-list extended INBOUND
 ! OSPF traffic can not be reflected
 permit ospf any any
 evaluate MIRROR
 deny   ip any any log

interface Serial1/1
 ip access-group INBOUND in
 ip access-group OUTBOUND out

interface Serial1/0.1 point-to-point
 ip access-group INBOUND in
 ip access-group OUTBOUND out

By default, locally generated traffic such as ping to outside from within the local router, or BGP traffic will not be subject to the OUTBOUND access-list, and not be reflected. To include local traffic in reflexive ACL so that its return traffic is permitted, we need to route local traffic to a loopback interface. Following config acomplish that goal.

ip access-list extended LOCAL_TRAFFIC
 permit tcp any any
 permit icmp any any
route-map LOCAL_POLICY permit 10
 match ip address LOCAL_TRAFFIC
 set interface Loopback0

ip local policy route-map LOCAL_TRAFFIC

Setting a Global Timeout Value

Reflexive access list entries expire after no packets in the session have been detected for a certain length of time (the “timeout” period). You can specify the timeout for a particular reflexive access list when you define the reflexive access list. But if you do not specify the timeout for a given reflexive access list, the list will use the global timeout value instead.

The global timeout value is 300 seconds by default. But, you can change the global timeout to a different value at any time.

To change the global timeout value, use the following command in global configuration mode:

R4(config)#ip reflexive-list timeout ?   
  <1-2147483>  timeout in seconds

R4(config)#ip reflexive-list timeout 300

Verification

R1#ping 150.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/96/236 ms
R1#telnet 150.1.5.5
Trying 150.1.5.5 ... Open
R5#

R4#sh ip access-list MIRROR
Reflexive IP access list MIRROR
     permit tcp host 150.1.5.5 eq telnet host 150.1.4.4 eq 41848 (29 matches) (time left 286)
     permit icmp host 150.1.5.5 host 150.1.4.4  (19 matches) (time left 280)
     permit tcp host 150.1.5.5 eq bgp host 150.1.4.4 eq 17919 (575 matches) (time left 277)

Doc CD Navigation

  • Cisco IOS Security Configuration Guide, Release 12.4
  • Traffic Filtering, Firewalls, and Virus Detection
  • Configuring IP Session Filtering (Reflexive Access Lists)
  • Reflexive Access List Configuration Examples

TCP Intercept

August 8, 2008 at 5:35 pm | Posted in Blogroll, Security | Leave a 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.

Doc CD Navigation

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

and

  • Cisco IOS Security Command Reference
  • ip source-track through issuer-name

Configuration example:

access-list 199 permit tcp any 150.1.4.0 0.0.0.255 eq 80
ip tcp intercept list 199
ip tcp intercept mode watch
ip tcp intercept drop-mode random
ip tcp intercept watch-timeout 15
ip tcp intercept max-incomplete high 1500
ip tcp intercept max-incomplete low 1200

R1(config)#ip tcp intercept ?
connection-timeout  Specify timeout for connection info
drop-mode           Specify incomplete connection drop mode
finrst-timeout      Specify timeout for FIN/RST
list                Specify access-list to use
max-incomplete      Specify maximum number of incomplete connections before
clamping
mode                Specify intercepting mode
one-minute          Specify one-minute-sample watermarks for clamping
watch-timeout       Specify timeout for incomplete connections in watch mode

Debugging:

R1#debug ip tcp intercept
TCP intercept debugging is on

Next Page »

Blog at WordPress.com.
Entries and comments feeds.