CCNA Network Security Fundamentals Questions

Zero Trust assumes no implicit trust between zones, so the default interzone policy should deny all traffic, with access granted only through explicit rules. This satisfies the stem's requirement for the recommended default stance in that deployment model.

A custom URL list is configurable within a URL Filtering profile, letting administrators explicitly allow or block specific URLs beyond predefined categories. This satisfies the stem's requirement for settings adjustable in the profile itself, rather than global firewall or subscription-level configuration.

Requiring a second factor beyond a password makes credential theft far less useful to an attacker. Even if a password is guessed or phished, the additional factor blocks the login. This directly hardens the management plane, which is the plane that hosts administrator authentication and the configuration database.

The Traffic log records every session, including the rule name that allowed or denied it, source and destination zones, IP addresses, and application. By filtering the Traffic log for the malicious IP, the analyst can identify the exact rule that permitted the session, even after it has ended.

URL Filtering is a recognised Security Profile type on Palo Alto Networks firewalls, applied to traffic to control web access by category. It sits alongside Antivirus, Anti-Spyware, Vulnerability Protection and File Blocking as a distinct profile configured in the Security Profiles section.

Certificate Transparency requires that certificates be submitted to public, append-only Merkle tree logs, and the resulting signed certificate timestamps are embedded or stapled into the certificate. This creates an auditable record of issuance that monitors can watch for unauthorized or misissued certificates, directly meeting the traceability and audit goals.

App-ID identifies the application regardless of port or protocol, ensuring that only the specific web application is allowed. This prevents other applications from using the same ports to bypass policy. Combined with User-ID, it enforces least privilege by restricting access to the intended application and users.

Stateful inspection builds a session table entry on the first packet and applies the security policy once for that session. Subsequent packets are matched to the existing session and forwarded without re-evaluating the full policy, which is why the analyst sees a single policy check for thousands of packets. This is the defining behavior of session-based enforcement.

Binding a specific Address Object for the destination server to the correct zone restricts the rule to that host, satisfying least privilege. Referencing any or broad subnets would permit unnecessary destinations, contradicting the stem's stated principle.

App-ID identifies the application regardless of port, protocol, or encryption. In this scenario, the engineer can create a security policy that allows only the specific web application by its App-ID signature, such as 'ssl' with a URL category or a custom App-ID, ensuring only that application is permitted. This enforces least privilege and prevents other applications from using the same port.

Application identification is mandatory in a Security Policy rule, specifying which application or service the rule permits or denies. It satisfies the stem's requirement for a necessary rule component, alongside source and destination criteria that together define matching traffic.

Logging only at session end means the firewall records the session's start and finish times in a single entry, so the elapsed duration is captured precisely. This satisfies the consequence being tested: accurate session duration, which per-session logging cannot reliably provide when sessions span multiple log entries.

An Application Override policy allows an administrator to define a custom application based on a specific port and protocol, so the firewall can recognize and control traffic that would otherwise be unidentified. This is appropriate for a proprietary protocol on a non-standard port like TCP 8443.

DNS sinkholing intercepts queries for known malicious domains and responds with a non-routable or controlled address, preventing the client from reaching the real command-and-control server. It directly blocks resolution at the network level and can also generate alerts when clients attempt to resolve those domains, providing both prevention and detection.

An Address Group is a PAN-OS object that aggregates multiple IP addresses, static or dynamic, into a single named reference usable in security policy rules. This satisfies the requirement to group many addresses so one policy entry covers them all, rather than listing each address individually.

Destination NAT rewrites the public-facing address and port in the packet header to the internal server's private address and port. Without this translation, the firewall would forward the packet with the original public destination address, which the web server cannot recognize as its own, so the connection would never complete even with a permissive security policy.

Web-browsing depends on the ssl application for HTTPS traffic, so the firewall denies the session when ssl is absent from the allowed applications. Palo Alto Networks resolves applications with dependencies before matching; permitting only web-browsing leaves the encrypted flow unmatched, satisfying the stem's denial despite the policy match.

App-ID is the NetSec-Pro technology that identifies applications regardless of port, protocol, or encryption. It can distinguish between HTTP and HTTPS traffic and enforce policy based on the actual application, ensuring only the desired web protocols are allowed while blocking all others, which meets the requirement precisely.

GCM combines counter-mode encryption with a Galois field message authentication code, delivering confidentiality and integrity in one pass. Because it is a stream-oriented mode, blocks can be processed in parallel, and each packet uses a unique nonce to prevent keystream reuse. This satisfies all the stated requirements.

This configuration restricts access to the DMZ web server from the untrusted zone, allows only the web-browsing application, and uses the application-default service, which automatically allows only the ports required by that application. This is the most restrictive and secure approach, adhering to least privilege.

