RSA

Explanation:
IPsec uses two main types of cryptographic algorithms:

Encryption algorithms to provide confidentiality.

Integrity algorithms to provide data integrity and authentication.

Let's break down the correct answers:

C) HMAC-SHA1/SHA2 is CORRECT.
This is an integrity algorithm. HMAC (Hash-based Message Authentication Code) is the mechanism used within IPsec's Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols to ensure that packets have not been tampered with in transit. SHA-1 and the more secure SHA-2 family (SHA-256, SHA-384) are the specific hash functions used within HMAC.

E) AES-CBC is CORRECT.
This is an encryption algorithm. AES (Advanced Encryption Standard) is the most common symmetric encryption cipher used in modern IPsec implementations. CBC (Cipher Block Chaining) is a specific mode of operation for AES. While other modes like AES-GCM are becoming more popular (as they provide both encryption and integrity in one step), AES-CBC is a widely supported and valid algorithm for IPsec.

Why the other options are incorrect:

A) AES-BAC is INCORRECT.
"BAC" is not a valid mode of operation for the AES algorithm.

B) AES-ABC is INCORRECT.
"ABC" is not a valid mode of operation for the AES algorithm.

D) Triple AMC-CBC is INCORRECT.
This appears to be a misspelling or distractor. The correct algorithm is 3DES-CBC (Triple Data Encryption Standard in Cipher Block Chaining mode). While 3DES was used in the past, it is now considered weak and deprecated in favor of AES.

Reference:

IETF RFCs for IPsec: Foundational RFCs like RFC 4303 (ESP) and RFC 4305 (Cryptographic Algorithm Implementation Requirements) specify the use of AES and HMAC-SHA for encryption and integrity, respectively.

Cisco IPsec VPN Configuration Guides: The configuration commands for creating IPsec transform sets explicitly list these algorithms (e.g., esp-aes, esp-sha-hmac).

The attack is fragmented into groups of 8 octets before transmission.

Malformed packets are used to crash systems.

ExplanationPing of Death (PoD) is a type of Denial of Service (DoS) attack in
which an attacker attempts to crash,destabilize, or freeze the targeted computer or service
by sending malformed or oversized packets using a simple ping command.A correctlyformed
ping packet is typically 56 bytes in size, or 64 bytes when the ICMP header is
considered,and 84 including Internet Protocol version 4 header. However, any IPv4 packet
(including pings) may be as large as 65,535 bytes. Some computer systems were never
designed to properly handle a ping packet larger than the maximum packet size because it
violates the Internet Protocol documentedLike other large but well-formed packets, a ping
of death is fragmented into groups of 8 octets beforetransmission. However, when the
target computer reassembles the malformed packet, a buffer overflow can occur, causing a
system crash and potentially allowing the injection of malicious code.

Explanation:
This question involves the integration of network access control across different network segments, specifically allowing a central policy server to communicate with network access devices (switches) that may be behind a firewall.

Let's break down the key terms and each option:

CoA (Change of Authorization):
This is a RADIUS packet type defined in RFC 5176. It allows a RADIUS server (like Cisco ISE) to dynamically send a command to a network device (like a switch, router, or wireless controller) to change the authorization status of a user session after the initial authentication. Examples include re-authenticating a user, disconnecting a user, or bouncing a port.

Why Option B (UDP 1700) is Correct:
The standard destination port for a CoA packet is UDP 1700. For CoA to work, the firewall must permit traffic from the RADIUS server to the network access device on this port. There is also a related port, UDP 1700, used for Disconnect Messages (DM), which are similar but used to immediately terminate a session.

Why the Other Options are Incorrect:

Why Option A (TCP 6514) is Incorrect:
TCP 6514 is the default port for the RADIUS over TLS (RadSec) protocol. This is used for secure, TCP-based communication of RADIUS packets between servers and clients, but it is not the standard port for CoA.

Why Option C (TCP 49) is Incorrect:
TCP 49 is the port for the TACACS+ protocol. TACACS+ is primarily used for administrative access to network devices (AAA for device management), not for 802.1X user authentication or CoA commands, which are part of the RADIUS protocol family.

Why Option D (UDP 1812) is Incorrect:
UDP 1812 is the standard port for the initial RADIUS Authentication packets. This is the port used when the switch (the NAS) first contacts the RADIUS server to authenticate a user. CoA is a separate, subsequent communication initiated by the server back to the switch, and it uses its own dedicated port (UDP 1700).

Reference:
This falls under the Secure Network Access, Visibility, and Enforcement domain. A critical part of deploying a solution like Cisco ISE is ensuring proper network connectivity for all its functions. Understanding that CoA uses UDP port 1700 is essential for firewall rules to enable dynamic policy enforcement, such as quarantining a device or requiring re-authentication.

Explanation
In a Software-Defined Networking (SDN) architecture, the communication between different layers is defined by APIs (Application Programming Interfaces).

Southbound APIs are the protocols that the SDN Controller uses to communicate down to the network devices (switches, routers) in the data plane. Their primary function is to push configuration and instructions from the controller to the devices, enabling centralized, dynamic control of the entire network.

Examples of southbound API protocols include OpenFlow, OPFLEX, and NETCONF. These protocols allow the controller to install flow entries, modify routing tables, and configure interfaces on the network elements.

Therefore, the function is "to enable the controller to make changes" to the network infrastructure.

Why the other options are incorrect:

A. to allow for the dynamic configuration of control plane applications:
This describes the function of Northbound APIs. Northbound APIs sit between the controller and the business applications (or network services), allowing those applications to dynamically request network resources from the controller.

C. to enable the controller to use REST:
REST is a common architecture for Northbound APIs, not Southbound APIs. Southbound APIs typically use lower-level, device-specific protocols like OpenFlow.

D. to allow for the static configuration of control plane applications:
This is incorrect. The entire purpose of SDN and its APIs is to move away from static, device-by-device configuration and toward dynamic, centralized control. Southbound APIs are the mechanism for this dynamic control.

Reference:
The roles of northbound and southbound interfaces are a fundamental concept in SDN.

As defined in the Cisco Digital Network Architecture (DNA) Center and general SDN literature, the Southbound Interface is the "controller-to-device communication channel" used to "push configuration and policy to network devices." This aligns perfectly with enabling the controller to make changes.

Security Category Blocking

Explanation:
DHCP Snooping is a security feature that acts as a firewall between untrusted hosts and trusted DHCP servers.

How it works:
By default, DHCP Snooping treats all switch ports as untrusted. An untrusted port will block all DHCP server messages, such as DHCPOFFER and DHCPACK packets. This prevents rogue DHCP servers on the network.

The Problem:
The interface GigabitEthernet1/0/1 is the uplink to the distribution switch, which is almost certainly the path to the legitimate DHCP server. Because this port is untrusted, it is blocking the DHCP server's replies, which is why the user in VLAN 41 cannot obtain an IP address.

The Solution:
The uplink port that connects to the legitimate DHCP server (or to a network segment containing the server) must be configured as trusted. The command ip dhcp snooping trust applied to the uplink interface allows DHCP server responses to pass through the switch, enabling clients to receive their IP addresses.

Why the other options are incorrect:

A) ip dhcp snooping verify mac-address is INCORRECT.
This command enables a check to see if the source MAC address in an Ethernet frame matches the client MAC address in the DHCP request. It's a good security practice on access ports, but it does not solve the core problem of the DHCP server's responses being blocked on the uplink.

B) ip dhcp snooping limit 41 is INCORRECT.
This is not a valid command. The rate-limiting command is ip dhcp snooping limit rate.

C) ip dhcp snooping vlan 41 is INCORRECT.
This command is already configured globally for the switch (as seen in the running config: ip dhcp snooping vlan 41,44). It enables DHCP Snooping for the specified VLANs but does not define trusted interfaces. Applying it again on the interface would be incorrect syntax and would not solve the problem.

Reference:
Cisco IOS Security Configuration Guide: "Configuring DHCP Snooping": The official documentation states, "You must configure the connection between the switch and the DHCP server as trusted... You must configure all other ports as untrusted."

Detailed Explanation:
Cisco ASA NetFlow v9 Secure Event Logging is a specialized feature that goes beyond traditional NetFlow. Its key characteristic is that it exports specific security events related to network flows as they are created and terminated by the ASA's stateful firewall.

Let's break down each option:

Why Option A is Correct:
This is the precise definition of the feature. It logs three critical events in the lifecycle of a connection through the ASA:

Flow-Create:
Generated when a new connection is established and passes the ASA's security policies.

Flow-Teardown:
Generated when a connection is terminated normally (e.g., via a TCP FIN handshake) or due to a timeout.

Flow-Denied:
Generated when a connection attempt is explicitly blocked by the ASA's access control lists (ACLs) or other security policies. This is a crucial security event for threat detection and analysis.

Why Option B is Incorrect:
This statement describes traditional, stateless NetFlow used on routers and switches. The Cisco ASA is a stateful firewall, and its Secure Event Logging is built around this stateful nature. It does not simply export all records of a stateless IP flow.

Why Option C is Incorrect:
The logging is event-driven, not periodic. It sends a record when a specific event happens (create, teardown, deny), not on a fixed timer. Providing updates every 10 seconds is a characteristic of performance monitoring, not security event logging.

Why Option D is Incorrect:
This statement is misleading and does not accurately describe how the feature works. The ASA inspects traffic against its configured security policy (ACLs, rules) sequentially, not in parallel, to make an allow or deny decision. The NetFlow logging is a consequence of that decision, not a process that matches traffic classes in parallel.

Reference:
This feature is part of the Cisco ASA series and falls under the Security Protocols and Services domain. It is designed to provide detailed, stateful security telemetry to external collectors (like a SIEM or Stealthwatch) for advanced network visibility and threat response.

Explanation for Each Option:

A. Configure incoming content filters (Incorrect):
Incoming content filters on the Cisco Email Security Appliance (ESA) are used to analyze and block email content based on rules (e.g., keywords, attachments). They do not specifically prevent malicious actors from identifying valid recipients through LDAP accept queries, which target directory harvesting, making this option unsuitable. (Reference: Cisco ESA Content Filter Configuration Guide.)

B. Use Bounce Verification (Incorrect):
Bounce Verification on the Cisco ESA helps reduce backscatter by verifying recipient validity before sending bounce messages. While it addresses some email abuse, it does not prevent rapid identification of valid recipients via LDAP queries during a directory harvest attack, as its focus is on bounce management, not query protection, rendering this option incorrect. (Reference: Cisco ESA Bounce Verification Guide.)

C. Configure Directory Harvest Attack Prevention (Correct):
Directory Harvest Attack Prevention (DHAP) on the Cisco ESA limits the rate of LDAP accept queries to prevent malicious actors from quickly identifying valid recipients by brute-forcing the directory. By setting thresholds and delays, it mitigates the risk of directory harvesting, aligning with the goal of protecting against such attacks. (Reference: Cisco ESA Security Services, DHAP Configuration.)

D. Bypass LDAP access queries in the recipient access table (Incorrect):
Bypassing LDAP access queries in the recipient access table would disable LDAP-based recipient validation, potentially allowing unauthorized emails to be accepted. This does not prevent malicious actors from identifying valid recipients; it removes a security check, making this option counterproductive to the goal. (Reference: Cisco ESA Recipient Access Table Guide.)

Additional Notes:
Configuring DHAP is a key topic in the 350-701 SCOR exam under content security. As of 11:55 AM PKT, October 02, 2025, it remains essential for email security. For details, refer to the Cisco ESA Administration Guide (cisco.com) and the 350-701 Exam Blueprint (Section 3.0 Security Concepts).

Talos

Explanation
The question asks about inspecting secure HTTP traffic, which is another term for HTTPS traffic (HTTP over SSL/TLS). By default, this traffic is encrypted, making its contents unreadable to any intermediary device, including a security service.

C. SSL Decryption:
This is the specific feature within Cisco Umbrella that enables the inspection of HTTPS traffic. When enabled, Umbrella acts as a man-in-the-middle for selected encrypted connections. It terminates the user's HTTPS connection, decrypts the traffic, inspects the contents for threats, and then re-encrypts it before sending it to the final destination. This allows Umbrella to see and block malicious content hidden within encrypted web traffic.

Why the other options are incorrect:

A. File Analysis:
This is a feature that inspects files being downloaded for malware. While it may work in conjunction with SSL Decryption (a file downloaded over HTTPS would need to be decrypted first to be analyzed), it is not the feature that enables the inspection of the secure HTTP traffic itself.

B. SafeSearch:
This is a feature that forces search engines to use their "safe" filtering mode to block explicit content. It is a content filtering policy, not a mechanism for decrypting and inspecting traffic.

D. Destination Lists:
These are used to create custom allow lists or block lists for specific domains or IP addresses. They are a policy enforcement tool, not an inspection mechanism for encrypted traffic.

Reference:
The functionality of SSL Decryption is a core component of the Cisco Umbrella secure web gateway capabilities.

The Cisco Umbrella Documentation for SSL Decryption states that it "allows you to inspect encrypted web traffic (HTTPS) for advanced threat protection" and "gives you visibility into encrypted traffic to better protect your organization from threats." This confirms it as the correct feature.