Am I Sending Traffic to a "Sinkhole"?
Last Updated: 2013-11-18 17:56:45 UTC
by Johannes Ullrich (Version: 1)
It has become common practice to setup "Sinkholes" to capture traffic sent my infected hosts to command and control servers. These Sinkholes are usually established after a malicious domain name has been discovered and registrars agreed to redirect respective NS records to a specific name server configured by the entity operating the Sinkhole. More recently for example Microsoft gained court orders to take over various domain names associated with popular malware.
Once a sinkhole is established, it is possible for the operator of the sinkhole to collect IP addresses from hosts connecting to it. In many cases, a host is only considered "infected" if it transmits a request that indicates it is infected with a specific malware type. A simple DNS lookup or a connection to the server operating on the sinkhole should not suffice and be considered a false positive.
The data collected by sinkholes is typically used for research purposes, and to notify infected users. How well this notification works depends largely on the collaboration between the sinkhole operator and your ISP.
On the other hand, you may want to proactively watch for traffic directed at sinkholes. However, there is no authoritative list of sinkholes. Sinkhole operators try not to advertise the list in order to prevent botnet operators from coding their bots to avoid sinkholes, as well as to avoid revenge DoS attacks against the networks hosting sinkholes. Some ISPs will also operate their own Sinkholes and not direct traffic to "global" sinkholes to ease and accelerate customer notification.
And of course, you can always setup your own sinkhole, which is probably more effective then watching for traffic to existing sinkholes: See Guy's paper for details http://www.sans.org/reading-room/whitepapers/dns/dns-sinkhole-33523
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Nov 18th 2013
9 years ago
With a RPZ you can control what the response to certain queries will be. So instead of merely blocking a domain from resolving you can make it resolve to something else, but even better, you can also rewrite the query response based on the IP it normally resolves to. For instance, when I see someone hit a malicious URL I'll not only drop the hostname and/or domain into my RPZ to block it, I'll look up the IP as well and possibly drop in a rule to block all other hostnames that resolve to that IP or even that whole subnet.
So in addition to fetching a list of known untrustworthy domains, I also fetch a list of known compromised or hostile IPs and block any hostnames that resolve to those IPs from resolving as well.
I also log all these rewrites and use a tool called "oak" to watch the logs for specific rewrites. Some rewrites get summarized and emailed to desktop support once a day for systems doing queries on behalf of various spyware. Other rewrites cause an immediate alert to be sent because someone's system is querying for any of a list of domains (or hosts resolving to certain IPs) known to be used by.... certain parties - basically, when I know a particular query is an indication of a compromised system.
The RPZ feature is also great for rewriting all the queries for whatever.pool.ntp.org to your own in-house NTP servers, assuming you have them and would rather people use them instead of sending NTP queries to ... who knows where... often to IPs that snort or other tools flag as traffic to/from compromised systems or to/from IPs under the control of the Russian Business Network. :-)
Nov 18th 2013
9 years ago
Nov 20th 2013
9 years ago