Free Practice Questions for The SecOps Group CNSP Exam

SSL/TLS protocols secure network communication, but older versions have vulnerabilities:

SSLv2 (1995):Weak ciphers, no handshake integrity (e.g., MITM via DROWN attack, CVE-2016-0800). Deprecated by RFC 6176 (2011).

SSLv3 (1996):Vulnerable to POODLE (CVE-2014-3566), weak block ciphers (e.g., RC4). Deprecated by RFC 7568 (2015).

TLSv1.0 (1999, RFC 2246):Inherits SSLv3 flaws (e.g., BEAST, CVE-2011-3389), weak CBC ciphers. Deprecated by PCI DSS (2018) and RFC 8996 (2021).

TLSv1.1 (2006, RFC 4346):Improved over 1.0 but lacks modern cipher suites (e.g., AEAD). Deprecated with 1.0 by RFC 8996.

TLSv1.2 (2008, RFC 5246):Secure with strong ciphers (e.g., AES-GCM), widely used today.

TLSv1.3 (2018, RFC 8446):Latest, removes legacy weaknesses, mandatory forward secrecy.

Answer:C (A and B)—SSLv2, SSLv3, TLSv1.0, and TLSv1.1 are unsafe due to exploitable flaws. TLSv1.2 and 1.3 remain secure. CNSP likely aligns with IETF/PCI standards, mandating modern versions.

Why other options are incorrect:

A:Correct but incomplete without B.

B:Correct but incomplete without A.

D:Incorrectly includes TLSv1.2 and 1.3, which are secure and recommended.

Real-World Context:POODLE forced mass SSLv3 disablement in 2014; TLS 1.0/1.1 deprecation hit legacy systems in 2021.References:CNSP Official Documentation (Cryptographic Protocols); RFC 8996 (TLS Deprecation).

Negotiating a shared encryption key involves a process where two parties agree on a secret key over an insecure channel without directly transmitting it. This is distinct from encryption or hashing algorithms, which serve different purposes.

Why C is correct:The Diffie-Hellman (DH) algorithm is a key exchange protocol that enables two parties to establish a shared secret key using mathematical operations (e.g., modular exponentiation). It’s widely used in protocols like TLS and IPsec, as noted in CNSP for secure key negotiation.

Why other options are incorrect:

A:Triple-DES is a symmetric encryption algorithm for data encryption, not key negotiation.

B:SHA1 is a hash function for integrity, not key exchange.

D:AES is a symmetric encryption algorithm, not a key exchange mechanism.

References:CNSP "Cryptographic Protocols" (Section on Key Exchange) describes Diffie-Hellman as the standard for shared key negotiation, contrasting it with encryption algorithms.

ICMP (Internet Control Message Protocol), per RFC 792, handles diagnostics (e.g., ping) and errors in IP networks. It’s exploitable in:

A. Ping of Death:

Method: Sends oversized ICMP Echo Request packets (>65,535 bytes) via fragmentation. Reassembly overflows buffers, crashing older systems (e.g., Windows 95).

Fix: Modern OSes cap packet size (e.g., ping -s 65500).

B. Smurf Attack:

Method: Spoofs ICMP Echo Requests to a network’s broadcast address (e.g., 192.168.255.255). All hosts reply, flooding the victim.

Amplification: 100 hosts = 100x traffic.

C. ICMP Flooding:

Method: Overwhelms a target with ICMP Echo Requests (e.g., ping -f), consuming bandwidth/CPU.

Variant: BlackNurse attack targets firewalls.

Technical Details:

ICMP Type 8 (Echo Request), Type 0 (Echo Reply) are key.

Mitigation: Rate-limit ICMP, disable broadcasts (e.g., no ip directed-broadcast).

Security Implications:ICMP attacks are DoS vectors. CNSP likely teaches filtering (e.g., iptables -p icmp -j DROP) balanced with diagnostics need.

Why other options are incorrect:

A, B, C individually:All are ICMP-based; D is comprehensive.

Real-World Context:Smurf attacks peaked in the 1990s; modern routers block them by default.References:CNSP Official Study Guide (Network Attacks); RFC 792 (ICMP).

SSH (Secure Shell), per RFC 4251, uses asymmetric cryptography (e.g., RSA, ECDSA) for secure authentication:

Key Pair:

Public Key:Freely shareable, used to encrypt or verify.

Private Key:Secret, used to decrypt or sign.

Process:

User generates a key pair (e.g., ssh-keygen -t rsa -b 4096).

Public Keyis uploaded to the server, appended to ~/.ssh/authorized_keys (e.g., via ssh-copy-id).

Private Key(e.g., ~/.ssh/id_rsa) stays on the user’s machine.

Authentication: Client signs a challenge with the private key; server verifies it with the public key.

Technical Details:

Protocol: SSH-2 (RFC 4253) uses a Diffie-Hellman key exchange, then public-key auth.

Files: authorized_keys (server, 0644 perms), private key (client, 0600 perms).

Security: Private key exposure compromises all systems trusting the public key.

