Network Traffic Control

--- title: Network Traffic Control tags: Cisco IOS, networking, manual, reference, router, switch, technical, security, firewall --- <header> <h6>Network Traffic Control</h6> > [toc] </header> --- # Network Access Management using AAA AAA network security services provide the primary framework to set up access control on a network device. Network and administrative AAA security in the Cisco environment has three functional components: **Authentication**, **Authorization**, and **Accounting** ## Authentication AAA Authentication can be used to authenticate users for administrative access or it can be used to authenticate users for remote network access. Authentication can be established using username and password combinations, challenge and response questions, token cards, and other methods. Cisco provides two common methods of implementing AAA services: ### Local Authentication Local AAA uses a device's local database for authentication. This database is the same one that is required for establishing role-based CLI. Local AAA is ideal for **small networks**, as the system administrator must populate the local security database with profiles for each user that might log in. This method is sometimes known as **self-contained authentication**. #### Configuring Local AAA Authentication: <ol class="step-list"> <li>Add usernames and passwords to the local router database for users that need administrative access to the router, using the <code><b>username</b> <i>name</i> <b>secret</b> <i>password</i></code> global configuration command.</li> <li>Enable AAA globally on the router <code><b>aaa new-model</b></code> command.</li> <li>Configure AAA parameters on the router via the <code><b>aaa authentication login</b> <i>list method(s)</i></code> command.</li> <li>Confirm and troubleshoot the AAA configuration.</li> </ol> :::danger When the **aaa new-model** command is first entered, an unseen “default” authentication, using the local database, is automatically applied to all lines except the console. For this reason, always configure a local database entry **before** enabling AAA. ::: ```pug R1(config)# username JR-ADMIN algorithm-type scrypt secret Str0ng5rPa55w0rd R1(config)# username ADMIN algorithm-type scrypt secret Str0ng5rPa55w0rd R1(config)# aaa new-model R1(config)# aaa authentication login default local R1(config)# ``` The final portion of the **`aaa authentication login`** command identifies the type of methods that will be queried to authenticate the users. Up to four methods can be defined, providing fallback methods should one method not be available. Cisco IOS software attempts authentication with a fallback method only when an error occurs trying the preceding method. If the authentication method denies the user access, the authentication process stops and no other authentication methods are allowed. The following table displays common AAA authentication methods that can be specified: | Method | Description | | ------ | ----------- | | <div class="mono">**enable**</div> | Uses the enable password for authentication. | | <div class="mono">**local**</div> | Uses the local username database for authentication. | | <div class="mono">**local-case**</div> | Uses case-sensitive local username authentication. | | <div class="mono">**none**</div> | Uses no authentication. | | <div class="mono">**group radius**</div> | Uses the list of all RADIUS servers for authentication. | | <div class="mono">**group tacacs+**</div> | Uses the list of all TACACS+ servers for authentication. | | <div class="mono">**group** *group-name*</div> | Uses a subset of RADIUS or TACACS+ servers for authentication as defined by the **`aaa group server radius`** or **`aaa group server tacacs+`** command. | :::warning For security purposes, use the none keyword only when testing the AAA configuration. ::: For flexibility, different method lists can be applied to different interfaces and lines using the <code><b>aaa authentication login</b> <i>list</i></code> command. ```pug R1(config)# aaa new-model R1(config)# aaa authentication login SSH-LOGIN local-case R1(config)# line vty 0 15 R1(config-line)# login authentication SSH-LOGIN R1(config-line)# transport input ssh R1(config-line)# ``` If a line has a custom authentication method list applied to it, that method list overrides the default method list for that interface. When a custom authentication method list is applied to an interface, it is possible to return to the default method list by using the no authentication login command. ### Server-Based Authentication When configuring authenticaion for multiple routers and switches, **server-based AAA** is more appropriate. With the server-based method, the router accesses a **central AAA server**—which contains the usernames and password for all users—rather than relying on a local database. For increased redundancy, multiple servers can be implemented. Client devices use either the **Remote Authentication Dial-In User Service (RADIUS)** or **Terminal Access Controller Acces s Control System (TACACS+)** protocols to communicate with the AAA server. It is important to understand the many differences between the TACACS+ and RADIUS protocols: | Implementation | TACACS+ | RADIUS | | ---------------------- | ------- | ------ | | **Functionality** | Separates AAA according to the AAA architecture, allowing modularity of the security server implementation. | Combines authentication and authorization but separates accounting, allowing less flexibility in implementation than TACACS+. | | **Standard** | Mostly Cisco supported | Open/RFC standard | | **Transport Protocol** | TCP (port 49) | UDP | | **CHAP** | Bidirectional challenge and response as used in *Challenge Handshake Authentication Protocol* (CHAP). | Unidirectional challenge and response from the RADIUS security server to the RADIUS client. | | **Confidentiality** | Entire packet encrypted | Password encrypted | | **Customization** | Provides authorization of router commands on a per-user or per-group basis | Has no option to authorize router commands on a per-user or per-group basis | | **Accounting** | Limited | Extensive (includes **802.1X** and **<abbr title="Session Initiation Protocol">SIP</abbr>**) | :::info TACACS+ provides separate AAA services. Separating the AAA services provides flexibility in implementation because it is possible to use TACACS+ for authorization and accounting while using another method of authentication. ::: #### Configuring Server-Based AAA Authentication: <ol class="step-list"> <li>Enable AAA globally on the router <code><b>aaa new-model</b></code> command.</li> <li>Configure the target server that will provide AAA services for the router via the <code><b>{tacacs|radius}</b> <b>server</b> <i>name</i></code> global configuration command and subsequent server-configuration-mode commands.</li> <li>Configure the encryption key needed to encrypt the data transfer between the network device and AAA server via the <code><b>key</b> <i>string</i></code> command.</li> <li>Configure the AAA authentication method list to refer to the TACACS+ or RADIUS server. For redundancy, it is possible to configure more than one server.</li> </ol> ```pug R1(config)# aaa new-model R1(config)# R1(config)# tacacs server Server-T R1(config-server-tacacs)# address ipv4 192.168.1.100 R1(config-server-tacacs)# single-connection R1(config-server-tacacs)# key TACACS-Pa55w0rd R1(config-server-tacacs)# exit R1(config)# R1(config)# radius server SERVER-R R1(config-radius-server)# address ipv4 192.168.1.101 auth-port 1812 acct-port 1813 R1(config-radius-server)# key RADIUS-Pa55w0rd R1(config-radius-server)# exit R1(config)# R1(config)# aaa authentication login default group tacacs+ group radius local-case R1(config)# end ``` :::success By default, TACACS+ establishes a new TCP session for every authorization request, which can lead to delays when users enter commands. To improve performance, AAA supports persistent TCP sessions that are configured with the **`single-connection`** tacacs server configuration command. ::: ### Additional Authentication Security Additional security can be implemented on the line using the <code><b>aaa local authentication attempts max-fail</b> <i>attempts</i></code> global configuration command. This command secures AAA user accounts by locking accounts that have been the subject of multiple failed attempts to log in. The locked out user account remains locked until it is manually cleared by an administrator, using the **`clear aaa local user lockout`** privileged EXEC mode command. To display a list of all locked-out users, use the **`show aaa local user lockout`** command. ```pug R1# show aaa local user lockout ! ! Local-user Lock time ! ADMIN 04:28:49 UTC Tue Feb 16 2021 ! R1# clear aaa local user lockout ADMIN R1# ``` ## Authorization After the user is authenticated, authorization services determine which resources the user can access and which operations the user is allowed to perform. This is done through a set of attributes that describes the user’s access to the network. Authorization attributes are compared to information contained within the **AAA database**, which then delivers restrictions for a given user to the local router where the user is connected. :::info Authorization is automatic and does not require users to perform additional steps after authentication. ::: #### AAA Authorization Configuration To configure authorization, use the <code><b>aaa authorization</b> <i>type list method(s)</i></code> command: ```pug R1(config)# aaa new-model R1(config)# aaa authentication login default group tacacs+ R1(config)# aaa authorization exec default group tacacs+ R1(config)# aaa authorization network default group tacacs+ ``` The authorization-type keywords specify the types of commands or services to protect: | Type | Usage | | ---- | ----- | | <div class="mono"><b>network</b></div> | For network services such as PPP and SLIP. | | <div class="mono"><b>exec</b></div> | For **User EXEC** terminal sessions. | | <div class="mono"><b>commands</b> <i>level</i></div> | Command authorization attempts authorization for all EXEC mode commands, including global configuration commands, associated with a specific privilege level. | ## Accounting and Auditing AAA Accounting collects and reports usage data. This data can be used for such purposes as auditing or billing. The collected data might include the start and stop connection times, the commands executed, the number of packets, and the number of bytes. Accounting is implemented using a **AAA server**. This service reports usage statistics back to the **ACS server**. These statistics can be extracted to create detailed reports about the configuration of the network. #### AAA Acounting Configuration To configure authorization, use the <code><b>aaa accounting</b> <i>type list</i> <b>\{start-stop | stop-only | none\}</b> <b>[broadcast]</b> <i>method(s)</i></code> command: ```pug R1(config)# aaa new-model R1(config)# aaa authentication login default group tacacs+ R1(config)# aaa authorization exec default group tacacs+ R1(config)# aaa accounting exec default start-stop group tacacs+ R1(config)# aaa authorization network default group tacacs+ R1(config)# aaa accounting network default start-stop group tacacs+ ``` The accounting-type keywords specify the types of commands or services to report: | Type | Usage | | ---- | ----- | | <div class="mono"><b>network</b></div> | Runs accounting for all network-related service requests, including PPP. | | <div class="mono"><b>exec</b></div> | Runs accounting for the EXEC shell session. | | <div class="mono"><b>connection</b> <i>level</i></div> | Runs accounting on all outbound connections such as SSH and Telnet. | The trigger-condition keyword is used to specify what actions cause accounting records to be updated: | Trigger | Meaning | | ---- | ----- | | <div class="mono"><b>start-stop</b></div> | Sends a "start" accounting notice at the beginning of a process and a "stop" accounting notice at the end of the process. | | <div class="mono"><b>stop-only</b></div> | Sends a "stop" accounting record for all cases including authentication failures. | | <div class="mono"><b>none</b> <i>level</i></div> | Disables accounting services on a line or interface. | #### Auditing Accounts via AAA Accounting provides additional security to the network, by keeping a detailed log of exactly what authenticated users do on managed devices. This information is useful when troubleshooting devices. It also provides leverage against individuals who perform malicious actions. To display the attributes that are collected for one AAA session, use the **`show aaa user`** privileged EXEC command. This command only provides information for those users who have been authenticated or authorized using AAA, or whose sessions are being accounted for by the AAA module. The **`show aaa sessions`** command can be used to show details about current and recent sessions. # Network Access Management using ACL An Access Control List (ACL) is a network management service that is used to filter packets based on information found in the packet header. By default, a router does not have any ACLs configured. However, when an ACL is applied to an interface, the router performs the additional task of evaluating all network packets as they pass through the interface to determine if the packet can be forwarded. An ACL uses a sequential list of permit or deny statements, known as Access Control Entries (ACEs), which are also sometimes referred to as "ACL Statements". Several tasks performed by routers require the use of ACLs to identify and manage network traffic: * Limiting network traffic to increase network performance. * Providing traffic flow control. * Providing basic security for network access. * Filtering traffic based on traffic type. * Screening hosts to permit or deny them access to network services. * Providing priority to certain classes of network traffic. An **Inbound ACL** filters packets before they are routed to the outbound interface. An inbound ACL is efficient because it saves the overhead of routing lookups if the packet is discarded. Inbound ACLs are most efficient when the permissions applied by the ACL are only relevant to **one inbound interface**. An **outbound ACL** filters packets after they are routed to the outbound interface, *no matter the inbound interface*. Outbound ACLs are most efficient when the same filter will be applied to packets coming from **multiple inbound interfaces** before exiting the same outbound interface. :::info Outbound ACLs do not act on packets that originate from the device performing the filtering. ::: The last statement of an ACL is always an implicit deny that **blocks all traffic**. By default, this statement is implicitly applied to the end of an ACL, but will not displayed in the configuration. :::warning An ACL must have at least one permit statement otherwise all traffic will be denied due to the implicit deny ACE statement. ::: **Cisco routers support two types of ACLs:** 1. **Standard ACLs** — ACLs only filter at OSI **Layer 3 (Network)** using the **source IPv4** address from the packet header. 1. **Extended ACLs** — ACLs filter at Layer 3 (Network) using the **source or destination IPv4 address**. Extended ACLs also filter at **Layer 4 (Transport)** based on **TCP and UDP ports**, and **optional protocol type** information for finer control. ## ACL Identifiers **Numbered ACLs** ACLs number 1-99 and 1300-1999 are **standard** ACLs while ACLs number 100-199 and 2000-2699 are **extended** ACLs: ```pug R1(config)# access-list ? ! <1-99> IP standard access list ! <100-199> IP extended access list ! <1100-1199> Extended 48-bit MAC address access list ! <1300-1999> IP standard access list (expanded range) ! <200-299> Protocol type-code access list ! <2000-2699> IP extended access list (expanded range) ! <700-799> 48-bit MAC address access list ! rate-limit Simple rate-limit specific access list ! template Enable IP template acls R1(config)# access-list ``` **Named ACLs** Named ACLs are preferred, to provide information about the purpose of the ACL. The guidelines for named ACLs can be summarized as: * Assign a name to identify the purpose of the ACL. * Names can contain alphanumeric characters. * Names cannot contain spaces or punctuation. * Names should be written in CAPITAL LETTERS. ## ACE Wildcard Masks A wildcard masks is a 32-bit address string that looks like a subnet mask. However, where the subnet mask uses a high-bit to indicate a position that must be matched and a low-bit to indicate a wild position, the wildcard mask works in reverse: * **Wildcard mask bit 0** - Match the corresponding bit value in the rule's address * **Wildcard mask bit 1** - Ignore the corresponding bit value in the rule's address In this way, ACE rules can be scaled to match an address range, or an entire subnet. For example: | Wildcard Mask | Meaning | | ------------- | ------- | | <b>0.0.0.0</b> | All octets of the packet address must exactly match the ACE's target address. | | <b>0.0.0.255</b> | The first three octets must exactly match, while the final octet may have any value. | | <b>0.0.0.252</b> | The first three octets must exactly match. The first six bits of the last octet may have any value. The final two bits must again match the target address! | The easiest way to match a range of addresses is to subtract the subnet mask of the range from the /32 mask (**255.255.255.255**).In other words, the entire range of addresses included in the subnet /28 mask (**255.255.255.240**) can be matched by subtracting /28 from /32: **0.0.0.15** **Wildcard Mask Keywords** Cisco IOS provides two keywords to identify the most common uses of wildcard masking: * **host** — This keyword substitutes for the **0.0.0.0** mask, and will require an exact match of the target address. * **any** — This keyword substitutes for the **255.255.255.255** mask, and will match any address. Wildcard keyword come *before* the target address. The following ACE statements would block the device at 192.168.10.10, while allowing all other traffic. ACLs of this type are referred to a "block-lists", because they only block traffic from specific addresses. ```pug R1(config)# access-list EXAMPLE deny host 192.168.10.10 R1(config)# access-list EXAMPLE permit any R1(config)# ``` ## Configuring ACLs ### Creating To create a new ACL, use the <code><b>ip access-list</b> \{<b>standard</b>|<b>extended</b>\} <i>identifier</i></code> global configuration command. This will enter ACL configuration mode. To configure an Access Control Entry (ACE), i.e. a `permit` or `deny` instruction, use the <code><b>access-list</b> <i>identifier</i> \{<b>permit</b>|<b>deny</b>\} <i>ip-address</i> [<i>mask</i>] [<b>log</b>]</code> configuration command. The <code><b>access-list</b> <i>identifier</i></code> prefix is not used when in ACL configuration mode. :::success To create a **numbered** ACL, skip the **`ip access-list`** command. A new, numbered ACL is automatically generated when an <code><b>access-list</b> <i>identifier</i></code> global configuration command indicates a numbered list that does not yet exist. ::: The options for this command are described below: | Paramter | Description | | -------- | ----------- | | <div class=mono><i>identifier</i></div> | The name or number of the ACL that the new rule should be associated with. | | <div class=mono><b>deny</b></div> | Deny access if the condition is matched. | | <div class=mono><b>permit</b></div> | Permits access if the condition is matched. | | <div class=mono><i>ip-address</i></div> | This identifies the source network or host address to filter. | | <div class=mono><i>mask</i></div> | (Optional) This is a 32-bit wildcard mask that is applied to the source (see [below](#ACE-Wildcard-Masks)). If omitted, a default 0.0.0.0 mask is assumed. | | <div class=mono><b>log</b></div> | (Optional) This keyword generates an informational message whenever the ACE is matched. ACL logging seriously affects the performance of the device, and should only be used when an administrator is trying to thwart a network attack. | Extended Syntax IPv4 ACL entries provide additional options for configuration: <code><b>access-list</b> <i>identifier</i> \{<b>permit</b>|<b>deny</b>\} <i>protocol source-address</i> [<i>source-mask</i>] [<i>operator port(s)</i>] <i>destination-address</i> [<i>destination-mask</i>] [<i>operator port(s)</i>] [<b>log</b>]</code> :::info Note that, for **Extended ACLs**, the target *`ip-address`* attribute is split into separate *`source`* and *`destination`* parameters. ::: Several additional options available to the Extended ACL entries are descibed below: | Paramter | Description | | -------- | ----------- | | <div class=mono><i>protocol</i></div> | Name or number of an internet protocol. Some common protocol keywords include **ip**, **tcp**, **udp**, and **icmp**. The **ip** keyword matches all IP protocols. | | <div class=mono><i>operator</i></div> | (Optional) This compares the source or destination port to the listed port(s). Operators include **lt** (less than), **gt** (greater than), **eq** (equal), **neq** (not equal), and **range** (inclusive range). | | <div class=mono><i>port(s)</i></div> | (Optional) Up to 10 numeric port numbers and/or common TCP/UDP port names (e.g. `ftp`, `irc`, and so on). | | <div class=mono><b>established</b></div> | (Optional, applies to TCP protocol only) This is a 1st-generation stateful firewall feature. When configured, this ACE statement will only match if the returning TCP segment has the **ACK** or **RST** (reset) flag bits set. | **Documentation** can be added to the ACL configuration via the <code><b>access-list</b> <i>identifier</i> <b>remark</b> <i>text</i> <i>ip-address</i></code> configuration command. Each **`remark`** entry is limited to 100 characters. ACE statements must indicate an IP address as a base for the rule to match. The ACE address must exactly match the source IP (for Standard ACLs) or destination IP (using Extended ACLs) of the incoming packet. However, ACE statements also employ a **wildcard mask** to indicate bits in the IP address that can be ignored. ```pug R1(config)# access-list 120 permit tcp any 192.168.10.0 0.0.0.255 established R1(config)# interface g0/0/0 R1(config-if)# ip access-group 120 out R1(config-if)# end R1# show access-lists Extended IP access list 110 10 permit tcp 192.168.10.0 0.0.0.255 any eq www 20 permit tcp 192.168.10.0 0.0.0.255 any eq 443 (657 matches) Extended IP access list 120 10 permit tcp any 192.168.10.0 0.0.0.255 established (1166 matches) R1# ``` ### Modifying ACL entries can be modified in one of two ways: 1. Replace the **entire ACL** — The entire ACL can be blown away using <code><b>no access-list</b> <i>identifier</i></code>, and then recreated using the corrected configuration. 2. Replace the **specific ACE** — The specific, offending ACE can be replaced from within the ACL Configuration mode (<code><b>ip access-list</b> <i>type identifier</i></code>) for the desired ACL. Once in ACL Configuration mode, use the <code><b>no</b> <i>sequence-number</i></code> command to remove a specific entry (use **`show access-lists`** to see each entry in an ACL). Write a new entry by prepending the same sequence-number to the correct ACE configuration command (e.g. `10 permit host 192.168.10.10`). ### Implementing To apply an ACL to an interface, use the <code>ip access-group <i>identifier</i> \{<b>in</b>|<b>out</b>\}</code> interface configuration command. To apply the ACL to the console line, use <code>ip access-class <i>identifier</i> \{<b>in</b>|<b>out</b>\}</code>. The final segment of the command indicates whether the ACL should be applied to **inbound** or **outbound** traffic on that interface. Additional useful notes: * Only one ACL is allowed per interface, per protocol, per direction. * Router-generated packets are not filtered by **outbound** ACLs. * Place **standard** ACLs as close to the destination as possible. * Place **extended** ACLs as close to the source as possible. ## IPv6 ACLs An IPv6 ACL contains an implicit **`deny ipv6 any any`** and two implicit **permit** rules to enable IPv6 neighbor discovery. If an administrator manually configures the **`deny ipv6 any any`** command without explicitly permitting neighbor discovery, then the IPv6 Neighbor Discovery Protocol (NDP) will be disabled. Create an IPv6 ACL using the following command syntax: ```pug Router(config)# ipv6 access-list <access-list-name> Router(config-ipv6-acl)# deny | permit <protocol> {<source-ipv6-prefix>/<prefix-length> | any | host <source-ipv6-address>} [<operator> [<port-number>]] {<destination-ipv6-prefix>/<prefix-length> | any | host <destination-ipv6-address>} [<operator> [<port-number>]] [dscp <value>] [fragments] [log] [log-input] [sequence <value>] [time-range <name>] ``` Apply an IPv6 ACL to an interface with the <code><b>ipv6 traffic-filter</b> <i>name</i></code> command. Several additional options available to IPv6 ACL entries, as descibed below: | Paramter | Description | | -------- | ----------- | | <div class=mono><b>dscp</b> <i>value</i></div> | (Optional) Matches against the Traffic Class value field of the IPv6 packet header. The acceptable range is 0-63. | | <div class=mono><b>fragments</b></div> | (Optional) Matches non-initial fragmented packets where the fragment extension header contains a non-zero fragment offset. | | <div class=mono><b>log input</b></div> | (Optional) Provides the same function as the **`log`** keyword, except that the logging message also includes the input interface. | | <div class=mono><b>sequence</b> <i>value</i></div> | (Optional) Specifies the sequence number value for the ACE. The acceptable range is 1-4294967295. This setting allows creation of the ACL in an arbitrary order. | | <div class=mono><b>time-range</b> <i>dname</i></div> | (Optional) Specifies the time range that applies to the permit statement. The name of the time range and its restrictions are specified by the **`time-range`** command | # Network Access Management using 802.1X ## Authentication Protocol The IEEE 802.1X standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. **The 802.1x roles include:** * **Supplicant (Client)** - A device that requests access to LAN and switch services. The port that the client is attached to is the actual **supplicant** in the IEEE 802.1X specification. * **Authenticator (Switch)** - The switch is the device that controls physical access to the network based on the authentication status of the client. It acts as a **proxy** (middleman) between the **supplicant** and the **authentication server**, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. * **Authentication server** - The server performs the actual **authentication** of the client. The authentication server **validates the identity** of the client and **notifies the switch** whether the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. :::info The switch uses a RADIUS software agent, which is responsible for encapsulating and de-encapsulating the EAP (Extensible Authentication Protocol) frames and interacting with the authentication server. The RADIUS security system with EAP extensions is the only supported authentication server. ::: ## Port Authorization States The switch port **state** determines whether the client is granted access to the network: * When configured for 802.1X port-based authentication, the port **starts** in the **unauthorized** state. While in this state, the port disallows all ingress and egress traffic except for **802.1X protocol**, **STP**, and **CDP** packets. * When a client is successfully authenticated, the port **transitions** to the **authorized** state, allowing **all traffic** for the client to flow normally. * If the switch requests the client identity (**authenticator initiation**) and the client does not support 802.1X, the port remains in the unauthorized state, and the client is not granted access to the network. * When a client logs out, it sends an **EAPOL-logout** message, causing the switch port to transition to the **unauthorized** state. :::info When an 802.1X-enabled **client** connects to a port and the client initiates the authentication process (**supplicant initiation**) by sending the **EAPOL-start frame** to a switch that is not running the 802.1X protocol, the client will continue sending frames as if the port were in the **authorized** state. ::: to enable 802.1X on the port, use the <code><b>authentication port-control auto</b></code> interface configuration command. It may sometimes be necessary to configure a switch port to override the 802.1X authentication process. To do this, use the <code><b>authentication port-control</b> \{<b>force-authorized</b>|<b>force-unauthorized</b>\}</code> interface configuration command. ## Service Configuration **Configuring 802.1X requires a few basic steps:** <ol class='step-list'> <li>Enable AAA using the <code><b>aaa new-model</b></code> command.</li> <li>Designate the RADIUS server using <code><b>radius server</b> <i>name</i></code> global configuration command. This will enter the radius-server subconfiguration mode.</li> <li>Set the address and ports that are configured on the RADIUS server, using the <code><b>address</b> {<b>ipv4</b>|<b>ipv6</b>} <i>ip-address</i> <b>auth-port</b> <i>port</i> <b>acct-port</b> <i>port</i></code> radius-server sub-configuration command.</li> <li>Create an 802.1X port-based authentication method list using the <code><b>aaa authentication dot1x</b> <i>list</i> <b>group</b> <i>protocol</i></code> global configuration command.</li> <li>Globally enable 802.1X port-based authentication using the <code><b>dot1x system-auth-control</b></code> global configuration command.</li> <li>Enable port-based authentication on the interface using the <code><b>authentication port-control auto</b></code> interface configuration command.</li> <li>Enable 802.1X authentication on the interface using the <code><b>dot1x pae authenticator</b></code> interface command. <br><br> :::info The <code><b>authenticator</b></code> option sets the <b>Port Access Entity (PAE)</b> type so the interface acts only as an authenticator and will not respond to any messages meant for a supplicant. ::: </li> </ol> **Example:** ```pug S1(config)# aaa new-model S1(config)# radius server NETSEC S1(config-radius-server)# address ipv4 10.1.1.50 auth-port 1812 acct-port 1813 S1(config-radius-server)# key RADIUS-Pa55w0rd S1(config-radius-server)# exit S1(config)# S1(config)# aaa authentication dot1x default group radius S1(config)# dot1x system-auth-control S1(config)# S1(config)# interface F0/1 S1(config-if)# description Access Port S1(config-if)# switchport mode access S1(config-if)# authentication port-control auto S1(config-if)# dot1x pae authenticator ``` # Firewalls There are two configuration models for Cisco IOS Firewall: * **Classic Firewall** — The traditional configuration model in which firewall policy is applied on interfaces. * **Zone-based Policy Firewall (ZPF)** — The configuration model in which interfaces are assigned to security zones, and firewall policy is applied to traffic moving between the zones. :::warning Both configuration models can be enabled concurrently on a router, but not on a single interface. ::: Policies identify actions that the ZPF will perform on network traffic. There are three possible actions that can be configured: * **Inspect** — This performs Cisco IOS stateful packet inspection. * **Drop** — This is analogous to a deny statement in an ACL. A log option is available to log the rejected packets. * **Pass** — This is analogous to a permit statement in an ACL. The pass action does not track the state of connection ## Basic Security Zone Topology The basic zone rules depend on the zones of the ingress and egress interfaces used by the inspected traffic: * **neither interface is in a zone** — **pass** the traffic. * **both are in the same zone** – **pass** the traffic. * **both are in unpaired zones** — **drop** the traffic. * **both are in paired zones** — inspect, allow, or drop as **defined by the policy** (if a policy exists). ## Zone-Based Firewall Configuration Zone-Based Policy Firewall (ZPF) configuration has five steps: <ol class="step-list"> <li>Create the zones.</li> <li>Define class-maps used to identify traffic.</li> <li>Define policy actions via policy-maps.</li> <li>Associate zone pairs and apply policy-maps.</li> <li>Assign interfaces to their appropriate zones.</li> </ol> ### Zone Creation Create zones using the <code><b>zone security</b> <i>name</i></code> global configuration command. ### Traffic Class Definition Traffic classes are used to identify packets based on their contents. Once assigned to a traffic class, packets can be managed by firewall policies. Configure traffic classes via the <code><b>class-map type inspect</b> \{<b>match-any</b>|<b>match-all</b>\} <i>name</i></code> global configuration command. There are two packet-match modes used to determine class-eligibility: * **`match-any`** — Packets must meet at least one match criterion. * **`match-all`** — Packets must meet all match criteria. The **`class-map`** command enters the **class-map sub-configuration** mode. There are three ways to filter for class-map matching: * <code><b>match access-group</b> <i>acl-identifier</i></code> — matches packets that pass the indicated ACL policy. * <code><b>match protocol</b> <i>protocol-identifier</i></code> — matches packets that use the indicated protocol. * <code><b>match class-map</b> <i>class-map-name</i></code> — matches packets that are eligible for the indicated class. Example: ```pug R1(config)# class-map type inspect match-any HTTP-TRAFFIC R1(config-cmap)# match protocol http R1(config-cmap)# match protocol https R1(config-cmap)# match protocol dns ``` ### Policy Action Configuration Zone-based firewalls filter traffic based on the traffic classes assigned to the traffic. This is done through the use of **policy maps**, which define what action to take when inspected traffic belongs to a configured class-map. There are three steps to configure a policy map: <ol class="step-list"> <li>Define a policy-map via the <code><b>policy-map type inspect</b> <i>name</i></code> global configuration command. This will enter the <b>policy-map</b> sub-configuration mode.</li> <li>Assign traffic classes to be governed by the policy using <code><b>class type inspect</b> <i>name</i></code>. This will enter the <b>policy-map class-action</b> sub-configuration mode.</li> <li>Declare an action to take for traffic of the current class via the <code>{<b>inspect</b>|<b>drop</b>|<b>pass</b>}</code> command. If the <code><b>inspect</b> action is chosen, then the router will maintain session information for TCP and UDP packets, in order to permit return traffic. </code></li> </ol> :::success Similar to the implicit **deny any** at the end of every ACL, there is an explicit **drop** applied by the IOS to the end of every policy−map. It is listed as **class class-default** in the last section of any policy-map configuration. ::: Example: ```pug R1(config)# policy-map type inspect PRIV-TO-PUB-POLICY R1(config-pmap)# class type inspect HTTP-TRAFFIC R1(config-pmap-c)# inspect ``` ### Zone Pairing To identify a zone-pair, use the <code><b>zone-pair security</b> <i>zone-pair-name</i> <b>source</b> \{<i>source-zone-name</i>|<b>self</b>\} <b>destination</b> \{<i>destination-zone-name</i>|<b>self</b>\}</code> global configuration command. This will enter the zone-pair configuration mode. Apply a policy to the zone-pair traffic flow via the <code><b>service-policy type inspect</b> <i>policy-map--name</i></code> command. #### Traffic to the Self Zone The self zone is the router itself and includes all of the IP addresses assigned to the router interfaces. This zone is used for traffic that originates at the router or is addressed to a router interface, and should exclusively consist of device management traffic, such as SSH connections or traffic forwarding control packets. ### Interface Assignment Assigning an interface to a zone will immediately apply the service-policy that has been associated with that zone. If no service-policy has been configured for the zone, all transit traffic will be dropped. To assign an interface to a zone, use the <code><b>zone-member security</b> <i>zone-name</i></code> interface configuration command. :::danger Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment. Applying the zone-member configuration command always results in a temporary interruption of service until the other zone-member is configured. ::: ### Verify Configuration ```pug R1# show class-map type inspect ! Class Map type inspect match-any HTTP-TRAFFIC (id 1) ! Match protocol http ! Match protocol https ! Match protocol dns ! R1# show zone security ! zone self ! Description: System Defined Zone ! ! zone PRIVATE ! Member Interfaces: ! GigabitEthernet0/0 ! ! zone PUBLIC ! Member Interfaces: ! Serial0/0/0 ! R1# show zone-pair security ! Zone-pair name PRIV-PUB ! Source-Zone PRIVATE Destination-Zone PUBLIC ! service-policy PRIV-TO-PUB-POLICY ! R1# show policy-map type inspect ! Policy Map type inspect PRIV-TO-PUB-POLICY ! Class HTTP-TRAFFIC ! Inspect ! Class class-default ! Drop ! R1# show policy-map type inspect zone-pair sessions ! ! policy exists on zp PRIV-PUB ! Zone-pair: PRIV-PUB ! ! Service-policy inspect : PRIV-TO-PUB-POLICY ! ! <...output truncated...> ! R1# ``` --- --- {%hackmd 7PGmjAHeTXak2VUM3iw5Wg %}

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.