5.2.3. Wireless and Mobile Network Security
💡 First Principle: DNS is the phone book of the internet — it translates human-readable names into machine-routable IP addresses. Every internet-facing service depends on DNS. Because DNS was designed without authentication, malicious DNS responses can redirect any traffic to any destination — making DNS a high-value attack target that most organizations under-protect.
DNS operation:
- Client queries local DNS cache
- If not cached → queries recursive resolver (usually ISP or 8.8.8.8)
- Recursive resolver queries root nameservers → TLD nameservers → authoritative nameservers
- Authoritative nameserver returns answer; recursive resolver caches with TTL
DNS attack types:
| Attack | Mechanism | Impact | Defense |
|---|---|---|---|
| DNS Cache Poisoning | Inject fraudulent records into resolver cache | Redirect users to attacker-controlled IP | DNSSEC; randomize source port/query ID |
| DNS Hijacking | Compromise resolver or registrar to change authoritative records | Redirect entire domain's traffic | Registrar lock; MFA on registrar; monitor DNS records |
| DNS Tunneling | Encode data in DNS queries/responses to exfiltrate or C2 | Data exfiltration bypassing firewall | DNS traffic analysis; block unusual DNS patterns; RPZ |
| DDoS via DNS amplification | Small query generates large response; source IP spoofed to victim | Amplified flood attack against victim | BCP38 source address validation; response rate limiting (RRL) |
| NXDOMAIN attack | Flood with random subdomain queries | Exhaust resolver/authoritative server | Rate limiting; QNAME minimization |
DNSSEC (DNS Security Extensions):
DNSSEC adds cryptographic signatures to DNS records — the authoritative nameserver signs its records with a private key, and resolvers can validate with the corresponding public key. Provides:
- Origin authentication: Record came from the authoritative source
- Data integrity: Record was not modified in transit
DNSSEC does NOT provide confidentiality — DNS queries and responses remain visible. DoH (DNS over HTTPS) and DoT (DNS over TLS) provide confidentiality by encrypting DNS queries.
DoH vs. DoT:
| Feature | DNS over HTTPS (DoH) | DNS over TLS (DoT) |
|---|---|---|
| Port | 443 (same as HTTPS) | 853 (dedicated) |
| Filtering visibility | Difficult — blends with HTTPS traffic | Easy — dedicated port allows blocking |
| Privacy | Same as DoT | Same as DoH |
| Use case | Browser-level, bypasses network-level DNS control | Network/OS-level, admin-visible |
Other network service security:
DHCP snooping: DHCP is unauthenticated — an attacker can run a rogue DHCP server and hand out malicious gateway/DNS settings to clients. DHCP snooping on switches marks specific ports as trusted (legitimate DHCP server connected) and untrusted (client ports). DHCP responses from untrusted ports are dropped.
SNMP security:
| Version | Security | Recommendation |
|---|---|---|
| SNMPv1 | Plaintext community strings | ❌ Deprecated — community strings trivially intercepted |
| SNMPv2c | Plaintext community strings (improved efficiency) | ❌ Deprecated — same problem |
| SNMPv3 | Authenticated + encrypted (SHA + AES) | ✅ Only acceptable version |
NTP security: Time synchronization is critical for log correlation, certificate validity, and Kerberos authentication (5-minute clock skew tolerance). NTP attacks (time shifting) can invalidate certificates, break Kerberos, and corrupt log timestamps. Use authenticated NTP (NTPv4 with MD5/SHA or hardware time sources).
⚠️ Exam Trap: DNS tunneling — encoding data in DNS queries to bypass firewalls — is a common data exfiltration and command-and-control technique because most firewalls allow outbound DNS traffic. Detecting DNS tunneling requires DNS traffic analysis looking for: unusually long hostnames, high query rates to unusual domains, non-standard record types (TXT), or large response payloads for A records. A firewall rule blocking all DNS except to approved resolvers is a necessary (though not sufficient) control.
Reflection Question: A security operations analyst notices that one internal workstation is generating thousands of DNS queries per hour to a domain registered three weeks ago, using long, random-looking subdomains. The queries are all A record requests returning valid IP addresses, but the domain has no web presence. What attack is most likely occurring, what data is at risk, and what three controls would detect or prevent it?
