#Infoblox dns blackhole rpz mac#

(Although the Infoblox DNS Firewall – FireEye Adapter can help here, since it can inform DNS Firewall of malware-related domains and IP addresses that are identified internally and may not yet be known to commercial malware analysis firms.)Īlso, even with a known site Infoblox DNS Firewall cannot completely cut off DNS tunneling traffic, since by design the underlying RPZ technology applies its checks based on the DNS response and not on the DNS query-in other words, after a DNS query with tunneled data has already exited the network. As with ADP itself, DNS Firewall cannot completely eliminate the possibility of DNS tunneling: It works only with known malware sites, and cannot detect DNS tunneling done to a previously unknown site. Infoblox DNS Firewall also can play a role here, and can be deployed on Infoblox Advanced Appliances with ADP that are used as recursive resolvers.

The switch ports to which the infected PCs are connected (if Infoblox Network Insight is used to collect and collate network-related data).

#Infoblox dns blackhole rpz mac#

The MAC addresses of the infected PCs (if Infoblox is used for DHCP).The true source IP address of PCs that may be infected (if Infoblox is used for first-tier DNS resolution instead of Microsoft or some other DNS server).There can be a slow trickle of data exfiltration via DNS with ADP. So while ADP cannot completely eliminate use of DNS for data exfiltration, it can at least make it more difficult, and allow potential cases of DNS tunneling to be identified and investigated. As noted in the Advanced DNS Protection description:įor tunneling, Advanced DNS Protection drops the DNS tunneled queries with the ability to throttle so that legitimate usage of that DNS tunneling technique for AV updates, as an example, goes through. This is one of the things that Advanced DNS Protection is intended to address: If Infoblox Advanced Appliances with ADP (PT-1400, PT-2200, or PT-4000) are deployed inside the network to serve as recursive resolvers for internal DNS clients, then they can analyze DNS queries originating from PCs and other systems and identify signs that such queries are being used to exfiltrate data from the network.

In other words, they didn’t have much visibility into what was going on with DNS, and didn’t have any real way to detect and mitigate the use of DNS to tunnel malware-related traffic back to the attackers. We could see it was doing a lot of the work, but we couldn’t see it was actually leaving the organization. We never solved that problem, we were still looking when the engagement ended. So if they wrapped the stolen data up in outbound DNS packets, maybe. The only protocols that were allowed outbound were DNS. We were never able to figure out how they egressed the data. His recent “insider story” about an investigation into a security breach at a retailer (similar to the recently-publicized attack on the point-of-sale systems at Target), titled “ These Guys Battle BlackPOS at a Retailer,” includes this interesting paragraph.

Very valuable insights on DNS deployment to stop data exfiltration via DNS.įirst, if you’re not reading Brian Krebs’ blog “ KrebsonSecurity,” you should be it’s one of the best, if not the best, sources of news about real-life criminal hackers and their attacks. A great write up by one of Infoblox’s technical experts, Frank Hecker that I wanted to share as a blog.