Security Implications:CNSP likely stresses key management (e.g., passphrases, rotation) and server-side authorized_keys hardening (e.g., PermitRootLogin no).

Why other options are incorrect:

B:Uploading the private key reverses the model, breaking security—anyone with the server’s copy could authenticate as the user. Asymmetric crypto relies on the private key remaining secret.

Real-World Context:GitHub uses SSH public keys for repository access, with private keys on user devices.References:CNSP Official Documentation (SSH Security); RFC 4253 (SSH Authentication Protocol).

Network segmentation isolates network zones for security, but certain techniques can circumvent these controls, a focus of CNSP penetration testing.

Why D is correct:

A:DNS tunneling encodes data in DNS queries, bypassing segmentation via legitimate DNS traffic.

B:VLAN hopping exploits switch misconfigurations (e.g., double tagging) to access other VLANs.

C:Covert channels use hidden communication paths (e.g., timing channels) to evade segmentation.All are valid techniques per CNSP for testing segmentation controls.

Why other options are incomplete:A, B, or C alone exclude other viable methods, making D the comprehensive answer.

References:CNSP "Penetration Testing Techniques" (Section on Network Segmentation Bypass) lists DNS tunneling, VLAN hopping, and covert channels as effective methods.

Online attacks require real-time interaction with a target system (e.g., a login interface), whereas offline attacks occur without direct system interaction, typically after obtaining data like password hashes. A rainbow table attack is an offline method that uses precomputed tables of hash values to reverse-engineer passwords from stolen hash databases, distinguishing it from the other options, which are online.

Why B is correct:Rainbow table attacks are performed offline after an attacker has already acquired a hash (e.g., from a compromised database). The attacker matches the hash against precomputed tables to find the plaintext password, requiring no interaction with the target system during the attack. CNSP classifies this as an offline password recovery technique.

Why other options are incorrect:

A:Brute force attacks involve repeatedly submitting password guesses to a live system (e.g., via SSH or a web login), making it an online attack.

C:Password spraying attacks test a few common passwords across many accounts on a live system, also an online attack aimed at avoiding lockouts.

D:Phishing attacks trick users into submitting credentials through fake interfaces (e.g., emails or websites), requiring real-time interaction and thus classified as online.

References:CNSP "Password Attack Methodologies" (Section on Online vs. Offline Attacks) defines rainbow table attacks as offline and contrasts them with online methods like brute force and phishing.

SNMP community strings authenticate access, with defaults posing security risks if unchanged.

WhyCis correct:

A:"public" is the standard read-only default, per SNMP specs and CNSP.

B:"private" is the standard read-write default, also per SNMP and CNSP.Both are true, makingCthe answer.

Why other options are incorrect:

1, 2:Exclude one true statement each.

4:Both statements are true, so "none" is wrong.

References:CNSP "SNMP Security" (Section on Defaults) confirms "public" and "private" as standard community strings.

A DNS zone transfer replicates an entire DNS zone (a collection of DNS records for a domain) from a primary nameserver to a secondary one, typically for redundancy or load balancing. TheAXFR(Authoritative Full Zone Transfer) query type, defined in RFC 1035, facilitates this process. The dig (Domain Information Groper) tool, a staple in Linux/Unix environments, is used to query DNS servers. The correct syntax is:

dig @ axfrHere, dig @10.0.0.1 victim.com axfr instructs dig to request a zone transfer for "victim.com" from the nameserver at 10.0.0.1. The @ symbol specifies the target server, overriding the system’s default resolver.

Technical Details:

The AXFR query is sent over TCP (port 53), not UDP, due to the potentially large size of zone data, which exceeds UDP’s typical 512-byte limit (pre-EDNS0).

Successful execution requires the nameserver to permit zone transfers from the querying IP, often restricted to trusted secondaries via Access Control Lists (ACLs) for security. If restricted, the server responds with a "REFUSED" error.

Security Implications:Zone transfers expose all DNS records (e.g., A, MX, NS), making them a reconnaissance goldmine for attackers if misconfigured. CNSP likely emphasizes securing DNS servers against unauthorized AXFR requests, using tools like dig to test vulnerabilities.

Why other options are incorrect:

A. dig @10.0.0.1 victim.com axrfr:"axrfr" is a typographical error. The correct query type is "axfr." Executing this would result in a syntax error or an unrecognized query type response from dig.

B. dig @10.0.0.1 victim.com afxr:"afxr" is another typo, not a valid DNS query type per RFC 1035. dig would fail to interpret this, likely outputting an error like "unknown query type."

C. dig @10.0.0.1 victim.com arfxr:"arfxr" is also invalid, a jumbled version of "axfr." It holds no meaning in DNS protocol standards and would fail similarly.

Real-World Context:Penetration testers use dig ... axfr to identify misconfigured DNS servers. For example, dig @ns1.example.com example.com axfr might reveal subdomains or internal IPs if not locked down.References:CNSP Official Documentation (DNS Security and Tools); RFC 1035 (Domain Names - Implementation and Specification).