Dynamic access lists or Lock-and-Key Security is a type of ACL traffic filtering security feature that dynamically filters IP protocol traffic. Users that would like to traverse through the router are normally blocked by the extended ACL until they authenticates themselves to the router through a Telnet session with a username and password. After the user is authenticated, the Telnet connection is dropped, and a dynamic ACL entry is appended to the existing extended ACL to temporary allow the user to access resources that are blocked behind the router for certain duration until the specified timeout expires.
Below shows a sample Dynamic Access Lists configuration on RT1:
Router(config)#username remote password cisco123 Router(config)#username remote autocommand access-enable host timeout 10 Router(config)#access-list 101 permit tcp any host 172.16.0.1 eq telnet log Router(config)#access-list 101 dynamic remote-access01 timeout 15 permit ip 172.16.0.0 0.0.0.255 10.10.10.0 0.0.0.255 log Router(config)#int fa0/0 Router(config-if)#ip access-group 101 in Router(config-if)#exit Router(config)#line vty 0 4 Router(config-line)#login localNote: Configuring the autocommand access-enable host timeout 10 line command under line vty 0 4 which is normally found in other configuration examples is not as flexible as configuring the autocommand for particular users with the username privileged commands.
Below describes the configuration steps for the sample dynamic access list configuration:
1) Create a user authentication method on the router. This can either be local authentication or remote security database using RADIUS or TACACS+ server. This sample configuration defines a user named remote with a password of cisco123 and a line of command (access-enable host timeout 10 in this case) which will be issued automatically (due to the autocommand keyword) after the user is authenticated via the Telnet session to the router.
Note: The access-enable EXEC command creates a temporary access-list entry.
2) Define an extended ACL to allow only Telnet access to the router (for authentication), but block all other traffic.
3) Create a dynamic extended ACL that applies to the extended access list 101 after the user is authenticated via the Telnet session to the router.
4) Since this sample configuration is using local authentication, the router needs to be configured to locally authenticate when a user connects to its VTY ports.
Reflexive access lists are dynamic access lists that allow traffic based on the detection of traffic in the opposite direction as well as upper-layer session information. They often permit outbound traffic which originated from an inside network but deny inbound traffic which originated from an outside network.
Reflexive ACLs cannot be defined with standard or numbered ACLs; they can only be defined with extended named ACLs and can be used along with other standard or extended ACLs. They are temporary entries that are created when a new IP session begins and are removed when the session ends (when the last segment with FIN or RST is seen or the idle timeout expires). Reflexive ACLs are not applied directly to an interface, but are “nested” within an extended named IP ACL that is applied to an interface.
Below shows a sample Reflexive Access Lists configuration on RT1 as well as the output of the show access-list EXEC command on RT1:
! ip access-list extended Telnet-In evaluate RACL-1 deny ip any any ip access-list extended Telnet-Out permit tcp host 172.16.0.2 host 10.10.10.2 eq telnet reflect RACL-1 deny ip any any ! interface FastEthernet1/0 ip address 10.10.10.1 255.255.255.0 ip access-group Telnet-In in ip access-group Telnet-Out out ! ---------------------------------------------------------------------------- RT1#sh access-list Reflexive IP access list RACL-1 Extended IP access list Telnet-In 10 evaluate RACL-1 20 deny ip any any Extended IP access list Telnet-Out 10 permit tcp host 172.16.0.2 host 10.10.10.2 eq telnet reflect RACL-1 20 deny ip any any RT1#
Time-based access lists provide time-oriented access control. A certain time of day and week is specified and the period is often identified with a time range reference name. The time range name will be used as a reference in extended ACL configuration.
Below shows a sample Time-based Access Lists configuration that defines no Internet access during office hours – Monday to Friday, 9am to 6pm.
Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#time-range no-http Router(config-time-range)#? Time range configuration commands: absolute absolute time and date default Set a command to its defaults exit Exit from time-range configuration mode no Negate a command or set its defaults periodic periodic time and date Router(config-time-range)#periodic ? Friday Friday Monday Monday Saturday Saturday Sunday Sunday Thursday Thursday Tuesday Tuesday Wednesday Wednesday daily Every day of the week weekdays Monday thru Friday weekend Saturday and Sunday Router(config-time-range)#periodic weekdays 09:00 to 18:00 Router(config-time-range)#exit Router(config)#ip access-list extended Time_no-http Router(config-ext-nacl)#deny tcp any any eq www time-range no-http Router(config-ext-nacl)#permit tcp any any Router(config-ext-nacl)#exit Router(config)#int fa0/0 Router(config-if)#ip access-group Time_no-http in Router(config-if)#^Z Router# Router#sh clock 10:00:01.835 UTC Sun Jan 6 2008 Router#sh time-range time-range entry: no-http (inactive) periodic weekdays 9:00 to 18:00 used in: IP ACL entry Router#sh access-list Extended IP access list Time_no-http deny tcp any any eq www time-range no-http (inactive) permit tcp any any Router# ---------------------------------------------------------------------------- Router#sh clock 10:00:01.139 UTC Mon Jan 7 2008 Router#sh time-range time-range entry: no-http (active) periodic weekdays 9:00 to 18:00 used in: IP ACL entry Router#sh access-list Extended IP access list Time_no-http deny tcp any any eq www time-range no-http (active) permit tcp any any Router#
Context-Based Access Control (CBAC) is a Cisco IOS Firewall feature which provides advanced traffic filtering functionality and secure access control on a per-application basis. CBAC is often referred to as Stateful IOS Firewall Inspection.
CBAC provides multiple levels of network protection with the following functions:
| Traffic Filtering | Intelligently filters TCP and UDP segments based on application layer protocol information (eg: FTP connection information). Without CBAC, traffic filtering is limited to access list implementations which only able to examine the information at the network and transport layers. Due to the capability of learning the state information of the sessions and control them, CBAC supports filtering for application layer protocols that involve multiple channels created as a result of negotiations in the control channel. Many multimedia protocols and other protocols (eg: FTP, RPC, SQL*Net) involve multiple channels in their communications. CBAC can be configured to inspect application layer traffic for sessions and connections that are originated from either side of a firewall and permit the specified traffic through it; hence it can be used for intranet, extranet, and Internet perimeters of a network. |
| Traffic Inspection | Inspects traffic that passes through a firewall to discover and manage state information for TCP and UDP sessions. The state information is used to create temporary openings in the access lists to allow return traffic for permissible sessions. With the capabilities of inspecting and maintaining TCP and UDP session information, CBAC is able to detect and prevent certain types of network attacks, eg: SYN Flooding. CBAC helps to protect against DoS attacks with the following approaches: i) Inspects TCP sequence numbers in to see if they are within expected ranges and drops the suspicious packets. ii) Drops half-open connections, which require firewall processing and memory resources to maintain. iii) Detects unusually high rates of new connections and issue alert messages. Besides that, CBAC can also help to protect against certain DoS attacks which involve fragmented IP packets. Even though the firewall prevents an attacker from establishing actual connections to an end system, the attacker can disrupt services on the end system by sending many non-initial IP fragments, which can eventually tie up resources on the target end system as it tries to reassemble the incomplete packets. |
| Alerts and Audit Trails | Generates real-time alerts and audit trails for tracking suspicious activities and network transactions (eg: time stamps, source and destination hosts, ports, total number of transmitted bytes, etc). With CBAC inspection rules, alerts and audit trail information can be configured on a per-application protocol basis. |
| Intrusion Prevention | Provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, SYSLOG messages are reviewed and monitored for specific attack signatures. When CBAC detects an attack, it resets the offending connections and generates a SYSLOG message to a SYSLOG server. |
CBAC only effective for the specified protocols. If a particular is not specified for CBAC, the existing access lists will determine how the traffic for the particular protocol is being processed. No temporary openings will be created for protocols that are not specified for CBAC inspection.
CBAC can only provide protection against certain types of attacks, but not all types of attacks. CBAC should not be considered as a perfect defense; there is no such thing as a perfect defense. CBAC detects and prevents most types of popular network attacks.
Authentication Proxy requires the Cisco IOS Firewall feature set as well. It is able to authenticate inbound and/or outbound users and grant the access to the resources that are blocked behind a firewall. By launching a browser to access resources behind the firewall, the firewall would respond to the HTTP session and redirect the user to an authentication page which a valid username and password must be supplied for authentication purpose. An authentication entry will be created for the user. There is no intervention by the authentication proxy for subsequent HTTP sessions through the firewall as long as a valid authentication entry exists for the user.
No comments:
Post a Comment