Infrastructure Security practice questions

Configure an ACL to permit TCP port 22 inbound on the VTY lines using the access-class command.

Why it fails: While an ACL can restrict SSH access, it is not required to enable SSH. The inability to establish an SSH session is due to missing RSA keys, not an ACL. If an ACL were blocking, the session would be denied, but the symptom would be different (e.g., connection refused or timeout). The primary issue is the lack of SSH server configuration.

Set the login method to use the local database with the 'login local' command under the VTY lines.

Why it fails: The 'login local' command is necessary for authentication using local usernames, but it does not enable SSH itself. Without RSA keys, SSH will not work regardless of the login method. The engineer must first generate RSA keys to enable the SSH server, then configure authentication.

Enable the SSH server using the 'ip ssh server' command in global configuration mode.

Why it fails: The 'ip ssh server' command is not required on Cisco IOS because the SSH server is enabled by default when RSA keys are present. The transport input ssh command already restricts VTY lines to SSH. The missing piece is the RSA key generation, not enabling the SSH server.

aaa authentication login default group tacacs+ none

Why it fails: The 'none' method disables authentication entirely, allowing access without any credentials. This is a severe security risk and does not provide fallback to local usernames. It also fails to log authentication attempts to TACACS+ because no authentication method is used when the server is unreachable.

aaa authentication login default group tacacs+ enable

Why it fails: Using 'enable' as the fallback method means that if the TACACS+ server is unavailable, the router will prompt for the enable password, not the local username database. This does not meet the requirement to fall back to local usernames, and it could allow users who only know the enable password to access the device.

aaa authentication login default local group tacacs+

Why it fails: This command reverses the order, attempting local authentication first and then TACACS+ only if local fails. Since local authentication would succeed for any valid local user, the TACACS+ server would never be queried for normal logins, defeating the purpose of centralized authentication and logging.

crypto isakmp policy with authentication pre-share, crypto ipsec transform-set with esp-aes esp-sha-hmac, and crypto map with set pfs group5

Why it fails: This uses IKEv1 (isakmp) instead of IKEv2, which does not meet the requirement for IKEv2. Although PFS is configured with group5, the IKEv1 pre-shared key exchange is less secure and does not align with the IKEv2 requirement. The transform-set is for IPsec, but the overall configuration is not IKEv2.

crypto ikev2 keyring with pre-shared-key, crypto ikev2 profile with authentication local pre-share, and crypto ipsec profile with set security-association lifetime seconds 3600

Why it fails: This includes IKEv2 pre-shared key authentication, but the IPsec profile lacks PFS configuration. Without set pfs, the IPsec SA does not use perfect forward secrecy, so the requirement for PFS is not met. The lifetime setting is unrelated to PFS.

crypto ikev2 proposal with encryption aes-cbc-256, crypto ikev2 policy, and crypto ipsec profile with set security-association lifetime seconds 3600

Why it fails: This configures IKEv2 proposal and policy but does not include any authentication method or PFS settings. Without a pre-shared key or certificate, authentication fails. The IPsec profile sets a lifetime but no PFS, so perfect forward secrecy is not enabled. Thus, it does not meet the requirements.

VRF-aware uRPF

Why it fails: VRF-aware uRPF is a feature that allows uRPF checks to be performed within a specific VRF, but it does not inherently solve asymmetric routing issues. It is used in MPLS or VRF-lite environments to apply uRPF per VRF. In this scenario, the problem is asymmetric routing, not VRF separation.

Unicast RPF with allow-default

Why it fails: The allow-default option permits uRPF to pass packets if the default route is used, but it does not address asymmetric routing specifically. It can be used with loose or strict mode to allow default routes, but it is not a distinct mode. The requirement is to handle asymmetric routing, which is better addressed by loose or feasible path modes.

Strict mode

Why it fails: Strict mode requires that the source IP address be reachable via the same interface on which the packet was received. In an asymmetric routing scenario, return traffic may use a different path, causing strict mode to drop legitimate packets. Therefore, strict mode is not suitable when asymmetric routing is present.

Authentication critical

Why it fails: Authentication critical is used to grant access to a critical VLAN when the RADIUS server is unreachable. However, the critical VLAN typically provides full network access, not restricted access for remediation. The scenario specifically asks for a restricted VLAN with limited access to remediation resources, so critical authentication does not match the requirement.

Authentication host-mode multi-auth

Why it fails: Multi-auth host mode allows multiple devices to authenticate independently on a single port. It does not control fallback behavior when the RADIUS server is unavailable. The scenario requires a specific fallback VLAN for remediation, which is not provided by multi-auth. Therefore, this option is incorrect for the stated requirement.

Authentication open

Why it fails: Authentication open allows all traffic to pass through the port before authentication, which is not the desired behavior. It does not provide restricted access upon RADIUS server failure; instead, it permits full access without authentication. This would not meet the requirement of placing the port in a restricted VLAN for remediation when the server is unavailable.

class-map match-all ICMP match access-group 101 ! policy-map COPP class ICMP police 50000 100000 conform-action transmit exceed-action drop ! control-plane host service-policy input COPP access-list 101 permit icmp any any echo

Why it fails: The 'control-plane host' configuration mode is used to apply policies to specific host protocols, but the service-policy command under 'control-plane host' is not valid for applying a policy map. The correct mode is simply 'control-plane' (global) to apply a service policy to all control plane traffic. Using 'control-plane host' would result in a syntax error or ineffective configuration.

class-map match-all ICMP match access-group 101 ! policy-map COPP class ICMP police 50 100 conform-action transmit exceed-action drop ! control-plane service-policy input COPP access-list 101 permit icmp any any echo

Why it fails: The police command values are in bits per second, not packets per second. Specifying 'police 50 100' would limit to 50 bps with a burst of 100 bits, which is extremely low and would drop virtually all ICMP traffic. The administrator intended 50 packets per second, which requires converting to bits per second based on packet size, typically using 50000 and 100000 for 1000-bit packets.

class-map match-all ICMP match access-group 101 ! policy-map COPP class ICMP police 50000 100000 conform-action transmit exceed-action drop ! interface GigabitEthernet0/0 service-policy input COPP access-list 101 permit icmp any any echo

Why it fails: This applies the service policy to a physical interface, not the control plane. CoPP requires the service policy to be attached to the control-plane global configuration, not to an interface. Applying it to an interface would police all traffic entering that interface, not specifically traffic destined to the route processor, and would not achieve the goal of protecting the control plane.

transform set

Why it fails: A transform set defines the encryption and authentication algorithms used to protect the data, such as ESP with AES and SHA. It does not specify which traffic is encrypted. The transform set is applied within the crypto map, but it operates on the traffic selected by the access list, so it is not the element that defines the traffic itself.

crypto map

Why it fails: A crypto map ties together the various IPsec configuration elements, such as the peer, the transform set, and the access list that defines interesting traffic. However, the crypto map itself does not define the traffic to be encrypted; it references an access list that does. Therefore, this option is not the direct answer to what defines the traffic.

crypto ACL

Why it fails: While the term 'crypto ACL' is sometimes used informally to refer to the access list that defines interesting traffic, it is not a distinct configuration element. The actual configuration uses a standard or extended access list, not a special 'crypto ACL'. Therefore, this option is misleading and not the precise answer.

ip ssh version 2 crypto key generate rsa modulus 1024

Why it fails: This command generates an RSA key with a modulus of 1024 bits, which does not meet the requirement of at least 2048 bits. While 'ip ssh version 2' correctly forces SSH version 2, the key size is insufficient for the stated security requirement. A larger modulus is needed for stronger encryption.

ip ssh version 1 crypto key generate rsa modulus 2048

Why it fails: This command sets SSH to version 1, which is less secure and does not meet the requirement to use only SSH version 2. Although the key modulus is correct at 2048 bits, the SSH version is wrong. SSH version 1 has known vulnerabilities and should be avoided.

ip ssh version 2 crypto key generate rsa general-keys modulus 4096

Why it fails: This command generates a 4096-bit RSA key, which exceeds the minimum requirement of 2048 bits and is acceptable, but the question asks for at least 2048 bits, so this is not the best answer because it goes beyond the requirement unnecessarily. However, technically it satisfies the requirement. But since the question likely expects the exact minimum, the 2048-bit option is preferred. In an exam, choose the simplest correct answer that meets the requirement.

Apply the policy-map to the control plane interface using the service-policy command.

Why it fails: While applying a policy-map to the control plane is necessary for CoPP, the service-policy command is applied under the control-plane configuration mode, not directly to an interface. The control plane is a virtual interface, and the command is 'service-policy input <policy-map-name>' under 'control-plane' configuration.

Enable NetFlow to monitor ICMP traffic and automatically rate-limit it.

Why it fails: NetFlow is a monitoring technology that collects IP traffic information. It does not automatically rate-limit traffic. CoPP requires explicit configuration of class-maps and policy-maps. NetFlow could be used to analyze traffic patterns, but it is not part of the CoPP configuration process.

Configure a route-map to match ICMP echo requests and set the next-hop to null0.

Why it fails: A route-map is used for routing policy, not for CoPP. CoPP uses class-maps and policy-maps to classify and police traffic. Setting next-hop to null0 would drop traffic but not rate-limit it, and it would affect forwarding, not control plane policing.

Create a class-map matching HTTP, a policy-map with inspect action for that class, and a class-default with inspect action; apply the policy-map as a service-policy type inspect between INSIDE and OUTSIDE.

Why it fails: The class-default with inspect action would allow all other traffic, not block it. This violates the requirement to block all other traffic from INSIDE to OUTSIDE. The class-default should have a drop action to block unmatched traffic.

Create a class-map matching HTTP, a policy-map with inspect action for that class, and a class-default with drop action; apply the policy-map as a service-policy type inspect between OUTSIDE and INSIDE.

Why it fails: Applying the policy-map between OUTSIDE and INSIDE would control traffic from OUTSIDE to INSIDE, not from INSIDE to OUTSIDE. The requirement is to allow HTTP from INSIDE to OUTSIDE, so the policy must be applied in the correct direction. This application would not achieve the desired effect.

Create a class-map matching HTTP, a policy-map with pass action for that class, and a class-default with drop action; apply the policy-map as a service-policy type inspect between INSIDE and OUTSIDE.

Why it fails: The pass action only allows the traffic without maintaining state, so return traffic would be blocked by the class-default drop. To allow return traffic, the inspect action is required. Therefore, this configuration does not meet the requirement.

aaa new-model aaa authentication login default group radius local radius server RAD1 address ipv4 10.1.1.100 auth-port 1812 acct-port 1813 key Cisco123 username admin privilege 15 password AdminPass line vty 0 4 login authentication default

Why it fails: The username command uses 'password' instead of 'secret', storing the password in clear text in the configuration. This is a security risk. The rest of the configuration is correct, but the requirement implies secure local authentication; using 'secret' is preferred.

aaa new-model aaa authentication login default group radius radius server RAD1 address ipv4 10.1.1.100 auth-port 1645 acct-port 1646 key Cisco123 username admin privilege 15 secret AdminPass line vty 0 4 login authentication default

Why it fails: This configuration lacks the 'local' fallback method in the AAA authentication list, so if RADIUS is unreachable, authentication fails. Additionally, it uses legacy RADIUS ports 1645/1646 instead of the standard 1812/1813, which may cause connectivity issues if the server expects standard ports.

aaa new-model aaa authentication login default group radius local radius server RAD1 address ipv4 10.1.1.100 auth-port 1812 acct-port 1813 key Cisco123 username admin privilege 15 secret AdminPass line console 0 login authentication default

Why it fails: This configuration applies the AAA method list to the console line instead of the VTY lines. The scenario specifies login users, typically remote via Telnet/SSH, so VTY lines should be configured. Console authentication is not required and may lock out console access if misconfigured.

access-list 100 deny ip any any access-list 100 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

Why it fails: Placing a deny ip any any before the permit statement would block all traffic, including the desired traffic, because the ACL is processed top-down. The permit statement would never be reached. This would prevent the VPN from establishing and also block all other traffic, which is not the intention.

access-list 100 permit ip 10.1.1.0 0.0.0.255 any

Why it fails: This ACL permits traffic from the local subnet to any destination, which would cause all traffic from 10.1.1.0/24 to be encrypted, including traffic destined to the Internet or other networks. This violates the requirement to encrypt only traffic to 10.2.2.0/24. The VPN would attempt to encrypt traffic that should be sent unencrypted, potentially causing connectivity issues.

access-list 100 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 access-list 100 deny ip any any

Why it fails: The implicit deny at the end of an ACL already drops all traffic not explicitly permitted. Adding an explicit deny any any after the permit does not change the behavior for the crypto ACL: only the permitted traffic is encrypted. However, this explicit deny is redundant and does not affect the encryption of other traffic, but it is not incorrect per se. The question asks for the configuration to encrypt only the specified traffic; this would still work, but the explicit deny is unnecessary. However, in some contexts, an explicit deny might cause confusion, but it does not break the VPN. The best answer is the one without the explicit deny, as it is simpler and meets the requirement.

