AI, ML, Development + Cisco Learning Blog Learning about Machine Learning, Artificial Intelligence, related devlopment topics and formerly Routing and Switching, Datacenter, Security and other topics, CCIE #23664, Frank Wagner

2. Dezember 2008

Cisco Firewall evolution with access-lists, reflexive access-lists, ip tcp intercept and CBAC

Filed under: IP and IOS Features,Security — ocsic @ 17:25

What can i do with cbac and who to configure it? What is it thought of? What can also be done with reflexive access-lists? Might be ip tcp intercept also helpful?

Reflexive Access Lists are cisco introduction to statefull filtering. For Firewalling it is a nice feature and can be thought as a kind of ip nat with overload without beeing able to reach the inside, only if you have trigged a connection from the inside, then traffic is allowed to pass.

Speaking of a established session, means the device in between records the connection and dynamically adds an allow filter to let the traffic matching to this session passing back through the firewall. That is the meaning of a statefull filter. Cisco standard and extended access-lists can only filter statically. Here is where reflexive access-lists come into play.

This are two configuration examples regarding telnet access for telnet sessions:

1. The first example allows telnet for established sessions in a „extended“ access-listinterface

ip access-list extended ESTABLISHED
permit tcp any eq telnet any established


ip access-group ESTABLISHED in

Here only telnet traffic originated from the inside client is allowed to come back into the network.

As you already expect there is another way with reflexive access-lists:


ip access-group REFL_IN in
ip access-group REFL_OUT out

ip access-list extended REFL_IN
evaluate REFLECT
ip access-list extended REFL_OUT
permit tcp any any eq telnet reflect REFLECT timeout 30

FW#sh access-lists

Reflexive IP access list REFLECT
permit tcp host eq telnet host eq 28929 (12 matches) (time left 25)

Extended IP access list REFL_IN
10 evaluate REFLECT
Extended IP access list REFL_OUT
10 permit tcp any any eq telnet reflect REFLECT (7 matches)

Here the host is outside from firewalls perspective and is answering telnet requests from This reflexive access-list is dynamically generated. By default this list is active for 300 seconds. If the connection is idle for that amount of time, the access-list is removed from the list and memory, but does not terminate the session. The active session will again bring up a new reflexive access-list. So this timeout has nothing to do with an absolut or idle timeout in the normal way of understanding idle timeout. It is more a „clean up“ timeout.

Here is a possible use of „ip tcp intercept“. vs. reflexive access-lis

ip tcp intercept list REFL_OUT
ip tcp intercept connection-timeout 20

Here you can set an idle timeout for the tcp connection in your firewall. The idle timeout is now set to 20 seconds.

R2#sh tcp intercept connections
Client Server State Create Timeout Mode

Client Server State Create Timeout Mode ESTAB 00:00:59 00:00:01 I

After that time you can see your firewall sending an TCP Session Reset to both ends:

Packet debug on the firewall:

*Mar 1 10:37:00.665: IP: s= (local), d= (Vlan5), len 40, sending
*Mar 1 10:37:00.665: TCP src=23, dst=50346, seq=197049759, ack=1038522490, win=0 ACK RST
*Mar 1 10:37:00.665: IP: s= (local), d= (FastEthernet0/0), len 40, sending
*Mar 1 10:37:00.665: TCP src=50346, dst=23, seq=1038522490, ack=197049759, win=0 ACK RST
The connection is cleanly reset.

With ip tcp intercept you have more possible scenarios. For example if you are under a DOS Syn attack. Here i use nmap as a tool for generating multiple TCP SYN packets.


nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &
nmap -sS -P0 -p 23 &

If you start this several times you will see ip tcp intercept starting some actions against half open sessions. High watermark is the point for starting aggressive mode and low watermark has to be crossed for starting normal mode again.

*Mar 1 13:50:35.548: %TCP-6-INTERCEPT: getting aggressive, count (5/5) 1 min 9
*Mar 1 13:50:35.548: INTERCEPT: Possible attack! Aborting half-open connection SYNRCVD ( <->
*Mar 1 13:50:35.548: INTERCEPT(*): ( <- RST
*Mar 1 13:50:35.548: INTERCEPT: new connection ( SYN ->
*Mar 1 13:50:35.548: INTERCEPT(*): ( <- ACK+SYN
*Mar 1 13:50:35.584: INTERCEPT: Possible attack! Aborting half-open connection SYNRCVD ( <->

Now tcp intercept is starting to drop half open connections. Oldest first. You can also change the drop mode.

Next take a look at „ip inspect“ called CBAC (Context-Based Access Control).

interface FastEthernet0/0

ip access-group 101 in
ip inspect TELNET out

access-list 101 deny tcp any eq telnet any

ip inspect tcp idle-time 15
ip inspect name TELNET telnet

After opening a session, the telnet connection is able to establish and inspect has registred the session:

FW#sh ip inspect sessions
Established Sessions
Session 6571BC0C (>( telnet SIS_OPEN

You can enable an idle timeout for telnet session:

ip inspect name TELNET telnet timeout 10

or for all tcp sessions:

ip inspect tcp idle-time 10

ip inspect max-incomplete low 4
ip inspect max-incomplete high 5
ip inspect name TELNET telnet alert on audit-trail off timeout 10

If you test the TCP Syn flood here also, you will get ip inspect react on the SYN Attack:

*Mar 1 14:24:43.736: %FW-4-ALERT_ON: getting aggressive, count (6/5) current 1-min rate: 6
*Mar 1 14:24:44.012: %FW-4-ALERT_OFF: calming down, count (3/4) current 1-min rate: 16

Audit-trail will log all connections/attempts. Alert will send only those to the log, which have been found suspicious.

CBAC does support many different protocols. Also protocols which negotiate ports dynamically. And is therefore able to inspect at the application layer.


Keine Kommentare »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress