Infoblox DNS Firewall provides a mechanism to further protect your network from malware and APTs (Advanced Persistent Threats) through the integration of FireEye appliances. When your NIOS appliance is properly integrated with a FireEye appliance, it receives periodic alerts and APTs from the FireEye appliance when it identifies such threats. Based on your configuration, the NIOS appliance translates these alerts into RPZ rules that not only further protect your network from malicious attacks, but also aid in identifying clients that have been compromised.
As illustrated in Figure 42.2, after installing the required RPZ and FireEye licenses on the NIOS appliance, you can configure a FireEye integrated RPZ in which you map RPZ rules to FireEye alert types. While creating the FireEye RPZ, the appliance generates a URL to which the FireEye appliance sends alerts. Ensure that you enter this URL when configuring the FireEye appliance. The NIOS appliance also creates the fireeye-group admin group after you define the first FireEye RPZ. You can add multiple admin users to this admin group. Note that users in the fireeye-group can only send alerts to the NIOS appliance; they cannot access the Infoblox GUI, CLI, API and RESTful API. They also do not have permissions to perform other tasks on the appliance. Ensure that you record the usernames and passwords for all user accounts so you can enter them correctly when you configure the FireEye appliance. You can map a single or multiple FireEye appliances to a NIOS appliance where multiple users or zones exist.
Figure 42.2 FireEye Integrated RPZ

1. Create a new FireEye integrated RPZ, as described in Configuring FireEye RPZs.
2. Create FireEye admin users, as described in For FireEye Integrated RPZs.
3. Add URL and user credentials on the FireEye appliance, as described in Configuring the FireEye appliance.
4. When a malware or threat is detected, the FireEye appliance sends an alert message to the NIOS appliance, which is stored in the syslog. For more information, see Handling Alerts from the FireEye appliance.

Configuring FireEye RPZs

You must create an RPZ zone and map the FireEye alerts with an RPZ rule to receive alerts from FireEye. These alerts will then be translated into appropriate RPZ rules that are added to the FireEye RPZ. You can also define a time limit for a specific alert type or set the alert type to live forever. When you define a lifetime, the alert type will be active for the specified number of days or weeks in the NIOS appliance, and will then expire after the specified time. After you configure the FireEye integrated RPZ, the NIOS Grid receives alerts from the FireEye appliance and creates RPZ rules for some of the alerts received. FireEye appliance sends alert messages with basic authentication. You must configure a username and password on the NIOS appliance prior to receiving any alerts from the FireEye appliance.

Note: The NIOS appliance treats the FireEye integrated RPZ as a local RPZ. Thus, you cannot assign an external primary name server to the zone.

An alert contains the malware URL along with a valid FQDN. The NIOS appliance can only map an alert to a RPZ rule if the FQDN is present. If an alert doesn't contain the FQDN, then the alert is ignored by the NIOS appliance. For more information about alerts, see Handling Alerts from the FireEye appliance. Once the alert is processed and properly mapped to an RPZ rule, it remains in the database until you delete it manually. You can get more information about the alerts, which are sent by the FireEye appliance, from the syslog.

Note: You can configure feeds from multiple FireEye appliances. To enable or disable FireEye integration module feeds from individual appliances, you must enable or disable user access of the particular FireEye appliance. Note that the FireEye feeds will not be in the RPZ format, but when you configure a FireEye integrated RPZ, the NIOS appliance creates a new URL through which the FireEye appliance sends alerts.

To configure a FireEye integrated RPZ:

1. From the Data Management tab, select the DNS tab -> Response Policy Zones tab, and then click the Add icon.
2. When you click the Add icon, either the Add Response Policy Zone Wizard or the Add DNS View wizard is displayed based on the following:
   • When you click the Add icon, the Add Response Policy Zone Wizard is displayed if you have not created additional DNS views and only have the default view.