policy-map COPP_POLICY class ICMP_CLASS police 10000000 conform-action transmit exceed-action drop class class-default police 8000 conform-action transmit exceed-action drop interface GigabitEthernet0/0 service-policy input COPP_POLICY

Why it fails: This applies the policy to a physical interface, not to the control plane. CoPP requires the service-policy to be applied globally with the 'service-policy input' command under 'control-plane' configuration. Applying it to an interface affects all traffic entering that interface, not just control plane traffic, and does not protect the route processor.

policy-map COPP_POLICY class ICMP_CLASS police 10000000 conform-action transmit exceed-action drop interface GigabitEthernet0/0 service-policy output COPP_POLICY

Why it fails: Applying the service-policy output on an interface affects traffic leaving that interface, not traffic destined to the control plane. CoPP is applied to the control plane itself, not to physical interfaces. This configuration would not rate-limit ICMP echo requests destined to the router's management IP.

policy-map COPP_POLICY class ICMP_CLASS police 10000000 conform-action transmit exceed-action drop control-plane service-policy output COPP_POLICY

Why it fails: The 'service-policy' under 'control-plane' uses the 'input' direction to police traffic destined to the control plane. Using 'output' would police traffic originating from the control plane, which is not the goal. The requirement is to rate-limit incoming ICMP echo requests, so the correct direction is input.

ip access-list extended OUTSIDE-IN permit ip any any log deny ip any any interface GigabitEthernet0/0 ip access-group OUTSIDE-IN in logging host 192.168.1.50

Why it fails: This ACL permits all IP traffic with logging, which would log all traffic, not just denied. The deny statement is after the permit, so it will never be matched. This does not meet the requirement to log only denied traffic.

ip access-list extended OUTSIDE-IN deny ip any any log-input permit ip any any interface GigabitEthernet0/0 ip access-group OUTSIDE-IN out logging host 192.168.1.50

Why it fails: The ACL is applied outbound on the outside interface, which would log denied traffic leaving the interface, not entering. The scenario specifies logging denied traffic on the outside interface, typically inbound from the internet. Applying outbound would not capture traffic from the outside trying to enter.

ip access-list extended OUTSIDE-IN deny ip any any log permit ip any any interface GigabitEthernet0/0 ip access-group OUTSIDE-IN in logging host 192.168.1.50

Why it fails: The 'log' keyword logs the packet but does not include the input interface or port numbers in the same detail as 'log-input'. While it includes source and destination IP addresses, it may not include port numbers for non-TCP/UDP protocols. The requirement specifies port numbers, so 'log-input' is more appropriate.

The route to the remote subnet points to the tunnel interface instead of the physical interface.

Why it fails: In policy-based VPNs, the route to the remote subnet should point to the physical interface (or next-hop) that the crypto map is applied to, not to a tunnel interface. If the route pointed to a tunnel interface, it would be a route-based VPN (VTI), which is a different configuration. However, the scenario describes a crypto map, which is policy-based. This is not the most likely cause.

The crypto ACL is not mirrored correctly on the remote peer.

Why it fails: If the crypto ACL on the remote peer does not mirror the local ACL, the tunnel might not establish or traffic might fail in one direction. However, the scenario states the tunnel is up, which implies the ACLs are likely mirrored correctly for the tunnel to establish. Additionally, clear-text leakage on the local router is typically due to local configuration, not the remote peer's ACL.

The transform set is misconfigured.

Why it fails: If the transform set were misconfigured, the IPsec tunnel would not establish at all. Since the tunnel is up, the transform sets on both peers must match and be acceptable. Therefore, a misconfigured transform set is not the cause of traffic being sent in clear text while the tunnel is up.

authentication event fail action authorize vlan 100

Why it fails: This command specifies an action to take when authentication fails, such as authorizing the port into a specific VLAN. It does not enable MAB fallback or critical authentication. While it can be part of a broader authentication configuration, it does not directly achieve the goals of falling back to MAB or enabling critical authentication for a phone.

dot1x pae authenticator

Why it fails: This command configures the switch port as an 802.1X authenticator, but it does not enable MAB fallback or critical authentication. It is typically configured on the interface to enable 802.1X. However, it is not the command that specifically enables MAB or critical authentication; those require separate configuration.

aaa authentication dot1x default group radius

Why it fails: This command enables 802.1X authentication using the RADIUS server group, but it does not provide fallback to MAB or critical authentication. It is a necessary step for 802.1X, but alone it does not meet the requirement for fallback or critical authentication. Additional commands are needed to configure MAB and critical authentication.

