Wednesday, December 6, 2006

Thoughts on Traffic Analysis for Detecting DNS Covert Tunnels


Over at Infosec Potpourri Hanashi conjectures that a good way to catch DNS tunnels would be to keep a ratio of the number of bytes sent via a dns request vs the number of bytes in the response over time for the psuedo-session. If this ratio surpasses a given threshold say 2:1 then you need to investigate the host. I use the term psuedo-session as it is how SANCP the session tool from the Sguil suite of tools would group the data and Hanashi used the term first :).




The resulting equation looks like: (bytes in request / bytes in response) or vice versa depending upon if you're searching for data entering your network.



Off the top of my head there are two points that need to be addressed by this analysis.




  1. You can use multiple upstream resolvers

  2. The ratio is easily avoided by using CNAME records





CLNT Host 1 SVR Host 2
| DNS A record request |
|------------------------------------------------->|
| SVR DNS RESPONSE (1 ANSWER) |
|<-------------------------------------------------|
| |



The response is discarded as only the dns name before the subdomain.domain.tld in the A record request is data to be sent upstream. This is wasteful as you could use the response to squeeze out a few bytes but is done to keep the code simple.



Since all we care about to send data upstream is the part of the dns name before subdomain.domain.tld we can use any time of record including a CNAME. The CNAME can have multiple A records associated with this thus we can create more data in the downstream response then what we sent outbound.



Sending data up stream modified




CLNT Host 1 SVR Host 2
| DNS A record request |
|--------------------------------------------------> |
| SVR DNS RESPONSE (N ANSWERS) |
|<-------------------------------------------------- |
| |



Traffic analysis does show some promise though for detection. However one has to make sure that analysis is done at the one point that cannot be changed by the attacker their client endpoint. More to come on this topic in the future.

0 comments: