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.
Raw events:
index=ib_dns source=”ib:dns:query:top_rpz_hit” Summary events: index=ib_dns_summary source=”si-search-dns-rpz-hits” |
host (index=ib_dns) orig_host (index=ib_dns_summary) |
Hostname of DNS server |
CLIENT | Client IP address | |
DOMAIN_NAME | Requested domain name | |
MITIGATION_ACTION | NX – NXDOMAIN | |
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 | |
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 | |
RULE_SID | Rule ID | |
SOURCE_IP | Client IP address | |
SOURCE_PORT | Source port from which the packet(s) was sent | |
index=ib_security source=ib:ddos:events | 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 | |
SEVERITY | Severity | |
SID | Rule ID |
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:
index=ib_dns_summary source="si-search-dns-rpz-hits" | rename CLIENT as SOURCE_IP | join SOURCE_IP [search index=ib_security source="ib:ddos:ip_rule_stats"] | table SOURCE_IP,ACTIVE_COUNT,TOTAL_COUNT | stats sum(ACTIVE_COUNT) as ADP, sum(TOTAL_COUNT) as DNSFW by SOURCE_IP | sort -ADP, -DNSFW
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.
index=ib_dns_summary source="si-search-dns-rpz-hits" | rex field=DOMAIN_NAME "^.*(\.|^)(?<l2domain>[^\.]+\..*)" | table l2domain, TOTAL_COUNT | stats sum(TOTAL_COUNT) as Matches by l2domain | sort -Matches
- IPAM blacklisted networks
This simple search checks if networks registered in IPAM were compromised.
index=ib_ipam sourcetype="ib:ipam:network" | dedup NETWORK | rex field=address "^(?<ip1>\d+\.)(?<ip2>\d+\.)(?<ip3>\d+\.)(?<ip4>\d+)$" | eval REQ=cidr.".".ip4.".".ip3.ip2.ip1."rpz-ip.cnc.rpz.infoblox.local" | addthreatstopdetails rpzorip REQ | search short_description !="UNKNOWN"| table NETWORK, short_description , public_description
Conclusion
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