2549 - Configuring Blocking local RPZ rules in NIOS

Scenario

As a measure to increase your corporate DNS security posture, a corporate compliance policy was created, the policy dictates that specific Domains and IP Addresses are blocked for all users. Any user attempting to access a specific site must be redirected to a walled garden where they are presented with a web page outlining corporate policy.

Your current task is to create a Blocking policy blocking known malicious domains from being accessed.

Course References

• 2031: Configuring Local RPZ in NIOS

Estimate Completion Time

• 25 to 30 minutes

Credentials

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.

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

• Task 1: Apply the RPZ license to ibns1.techblue.net and ibns2.techblue.net

• Task 2: Create local RPZ - denylist.rpz

• Task 3: Arrange Response Policy Zones in the correct order

• Task 4: Add Block Domain Name Policy Rules to denylist.rpz

• Task 5: Add Block IP Address Rule to denylist.rpz

• Task 6: Add Block Client IP Address Rule to denylist.rpz

• Task 7: Testing Blocking Local RPZ Rules

• Task 8: Modify denylist.rpz to Block (NXDOMAIN) instead of Passthru

• Task 9: Verify the Block IP Address (No Such Domain) Rule

• Task 10: Verify the Block Client IP Address (No Such Domain) Rule

Task 1: Apply the RPZ license to ibns1.techblue.net and ibns2.techblue.net

• Apply the RPZ license file stored on /mnt/shared/licenses.

• Verify that DNS licenses are enabled and running on members that will be hosting RPZ.

• Add the RPZ licenses located in the shared Drive/Licenses folder under the name RPZ.txt

Task 2: Create local RPZ - denylist.rpz

• Create a local RPZ to block unwanted traffic without affecting legitimate traffic

  1. Create a Local RPZ named denylist.rpz

  2. Set the override value to passthru and severity level to critical

  3. Use the RPZ Local NSG server group

  4. Verify the creation of the RPZ

Task 3: Arrange 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

  1. Allowlist.rpz

  2. Denylist.rpz

Task 4: Add Block Domain Name Policy Rules to denylist.rpz

• Add a rule to the denylist.rpz to block the naughtysite.signalorange.net domain and all its sub-domains

Task 5: Add Block IP Address Rule to denylist.rpz

• Add a rule to block a destination IP Address 244.244.244.244 in the denylist.rpz. The host bogon.signalorange.net resolves to IP Address 224.224.224.224

Task 6: 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 7: Testing Blocking 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 command ifconfig.

• Use dig and syslog entries to validate the local RPZ configurations.

  • When using dig please specify the server 10.100.0.105 in the command using the @ symbol, i.e.: dig @10.100.0.105 <domain>

If you see the error message "Failed to reload network settings: No such file or directory", please re-enter "sudo set-network-static-nios".

Task 8: Modify denylist.rpz to Block (NXDOMAIN) instead of Passthru

• In the previous task, we verified that the denylist.rpz is matching the traffic we plan to block. In this task, you change the Policy Override value for denylist.rpz to Block (No Such Domain)

• When using dig please specify the server 10.100.0.105 in the command using the @ symbol, i.e.: dig @10.100.0.105 <domain>

Task 9: Verify the Block IP Address (No Such Domain) Rule

• In this task, you verify that queries to the IP address 224.224.224.224 are blocked by denylist.rpz. This is the IP Address of the host bogon.signalorange.net.

• When using dig please specify the server 10.100.0.105 in the command using the @ symbol, i.e.: dig @10.100.0.105 <domain>

Task 10: Verify the Block Client IP Address (No Such Domain) Rule

• In this task, you test that queries from the Client IP Address 172.31.101.250 are blocked by denylist.rpz

This is the IP Address of the Testing-Linux. Ensure you disable the rule after testing.

Solutions

Task 1 Solution: Apply the RPZ license to ibns1.techblue.net and ibns2.techblue.net