SSL decryption alone yields plaintext, but threat inspection requires a Security Profile such as Anti-Virus to scan that decrypted stream. Without a profile bound to the decryption policy, malicious payloads pass uninspected, so the profile satisfies the visibility requirement alongside decryption.

URL Filtering profiles categorise and control web destinations, so blocking a specific site requires editing the URL Filtering profile and its category or custom URL list. Anti-Virus, Vulnerability Protection and File Blocking inspect content rather than destinations, so they cannot restrict site access.

ACLs on routers filter packets based on IP addresses, protocols, and port numbers, and can be applied to interfaces to control traffic between VLANs. They provide network-layer segmentation and can restrict which subnets communicate, directly supporting the requirement for VLAN traffic control.

Application Default applies the predefined port set associated with the identified application signature, so traffic is limited to those standard ports rather than any port. This satisfies the constraint of enforcing application-specific port behaviour without writing custom rules.

Allowing any application means traffic is filtered only by port, not by process identity, so malware tunnelling over permitted ports such as 443 or 53 passes unchallenged. This satisfies the stem's constraint: a policy permitting any application cannot distinguish legitimate software from hidden threats abusing those same allowed ports.

A distributed virtual firewall integrated with SDN enforces security policy at the hypervisor or host level, allowing micro-segmentation between workloads on the same VLAN without hairpinning traffic to a physical appliance. It provides centralized management, identity-based rules, and service chaining, which directly satisfies the east-west zero-trust requirement described.

App-ID inspects the application payload to distinguish web-browsing from other applications tunnelling over port 80, so policy matches on the actual application rather than the port alone. This enforces the stem's requirement that only web-browsing is permitted.

DNS Security's predictive analysis uses machine learning models to score domains that exhibit DGA characteristics, such as high entropy or unusual character patterns, even when the domain has no prior reputation. Enabling it lets the firewall block or alert on queries to domains that are probable DGA outputs, directly addressing the command-and-control technique described. Sinkholing alone only covers known malicious domains and cannot catch newly generated ones.

Security policies on PAN-OS are unidirectional and evaluated based on the source and destination zones of the initiating session. A deny rule from web to database blocks web-initiated connections, while the allow rule from database to web permits replication traffic initiated by the database tier, satisfying the asymmetric requirement.

For a new session the very first packet is sent to the dataplane, where the security policy is evaluated and a session entry is installed in the session table. All subsequent packets of that flow are matched to the existing session and forwarded without repeating a full policy lookup, which is what gives PAN-OS its performance advantage.

Port security limits the number of source MAC addresses learned on an access port and can take action when the limit is exceeded. This directly counters MAC flooding, where an attacker overwhelms the CAM table with bogus addresses to force the switch into hub-like flooding, so it is a correct hardening measure.

Traffic between interfaces in the same zone is intrazone and is allowed by default without requiring an explicit rule, so it may not be subject to the intended policy and inspection. Assigning each segment to its own zone makes the traffic interzone, which is denied by default and requires an explicit allow rule, enabling enforcement.

The App-ID Test tool allows the engineer to input session parameters and see how the firewall would identify the application. It can simulate a session and display the App-ID, providing real-time classification. This is the most direct way to verify application identification and troubleshoot misclassification issues.

App-ID identifies facebook-base rather than web-browsing, so the session fails to match the allowing rule and falls through to the default deny, dropping it. Application identification overrides port-based assumptions, which is the behaviour the stem describes.

App-ID identification can require several packets to complete. If the application cannot be identified within the configured packet threshold, the session may be denied or handled according to the unidentified traffic settings. This matches the observed drop reason and explains the intermittent nature, since only some flows fail to identify in time.

Dynamic Address Groups derive their membership from tags registered by a workload registry or orchestration platform, so policy follows the workload's identity rather than its IP address. When a virtual machine migrates and its tag is updated, the group membership refreshes automatically and the existing policy continues to apply. This directly satisfies the requirement for identity-based segmentation that survives live migration across hypervisors and physical hosts.

App-ID classifies traffic by application regardless of port or protocol, feeding the single-pass pipeline so identification, threat inspection and policy enforcement occur once per packet. This satisfies the architecture's requirement that all three functions run in one unified pass rather than separate engines.

Source Zone is a valid match criterion because zones represent the ingress interface or tunnel from which traffic originates. Rules match on source zone to enforce policy between trust levels, satisfying the stem's requirement for items usable as match criteria in a Security Policy rule.

SSL Forward Proxy decryption lets the firewall act as a man-in-the-middle for outbound TLS sessions, decrypting the traffic so that security profiles can inspect the application data inside. Because the sessions are outbound and the protocol is decryptable, this is the appropriate mechanism. Attaching profiles to the allowing rule ensures the decrypted content is actually scanned for threats and sensitive data.

