We have developed a set of defenses based on the detection of abnormal combinations of network events. For example, to detect the injection of a DNS reply, we use bookkeeping of request-reply pairs to flag excess, inconsistent replies. We also raise an alert when a host appears to retransmit requests after having received replies, so we can prevent a situation where the attacker keeps inserting a fake request, just before the legitimate reply for the previous request arrives, in order to maintain the request-response balance.
While there are no visible duplicate replies in case of a whisper attack, the AP may still detect the attack indirectly. A solution for HTTP is to extract from each HTTP connection the server hostname from the corresponding mandatory HTTP header and the server address from the IP header, and compare this pair against the hostname and IP pairs extracted from observed DNS replies. If a reply has been whispered, no DNS reply will match the HTTP header and the attack will be detected.
We have evaluated our technique for detecting whisper attacks against 41,426 DNS and 339,317 HTTP requests generated by 65 IP addresses over a period of a week. We obtained 18 alerts (6 unique web sites), all of them false, corresponding to a false positive rate of 0.53 × 10-4 of all HTTP requests. For the same trace we observed zero excess DNS replies. We further evaluated only our first technique for detecting excess DNS replies against 43,272,448 DNS requests obtained over a period of more than 1 month by instrumenting an enterprise network with about 400 users. We obtained 22 alerts, all of them false, corresponding to a false positive rate of 0.5 × 10-7. Looking deeper into the alerts revealed a Content Delivery Network that is employing spoofing, probably for server selection.
Once an attack is detected, it has to be blocked. However, given two inconsistent DNS responses, the detector cannot directly distinguish which one is legitimate and which one is spoofed. Doing a secondary lookup is one option, but the wide use of load balancing, particularly for popular services, implies that the secondary lookup may not always agree with one of the two inconsistent responses. A more relaxed check against the network prefix is also unlikely to help in the general case, as server replicas may not be co-located. In lack of any other satisfactory solution, our current implementation blocks the victim and redirects him to a warning page, notifying him of a potential spoofing attack, and giving him the option to proceed (and re-issue the request) through temporary HTTP redirection.