CNSP Exam Questions & Answers

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 Key is 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.

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. The AXFR (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 @<nameserver> <domain> axfr

Here, 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.

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.

In Unix-based systems (e.g., Linux), the ifconfig command is historically used to configure network interfaces, including changing the Media Access Control (MAC) address of an Ethernet adapter. The correct syntax to set a new MAC address for an interface like eth0 is ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF, where hw specifies the hardware address type (ether for Ethernet), followed by the new MAC address in colon-separated hexadecimal format.

Why A is correct: The hw ether argument is the standard and correct syntax recognized by ifconfig to modify the MAC address. This command temporarily changes the MAC address until the system reboots or the interface is reset, assuming the user has sufficient privileges (e.g., root). CNSP documentation on network configuration and spoofing techniques validates this syntax for testing network security controls.

Why other options are incorrect:

B: hdw is not a valid argument; it's a typographical error and unrecognized by ifconfig.

C: hdwr is similarly invalid; no such shorthand exists in the command structure.

D: hwr is incorrect; the full keyword hw followed by ether is required for proper parsing.

DNS cache poisoning, also known as DNS spoofing, involves an attacker injecting false DNS records into a resolver's cache, altering how domain names resolve.

Why A is correct: The primary risk is that an attacker can redirect users to malicious websites (e.g., phishing or malware sites) by poisoning the DNS cache with fake IP addresses. This can lead to credential theft, data exfiltration, or malware distribution. CNSP identifies this as the core threat of DNS cache poisoning, aligning with real-world attack vectors.

Why other option is incorrect:

B . Manipulate the cache of the web server or proxy server: This describes web cache poisoning, a different attack targeting HTTP caches, not DNS servers. DNS cache poisoning affects DNS resolution, not web or proxy server caches directly.