Looking at the hoffmeister.be data (yes, our previously identified attacker fixed a typo in the TLD) and recent attempts at large-scale amplification attacks, I noticed a surprising absence of spoofed source addresses. My first thought was that the ISP forces the correct IP onto packets entering the network, but that is not common practice (illegal source address packets are dropped if you implement BCP38, SAVI and/or unicast RPF).
The Y-axes represents the percentage of all queries that we observe; 0.11 means that at the peak, close to 11% of our sample of the queries worldwide were made to this amplification domain with ANY query.
Any source address validation is more effective than the ThreatAvert amplification attack protection from the targets perspective. If the carrier network allows spoofed addresses and the target is within the carrier’s network, we do protect the target with Threat Avert. This should be a rare case. If the target is outside such a carrier’s network, a properly set up CacheServe will drop all spoofed queries and protect the target even without ThreatAvert. So why use ThreatAvert? More importantly, why are we still seeing the queries and why do we see large amounts of them even in otherwise protected networks?
It turns out home routers are the reason. A spoofed packet that is sent to a router with address translation (NAT) will in most cases be forwarded with the router’s outside address as source.
To test this I set up a UDP responder on a public system with netcat in a terminal window:
nc –4lu 5555
and for good measure listened to the traffic to that port. On a local system inside a NAT network I trick netcat to spoof a different address than the one assigned to the LAN interface:
ifconfig en0 alias 172.22.7.7 255.255.255.0
nc -u -s 172.22.7.7 public.example.com 5555
This allows me to enter characters on the local system and receive them on the public server, and vice versa. So to summarize, public server is public.example.com, local router WAN interface is 192.0.2.213, internal legitimate network address is 192.168.2.2 and internal spoofed address is 172.22.7.7. The home router knows nothing of the 172.22.7.0 network.
The result of the local system sending “test” to the local router with the spoofed source address 172.22.7.7:
15:24:20.661842 IP 172.22.7.7.51103 > public.example.com.5555: UDP, length 5
which the router gladly does network address translation for, and we see the following packet arrive at the public system:
15:24:20.716712 IP 192.0.2.213.51103 > public.example.com.5555: UDP, length 5
Typing a similar message on the public system is lost, since the local router lacks a route for the 172.22.7.0/24 network:
15:53:27.348626 IP public.example.com.5555 > 192.0.2.213.51103: UDP, length 5
with no traffic seen at the local machine.
It does however make it’s way back to the router where it is seen on the WAN interface:
15:53:27.401464 IP public.example.com.5555 > 172.22.7.7.51103: UDP, length 5
Had this been an amplification attack domain, the actual payload sent to (and dropped by) the home router would be around 4k per query, and you only need around 30 thousand of those queries per second to fill up a Gigabit link . If your subscribers are connected with anything less than that, they will be miserable much sooner.
So even when a carrier implements all best common practices, and configure our (or other) resolvers correctly, there is still a significant amount of amplification attack data bouncing around inside the carrier network. It’s not reaching it’s intended target but it bypasses all other countermeasures, still fills up internal links with useless traffic and effectively DoS-ing the carrier’s own (infected) customers. Ideally, home routers should not do NAT on addresses outside of the configured local network, but until that’s fixed by the manufacturers, ThreatAvert will limit the impact on both the network and the subscribers – and as an added benefit also identify infected clients that would otherwise be invisible.