Configuring Blocking local RPZ rules in NIOS (2549)
This lab requires a NIOS 9.0 Lab Environment
This lab guide has been developed using the new NIOS 9.0 Lab Environment (experimental) lab. Please ensure that you deploy a NIOS 9.0 lab environment to complete these lab tasks. If you use a different lab environment, this is untested, and the lab likely will not work.
Scenario
A corporate compliance policy was created to increase your corporate DNS security posture. The policy dictates what domains will be allowed and which ones will be blocked or modified. Your current task is to create a blocking policy to stop known malicious domains from being accessed.
Learning Content
Estimate Completion Time
25 to 30 minutes
Credentials
Description | Username | Password | URL or IP |
---|---|---|---|
Grid Manager UI | admin | infoblox |
Requirements
Administrative access to the Grid
Lab Initiation
Access jump-desktop
Once the lab is deployed, you can access the virtual machines required to complete this lab activity. To initiate the lab, click on the jump-desktop tile and login to the Linux UI:

Username: training
Password: infoblox
Initiate lab
To initiate the lab, double-click the Launch Lab icon on the Desktop.

Launch Lab
Choose the lab number from the list and click OK.

After clicking OK, you will see a pop-up message with a brief description of the lab task. If the description looks correct, click Yes to continue lab initiation.

Lab initiation will take a couple of minutes to finish.
Once complete, you will see another pop-up message with the login credentials and the URL for the Grid Manager’s User Interface. Note that the credentials may differ from those from prior labs.

Tasks
Create a local RPZ named denylist.rpz with an initial action of pass-thru
Re-arrange Response Policy Zones in the correct order
Add Block Domain Name Policy Rules to denylist.rpz
Add Block IP Address Rule to denylist.rpz
Add a Block Client IP Address Rule to denylist.rpz
Test denylist.rpz to verify it is detecting the traffic and passing it through
Modify denylist.rpz to Block traffic instead of passing it through
Verify that traffic matching rules in denylist.rpz is now blocked
Task 1: Create local RPZ - denylist.rpz
Create a local RPZ named denylist.rpz to ensure DNS traffic from unwanted domains is allowed to pass through for now as a test, using a previously configured server group called RPZ Local NSG.
Task 2: Rearrange Response Policy Zones in the correct order
Place the RPZ’s into the correct order, ensuring that traffic that should pass through is not blocked, and vice versa
Allowlist.rpz
Denylist.rpz
Task 3: Add Block Domain Name Policy Rules to denylist.rpz
Add a rule to the denylist.rpz to block the
eicar.net
domain and all its sub-domains.
Task 4: Add Block IP Address Rule to denylist.rpz
Add a rule to block a destination IP Address 224.224.224.224 in the denylist.rpz.
This IP Address 224.224.224.224 is an Infoblox-owned IP we will use it to simulate a known bogon domain bogon.singalorange.net.
Task 5: Add Block Client IP Address Rule to denylist.rpz
Add a rule to block DNS queries from a specific client IP address. The address used in the lab is 172.31.101.250.
This is the IP address of the Testing-Linux machine; for this reason, the rule is left disabled until we test it.
Task 6: Test denylist.rpz Local RPZ Rules
Switch over to the testing-linux machine with the credentials (training/infoblox) and set the machine up for testing.
Open a terminal window and issue the command
sudo set-network-static-nios
and verify that the machine now has the IP address 172.31.101.250 using the commandifconfig
.
Use dig and syslog entries to validate the local RPZ configurations.
Task 7: Modify denylist.rpz to Block traffic
Change the Policy Override value for denylist.rpz to Block (No Such Domain)
Task 8: Verify denylist.rpz is blocking traffic
Switch over to the testing-linux machine with the credentials (training/infoblox).
Use dig and syslog entries to validate the local RPZ configurations.
Verify that queries to
eicar.net
and the IP address 224.224.224.224, and queries from 172.31.101.250 are blocked.Enable the Block Client IP Address rule.
Solutions
Task 1 Solution: Create local RPZ - denylist.rpz
In this task, we create a local RPZ called denylist.rpz. The RPZ is initially created with Passthru mode. This allows you to test the RPZ without unintentionally blocking legitimate traffic.
On the jump-desktop machine, open a browser window and surf https://10.100.0.100.
Navigate to Data Management → DNS → Response Policy Zones.
Click the plus (+) symbol to add a new RPZ.
Select Add Local Response Policy Zone and click Next.
Enter denylist.rpz for the name of the zone.
Select Passthru from the drop-down list for the Policy Override value.
NOTE: The Policy will be changed once the RPZ policy action is verified.
Change the Severity to Critical.
Type in a comment to describe the purpose of the RPZ.
Click Next to continue.
Select the Use this Name Server Group button.
Choose RPZ Local NSG from the drop-down list.
Click Save & Close.
Restart Services when prompted.
Task 2 Solution: Rearrange Response Policy Zones in the correct order
In this task, we place the RPZs in the correct order, ensuring that traffic that should pass through is not blocked and vice versa. This will be very important when we eventually switch denylist.rpz to blocking traffic. We don't want it to accidentally block a domain that should be allowed, so we are placing it under allowlist.rpz.
Navigate to Data Management → DNS → Response Policy Zones.
Click Order Response Policy Zones on the toolbar.
Arrange the RPZs so that allowlist.rpz is first, and denylist.rpz is second.
Click OK.
Restart services when prompted.
Task 3 Solution: Add Block Domain Name Policy Rules to denylist.rpz
In this task, we will add a first rule to the denylist.rpz to block eicar.net
domain. We then add a second rule to the denylist.rpz to block all eicar.net
subdomains, ensuring that they are blocked.
Navigate to Data Management → DNS → Response Policy Zones.
Click the link to denylist.rpz.
Click the arrow next to the plus (+) symbol and select Block (No Such Domain) Rule from the drop-down list.
Select Block Domain Name (No Such Domain) Rule.
Enter
eicar.net
in the Name field.Type a Comment to describe the purpose of the rule.
Click Save & Close.
Click the arrow next to the plus (+) symbol and select Block (No Such Domain) Rule from the drop-down list.
Select Block Domain Name (No Such Domain) Rule then enter
*.eicar.net
in the Name field.Type a Comment to describe the purpose of the rule.
Click Save & Close.
Task 4 Solution: Add Block IP Address Rule to denylist.rpz
In this task, you add a rule to block a destination IP Address to the denylist.rpz. This IP Address 224.224.224.224 is an Infoblox-owned IP we will use it to simulate a known bogon domain bogon.singalorange.net.
Navigate to Data Management → DNS → Response Policy Zones.
Click the link to denylist.rpz.
Click the arrow next to the plus (+) symbol and select Block (No Such Domain) Rule from the drop-down list.
Select Block IP Address (No Such Domain) Rule.
Enter 224.224.224.224 in the IP Address or Network field.
Type a Comment to describe the purpose of the rule.
Click Save & Close.
Task 5 Solution: Add Block Client IP Address Rule to denylist.rpz
In this task, you add a rule to block DNS queries from a specific client IP address. The address used in the lab is 172.31.101.250. This is the IP address of the testing-linux machine. For this reason, the rule is left disabled until we test it.
Navigate to Data Management → DNS → Response Policy Zones.
Click the link to denylist.rpz.
Click the arrow next to the plus (+) symbol and select Block (No Such Domain) Rule from the drop-down list.
Select Block Client IP Address (No Such Domain) Rule.
Enter 172.31.101.250 in the Client IP Address or Network field.
Type a Comment to describe the purpose of the rule.
Check the Disable box.
Click Save & Close.
Task 6 Solution: Test denylist.rpz Local RPZ Rules
The newly created RPZs must be tested to ensure that traffic is being passed through for now. In this task, we will use dig and syslog entries to validate the local RPZ configurations for eicar.host
and the IP address 224.224.224.224. However, we will not be able to test the rule matching traffic coming from the testing-linux machine yet, as it is disabled.
Switch over to the testing-linux machine with the credentials (training/infoblox) and set the machine up for testing.
Open a terminal window, issue the command sudo
set-network-static-nios
, and verify that the machine now has the IP address 172.31.101.250 using the commandifconfig
.
Open a terminal window.
Use the dig command
dig @10.100.0.105 eicar.net
. The DNS server returns the address record. The DNS query and response have been allowed to pass through.Use the dig command
dig @10.100.0.105 bogon.singalorange.net
to perform a DNS query for the bogon domain. The DNS server returns the address record. The DNS query and response have been allowed to pass through.Switch back the the jump-desktop machine.
Navigate to Administration → Logs → Syslog.
Select the Member ibns1.techblue.net from the drop-down list.
Choose RPZ Incidents Logs from the Quick Filter drop-down list.
The DNS Query for
eicar.net
and 224.224.224.224 are listed in the messages section, in CEF format.The queries has matched a PASSTHRU rule in denylist.rpz.
We are confident that the denylist.rpz policy is matching the DNS requests/responses we want it to.
Task 7 Solution: Modify denylist.rpz to Block traffic
In the previous task, we verified that the denylist.rpz is matching the traffic we plan to block. In this task, we change the Policy Override value for denylist.rpz to Block (No Such Domain) to be able to finally stop the unwanted traffic.
Navigate to Data Management → DNS → Response Policy Zones.
Click the hamburger icon to edit denylist.rpz.
Select Block (No Such Domain) from the drop-down list for Policy Override.
Click Save & Close.
Restart the services when prompted.
Task 8 Solution: Verify denylist.rpz is Blocking traffic
In this task, we verify that queries to eicar.host
and the IP address 151.101.38.253 and queries from 172.31.101.250 are blocked, we need to enable the testing-linux rule before testing it.
Switch over to the testing-linux machine with the credentials (training/infoblox) and set the machine up for testing.
Open a terminal window.
Use the dig command
dig @10.100.0.105 eicar.net
. The DNS server should return an NXDOMAIN response.Use the dig command
dig @10.100.0.105 bogon.singalorange.net
to perform a DNS query for the bogon domain. The DNS server should return an NXDOMAIN response.Navigate back the the jump-desktop machine.
Navigate to Data Management → DNS → Response Policy Zones.
Click the link to denylist.rpz.
Click the check box for the 172.31.101.250 rule.
Click the hamburger icon, or the edit icon to edit the rule.
Remove the check from the Disable box.
Click Save & Close.
Navigate back the the testing-linux machine.
Open a terminal window.
Use the dig command
dig @10.100.0.105 training.infoblox.com
. The DNS server should return an NXDOMAIN response because the request is coming from testing-linux.Switch back the the jump-desktop machine.
Navigate to Administration → Logs → Syslog.
Select the Member ibns1.techblue.net from the drop-down list.
Choose RPZ Incidents from the Quick Filter drop-down list.
Click Toggle Multi line view link.
The DNS Query for
eicar.net
is listed in the messages section, in CEF format. The query has matched a Block No Such Domain rule in denylist.rpz.The DNS Query for 224.224.224.224 is listed in the messages section, in CEF format. The query has matched a Block No Such Domain rule in denylist.rpz.
The DNS Query for training.infoblox.com is listed in the messages section, in CEF format. The query has matched a Client IPBlock No Such Domain rule in denylist.rpz.