Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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 4442.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.

Anchor
bookmark3302
bookmark3302
Figure 4442.2 FireEye Integrated RPZ
1Create a FireEye integrated RPZ zone and define rule mapping.
Log in to the FireEye GUI. Add user credentials and the URL that is generated by the NIOS appliance.
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
Image Removed
25While processing the FireEye RPZ, NIOS generates an URL.
Create admin users in the
3fireeye-group. Note that the
fireeye-group is created automatically.Image Removed
Image Removed
6
Malware is detected4
Copy the generated URL.
7Fireeye generates an alert
Drawio
border1
baseUrlhttps://infoblox-docs.atlassian.net/wiki
diagramName42.2
zoom1
pageId22253122
custContentId7083529
lbox1
contentVer1
revision1


To configure a FireEye integrated RPZ, complete the following:

  1. Create a new FireEye integrated RPZ, as described in Configuring FireEye RPZs3.
  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 onpage 1716.
  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.

Anchor
Configuring FireEye RPZs
Configuring FireEye RPZs
Anchor
bookmark3303
bookmark3303
Anchor
bookmark3304
bookmark3304
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.
Image Removed
NIOS 8.1NIOS Administrator Guide (Rev. A) 1713

...

Infoblox DNS Firewall
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.

...

...

...

  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:

    • 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 4442.2 FireEye Rule Mapping

FireEye Alert Type

RPZ Policy Type

Lifetime

 


Domain Match

Infection Events

Callback Events

Malware Object

Web Infection

on page 1696

Specify a lifetime for each FireEye alert in Days, Weeks, or select Live Forever from the drop-down list. The following are the default values for different alert types:

  • Domain Match - 1 week
  • Infection Events - 1 day
  • Callback Events - 1 week
  • Malware Object - 1 day
  • Web Infection - 1 day
    Click on the default value to change the lifetime
value.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
  • value.


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
      • – 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
      • – 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
      • – 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
      • – Select this if you want the user to receive a response that indicates that there is no data.
      • Substitute (Domain Name)
  • –Select
      • – 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:

    • 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
  1. 3
  2. 6

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.

Anchor
Configuring Rules for FireEye RPZs
Configuring Rules for FireEye RPZs
Anchor
bookmark3305
bookmark3305
Configuring 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:
  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.

...

  1. Install required license on the NIOS appliance. For more information about license, see License Requirements and Admin Permissions9.
  2. Create a new FireEye RPZ zone. For more information, see Configuring FireEye RPZs3.
  3. Create FireEye admin users. For more information, see For FireEye Integrated RPZs .

...

  1. .

...

...

  1. 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 RPZs4.
  2. 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.

...

  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 RPZs0.
    • 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.
Image Removed
NIOS 8.1NIOS Administrator Guide (Rev. A) 1717
Infoblox DNS Firewall

...

Anchor
Handling Alerts from the FireEye applian
Handling Alerts from the FireEye applian
Anchor
bookmark3308
bookmark3308
Handling Alerts from the FireEye appliance

...

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.

Anchor
Configuration Examples
Configuration Examples
Anchor
bookmark3310
bookmark3310
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 \\ \\ !worddav82aac1426f41e4bf41b080762501fdd1.png|height=20,width=11! 1718NIOS Administrator Guide (Rev. A)NIOS 8.1 About FireEye Integrated RPZs \\ \\ If the above command returns 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

Wiki MarkupFollowing 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

...

  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 on page 1693.
  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 Records5.
  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.