• In this task, you apply the RPZ license file stored on the Jump-desktop. The license file is called RPZ.txt and is located in the /home/training/Documents/Licenses folder.

  1. Navigate to Grid → Licenses.

  2. Click the plus (+) symbol to add the RPZ license.

     

  3. Select the Upload License File radio button. Click Select File.

     

  4. Navigate to shared Drive/Licenses. Click the RPZ.txt file and select Open.

     

  5. Click Save License(s).

     

  6. Click Filter On and use a quick filter to search for RPZ licenses. There are two licenses associated with ibns1.techblue.net as this member is part of an HA pair.

     

Task 2 Solution: Create local RPZ - denylist.rpz

• In this task, you 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.

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click the plus (+) symbol to add a new RPZ.

     

  3. Select Add Local Response Policy Zone and click Next.

     

  4. Enter denylist.rpz for the name of the zone. Select Passthru from the drop-down list for the Policy Override value. The Policy will be changed once the RPZ policy action is verified.

     

  5. Change the Severity to Critical. Type in a comment to describe the purpose of the RPZ. Click Next to continue.

     

  6. Select the Use this Name Server Group button. Choose RPZ Local NSG from the drop-down list. Click Save & Close.

     

Task 3 Solution: Arrange Response Policy Zones in correct order

• In this task, you place the RPZs into the correct order, ensuring that traffic that should pass through is not blocked, and vice versa.

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click Order Response Policy Zones on the toolbar.

     

  3. Drag and drop the zones into the correct order. Alternatively, use the arrows to move the zones up or down in the list.

     

  4. Arrange the RPZs so that allowlist.rpz is first, and denylist.rpz is second. Click OK.

     

  5. Restart services.

Task 4 Solution: Add Block Domain Name Policy Rules to denylist.rpz

• In this task, you add a rule to the denylist.rpz to block the  naughtysite.signalorange.net domain. You then add a second rule to the denylist.rpz to block *.naughtysite.signalorange.net ensuring that all labels to the left of the domain are blocked.

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click the link to denylist.rpz.

     

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

     

  4. Enter naughtysite.signalorange.net in the Name field. Type a Comment to describe the purpose of the rule. Click Save & Close.

     

  5. Add a rule to Block all labels for the domain, ensuring DNS queries such as www.naughtysite.signalorange.net, will be blocked. 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 *.naughtysite.signalorange.net in the Name field. Type a Comment to describe the purpose of the rule.

  6. Click Save & Close.

     

Task 5 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. The host bogon.signalorange.net resolves to IP Address 224.224.224.224.

• We will use this address in our Block IP Address (No Such Domain) Rule.

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click the link to denylist.rpz.

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

     

  4. 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 6 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 10.100.0.10. This is the IP address of the Linux Desktop. For this reason, the rule is left disabled until we test it.

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click the link to denylist.rpz.

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

     

  4. Enter 172.31.101.250 in the Client IP Address or Network field. Type a Comment to describe the purpose of the rule.

  5. Check the Disable box.

  6. Click Save & Close.

     

Task 7 Solution: Testing Blocking Local RPZ Rules

If you see the error message "Failed to reload network settings: No such file or directory", please re-enter "sudo set-network-static-nios".

• The newly created RPZs must be tested before being implemented in production. In this task, you use dig and syslog entries to validate the local RPZ configurations.

  1. Switch over to the testing-linux machine with the credentials (training/infoblox) and set the machine up for testing.

     1. 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 command ifconfig

        

  2. In the terminal window on the Testing-Linux, run the command dig @10.100.0.105 naughtysite.signalorange.net.
     The DNS server returns the address record. The DNS query and response have been allowed to pass through.

     

  3. Navigate back to the Jump-Desktop machine and check syslog for a record of the RPZ query. Navigate to Administration → Logs → Syslog → Active.
     Select Member ibns1.techblue.net from the drop-down list.

  4. Choose RPZ Incidents from the Quick Filter drop-down list.
     The DNS Query for naughtysite.signalorange.net is listed in the messages section, in CEF format.
     The query 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 8 Solution: Modify denylist.rpz to Block (NXDOMAIN) instead of Passthru

• In the previous task, we verified that the denylist.rpz is matching the traffic we plan to block. In this task, you change the Policy Override value for denylist.rpz to Block (No Such Domain).

  1. Navigate to Data Management → DNS → Response Policy Zones.

  2. Click the check box next to the entry for denylist.rpz. Click the hamburger icon, or the edit icon to edit denylist.rpz.

     

  3. Select Block (No Such Domain) from the drop-down list for Policy Override. Click Save & Close.

     

  4. Restart the services when prompted.

  5. Open a terminal window on the Testing-Linux machine. Repeat the dig command to lookup naughtysite.singnalorange.net.
     The result shows the effect of the policy in denylist.rpz.
     The DNS response returns a value of NXDOMAIN. In the ADDITIONAL SECTION, you can see the name of the RPZ triggered by the initial DNS request – denylist.rpz.

     

  6. Navigate back the the Jump-Desktop machine, under Administration → Logs → Syslog → Active. Select Member ibns1.techblue.net from the drop-down list.

  7. Choose RPZ Incidents from the Quick Filter drop-down list. The DNS Query for naughtysite.signalorange.net is listed in the messages section, in CEF format.
     The query has matched a Block No Such Domain rule in denylist.rpz.

     

Task 9 Solution: Verify the Block IP Address (No Such Domain) Rule

• In this task, you verify that queries to the IP address 224.224.224.224 are blocked by denylist.rpz. This is the IP Address of the host bogon.signalorange.net.

  1. Open a terminal window on the Testing-Linux. Run the command dig @10.100.0.105 bogon.signalorange.net.
     The command output shows the DNS query was for the A record of bogon.signalorange.net.

  2. The name server has returned an NXDOMAIN response.

     

  3. Navigate back the the Jump-Desktop machine, under Administration → Logs → Syslog. Select Member ibns1.techblue.net from the drop-down list.

  4. Choose RPZ Incidents from the Quick Filter drop-down list.
     The DNS Query for bogon.signalorange.net is listed in the messages section, in CEF format.
     The query has matched a Block No Such Domain rule in denylist.rpz.

     

Task 10 Solution: Verify the Block Client IP Address (No Such Domain) Rule

This is the IP Address of the Linux Desktop. Ensure you disable the rule after testing, otherwise none of the other labs will work

• In this task, you test that queries from the Client IP Address 172.31.101.250 are blocked by denylist.rpz.

  1. Open a terminal window on the Testing-Linux. Run the command dig training.infoblox.com.
     The output of the command shows the DNS server returned the A record for training.infoblox.com.

     

  2. Navigate back the the Jump-Desktop machine, under Data Management → DNS → Response Policy Zones. Click the link to denylist.rpz.

     

  3. Click the check box for the 172.31.101.250 rule. Click the hamburger icon, or the edit icon to edit the rule.

     

  4. Remove the check from the Disable box. Click Save & Close.

     

  5. Open a terminal window on the Testing-Linux machine. Run the command dig @10.100.0.105 http://training.infoblox.com .
     The result shows the effect of the policy in denylist.rpz. The DNS response returns a value of NXDOMAIN.
     In the ADDITIONAL SECTION, you can see the name of the RPZ triggered by the initial DNS request – denylist.rpz.

     

  6. Navigate back the the Jump-Desktop machine, under Administration → Logs → Syslog → Active. Select Member ibns1.techblue.net from the drop-down list.

  7. Choose RPZ Incidents from the Quick Filter drop-down list. The DNS Query for http://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.

     

  8. Navigate to Data Management → DNS → Response Policy Zones. Click the link to denylist.rpz.

  9. Click the check box next to the entry for 172.31.101.250. Click the hamburger icon, or the edit icon to edit the rule.

  10. Check the Disable box. Click Save & Close.

  11. Open a terminal window on the Testing-Linux machine. Run the command dig @10.100.0.105 http://training.infoblox.com .
      The output of the command shows the DNS server returned the A record for http://training.infoblox.com.