DHCP and NTP Risks
The services that hand out addresses and set the clock decide who you trust.
What you will learn
- -Explain how a rogue DHCP server becomes a man in the middle
- -Show why a wrong clock quietly breaks authentication and TLS
- -Spot the signs of DHCP and NTP abuse on a network you defend
Two services run so quietly that most people forget they exist, and both hand out something every other trusts without checking. tells a machine its address, its gateway, and which to ask. NTP tells it what time it is. Corrupt either one and you have not broken a single application directly, yet you have compromised all of them.
Rogue DHCP: owning the defaults
When a laptop joins a , it shouts a DHCPDISCOVER to the broadcast address asking for configuration. Whatever server answers first with a DHCPOFFER usually wins. There is no in that exchange. The believes the first plausible answer.
Stand up your own DHCP server on the same segment and race the legitimate one, and you to dictate the winning client's settings. The two fields that matter to an attacker are the and the DNS server. Set the gateway to your box and every the victim sends off- routes through you. Set the DNS server to your box and you answer every name lookup they make, which folds the whole previous lesson's poisoning problem into a single handout.
$ip route show default$cat /etc/resolv.conf$nmcli device show | grep -i dnsIf the gateway or DNS server on a client does not match what the network admin configured, that is the alarm. The fix on managed switches is DHCP snooping, which only trusts DHCP replies from a designated and drops offers from anywhere else. Without it, any on the can play server.
A rogue DHCP server does not politely target one victim. It answers whoever races fastest, and on a busy segment that can be dozens of unrelated machines whose traffic suddenly routes through you. Practice this only on an isolated lab network you fully own, never on shared or corporate wireless, because the collateral sweeps in people who were never part of your test.
Time is a security dependency
Nobody thinks of the clock as an attack surface until it drifts. Then things break in confusing ways, because a surprising amount of security assumes the time is roughly correct.
rejects tickets whose timestamp is off by more than a few minutes, five by default, to stop replay. Push a -joined machine's clock far enough and its authentication simply stops working. have a validity window; move the clock past a cert's expiry and validation fails, or move it back before a revoked cert's revocation and you might accept something you should not. two-factor codes are derived from the current time, so a skewed clock rejects valid codes. , forensic timelines, and log correlation all lean on synchronized time to line events up.
NTP is what keeps clocks aligned, and classic NTP has no authentication either. A machine that trusts an attacker-controlled time source can be nudged. The subtle version is not slamming the clock to 1970, which is obvious, but easing it minutes at a time until Kerberos or a cert check quietly fails and someone blames a flaky server.
$chronyc trackingThe defense is boring and effective. Point every host at a small set of trusted internal NTP servers, block outbound NTP to arbitrary internet sources at the , and on clients whose offset jumps. A network where every machine agrees on the time within a second is one where the time-based attacks have nowhere to stand.
Which two DHCP-supplied values give a rogue server the most control over a victim's traffic?
A domain-joined workstation suddenly cannot authenticate, and its clock is nine minutes ahead of the domain controller. In one sentence, why does the login fail?
The account and are fine. Think about what Kerberos checks besides the .