{"id":2848,"date":"2016-02-10T17:59:18","date_gmt":"2016-02-10T17:59:18","guid":{"rendered":"https:\/\/live-infoblox-blog.pantheonsite.io\/?p=2848"},"modified":"2020-05-06T10:30:05","modified_gmt":"2020-05-06T17:30:05","slug":"infoblox-reporting-and-analytics-for-security","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/community\/infoblox-reporting-and-analytics-for-security\/","title":{"rendered":"Infoblox Reporting and Analytics for Security"},"content":{"rendered":"

Recently Infoblox released a new version of our\u00a0reporting solution, which we renamed \u201cInfoblox Reporting and Analytics\u201d. 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\u00a0gives you unlimited possibilities to analyze data and mine invaluable knowledge about your network.<\/p>\n

In this post I\u2019ll show how to extract information about security events from the reporting database and build custom reports.<\/p>\n

In the beginning was the data model\u2026<\/strong><\/p>\n

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\u2019t yet provide full details about where and how data are stored in a database so this is why it is very important to review.<\/p>\n

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\u00a0can 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 \u201c_summary\u201d suffix in the name. E.g. \u201cib_dns\u201d index contains raw events and \u201cib_dns_summary\u201d contains aggregated data. This gives you a possibility of managing database size effectively and do not loose the history.<\/p>\n

The table below contains descriptions of the \u201csecurity\u201d events in the database.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Search string<\/center><\/td>\n
Field<\/center><\/td>\n
Description<\/center><\/td>\n<\/tr>\n<\/thead>\n
DNS Firewall and Analytics events<\/strong><\/center><\/td>\n<\/tr>\n
Raw events:<\/p>\n

index=ib_dns source=”ib:dns:query:top_rpz_hit”<\/p>\n

Summary events:<\/p>\n

index=ib_dns_summary source=”si-search-dns-rpz-hits”<\/td>\n

host (index=ib_dns)
\norig_host (index=ib_dns_summary)<\/td>\n		Hostname of DNS server<\/td>\n<\/tr>\n
CLIENT<\/td>\nClient IP address<\/td>\n<\/tr>\n
DOMAIN_NAME<\/td>\nRequested domain name<\/td>\n<\/tr>\n
MITIGATION_ACTION<\/td>\nNX – NXDOMAIN<\/td>\n<\/tr>\n
RPZ_QNAME<\/td>\nDNS Firewall rule<\/td>\n<\/tr>\n
RPZ_SEVERITY<\/td>\nSeverity level<\/td>\n<\/tr>\n
TOTAL_COUNT<\/td>\nCount of times the rule was hit<\/td>\n<\/tr>\n
VIEW<\/td>\nDNS view internal name<\/td>\n<\/tr>\n
display_name<\/td>\nDNS view display name<\/td>\n<\/tr>\n
External DNS Security\/Advanced DNS Protection (ADP) events<\/strong><\/center><\/td>\n<\/tr>\n
index=ib_security source=ib:ddos:ip_rule_stats<\/td>\nhost (index=ib_security)<\/td>\nHostname of DNS server<\/td>\n<\/tr>\n
ACTIVE_COUNT<\/td>\nCount of events<\/td>\n<\/tr>\n
NAT_STATUS<\/td>\nIndicate if the client is behind NAT activated<\/td>\n<\/tr>\n
BLOCK_START<\/td>\nNAT ports start range<\/td>\n<\/tr>\n
BLOCK_END<\/td>\nNAT ports end range<\/td>\n<\/tr>\n
RULE_DESCRIPTION<\/td>\nDescription why the alert was generated or packet was dropped<\/td>\n<\/tr>\n
RULE_NAME<\/td>\nRule name<\/td>\n<\/tr>\n
RULE_SID<\/td>\nRule ID<\/td>\n<\/tr>\n
SOURCE_IP<\/td>\nClient IP address<\/td>\n<\/tr>\n
SOURCE_PORT<\/td>\nSource port from which the packet(s) was sent<\/td>\n<\/tr>\n
index=ib_security source=ib:ddos:events<\/td>\nhost<\/td>\nHostname of DNS server<\/td>\n<\/tr>\n
ACOUNT<\/td>\nCount of alerts generated by the rule<\/td>\n<\/tr>\n
DCOUNT<\/td>\nCount of the dropped packets by the rule<\/td>\n<\/tr>\n
CATEGORY<\/td>\nCategory of the rule<\/td>\n<\/tr>\n
MESSAGE<\/td>\nRule name<\/td>\n<\/tr>\n
SEVERITY<\/td>\nSeverity<\/td>\n<\/tr>\n
SID<\/td>\nRule ID<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The analytics engine utilizes DNS Firewall in order to block communications. This is why events from Analytics are stored with DNS Firewall events.<\/p>\n

Let\u2019s create some dashboards<\/strong><\/p>\n