Chapter 1.1 Quiz Network Architecture & Attack Surfaces
Quiz Mode All answers are hidden under collapsible sections. Attempt each question before revealing the answer.
Question 1
An attacker on the same LAN segment sends unsolicited ARP replies claiming that the gateway's IP (192.168.1.1) resolves to the attacker's MAC address. Hosts on the segment begin routing all traffic through the attacker's machine. Which layer of the OSI model is being exploited, and what is the primary reason this attack is effective?
Reveal Answer & Explanation
Answer: Layer 2 Data Link Layer
Explanation:
ARP operates at Layer 2 (Data Link). The attack is effective because:
- ARP is stateless hosts accept and cache ARP replies even if they never sent a request (gratuitous ARP). There is no challenge-response mechanism.
- No authentication there is no cryptographic binding between an IP address and a MAC address at Layer 2. Any host can claim any IP.
- Broadcast domain trust all hosts on the same VLAN receive and process ARP broadcasts.
Impact chain: Layer 2 compromise → all higher-layer encryption (TLS at L4-L7) becomes ineffective for confidentiality because the attacker controls the routing before the encrypted channel even begins.
Detection commands:
# Watch ARP table for changes (Linux)
watch -n 1 arp -n
# Detect ARP poisoning with arpwatch
arpwatch -i eth0
# Check ARP cache for duplicate MACs (multiple IPs sharing same MAC)
arp -n | awk '{print $3}' | sort | uniq -d
Mitigation: Dynamic ARP Inspection (DAI) on Cisco switches validates ARP packets against the DHCP snooping binding table:
Switch(config)# ip arp inspection vlan 10
Switch(config-if)# ip arp inspection trust ! on uplinks only
Question 2
You run the following Nmap command against a target: nmap -sS -sV -p 22,80,443,445 10.0.0.50 and receive the following output:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.4 (protocol 2.0)
80/tcp open http Apache httpd 2.4.6
443/tcp filtered https
445/tcp open microsoft-ds Windows Server 2008 R2 microsoft-ds
What does filtered mean for port 443, and what security concern does the SMB result raise that you should investigate immediately?
Reveal Answer & Explanation
Answer: Filtered = firewall dropping packets; SMB on Server 2008 R2 = likely EternalBlue (MS17-010) vulnerable.
Explanation filtered state:
In an Nmap SYN scan:
openSYN-ACK received: service is listeningclosedRST received: port reachable but nothing listeningfilteredno response or ICMP unreachable received: a firewall, ACL, or host-based filter is silently dropping packets
filtered does NOT mean the service isn't running it means something in the path is blocking the probe. This is actually the correct behavior for a firewall.
SMB on Windows Server 2008 R2:
Windows Server 2008 R2 running SMB (port 445) is a critical red flag:
- Microsoft ended mainstream support in 2013, extended support in 2020
- CVE-2017-0144 (EternalBlue / MS17-010) remote code execution via SMBv1, no authentication required
- This vulnerability was used by WannaCry and NotPetya ransomware to propagate globally
Immediate validation:
# Check if target is vulnerable to EternalBlue
nmap --script smb-vuln-ms17-010 -p 445 10.0.0.50
# Check SMB version support
nmap --script smb-protocols -p 445 10.0.0.50
# Using Metasploit for validation (authorized test only)
use auxiliary/scanner/smb/smb_ms17_010
set RHOSTS 10.0.0.50
run
Expected vulnerable output:
Host is VULNERABLE to MS17-010! - Windows Server 2008 R2 SP1 x64
Remediation priority: CRITICAL patch immediately or isolate the host.
Question 3
A developer tells you "we don't expose SSH externally, so our SSH service on port 22 doesn't need key-based authentication password auth is fine." Explain why this reasoning is flawed, referencing at least two distinct attack scenarios.
Reveal Answer & Explanation
Answer: Perimeter-only thinking ignores internal threats and post-compromise lateral movement.
Explanation:
This is the classic implicit trust of the internal network fallacy. Here are the attack scenarios:
Scenario 1 Insider threat / compromised workstation
An attacker who has phished an employee or planted malware on a workstation is already inside the network. If SSH uses password auth and employees use weak or reused passwords:
# Attacker runs internal SSH brute force with Hydra
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.50
# Medusa for parallel SSH brute force
medusa -H hosts.txt -U users.txt -P passwords.txt -M ssh -t 4
Scenario 2 Credential stuffing from breached databases
Passwords from previous breaches (LinkedIn, Adobe, RockYou2021 8.4 billion entries) are used against internal SSH. Users who reuse passwords are immediately compromised.
Scenario 3 MITM on internal network
If ARP spoofing is active (see Q1), an attacker can intercept the SSH handshake. While SSH encrypts the session, password-based auth sends the password over the encrypted channel if the attacker presents a forged host key and the user accepts it (TOFU trust model), the password is captured.
SSH keys mitigate this: the private key never leaves the client. The authentication is a cryptographic proof of possession, not a secret transmitted over the network.
Correct SSH hardening:
# /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers deploy admin
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
# Restrict source IPs in firewall (even internally)
ufw allow from 10.0.1.0/24 to any port 22 # Only from management subnet
# Reload SSH config without dropping sessions
systemctl reload sshd
Key takeaway: Network location (internal vs. external) is not a security control. Defense in depth requires every service to be hardened independently.
Question 4
Given the following output from dig axfr @dns1.target.com target.com, what security misconfiguration is present, and what information can an attacker extract from it?
; <<>> DiG 9.16.1 <<>> axfr @dns1.target.com target.com
;; global options: +cmd
target.com. 3600 IN SOA dns1.target.com. hostmaster.target.com. ...
target.com. 3600 IN NS dns1.target.com.
target.com. 3600 IN NS dns2.target.com.
target.com. 3600 IN MX 10 mail.target.com.
www.target.com. 3600 IN A 203.0.113.10
mail.target.com. 3600 IN A 203.0.113.11
vpn.target.com. 3600 IN A 203.0.113.15
dev-internal.target.com. 3600 IN A 10.0.0.50
db01.target.com. 3600 IN A 10.0.0.100
staging-api.target.com. 3600 IN A 10.0.0.75
Reveal Answer & Explanation
Answer: Unrestricted DNS zone transfer (AXFR) the name server allows any host to download the entire zone.
Explanation:
A zone transfer (AXFR) is a mechanism for DNS secondary servers to replicate zone data from the primary. It should only be permitted to authorized secondary nameservers. When unrestricted, any attacker can download the complete DNS zone a full map of your infrastructure.
What the attacker learns from this output:
| Record | Revealed Information | Attack Value |
|---|---|---|
vpn.target.com → 203.0.113.15 | VPN endpoint IP | Target for credential stuffing, CVE scanning |
dev-internal.target.com → 10.0.0.50 | Internal dev server, private IP range | Confirms internal subnet 10.0.0.0/24 |
db01.target.com → 10.0.0.100 | Database server hostname and internal IP | High-value lateral movement target |
staging-api.target.com → 10.0.0.75 | Staging API server | Often less hardened than production |
hostmaster.target.com | Admin email address (in SOA) | Spear phishing target |
This output tells an attacker:
- The internal IP range:
10.0.0.0/24 - All internet-exposed services and their IPs
- Existence of a VPN endpoint (prime target)
- Database server naming convention and IP
- That there is a staging API (likely with weaker controls)
Remediation:
# Bind9: restrict zone transfer to secondary nameservers only
# /etc/bind/named.conf.options
acl "trusted-secondaries" {
203.0.113.20; # Secondary nameserver IP
203.0.113.21;
};
zone "target.com" {
type master;
file "/etc/bind/db.target.com";
allow-transfer { trusted-secondaries; }; # Restrict AXFR
allow-query { any; }; # Normal queries still work
};
# Verify fix: this should now return "Transfer failed"
dig axfr @dns1.target.com target.com
# Microsoft DNS: restrict zone transfers in DNS Manager
# Properties → Zone Transfers → Allow only to specific servers
DNSSEC does NOT prevent zone enumeration it only ensures authenticity. To prevent enumeration, NSEC3 with opt-out and zone transfer restrictions are both needed.