You can use the audit log, the replication status, the traffic capture tool, and the capacity report in a Grid or HA pair to monitor administrative activities and capture traffic for diagnostic purposes. You can also use CLI commands to monitor certain DNS transactions.
This section includes the following topics:

• Using the Audit Log
• Viewing the Replication Status
• Using the Traffic Capture Tool
• Using the Capacity Report
• Participating in the Customer Experience Improvement Program
• Monitoring DNS Transactions
• Viewing DNS Alert Indicator Status
• Configuring DNS Alert Thresholds

In addition, if Grid members manage Microsoft servers, Grid Manager creates a synchronization log file for each managed Microsoft server. For information, see Viewing Synchronization Logs.

Using the Audit Log

The audit log contains a record of all Infoblox administrative activities. It provides the following detailed information:

• Timestamp of the change. If you have different admin accounts with different time zone settings, the appliance uses the time zone of the admin account that you use to log in to the appliance to display the date and timestamp.
• Administrator name
• Changed object name
• New value of the object. If you change multiple properties of an object, the audit log lists all changes in a comma-separated log entry. You can also search the audit log to find the new value of an object.

The appliance logs the following successful operations:

• Logins to Grid Manager and the API.
• Logout events, including when users log out by clicking the Logout button, when the Grid Manager GUI times out, and when users are logged out due to an error.
• Write operations such as the addition, modification, and deletion of objects.
• System management operations such as service restarts and appliance reboots.
• Scheduled tasks such as adding an A record or modifying a fixed address.
• WAPI (RESTful API) session log information for each WAPI call, such as PUT, POST, and DELETE.

Enabling Audit Log Rolling

When the audit log reaches its maximum size, which is 100 MB, the appliance automatically writes the file into a new file by adding a .0 extension to the first file and incrementing subsequent file extensions by 1. Files are compressed during the rotation process, adding a .gz extension following the numerical increment (file.#.gz). The sequential incrementation goes from zero through nine. When the eleventh file is started, the tenth log file (file.9.gz) is deleted, and subsequent files are renumbered accordingly. For example, the current log file moves to file.0.gz, the previous file.0.gz moves to file.1.gz, and so on through file.9.gz. A maximum of 10 log files (0-9) are kept. To list the audit log files and their sizes, log in to the Infoblox CLI and execute the show logfiles command.
To enable audit log rolling:

1. From the Grid tab, select the Grid Manager tab -> Members tab, and then click Grid Properties -> Edit from the Toolbar.
2. In the Grid Properties editor, select the Security tab, and then select Enable Audit Log Rolling.

Specifying the Audit Log Type

Select Detailed (default), or Brief, or WAPI Detailed audit log type as follows:

1. From the Grid tab, select the Grid Manager tab -> Members tab, and then click Grid Properties -> Edit from the Toolbar.
   From the System tab, select the System Manager tab, and then click System Properties -> Edit from the Toolbar.
2. In the Grid Properties Editor, select the General tab, or in the System Properties Editor, click System tab, and then select one of the following:
   • Detailed: This is the default type. When you select this, Grid Manager displays detailed information on all administrative changes such as the timestamp of the change, administrator name, changed object name, and the new values of all properties in the logged message.
   • Brief: Provides information on administrative changes such as the changed object name and action in the log message. The logged message does not show timestamp or admin name.
   • WAPI Detailed: Select this option to view detailed RESTful API session information logs for successful WAPI calls such as PUT, POST, and DELETE. You can view the following session log information for each successful WAPI call:
     • URI: URI contains certain part of the incoming WAPI request. Example: version of WAPI and the associated object.
     • InData: InData contains input data fields of the incoming WAPI request. Example: Data field of the incoming WAPI request.
     • Response Time: Response time is calculated as the time difference between a WAPI request received and the response sent. 

This option helps you to troubleshoot and monitor performance issues that impact specific WAPI calls and track WAPI usage. When you select this option, you can view additional columns such as URI, InData and Response Time in the Audit log. 

The following example shows an audit log entry for a POST WAPI call: [2018-05-29 09:20:12.026Z] [admin]: Created(POST) v2.9/zone_auth {"fqdn":"foo.com"} 2.233 AuthZone foo.com DnsView=default: Set fqdn="foo.com"
In the example above:

• • • POST indicates the WAPI call
    • v2.9/zone_auth is the URI
    • {"fqdn":"foo.com"} represents InData
    • 2.233 is the response time.

Viewing the Audit Log

To view an audit log:

1. From the Administration tab, select the Logs tab -> Audit Log tab.
2. Optionally, use the filters to narrow down the audit log messages you want to view. Click Show Filters to enable the filters. Configure the filter criteria, and then click Apply.
   Based on your filter criteria (if any), Grid Manager displays the following in the Audit Log viewer:

• • Timestamp: The date, time, and time zone the task was performed. The time zone is the time zone configured on the member.
  • Admin: The admin user who performed the task.

• • Action: The action performed. This can be CALLED, CREATED, DELETED, LOGIN_ALLOWED, LOGIN_DENIED, MESSAGE, MODIFIED, POST, PUT, and DELETE.
  • Object Type: The object type of the object involved in this task. This field is not displayed by default. You can select this for display.
  • Object Name: The name of the object involved in this task.
  • Execution Status: The execution status of the task. Possible values are Executed, Normal, Pending Approval and Scheduled.
  • URI: A certain part of the incoming WAPI request.
  • InData: Input data fields of the incoming WAPI request.
  • Response Time: The processing time of the incoming WAPI request.
  • Message: Detailed information about the performed task.

You can also do the following in the log viewer:

• Toggle between the single line view and the multi-line view for display.
• Navigate to the next or last page of the file using the paging buttons.
• Refresh the audit log view.
• Click the Follow icon to have the appliance automatically refresh the log every five seconds.
• Download the log.
• Clear the contents of the audit log.
• Use filters and the Go To function to narrow down the list. With the autocomplete feature, you can just enter the first few characters of an object name in the Go to field and select the object from the possible matches.
• Create a quick filter to save frequently used filter criteria. 
• Export or print the content of the log.

Searching in the Audit Log

Instead of paging through the audit log file to locate messages, you can have the appliance search for messages with certain text strings.
To search for specific messages:

• Enter a search value in the search field below the filters, and then click the Search icon.

The appliance searches through the audit log file and highlights the search value in the viewer. You can use the arrow keys next to the Search icon to locate the previous or next message that contains the search value.

Downloading the Audit Log

You can download the audit log file to a specified directory, if you want to analyze it later. To download an audit log file:

1. From the Administration tab, select the Logs tab -> Audit Log tab, and then click the Download icon.
2. Navigate to a directory where you want to save the file, optionally change the file name (the default name is auditLog.tar.gz), and then click OK. If you want to download multiple audit log files to the same location, rename each downloaded file before downloading the next.

Viewing the Replication Status

The Replication Status panel reports the status of the database replication between Grid members and Grid Master, and between the two nodes in an independent HA pair. You can use this information to check the health of the Grid and HA pair activity.
To view the current replication status, from the Grid tab, select the Grid Manager tab -> Members tab, and then click Toggle Replication Status View.
Grid Manager can display the following replication information for each member:

• Name: The FQDN (fully qualified domain name) of the appliance.
• Send Queue: The size of the queue from the Grid Master to the Grid member.
• Last Send: The timestamp of the last replication information sent by the Grid Master.
• Receive Queue: The size of the queue from the Grid member to the Grid Master.
• Last Receive: The timestamp of the last replication information sent received by the Grid Master.
• Member Replication Status: The replication status between the member and the Grid Master. Grid Manager displays the status in green when the status is fine or red when the member is offline.
• HA Replication Status: The HA replication status between the active and passive nodes. The status is at the member level, not at the node level. Grid Manager displays the status in red when one of the nodes is offline.
• Status: The current operational status of the appliance. The status can be one of the following:
  • Green: The appliance is operating normally in a "Running" state.
  • Yellow: The appliance is connecting or synchronizing with its Grid Master.
  • Red: The Grid member is offline, is not licensed (that is, it does not have a DNSone license with the Grid upgrade that permits Grid membership), is upgrading or downgrading, or is shutting down.
• IPv4 Address: The IPv4 address of the appliance or the VIP of an HA pair.
• IPv6 Address: The IPv6 address of the appliance or the VIP of an HA pair.
• Identify: This field appears only if your appliance has the unit identification button. This can be On or Off. When you identify the appliance by pressing the UID button on the appliance or through the GUI or CLI command, this field displays On. Otherwise, this is Off.
• DHCP, DNS, TFTP, HTTP,FTP, NTP, bloxTools, Captive Portal, DNS Accelerator Usage, Discovery, Reporting: The current status of the service. The status can be one of the following:
  • Green: The service is enabled and running properly.
  • Yellow: The service is enabled, but there may be some issues that require attention.
  • Red: The service is enabled, but it is not running properly. A red status icon can also appear temporarily when a service is enabled and begins running, but the monitoring mechanism has not yet notified the Infoblox GUI.
  • Gray: The service is not configured or it is disabled.
• Hardware Type: The hardware type of the appliance, such as IB-1400.
• Serial Number: The serial number of the appliance.
• DB Utilization: The percentage of the database that is currently in use.
• Comment: Information about the appliance.
• Site: The location to which the member belongs. This is one of the predefined extensible attributes.
• HA: Indicates whether the member is an HA pair. If the member is an HA pair, Grid Manager displays the status of the HA pair.
• Hardware Model: The hardware model of the appliance.

You can do the following:

• Use filters and the Go To function to narrow down the list. With the autocomplete feature, you can just enter the first few characters of an object name in the Go to field and select the object from the possible matches.
• Create a quick filter to save frequently used filter criteria. 
• Modify some of the data in the table. Double click a row of data, and either edit the data in the field or select an item from a drop-down list. Note that some fields are read-only. For more information about this feature, see Modifying Data in Tables.
• Edit the properties of a member.
  • Click the check box beside a member, and then click the Edit icon.
• Delete a member.
  • Click the check box beside a member, and then click the Delete icon.
• Export or print the list.

Using the Traffic Capture Tool

You can capture the traffic on one or all of the ports on a NIOS appliance, and then view it using a third-party network protocol analyzer application, such as the Wireshark – Network Protocol Analyzer™. Using this tool, you can capture traffic for a single member or multiple Grid members simultaneously. The NIOS appliance must have a minimum of 500 MB of free disk space to start the traffic capture; otherwise, the traffic capture might fail.
The NIOS appliance saves all the traffic it captures in a .cap file and compresses it into a .tar.gz file. Your management system must have a utility that can extract the .tar file from the .gzip file, and an application that can read the .cap (capture) file format. The size of the .cap file is limited to 2 GB for the Infoblox-4010, Infoblox-4030, Infoblox-4030-10GE, and PT-4000, and the size is limited to 1 GB for all other NIOS appliances. You can also transfer the traffic capture file to your local management system, a TFTP server, an FTP server, or a SCP server.

NIOS saves failed traffic capture file transfer attempts in the syslog. Traffic capture file transfers can fail due to remote server issues, such as an invalid server IP address, or an incorrect username, or a password, or an invalid path. Note that the traffic capture fails when the disk space on the member is insufficient, but the file transfer will be successful. The NIOS appliance logs a warning message in the syslog when the traffic capture fails. You can find the following information about traffic capture and file transfers in the audit log: 

• Start and stop actions performed on the members for traffic capture.
• If the traffic capture file was transferred to a server or downloaded to a local directory. For more information about the audit log, see Using the Audit Log.

This section explains the process of capturing traffic, and how to download the traffic capture file to your management system. After that, you can extract the traffic capture file and view it with a third-party traffic analyzer application. The traffic capture file is shared between admin users.

You can also configure Grid Manager to trigger a traffic capture at set intervals and parameters. If Grid Manager detects that a parameter has breached a configured threshold or crossed the configured duration of time, it triggers a traffic capture. For more information about automated traffic capture, see Enabling Automated Traffic Capture.

For a single member, you can also capture traffic on the NIOS appliance through the Infoblox CLI using the set traffic_capture command. However, you cannot use this command to capture traffic for multiple members. NIOS displays the traffic capture status and it allows you to download the captured traffic, irrespective of whether the traffic capture is initiated from the Infoblox CLI or from Grid Manager.
To capture traffic for a single member or multiple Grid members:

1. From the Grid tab, select the Grid Manager tab -> Members tab, and then click Traffic Capture from the Toolbar.
   OR
   From the Administration tab, select the Logs tab → Syslog tab, and then click Traffic Capture from the Toolbar.
2. In the Traffic Capture dialog box, complete the following:

Members

• • Name: Click the Add icon to add either a single or multiple Grid members for which you want to capture traffic. When you click the Add icon, Grid Manager displays the Member Selector dialog box from which you can select one or multiple members. Use SHIFT+click to select multiple contiguous rows or use CTRL+click to select multiple non-contiguous rows. Click OK. The selected members are added to the list of members in the Members table. You cannot add offline members to the list or capture traffic on an offline member.

    Note

    Selecting members in the Grid Manager → Members tab does not capture traffic for the selected member. To capture traffic, you must select members from the Member Selector dialog box.

  • Interface: Select the port on which you want to capture traffic. You can view the selected interface while the traffic capture is in progress. Note that if you enabled the LAN2 failover feature, the LAN and LAN2 ports generate the same output and Grid Manager displays the interface as BOND while the traffic capture is in progress. By default the interface is set to ALL after the traffic capture process stops. For information about the LAN2 failover feature, see About Port Redundancy.

    • LAN: Select this to capture all the traffic the LAN port receives and transmits.
    • MGMT: Select this to capture all the traffic the MGMT port receives and transmits.
    • LAN2: Select to capture all the traffic the LAN2 port (if enabled) receives and transmits.
    • ALL: Select this to capture the traffic addressed to all ports. Note that the NIOS appliance only captures traffic that is addressed to it.

    • LANxnnnn: If you have configured VLANs on the LAN1 or LAN2 port, the appliance displays the VLANs in the format LANx nnnn, where x represents the port number and nnnn represents the associated VLAN ID.

  • File Size: Displays the size of the traffic capture log file, in kilobytes, for the respective member.
  • Status: Displays the status of the traffic capture session on the member. The status can be one of the following: 
    • STOPPED: Indicates that the traffic capture session has stopped.
    • RUNNING: Indicates that the traffic capture session is in progress. 
    • NOT STARTED: Indicates that the traffic capture session has not started.
  • Transfer Status: Displays the status of the traffic capture file transfer. The status can be one of the following:
    • NOT STARTED: Indicates that the file transfer has not started. 
    • STARTED: Indicates that the file transfer has started.
    • COMPLETED: Indicates that the file transfer has been completed.
    • FAILED: Indicates that the file transfer has failed.

3. Seconds to run: Specify the number of seconds you want the traffic capture tool to run.

4. Capture Control: Click the Start icon to start the capture. Note that the start action will overwrite the existing traffic capture file. You can click the Stop icon to stop the capture after you start it. 

5. Transfer To: Select the destination to transfer the traffic capture file. You can select My Computer, TFTP, FTP, or SCP from the drop-down list.

• • My Computer: Transfer the traffic capture file to a local directory on your computer. This is the default.

    Note

    To avoid consumption of the Grid Master disk space, NIOS restricts downloading the traffic capture files from multiple members to a local directory on your computer.

• • TFTP: Transfer the traffic capture file to a TFTP server.
    • Filename: Enter the directory path and the file name of the traffic capture file. For example, you can enter /home/test/traffic_capture_filename where traffic_capture_filename is the name of the file. 
    • IP Address of TFTP Server: Enter the IP address of the TFTP server to which you want to transfer the traffic capture file.
  • FTP: Transfer the traffic capture file to an FTP server.
    • Filename: Enter the directory path and the file name of the traffic capture file. For example, you can enter /home/test/traffic_capture_filename where traffic_capture_filename is the name of the file.
    • IP Address of FTP Server: The IP address of the FTP server.
    • Username: Enter the username of your FTP account.
    • Password: Enter the password of your FTP account.
  • SCP: Transfer the traffic capture file to an SCP server.
    • Filepath: Enter the directory path of the traffic capture file. For example, you can enter /home/test/.
    • IP Address of SCP Server: The IP address of the SCP server.
    • Username: Enter the username of your SCP account.
    • Password: Enter the password of your SCP account.

6. Uncompressed Capture File Size: Select the members for which you want to download the traffic capture file and then click Download to download the captured traffic. You can download and save the file only after the capture stops, but not when the tool is running. You can rename the file if you want. NIOS updates the size of the report when the capture tool is running.

7. Last updated: The timestamp of the last traffic capture process.

8. Use terminal window commands (Linux) or a software application (such as StuffIt™ or WinZip™) to extract the contents of the .tar.gz file.

9. When you see the traffic.cap file in the directory where you extract the .tar.gz file, open it with a third-party network protocol analyzer application.

Limitations of the Traffic Capture Tool

• You cannot add members to the list of members in the Members table on the Traffic Capture wizard when traffic capture is in progress.
• While the traffic capture file transfer is in progress on any member on the Traffic Capture wizard, Grid Manager does not allow you to start or stop traffic capture on members. However, you can start traffic capture using the CLI command even though the file transfer is in progress.
• If the traffic capture has already started on Grid Manager, you cannot initiate the capture again using the CLI command. You must wait until the process is complete.
• Traffic captures that are initiated using the CLI/WAPI commands do not appear in the Members table. To initiate traffic capture for a single member that was initiated and stopped using the CLI/WAPI command, add the respective member manually to the list of members in the Members table.
• Grid Manager does not allow you to initiate traffic capture on a list of selected members, if it has already been initiated for a member in the list using CLI/WAPI commands.
  

Using the Capacity Report

You can view the capacity usage and object type information of an appliance in a capacity report. The capacity report displays capacity and object type information of an independent appliance, a Grid Master, or a Grid member. For an HA pair, the report displays information on the active node.
The top half of the panel displays a capacity summary, and the bottom half displays the object types the appliance supports and the total counts for each object type.
To view a capacity report:

• From the Grid tab, select the Grid Manager tab -> Members tab -> member check box, and then click Capacity Report from the Toolbar.

The capacity summary contains the following information:

• Name: The name of the appliance.
• Role: The role of the appliance. The value can be Grid Master, Grid Master Candidate, Grid Member, or Standalone.
• Hardware Type: The type of hardware. For an HA pair, the report displays the hardware type for both the active and passive nodes.
• Object Capacity: The maximum number of objects the appliance can support.
• Total Objects: The total number of objects currently in the database.
• % Capacity Used: The percentage of the capacity in use.

The capacity report filters object types you can manage through the appliance. You can configure the object types you want to see in the following table by completing the following in the Minimum Object Total filter:

• Minimum Object Total: Enter the minimum number of objects within an object type of which Grid Manager displays. In the Object Type table, Grid Manager displays only the object types that contain at least the specified number of objects you enter in this field.

The capacity report displays the following information:

• Object Type: The type of objects. For example, DHCP Lease, Admin Group, or PTR Record. For objects that are only used for internal system operations, the report groups and shows them under Other.
• Total: The total number of objects for the specific object type. You can print the object type information or export it to a CSV file.

Participating in the Customer Experience Improvement Program

Administrators with superuser accounts can configure a Grid Master or an independent appliance to email reports monthly and after each upgrade to Infoblox Technical Support and other specified recipients. The reports are also included in support bundles that you download.

The reports provide status and event information about the Grid or independent appliance and its services. The report is an XML document that includes the following information:

• The phone home feature version.
• The report type, such as periodic and test.
• The time of the report.
• The Infoblox Support ID that was assigned to the account.
• Information about the Grid, such as its NIOS version, name, VIP, Grid Master hostname, LAN IP, and the number of Grid members and appliances in the Grid.
• The upgrade history of the Grid.
• Information about each Grid member, such as the hostname, IP address, status, role (such as standalone, master), and if the member is an HA pair. If the member is a peer in a DHCP failover association, the report also includes the DHCP failover status.
• Hardware information, such as the hardware type, serial number, HA status, and uptime.
• Information about the interfaces, such as the interface name and IP addresses.
• Resource usage information, such as CPU and system temperature, and CPU, database, disk, and memory usage.

Note that if the appliance is configured to send email notifications to an SMTP relay server, as described in Notifying Administrators, the appliance sends the phone home reports to the relay server as well.
To configure the Grid Master to email status reports:

• From the Grid tab, select the Grid Manager tab -> Members tab.
• Expand the Toolbar and click Grid Properties -> Edit.
• In the Grid Properties editor, select the Customer Improvement tab, and then complete the following:
  • Participate in Infoblox Customer Experience Improvement Program: Select the check box to send product usage data to Infoblox on a periodic basis. Infoblox uses this data to improve product functionality.
  • Support ID: Enter the Infoblox Support ID that was assigned to your account. It must be a number with four to six digits. Infoblox includes this ID in the data report.
  • Send notifications to:
    • Infoblox Support: Select this to email the reports to Infoblox Technical Support.
    • Additional email addresses: Optionally, you can specify up to 16 additional recipients. Click the Add icon and enter the email addresses of the recipients.
  • Send Test Report: Click this to send a test report to the specified recipients.

4. Save the configuration and click Restart if it appears at the top of the screen.

Monitoring DNS Transactions

The NIOS appliance provides tools for monitoring DNS transactions and mitigating cache poisoning from UDP (User Datagram Protocol) traffic on source port 53. Cache poisoning can occur when a DNS server accepts maliciously created unauthentic data. The DNS server ends up locally caching the incorrect entries and serving them to users that make the same DNS requests. In a maliciously created situation, the attacker can redirect Internet traffic from the legitimate host to another host that the attacker controls.
You can configure the appliance to track invalid DNS responses for recursive DNS queries. The appliance tracks DNS responses that arrive on invalid ports or have invalid TXIDs (DNS transaction IDs). Both invalid ports and invalid TXIDs could be indicators of cache poisoning. An invalid port is a DNS response that arrives from UDP (User Datagram Protocol) port 53 with either one of the following conditions:

• There are no outstanding DNS requests from the port on which the response arrives.
• The TXID of the DNS response matches the TXID of an outstanding request. However, the request was sent from a port other than the port on which the response arrives.

An invalid TXID is a DNS response that arrives from UDP port 53, and the TXID does not match the TXID of an outstanding DNS request. Figure 37.1 illustrates how the appliance detects an invalid port and an invalid TXID.

Figure 37.1 Invalid Port and Invalid TXID

Both invalid ports and invalid TXIDs could be indicators of DNS cache poisoning, although a small number of them is considered normal in situations where valid DNS responses arrive after the DNS queries have timed out. You can configure the appliance to track these indicators, and you can view their status. You can also configure thresholds for them. When the number of invalid ports or invalid TXIDs exceeds the thresholds, the appliance logs an event in the syslog file and sends an SNMP trap and e-mail notification, if you enable them. You can then configure rate limiting rules to limit incoming traffic or completely block connections from primary sources that send the invalid DNS responses.

Rate limiting is a token bucket system that accepts packets from a source based on the rate limit. You can configure the number of packets per minute that the Infoblox DNS server accepts from a specified source. You can also configure the number of packets for burst traffic, which is the maximum number of packets that the token bucket can accept. Once the bucket reaches the limit for burst traffic, it discards the packets and starts receiving new packets according to the rate limit.
The appliance monitors only UDP traffic from remote port 53 for the following reasons:

• The attacks that the appliance monitors do not happen over TCP.
• DNS responses are sent only from port 53. The appliance discards DNS responses that are sent from other ports.

To monitor invalid ports and invalid TXIDs on the Infoblox DNS server, follow these procedures:

• Enable DNS network monitoring and DNS alert monitoring. For information, see Enabling and Disabling DNS Alert Monitoring.
• Configure the thresholds for DNS alert indicators. For information, see Configuring DNS Alert Thresholds
• Enable SNMP traps and e-mail notifications. For information, see Configuring SNMP.
• Review the DNS alert status. For information, see Viewing DNS Alert Indicator Status
• Identify the source of the attack by reviewing the DNS alert status, syslog file, and SNMP traps. For information on SNMP traps for DNS alerts, see Threshold Crossing Traps.

To mitigate cache poisoning, you can limit incoming traffic or completely block connections from specific sources, as follows:

• Enable rate limiting on the DNS server. For information, see Enabling and Disabling Rate Limiting from External Sources.
• Configure rate limit traffic rules from specific sources. For information, see Configuring Rate Limiting Rules.

You can verify the rate limiting rules after you configure them. For information, see Viewing Rate Limiting Rules

Enabling and Disabling DNS Alert Monitoring

The appliance monitors only UDP traffic on port 53 for recursive queries, and then reports invalid DNS responses.
DNS alert monitoring is disabled by default. For an HA pair, you must enable DNS alert monitoring on both the active and passive nodes.
To enable DNS network monitoring and DNS alert monitoring:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

set monitor dns on
The appliance displays the following:
Turning on DNS Network Monitoring...

3. Enter the following command:

set monitor dns alert on

When you enable DNS alert monitoring and DNS network monitoring is disabled, the appliance automatically enables DNS network monitoring and displays the following:

DNS Network Monitoring is disabled. It must be enabled for alerting to function.

Enable DNS Monitoring now? (y or n):

You can also disable DNS network monitoring and DNS alert monitoring using the following commands:

set monitor dns off
set monitor dns alert off

You can then view the alert status to identify the primary source of invalid DNS responses. For information, see Viewing DNS Alert Indicator Status.

Viewing DNS Alert Indicator Status

To view DNS alert indicator status:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

show monitor dns alert status

The appliance displays historical alert counts and up to five primary sources that generate invalid DNS responses, as shown in the following example:
Data last updated: Mon Oct 6 14:47:12 2008

DNS Alert1m5m15m60m24hEver
============================================

port8 12  1212  12  12

txid8 12  1212  12  12

There were 80 DNS responses seen in the last minute.

10% were to an invalid port.

10% had an invalid TXID.

Primary sources of invalid responses:

4.4.4.4 (unknown) sent 4

2.2.2.2 (unknown) sent 3

7.7.7.7 (unknown) sent 1

The appliance attempts to resolve the hostnames of the sources that sent invalid responses, if the DNS resolver is enabled. If the appliance cannot resolve a hostname, it displays "unknown" as the hostname of the invalid response.

Configuring DNS Alert Thresholds

You can configure thresholds for DNS alerts to control when the appliance tracks DNS attacks on UDP port 53 and issues SNMP traps and e-mail notifications.

You can configure thresholds for both invalid ports and invalid TXIDs. The default thresholds for both invalid ports and TXIDs are 50%. When the number of invalid ports or invalid TXIDs exceeds the thresholds, the appliance logs the event and sends SNMP traps and notifications. You can configure the thresholds either as absolute packet counts or as percentages of the total traffic during a one minute time interval.
To configure DNS alert thresholds:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

set monitor dns alert modify port | txid over threshold_value packets | percent
where
port | txid = Enter port to set the threshold for invalid ports, or enter txid to set the threshold for invalid TXIDs.
threshold_value = Enter the number of packets or percentage for the threshold.
packets | percent = Enter packets if you want to track the total packet count, or enter percentage if you want to track a percentage of the total traffic. For a percentage-based threshold, the appliance does not generate a threshold crossing event if the traffic level is less than 100 packets per minute.

For example, if you want the appliance to send a DNS alert when the percentage of DNS responses arriving on invalid ports from UDP port 53 exceeds 70% per minute, you can enter the following command:

set monitor dns alert modify port over 70 percent

If you want the appliance to send a DNS alert when the total number of packets with invalid TXIDs from UDP port 53 is over 100 packets per minute, you can enter the following command:

set monitor dns alert modify txid over 100 packets

When there is a DNS alert, the appliance logs an event in the syslog file and sends an SNMP trap and e-mail notification if enabled.

Viewing DNS Alert Thresholds

You can view the DNS alert thresholds. The appliance displays the current thresholds. If you have not configured new thresholds, the appliance displays the default thresholds, which are 50% for both invalid port and TXID.
To view the DNS alert thresholds:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

show monitor dns alert

The appliance displays the threshold information as shown in the following example:

DNS Network Monitoring is enabled. Alerting is enabled.

DNS Alert Threshold (per minute)
===========================================
portover 70% of packets

txidover 100 packets

Enabling and Disabling Rate Limiting from External Sources

You can mitigate cache poisoning on your DNS server by limiting the traffic or blocking connections from UDP port 53. To enable rate limiting from sources:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

set ip_rate_limit on

The appliance displays the following:

Enabling rate limiting will discard packets and may degrade performance.

Are you sure? (y or n):

3. Enter y to enable rate limiting.

When you enable rate limiting, the appliance applies the rate limiting rules that you configured. You might want to configure the rate limiting rules before enabling rate limiting. For information on how to configure rate limiting rules, see Configuring Rate Limiting Rules.
You can also disable rate limiting by entering the following command:

set ip_rate_limit off

When you disable rate limiting, the appliance stops applying the rate limiting rules.

Configuring Rate Limiting Rules

You configure rate limiting rules to limit access or block connections from UDP port 53. The rules take effect when you enable rate limiting.
When adding rules, ensure that you do not include an IP address that matches the IP address of either the Grid Master or Grid member. Doing this could affect VPN connectivity. To configure rate limiting rules:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

set ip_rate_limit add source all | ip_address [/mask] limit packets/m [burst burst_packets]

where

all | ip_address = Enter all or 0.0.0.0 if you want to limit all traffic from all sources, or enter the IP

address from which you want to limit the traffic.

[/mask] = Optionally, enter the netmask of the host from which you want to limit the traffic.

packets = Enter the number of packets per minute that you want to receive from the source.

[burst burst_packets] = Optionally, enter burst and the number of packets for burst traffic. This is the maximum number of packets accepted.

The following are sample commands and descriptions for rate limiting rules:

• To block all traffic from host 10.10.1.1, enter the following command:

set ip_rate_limit add source 10.10.1.1 limit 0

• To limit traffic to five packets per minute from host 10.10.1.2, enter the following command:

set ip_rate_limit add source 10.10.1.2 limit 5/m

• To limit the traffic to five packets per minute from host 10.10.2.1/24 with an allowance for burst traffic of 10 packets, enter the following command:

set ip_rate_limit add source 10.10.2.1/24 limit 5/m burst 10

• To limit the traffic to 5000 packets per minute from all sources, enter the following command:

set ip_rate_limit add source all limit 5000/m

Removing Rate Limiting Rules

You can remove the existing rate limiting rules that limit access or block connections from UDP port 53. To remove all the existing rules:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:
  • To remove the rate limiting rule that limits traffic from all sources, enter:

set ip_rate_limit remove source all

or

• • To remove all of the rate limiting rules from all sources, enter:

set ip_rate_limit remove all

To remove one of the existing rules for an existing host:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

set ip_rate_limit remove source ip-address[/mask]

Viewing Rate Limiting Rules

You can view the existing rate limiting rules that limit access or block connections from UDP port 53. To view rate limiting rules:

• Log in to the Infoblox CLI as a superuser account.
• Enter the following CLI command:

show ip_rate_limit

The appliance displays the rules, as shown in the following example:

IP rate limiting is enabled.

Source           Limit            Burst
============================================

10.10.1.1    0 packets/minute    0 packets

10.10.1.2    5 packets/minute    5 packets

10.10.2.1/24 5 packets/minute    10 packets

all          5000packets/minute  5000 packets

* Note: Copy audit to syslog feature should not alter. But increases the syslog file size.