3. If you have configured multiple DNS views, you must drill-down to the corresponding view to assign a FireEye Integrated RPZ. Click the Add icon and the Add Response Policy Zone Wizard is displayed. To create a new DNS view for your FireEye integrated RPZ, click the Add icon and complete the details in the Add DNS View wizard. For information, see Adding a DNS View. For information on modifying an existing view, see Modifying DNS Views.
4. In the Add Response Policy Zone Wizard, select Add FireEye-Integrated Response Policy Zone, click Next and specify the following:
   • Name: Enter the name of the FireEye integrated RPZ. It can be a combination of alphanumeric characters. You can enter up to 256 characters.
   • DNS View: The name of the view that you have selected is displayed by default. You can select a view from the drop-down list to associate it with the FireEye integrated RPZ.
   • Policy Override: Select a value from the drop-down list. You can override the policy actions that are specified in the rule level.
     • Log Only (Disabled) – Select this if you want to disable an RPZ rewrite using rules in the RPZ. If the response to the recursive query matches any RPZ rule, then the rule is logged, but the response will not be altered. Note that this option will not override RPZ rules in other RPZ zones, if they take precedence. Select this option to preview the rules in the syslog before they take effect.
     • None (Given) – Select this if you want to use the policy from the rule level.
     • Block (No Data) – Select this to send a response that contains no data in it.
     • Block (No Such Domain) – Select this if you want the user to receive a DNS response that indicates there is no domain. All the policy actions in an RPZ are replaced with a NXDOMAIN block.
     • Passthru – Select this if you want to send an actual response without modification. All the policy actions in an RPZ are replaced with the passthru action.
     • Substitute (Domain Name) – Select this if you want to replace all the policy actions in an FireEye integrated RPZ with the specified substitution action.
       • Domain Name: This appears only when you select Substitute (Domain Name) from the Policy Override list. Enter the domain name that you want the client to receive instead of the actual domain name, which is malicious or unauthorized.
   • Comment: Optionally, enter additional information about the FireEye integrated RPZ.
   • Disable: Select the check box to disable the FireEye integrated RPZ without deleting its configuration. Clear the check box to enable the FireEye integrated RPZ. For information, see Enabling and Disabling Zones.

5. Click Next to define rule mapping:

1. • Server URL: The appliance displays the URL that you use when configuring the FireEye appliance. This URL is used to handle alerts, which is sent by the FireEye appliance. It handles alerts based on the standard authentication. The URL generated by the NIOS appliance consists of the Grid Manager IP address, network view, and DNS view of the FireEye zone. If you change the IP address, network view, zone or DNS view after you have configured a FireEye RPZ, the URL will change accordingly. Thus FireEye will not be able to send alerts to the updated URL. You must update the URL in the FireEye appliance to send alerts to the NIOS appliance. The Server URL is generated in this format:

https://<host address>/alert/feye/<network view>/<dns view>/<zone>

• • Rule Mapping: You can map a FireEye alert type with an RPZ policy. Select an RPZ policy type from the drop-down list. Note that the FireEye alert type is read-only. The NIOS appliance applies corresponding RPZ policy type when the FireEye appliance sends an alert to the NIOS appliance. You can also specify a time limit for each FireEye RPZ rule depending on the FireEye alert type. NIOS displays default lifetime value for each alert type. You can change the default lifetime of the alert type. When you define a value, the value must be greater than zero. When you select Live Forever from the drop-down list, the alert type will never expire and will be stored in the database until further notice. The NIOS appliance will use the default time if you do not specify a value. You can specify the expiration time in days or weeks only. The following table lists the FireEye alerts, RPZ policy types, and the time limit for a specific FireEye alert:

Table 42.2 FireEye Rule Mapping

When you edit the lifetime of an existing alert type, NIOS deletes the alert type based on the new lifetime setting. It also updates the expiration time for the corresponding alert type. Note that there might be an impact on the performance when you delete expired FireEye RPZ rules.

• • Override rule mapping for APT events: Select a value from the drop-down list to override rule mapping for Advanced Persistent Threats. Events that are marked as APT events by FireEye override rules that are set for other event types. The values in the drop-down list are:
    • NoOverride – Select this if you want to use the policy from the rule level and do not want to override the rule mapping settings. This value is displayed in the drop-down list, by default.
    • Passthru – Select this if you want the user to see the actual response without modification. All the policy actions in an RPZ are replaced with the passthru action.
    • Block (No Such Domain) – Select this if you want the user to receive a NXDOMAIN as the DNS response. All the policy actions in an RPZ are replaced with a NXDOMAIN block.
      
    • Block (No Data) – Select this if you want the user to receive a response that indicates that there is no data.

