![]() ![]() On Infoblox, Domain Name System Security Extension (DNSSEC) Zone Signing Keys (ZSKs) are stored on either a Hardware Security Module or the Infoblox Grid Master. The private key corresponding to the KSK (KSK-private) can still be kept offline. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) must have both the zone file master copy and the private key corresponding to the ZSK (ZSK-private) online to immediately update the signatures for the updated resource record (RR) sets. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. If possible, the private keys should be stored offline (with respect to the internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. | eval first3=mvindex(first3, 0, 2) |eval first3=mvjoin('first3',".The private keys in the Key Signing Key (KSK) and ZSK key pairs must be protected from unauthorized access. | append [search index=* sourcetype=ib:syslog CEF: $members$ $rpz_zone_str$ $domain_name_str$ earliest=-192h latest=-144h Index=* sourcetype=ib:syslog CEF: $members$ $rpz_zone_str$ $domain_name_str$ | table Query,QuerySourceName,RPZHit,QueryType,QuerySourceQuer圜ount,Quer圜ount ![]() | stats count as QuerySourceQuer圜ount values(Time) as Time values(QueryType) as QueryType values(RPZHit) as RPZHit values(Quer圜ount) as Quer圜ount values(QuerySource) as QuerySource by Query | stats Count as Quer圜ount values(*) as * by Query | eval KeepFields = _time + "::" + QuerySource + "::" + QueryType + "::" + RPZHit | table QuerySourceName,facility,Query,Time,QueryType,RPZHit,QuerySourceQuer圜ount,Quer圜ount | lookup subnettosite first3subnet as first3 | eval QuerySourceName=coalesce(QuerySourceName,QuerySource) | lookup dnslookup clientip as QuerySource output clienthost as QuerySourceName | stats count as QuerySourceQuer圜ount values(Time) as Time values(QueryType) as QueryType values(RPZHit) as RPZHit values(Quer圜ount) as Quer圜ount by QuerySource,Query | stats Count as Quer圜ount values(*) as * by QuerySource | eval KeepFields = _time + "::" + Query + "::" + QueryType + "::" + RPZHit Index=* sourcetype=ib:syslog CEF: $members$ $rpz_zone_str$ $domain_name_str$ $IBMembers$ Index=ib_dns_summary report=si_dns_rpz_hits It would greatly increase the supportability of this solution. If anyone finds a way to easily do a CIDR match in Infoblox’s Splunk, let me know. Before I import the CSV lookup table, I take any network that is larger than a /24 and list all the /24’s in it, duplicating the data. The code before the CSV lookups are a hack as there is no CIDR lookup option in Infoblox’s version of Splunk so I just match on the first 3 octects. It again is generated using the CSV lookup tables of our internal network to get to a physical location, latitude and longitude. The Geo Map is just the eye candy that can be exported and put up on a monitor in a NOC or “manager” report. The facility column in our case gets us to a physical location and local contact so this report can be further parsed to go directly to a regional or local security team if desired. The headings in the screen shots should be self-explanatory. The radio button to exclude Infoblox member will remove this noise from the reports. If you have forwarder chains in your Infoblox grid, you may have forwarded queries showing up multiple times depending on how your RPZ’s are scanning forwarded queries. I left this code in even though it is a custom CSV based lookup table as there is no direct way to get from the reporting tool to the networks’ EA's just to show what is possible. I've updated my RPZ syslog report to add in some more grouping options and add in the ability to match the IP back to our facility using the IPAM, Network EA's. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |