The SecOps Group Certified Network Security Practitioner CNSP Exam Questions

Answer : A

Authentication and Authorization (often abbreviated as AuthN and AuthZ) are foundational pillars of access control in network security:

Authentication (AuthN): Verifies 'who you are' by validating credentials against a trusted source. Examples include passwords, MFA (multi-factor authentication), certificates, or biometrics. It ensures the entity (user, device) is legitimate, typically via protocols like Kerberos or LDAP.

Authorization (AuthZ): Determines 'what you can do' after authentication, enforcing policies on resource access (e.g., read/write permissions, API calls). It relies on mechanisms like Access Control Lists (ACLs), Role-Based Access Control (RBAC), or Attribute-Based Access Control (ABAC).

Option A correctly separates these roles:

Authorization governs access decisions (e.g., 'Can user X read file Y?').

Authentication establishes identity (e.g., 'Is this user X?').

In practice, these processes are sequential: AuthN precedes AuthZ. For example, logging into a VPN authenticates your identity (e.g., via username/password), then authorizes your access to specific subnets based on your role. CNSP likely stresses this distinction for designing secure systems, as conflating them risks privilege escalation or identity spoofing vulnerabilities.

Why other options are incorrect:

B: Reverses the definitions---Authentication doesn't grant/deny access (that's AuthZ), and Authorization doesn't validate identity (that's AuthN). This mix-up could lead to flawed security models.

C: Falsely equates AuthN and AuthZ and attributes access rules to AuthN. They're distinct processes; treating them as identical undermines granular control (e.g., NIST SP 800-53 separates IA-2 for AuthN and AC-3 for AuthZ).

D: Misassigns access control to AuthN and claims they don't interoperate, which is false---they work together in every modern system (e.g., SSO with RBAC). This would render auditing impossible, contradicting security best practices.

Real-World Context: A web server (e.g., Apache) authenticates via HTTP Basic Auth, then authorizes via .htaccess rules---two separate steps.

Answer : A

The prefix $2a$ identifies the bcrypt hashing algorithm, which is based on the Blowfish symmetric encryption cipher (developed by Bruce Schneier). Bcrypt is purpose-built for password hashing, incorporating:

Salt: A random string (e.g., 22 Base64 characters) to thwart rainbow table attacks.

Work Factor: A cost parameter (e.g., $2a$10$ means 2^10 iterations), making it computationally expensive to brute-force.

Format: $2a$[cost]$[salt][hash]

Example: $2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

$2a$: Bcrypt variant (original is $2$; $2a$ fixes a minor bug).

$10$: 1024 iterations.

Next 22 characters: Salt.

Remaining: Hashed password.

Used in /etc/shadow on Linux, bcrypt's adaptive nature ensures it remains secure as hardware improves. CNSP likely includes it in cryptography modules for its strength over older algorithms like MD5.

Why other options are incorrect:

B . SHA256: Part of the SHA-2 family, outputs a 64-character hexadecimal string (e.g., e3b0c442...), no $ prefix. It's faster, less suited for passwords.

C . MD5: Produces a 32-character hex string (e.g., d41d8cd9...), no prefix. It's cryptographically broken (collisions found).

D . SHA512: SHA-2 variant, 128-character hex (e.g., cf83e135...), no $ prefix, not salted by default.

Real-World Context: Bcrypt protects SSH keys and web app passwords (e.g., in PHP's password_hash()).

Answer : C

Address spoofing fakes a source address (e.g., IP, MAC) to impersonate or amplify attacks. Analyzing protocol resilience:

C . TCP (Transmission Control Protocol):

Mechanism: Three-way handshake (SYN, SYN-ACK, ACK) verifies both endpoints.

Client SYN (Seq=X), Server SYN-ACK (Seq=Y, Ack=X+1), Client ACK (Ack=Y+1).

Spoofing Resistance: Spoofer must predict the server's sequence number (randomized in modern stacks) and receive SYN-ACK, impractical without session hijacking or MITM.

Correct Implementation: RFC 793-compliant, with anti-spoofing (e.g., Linux tcp_syncookies).

A . UDP:

Connectionless (RFC 768), no handshake. Spoofed packets (e.g., source IP 1.2.3.4) are accepted if port is open, enabling reflection attacks (e.g., DNS amplification).

B . ARP (Address Resolution Protocol):

No authentication (RFC 826). Spoofed ARP replies (e.g., fake MAC for gateway IP) poison caches, enabling MITM (e.g., arpspoof).

D . IP:

No inherent validation at Layer 3 (RFC 791). Spoofed source IPs pass unless filtered (e.g., ingress filtering, RFC 2827).

Security Implications: TCP's handshake makes spoofing harder, though not impossible (e.g., blind spoofing with sequence prediction, mitigated since BSD 4.4). CNSP likely contrasts this with UDP/IP's vulnerabilities in DDoS contexts.

Why other options are incorrect:

A, B, D: Lack handshake or authentication, inherently spoofable.

Real-World Context: TCP spoofing was viable pre-1990s (e.g., Mitnick attack); modern randomization thwarts it.

Answer : A

The Linux Filesystem Hierarchy Standard (FHS), per FHS 3.0, defines directory purposes:

/mnt: Designated for temporarily mounted filesystems, typically by system administrators.

Use: Mount points for removable media (e.g., USB drives: mount /dev/sdb1 /mnt/usb) or network shares (e.g., NFS).

Nature: Transient, user-managed, not persistent across reboots (unlike /etc/fstab mounts).

Contrast:

/media: Auto-mounts removable devices (e.g., by desktop environments like GNOME).

/mnt vs. /media: /mnt is manual, /media is system-driven.

Technical Details:

Empty by default; subdirectories (e.g., /mnt/usb) are created as needed.

Permissions: Typically root-owned (0755), requiring sudo for mounts.

Security Implications: Misconfigured /mnt mounts (e.g., world-writable) risk unauthorized access. CNSP likely covers mount security (e.g., nosuid option).

Why other options are incorrect:

B . System config/init scripts: Found in /etc (e.g., /etc/passwd, /etc/init.d).

C . Driver modules: Located in /lib/modules/<kernel-version>.

D . Kernel state: Resides in /proc (e.g., /proc/cpuinfo).

Real-World Context: Admins mount ISOs at /mnt during server provisioning (e.g., mount -o loop image.iso /mnt).

Answer : A

Symmetric encryption is a cryptographic technique where the same key is used for both encryption and decryption processes. In the context of network security, when data is encrypted prior to transmission and decrypted at the receiving end using a symmetric encryption algorithm (e.g., AES or Triple-DES), both the sender and receiver must share and utilize an identical secret key. This key is applied by the sender to transform plaintext into ciphertext and by the receiver to reverse the process, recovering the original plaintext. The efficiency of symmetric encryption makes it ideal for securing large volumes of data transmitted over networks, provided the key is securely distributed and managed.

Why A is correct: Option A accurately describes the fundamental property of symmetric encryption---using a single shared key for both encryption and decryption. This aligns with CNSP documentation, which emphasizes symmetric encryption's role in securing data in transit (e.g., via VPNs or secure file transfers).

Why other options are incorrect:

B: This describes asymmetric encryption (e.g., RSA), where different keys (public and private) are used for encryption and decryption, not symmetric encryption.

C: Symmetric encryption inherently relies on keys; the absence of keys contradicts its definition and operational mechanism.

D: Symmetric encryption is not inherently insecure; its security depends on key strength and management practices, not the algorithm itself. CNSP highlights that algorithms like AES are widely regarded as secure when implemented correctly.

Answer : B

Microsoft SQL Server (MSSQL) relies on specific ports for its core services, as defined by Microsoft and registered with IANA:

1433/TCP: The default port for the SQL Server Database Engine. Clients connect here for querying databases (e.g., via ODBC or JDBC). It's a well-known port, making it a frequent target for attacks if exposed.

1434/UDP: Used by the SQL Server Browser Service, which listens for incoming requests and redirects clients to the correct port/instance (especially for named instances). It's critical for discovering dynamic ports when 1433 isn't used.

1434/TCP: Less commonly highlighted but used in some configurations, such as dedicated admin connections (DAC) or when the Browser Service responds over TCP for specific instances. While 1433/TCP is the primary engine port, 1434/TCP can be involved in multi-instance setups.

Technical Details:

Ports can be customized (e.g., via SQL Server Configuration Manager), but these are defaults.

Named instances often use dynamic ports (allocated from the ephemeral range), with the Browser Service (1434/UDP) guiding clients to them.

Firewalls must allow these ports for MSSQL to function externally, posing risks if not secured (e.g., brute-force attacks on 1433/TCP).

Security Implications: CNSP likely covers MSSQL port security, as vulnerabilities like SQL Slammer (2003) exploited 1434/UDP misconfigurations. Hardening includes restricting access, changing defaults, and monitoring traffic.

Why other options are incorrect:

A . 1433/TCP, 2433/UDP, 3433/TCP: 2433/UDP and 3433/TCP are not MSSQL standards; they're likely typos or unrelated ports.

C . 1433/TCP, 2433/UDP, 1434/TCP: 2433/UDP is incorrect; 1434/UDP is the Browser Service port.

D . 1533/TCP, 1434/UDP, 2434/TCP: 1533/TCP and 2434/TCP aren't associated with MSSQL; they deviate from documented defaults.

Real-World Context: Tools like netstat -an | find '1433' on Windows confirm MSSQL's port usage during audits.

Answer : D

The Active Directory (AD) database on Windows domain controllers contains critical directory information, stored in a specific file format.

Why D is correct: The NTDS.DIT file (NT Directory Services Directory Information Tree) is the Active Directory database file, located in C:\Windows\NTDS\ on domain controllers. It stores all AD objects (users, groups, computers) and schema data in a hierarchical structure. CNSP identifies NTDS.DIT as the key file for AD data extraction in security audits.

Why other options are incorrect:

A . NTDS.DAT: Not a valid AD database file; may be a confusion with other system files.

B . NTDS.MDB: Refers to an older Microsoft Access database format, not used for AD.

C . MSAD.MDB: Not a recognized file for AD; likely a misnomer.