• • • Substitute (Domain Name) – Select this if you want to replace all the policy actions in an RPZ with the substitution action that is specified.
  • Substituted Domain Name: This appears only when you select Substitute (Domain Name) from the Policy Override list either for APT events or for FireEye alerts. Enter the domain name that you want the client to receive instead of the actual domain name, which is malicious or unauthorized.

6. Click Next to associate the FireEye integrated RPZ with at least one primary name server:

1. • Define the name servers for the FireEye integrated RPZ. A Grid name server must be recursive when primary Grid name server is used as an RPZ source. A FireEye integrated RPZ may or may not have a recursive server. For example, there could be a Grid that has only primary Grid name server for a FireEye integrated RPZ to act as an RPZ source for an external set of name servers. A FireEye integrated RPZ must have only one primary Grid name server and it can have one or more secondary Grid name servers. When you select All Recursive Name Servers from the list, all the recursive name servers in the Grid are added as secondary servers for the zone. For information on specifying primary or secondary name servers, see Assigning Zone Authority to Name Servers. For information on specifying name server groups, see About Name Server Groups. For information about all recursive name servers, see Configuring RPZs for All Recursive Servers.

7. Save the configuration and click Next to define extensible attributes. For information, see About Extensible Attributes.

8. Click Restart if it appears at the top of the screen.

Configuring Rules for FireEye RPZs

You can define a list of rules based on how the DNS server determines its response to recursive queries. Based on the rules defined, responses to clients are either manipulated or forwarded without any changes. To configure rules for FireEye RPZs:

1. From the Data Management tab, select the DNS tab -> Response Policy Zones tab, click DNS_View -> Zone and then click Add -> select a Rule.
2. The rules are classified as follows:
   • Passthru Rule: For information, see Managing Passthru Rules.
   • Block (No Such Domain) Rule: For information, see Managing Block (No Such Domain) Rules.
   • Block (No Data) Rule: For information, see Managing Block (No Data) Rules.
   • Substitute (Domain Name) Rule: For information, see Managing Substitute (Domain Name) Rules.
   • Substitute (Record) Rule: For information, see Managing Substitute (Record) Rules.
3. Complete the details in the corresponding editor.
4. Save the configuration and click Next to define extensible attributes. For information about extensible attributes, see About Extensible Attributes.

Configuring the FireEye appliance

You must configure the FireEye appliance to send alerts to the NIOS appliance. Ensure that the following are complete before you configure the FireEye appliance:

1. Install required license on the NIOS appliance. For more information about license, see License Requirements and Admin Permissions.
2. Create a new FireEye RPZ zone. For more information, see Configuring FireEye RPZs.
3. Create FireEye admin users. For more information, see For FireEye Integrated RPZs.
4. Get the URL from the NIOS appliance and record it. You need this to configure the FireEye appliance. For more information about the Server URL, see Configuring FireEye RPZs. If you have already configured a FireEye integrated RPZ, then you can retrieve the URL through the FireEye tab of the corresponding FireEye RPZ zone. For more information about managing and retrieving the URL, see Modifying RPZs.
5. Record the usernames and passwords on the NIOS appliance. You must use these credentials when configuring FireEye alerts to enable the alerts to be received by NIOS. For more information, see Configuring the FireEye appliance to send alerts to NIOS.

Configuring the FireEye appliance to send alerts to NIOS

You must configure the NIOS generated URL, usernames and passwords on the FireEye appliance. FireEye appliance embeds the configured usernames and passwords in the alerts for authentication. When an alert is received, the NIOS appliance verifies the FireEye username prior to processing the alert. Note that the NIOS appliance accepts alerts sent by the FireEye appliance in JSON Normal format only.
To configure a FireEye appliance:

