InfoBlox has updated the software powering its DNS appliance on Monday, releasing version 4.3 r2. The new rev makes your DNS infrastructure more resistant to DNS cache poisoning attacks by detecting and optionally reacting to the attack in real time. InfoBlox also added a run-time environment to the platform allowing users to create and run custom applications on the appliance. With this release, InfoBlox is setting the standard for IPAM appliances. Both features are available now.

DNS cache poisoning hit public awareness with the now infamous cache poisoning problem discovered by Dan Kaminsky of IOActive. DNS server's cache DNS address resolution "the IP addresses assigned to a hostname—responses from other DNS servers to avoid having to continually resolve a host name. Cache poisoning occurs when incorrect address resolution records are inserted into a DNS server.

Kaminsky discovered a design flaw in the DNS protocol which allows an unpatched DNS server to be tricked into storing name resolution records of the attackers choosing. For example, an attacker could redirect all users to amazon.com to a fake web site. All major DNS server software have patches available which make the attack much more difficult, but not impossible, to carry out.

InfoBlox's DNS firewall detects this attack based on behavior. The attacker has to guess two things to poison a DNS server. The first is the DNS transaction-ID that is used to match DNS responses to DNS requests. The second component is to guess which UDP source port the DNS server used to make the request. If the attacker can guess these two things correctly and get their response to the DNS server first, then the attack is successful.

The DNS cache poisoning attack is launched by getting the DNS server to request a name lookup and then firing lots of responses. In an unpatched DNS server, the cache can be poisoned in under a minute with a few thousand responses. A patched DNS server can still be poisoned in less than a day with millions of responses, but the bandwidth required makes such an attack over the Internet unlikely to succeed. The cache poisoning attack exhibits a high rate of unknown transaction-ID's and unknown UDP source port numbers, in the hundreds per second ,or more, indicate an attack is underway. InfoBlox's DNS firewall detects this behavior as malicious and can send an alert or simply rate limit requests from the offending host or network.

Granted, the likelihood of successfully poisoning a patched DNS server from across the Internet is unlikely just because of the bandwidth required to pull it off isn't available. However, an internal attacker has greater network capacity to work with and success is more likely. InfoBlox's DNS firewall strengthens protections from both internal and external attacks.

Building Blox

InfoBlox bloxTools is a sandbox running on the InfoBlox appliance which lets users develop custom applications to interact with the appliance. The bloxTools Runtime Environment (BRE), contains a web server and support for several common scripting languages and tools such as Perl, PHP, Python, CGI, and a scheduler. Applications written for BRE are called snap-ins. Using InfoBlox's API, snap-ins can interact with the appliance performing any action in the GUI through a script.

Snap-ins can also be shared and Infoblox is building a developer site to support bloxTools development and to share snap-ins among users. Rather than letting users post any snap-in, submissions will be analyzed and approved by InfoBlox before being available to the public which provides some assurance that snap-ins are not malicious.

A few snap-ins written by InfoBlox will be available for down load. GeoViewer uses address information assigned to each InfoBlox appliance and plots the location on Google Maps along with status information. Scheduler provides a GUI interface to schedule events. Reporting generates historical reports and integrates with the GeoViewer snap-in. Since the snap-ins are running on appliances, they get all the benefits of InfoBlox's grid technology such as high availability, easy distribution, and management.

The only feature missing from bloxTools we'd like to see is an event driven automation. Rather than writing a script that is run periodically, we'd like to be able to write a script that is executed based on an InfoBlox event. For example, we might want to fire off an alert when a new host makes a DHCP request. We could schedule a script to do the same thing, but a real-time event system would be more efficient.