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
FastEthernet0/0
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:
FastEthernet0/0
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 144.1.18.10 eq telnet host 144.1.5.5 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 144.1.18.10 is outside from firewalls perspective and is answering telnet requests from 144.1.5.5. 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
Incomplete:
Client Server State Create Timeout Mode
Established:
Client Server State Create Timeout Mode
144.1.5.5:50346 144.1.18.10:23 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=144.1.18.10 (local), d=144.1.5.5 (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=144.1.5.5 (local), d=144.1.18.10 (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.
cat syn-dos-test.sh
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
nmap -sS -P0 -p 23 144.1.18.10 &
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 (10.0.0.1:58971 <-> 144.1.18.10:23)
*Mar 1 13:50:35.548: INTERCEPT(*): (10.0.0.1:58971 <- RST 144.1.18.10:23)
*Mar 1 13:50:35.548: INTERCEPT: new connection (10.0.0.1:57671 SYN -> 144.1.18.10:23)
*Mar 1 13:50:35.548: INTERCEPT(*): (10.0.0.1:57671 <- ACK+SYN 144.1.18.10:23)
*Mar 1 13:50:35.584: INTERCEPT: Possible attack! Aborting half-open connection SYNRCVD (10.0.0.1:39401 <-> 144.1.18.10:23)
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 (144.1.5.5:12150)=>(144.1.18.10:23) telnet SIS_OPEN
Rack1SW2#
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.
Source:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_tcp_intercpt_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1001032
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_content_ac_ps6350_TSD_Products_Configuration_Guide_Chapter.html
Windows 2000 Server (English version only)
