Infoblox Reporting and Analytics for Security

    Recently Infoblox released a new version of our reporting solution, which we renamed “Infoblox Reporting and Analytics”. The solution is based on the Splunk engine and delivers an enhanced reporting interface so now you can create custom dashboards, reports, and alerts. This gives you unlimited possibilities to analyze data and mine invaluable knowledge about your network.

    In this post I’ll show how to extract information about security events from the reporting database and build custom reports.

In the beginning was the data model…

   Each dashboard allows to drill downs to the Search tab and explores the raw data. This is the best way to educate yourself about reporting’s possibilities. Unfortunately, the NIOS 7.3.0 Administrator Guide doesn’t yet provide full details about where and how data are stored in a database so this is why it is very important to review.

   There are two types of events stored in the database: raw events and summary/aggregated events. Raw events can contain low-level aggregated data. Because of the quantity of events that can be generated, some events are aggregated (summarized) on the appliance before sending it to the reporting server. These summary events are aggregated on the reporting server and contain less details. Summary events usually are stored in the indexes with “_summary” suffix in the name. E.g. “ib_dns” index contains raw events and “ib_dns_summary” contains aggregated data. This gives you a possibility of managing database size effectively and do not loose the history.

   The table below contains descriptions of the “security” events in the database.

Search string Field Description

DNS Firewall and Analytics events

Raw events:

Summary events:

host (index=ib_dns) orig_host (index=ib_dns_summary) Hostname of DNS server
CLIENT Client IP address
DOMAIN_NAME Requested domain name
RPZ_QNAME DNS Firewall rule
RPZ_SEVERITY Severity level
TOTAL_COUNT Count of times the rule was hit
VIEW DNS view internal name
display_name DNS view display name

External DNS Security/Advanced DNS Protection (ADP) events

index=ib_security source=ib:ddos:ip_rule_stats host (index=ib_security) Hostname of DNS server
ACTIVE_COUNT Count of events
NAT_STATUS Indicate if the client is behind NAT activated
BLOCK_START NAT ports start range
BLOCK_END NAT ports end range
RULE_DESCRIPTION Description why the alert was generated or packet was dropped
RULE_NAME Rule name
SOURCE_IP Client IP address
SOURCE_PORT Source port from which the packet(s) was sent
host Hostname of DNS server
ACOUNT Count of alerts generated by the rule
DCOUNT Count of the dropped packets by the rule
CATEGORY Category of the rule
MESSAGE Rule name

    The analytics engine utilizes DNS Firewall in order to block communications. This is why events from Analytics are stored with DNS Firewall events.

Let’s create some dashboards

  • ADP and DNS Firewall correlation

Since you now know where data are stored and we can start building custom reports. Lets start from the simple search:

    This search selects DNS Firewall events and joins ADP events by source IP. A resulting table shows simple events correlation and contains list of the IP addresses and count of events blocked by ADP and DNS Firewall simultaneously (during the search period).



    The report, which is posted here, contains drill-down possibilities, so if you click on any number in ADP or DNSFW column a report related to these events will be opened.

  • L2 domains blocked on DNS Firewall

    This search shows domains that were blocked on DNS Firewall. Simple regex extracts only L2 domains, so this report can help you quickly identify threats and false positives.


  • IPAM blacklisted networks

This simple search checks if networks registered in IPAM were compromised.



    You saw how simple it to create a new dashboards/reports or mine the data using searches. If you have any other questions regarding the reporting solution or created a dashboard, which you want to share with public, please post your messages on the reporting forum of the community site.

Vadim Pavlov