Configure the authentication critical recovery delay on the switch.

Why it fails: The 'authentication critical recovery delay' command sets the time the switch waits before attempting to reauthenticate with the RADIUS server after it becomes available again. It does not provide fallback access when the server is unavailable. It only controls recovery behavior after an outage, not the fallback policy itself.

Configure the authentication host-mode multi-auth command on the switch.

Why it fails: The 'authentication host-mode multi-auth' command allows multiple hosts to authenticate independently on a single switch port. It is unrelated to fallback behavior when the RADIUS server is unavailable. It does not provide limited access during server outages.

Configure the dot1x pae authenticator command on the switch.

Why it fails: The 'dot1x pae authenticator' command enables 802.1X authenticator functionality on the port. While necessary for 802.1X operation, it does not configure fallback access when the RADIUS server is down. It is a basic prerequisite, not a fallback mechanism.

interface GigabitEthernet0/1 authentication host-mode multi-auth authentication order dot1x authentication port-control auto authentication control-direction in authentication event server dead action reinitialize vlan 100

Why it fails: The command 'authentication event server dead action reinitialize vlan 100' is not valid syntax. The correct action for server dead is 'authorize', not 'reinitialize'. The 'authentication control-direction in' command is used for unidirectional control, not for fallback VLAN assignment.

interface GigabitEthernet0/1 authentication host-mode multi-auth authentication order dot1x authentication port-control auto authentication event fail action authorize vlan 100 authentication event server dead action authorize vlan 100

Why it fails: The 'authentication event fail action authorize vlan 100' command is used when authentication fails, not when the server is unreachable. While it might provide fallback for failed authentication, the requirement specifically addresses server unreachability. The 'server dead' action is the correct trigger for this scenario, but the inclusion of 'fail' action is not required and could cause unexpected behavior.

interface GigabitEthernet0/1 authentication host-mode multi-auth authentication order dot1x authentication port-control auto authentication violation restrict authentication fallback profile Remediation

Why it fails: The 'authentication fallback' command is used to specify a fallback profile for web authentication, not for restricted VLAN assignment. The 'authentication violation restrict' command is for handling security violations, not for fallback to a restricted VLAN. This configuration does not achieve the desired behavior.

Change the switch port's host mode to multi-domain to support both voice and data devices.

Why it fails: Multi-domain host mode is used when a single port connects both a voice device (IP phone) and a data device (PC). In this scenario, only a PC is connected, so changing host mode will not resolve the lack of EAPOL response from the PC. The PC still needs a supplicant.

Configure the switch port as a trunk port to allow multiple VLANs for authentication traffic.

Why it fails: 802.1X authentication occurs in the native VLAN or an authentication VLAN, not requiring a trunk. Configuring the port as a trunk does not enable the PC to respond to EAPOL frames and may complicate the authentication process. The issue is the lack of supplicant, not VLAN tagging.

Configure the RADIUS server to send EAPOL-Start frames to the PC.

Why it fails: EAPOL-Start frames are sent by the supplicant (PC) to initiate authentication, not by the RADIUS server. The RADIUS server communicates with the switch using RADIUS protocol, not EAPOL. The switch sends EAPOL-Request Identity, but the PC must respond; the server does not send EAPOL frames.

policy-map COPP class ARP police 1000 class class-default police 8000 interface GigabitEthernet0/0 service-policy input COPP

Why it fails: This configuration applies the policy map to a data interface, not to the control plane. CoPP requires the service-policy to be applied globally with 'service-policy input COPP' under 'control-plane' configuration mode, not on a physical interface. Applying it on an interface would police all input traffic on that interface, not specifically control plane traffic.

policy-map COPP class ARP police 1000 control-plane service-policy input COPP

Why it fails: This configuration lacks a class-default in the policy map. Without class-default, traffic that does not match the ARP class is not explicitly matched and may be dropped by the implicit default deny in policy maps, or it may not be processed as intended. In CoPP, it is best practice to include class-default to define behavior for unmatched traffic, even if it is just to allow it.

policy-map COPP class ARP police 1000 class class-default police 8000 control-plane service-policy input COPP

Why it fails: This configuration includes a police action for the class-default class, which would rate-limit all other traffic to 8000 pps. The requirement states to allow all other traffic without policing. Therefore, the class-default should not have a police action; it should be left unconfigured or set to 'police 0' if no policing is desired, but typically it is omitted.