1. Login to the FireEye appliance with your username and password.
2. In the FireEye GUI, click Settings tab and then click the Notifications tab on the left panel.
3. In the Notification Settings page, click the http link and then enter the name of the HTTP server you want to add. Click Add HTTP Server and complete the following:
   • Name: When you click add, the HTTP server name that you specified is listed in this column.
   • Enabled: Select the check box to enable alerts and notifications for the HTTP server.
   • Server Url: Enter the URL you received on the NIOS appliance. The alerts and notifications are sent using this URL by the FireEye appliance.
   • Auth: Select this check box if authentication is required for the server.
   • Username and Password: Enter the Username and Password of the user that you have configured for the fireeye-group on the NIOS appliance. For more information, see For FireEye Integrated RPZs.
   • Notification: Select a notification from the drop-down list. You can choose to include notifications for all events or only events of a selected type. The FireEye appliance will send an alert to the NIOS appliance only when selected event is encountered. When you select All Events, alerts are sent when each event is encountered by the FireEye appliance.
   • Delivery: Select Per Event from the drop-down list. Note that the NIOS appliance supports only Per Event selection. The FireEye appliance sends an alert each time it encounters an event.
   • Account: You can specify a user account name for this notification.
   • SSL Enable: Select this check box to enable SSL for secure transmission of alerts from the FireEye appliance to NIOS.
   • Default Provider: Select a default provider from the list.
   • Message Format: Select JSON Normal from the drop-down list. Note that the NIOS appliance supports only this message format.
4. Click Update at the bottom of the page.

Note: You can also click Test-Fire to test the configuration. If the configuration is successful, FireEye sends a confirmation message to the NIOS appliance and the NIOS appliance logs this message in the syslog. It generally takes a few seconds for the NIOS appliance to receive alerts. You must verify the configuration, if there is no entry in the syslog.

Handling Alerts from the FireEye appliance

The NIOS appliance processes each alert that it receives from the FireEye appliance. The alert contains the malware URL along with a valid FQDN. NIOS appliance can only map an alert to a RPZ rule if the FQDN is present. Once the alert is processed and properly mapped to an RPZ rule, it remains in the database until you delete it manually. When the RPZ rule is different from the existing rules, the new RPZ rule gains precedence over the existing RPZ rule in the FireEye integrated RPZ. Note that you cannot retrieve alerts that are ignored. You can get more information about the alerts, which are sent by the FireEye appliance, from the syslog. An alert will not be processed and will be ignored:

• when there are changes to the URL or if the alert does not have the malware URL or FQDN in them.
• if the zone is not found.
• if the alert is sent without any username in it or if the username does not belong to the fireeye-group.
• if a FireEye admin user is deleted. NIOS will neither authenticate the deleted user credentials nor process any future alerts with deleted user credentials.
• if the search mapping fields contain IP addresses other than FQDNs.
• if alerts contain domain names in an IPv4 or IPv6 address format.

Logging FireEye Integrated RPZ messages

The NIOS appliance logs FireEye events and alerts in the syslog and audit log. Each FireEye feed event is logged every time an alert is sent to NIOS by the FireEye appliance. When you create a new rule or update an existing rule, then those are also logged in the syslog. You can use messages logged in syslog to verify events that are related to communication between the FireEye and NIOS appliances. It also enables the admin to monitor alerts and verify how the alerts are processed. Details about alerts that are received and processed are also logged. Syslog messages are logged when:

• an alert is received from the FireEye appliance.
• syslog messages contain required information for reporting.
• an alert is successfully mapped to an RPZ rule. The message format is as follows:
  • <FireEye: Found an APT alert>
• the NIOS appliance cannot process alerts. For example, alert structure mismatch, unrecognizable data, etc. The messages will have the following format:
  • <FireEye: Cannot parse FQDN due to missing field''cnc-services''>
  • <FireEye: Cannot determine if it is an APT alert..>
  • <FireEye: Invalid Alert Type ....>
  • <FireEye: Couldn't find the required field...>
  • <FireEye: No mapping rule has been set for alert type.....>
• a duplicate alert is sent by the FireEye appliance for which the same RPZ rule already exists.

Note: For debugging purposes, alert messages will be displayed in the infoblox.log file.

NIOS periodically scans the syslog of a member that has RPZ license installed to generate recent hits data for the RPZ Recent Hits tab. This might cause a performance impact as CPU cycles will be used on the member. For more information about RPZ Recent Hits tab, see RPZ Recent Hits.

Configuration Examples

This section illustrates some of the examples of local and FireEye integrated RPZs.

Local RPZ Examples