The ssl application is defined to use TCP 443 as its default port. When the service is set to application-default, the firewall derives the port from the application definition rather than from a fixed service object. The rule therefore matches the server's outbound TCP 443 session and permits it, which explains the connectivity without a port-specific rule.

SSL decryption terminates the TLS session at the firewall, decrypting packets so deep packet inspection can scan payloads for malware and intrusions before re-encrypting and forwarding them. This directly satisfies the stem's requirement to inspect encrypted traffic for threats, which signature-based inspection of ciphertext alone cannot achieve.

Explicit allow rules that name only the necessary applications and services implement least privilege by permitting only known-good flows. Combined with a default deny posture, this ensures that a compromised host cannot initiate arbitrary connections to other tiers, because any traffic not matching an allow rule is dropped at the firewall.

An External Dynamic List hosts a file of addresses on an external server that the firewall imports and refreshes automatically, so the administrator updates the file centrally and the security rule's source membership changes without editing the rule. This matches the requirement to permit a changing set of partner addresses while keeping the rule stable. It also scales better than manual object edits.

File Blocking profiles inspect uploads and downloads against configured file-type rules, letting the administrator deny a named extension outright. This directly satisfies the stem's constraint of blocking one specific file type, since the profile enforces the restriction inline rather than relying on signatures or application identification.

Vulnerability Protection is a Security Profile, inspecting traffic for exploits such as buffer overflows and code execution attempts. It sits alongside Anti-Virus, Anti-Spyware, URL Filtering and File Blocking, all of which are profiles rather than interfaces, zones or administrative settings.

Source Zone is a mandatory matching criterion in PAN-OS Security Policy rules, defining which ingress zone traffic must originate from before the rule can apply. It satisfies the stem's requirement for a valid policy component, since every rule evaluates traffic against source and destination zones alongside addresses, applications and services.

Ingress and egress filtering, as described in BCP 38, drops packets whose source addresses do not belong to the network they are entering or leaving. This prevents an attacker from using spoofed addresses from outside the legitimate range. It is a foundational, correct mechanism for reducing IP spoofing at the edge.

URL Filtering profiles are configured under Objects > Security Profiles, alongside Anti-Virus, Anti-Spyware and Vulnerability Protection. Policies then reference the profile. Device and Network tabs hold interfaces, zones and routing, so Objects > Security Profiles is the correct location.

A TCP RST returned to a SYN confirms the destination host is reachable but no service is listening, so the port is closed. No response at all means an intermediate firewall or filter silently discarded the packet, which is the definition of a filtered port. This matches the analyst's observations exactly.

The Policy Test Tool (test security-policy-match) simulates a flow against the rulebase and returns the exact matching rule, including shadowed or preceding rules. Packet captures and logs show traffic behaviour but not rule precedence, so this tool satisfies the need to identify the specific rule.

Security policies are evaluated top-down, so a deny rule placed above the permissive legacy rule will match the malicious flow first and drop it. This approach blocks the specific behavior while leaving the broad outbound rule in place for other traffic, minimizing disruption and providing immediate containment of the suspected command-and-control activity.

The Internet layer in the TCP/IP model corresponds to the OSI Network layer and is responsible for logical addressing with IP addresses and for routing packets across interconnected networks. Protocols such as IP, ICMP, and routing protocols operate here, making it the correct layer for this function.

Grouping applications under one App-ID lets a single security policy match multiple applications, collapsing many near-identical rules into one. This directly satisfies the stem's simplification goal: fewer rules to audit, reorder, and maintain, while preserving the same enforcement granularity per application.

The Application Command Center provides visualizations and logs that show which applications are being detected on the network. By reviewing ACC, the administrator can verify if the SaaS application is being identified correctly. If misidentified, they can then use an Application Override policy to correct it, making ACC the appropriate verification tool.

User-ID maps IP addresses to usernames and group memberships, letting security policy match on user or group rather than IP alone. This satisfies the requirement for identity-based enforcement, so rules follow the person regardless of which address DHCP assigns them.

The Management Plane hosts the web interface and CLI, satisfying the stem's requirement for administrative access. It handles configuration, logging and management traffic separately from the Data Plane, which processes network sessions, and the Control Plane, which runs routing protocols. This separation lets administrators manage the firewall without disrupting forwarded traffic.

Logging is enabled per rule on the Actions tab of the Security Policy, where the Log at Session End or Log at Session Start option is selected. This satisfies the requirement to record traffic matching that specific rule, rather than relying on global logging settings.

Zone Protection Profiles defend the firewall's ingress against volumetric floods and scanning activity, covering both denial-of-service and reconnaissance. They satisfy the scenario's requirement by applying flood thresholds, packet-based attack protection, and reconnaissance detection at the zone level, before traffic reaches security policy evaluation, thereby shielding the protected zone's resources.