Following is an example of an IP related rule. For example, execute the following command:
dig @10.35.104.19 abc.net

If the above command returns 18.58.20.1, then define an IPv4 substitute rule 18.0.0.0/8, Substitute (IPv4) 8.8.8.89.

Execute the command dig @10.35.104.19 abc.net again. You will receive the substituted address instead of the actual domain name.

Following is an example of values in CEF for the above substitution example:

2012-11-06T19:04:02+00:00 daemon (none) named[25193]: info

CEF:0|Infoblox|NIOS|6.6.0-185622|RPZ-IP|records|4|app=DNS dst=10.35.104.19

src=10.32.0.242 spt=50035 view=_default qtype=A msg="rpz IP records rewrite abc.net [A]

via 8.0.0.0.18.rpz-ip.localrpz"

Following is an example of values in the CEF for Block (No Data) rules:

2012-11-06T19:00:01+00:00 daemon (none) named[25193]: info

CEF:0|Infoblox|NIOS|6.6.0-185622|RPZ-QNAME|NODATA|4|app=DNS dst=10.35.104.19

src=10.32.0.242 spt=50035 view=_default qtype=A msg="rpz QNAME NODATA rewrite nodata.net [A]

via nodata.net.localrpz"

You can view the NIOS version, name of the view, source, and destination.

FireEye Integrated RPZ Examples

Following is an example of a syslog message when an alert gets converted to an RPZ rule:

013-09-11T10:59:55-07:00 user (none) httpd[]: info fireeye-rpt:

'79167','infection-match','minr''eng-lab-249.inca.infoblox.com'

2013-09-11T10:59:55-07:00 user (none) httpd[]: info FireEye: Create an RPZ rule for

'd.bnksw.com' with 'SUBSTITUTE' rule in RPZ zone 'com.lock’

Note that the domain name lock.com is displayed in the reverse format.
Following is an example of a syslog message when an alert is ignored by the NIOS appliance:

2013-09-11T11:04:01-07:00 user (none) httpd[]: info fireeye-rpt:

'114488','malware-object','majr''eng-lab-249.inca.infoblox.com'

2013-09-11T11:04:01-07:00 user (none) httpd[]: info FireEye: Cannot parse FQDN due to

missing field''cnc-services''

Example of a basic RPZ Workflow

Following is an example of a basic RPZ workflow:

1. Install the RPZ license. For more information, see License Requirements and Admin Permissions.
2. Enable recursive queries for a DNS view, member, or Grid, as described in Enabling Recursion for RPZs.
3. Enable RPZ logging in the Grid DNS Properties editor to view syslog entries for RPZ queries. For more information, see Setting DNS Logging Categories.
4. Create a local RPZ. For more information, see Configuring Local RPZs.
5. Define a Substitute (PTR Record) Rule for domain name 3.3.3.5.in-addr.arpa, which is substituted with the domain name ptr1.com. For more information, see Defining Substitute Rules for PTR Records.
6. Execute the dig command to view output. The output contains the substituted domain name ptr1.com. Following is the output of an RPZ query for Substitute (PTR Record) Rule:

$ dig @10.36.2.73 3.3.3.5.in-addr.arpa in ptr
; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @10.36.2.73 3.3.3.5.in-addr.arpa in ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7351
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;3.3.3.5.in-addr.arpa.          IN         PTR

;; ANSWER SECTION:
3.3.3.5.in-addr.arpa. 7200      IN         PTR       ptr1.com.

;; Query time: 3 msec
;; SERVER: 10.36.2.73#53(10.36.2.73)
;; WHEN: Thu Sep 26 23:27:10 2013
;; MSG SIZE rcvd: 60

7. Following is the syslog entry for the query mentioned above:

2013-09-27T02:26:46-04:00 daemon (none) named[21737]: info
CEF:0|Infoblox|NIOS|6.9.0-218052|RPZ-QNAME|Local-Data|4|app=DNS dst=10.36.2.73
src=10.120.20.194 spt=40518 view=2 qtype=PTR msg="rpz QNAME Local-Data rewrite
3.3.3.5.in-addr.arpa [PTR] via 3.3.3.5.in-addr.arpa.local1.com"

For more information about syslog, see Viewing RPZ in the Syslog.