Date: 17-Feb :38

Transcription

1 Date: 17-Feb :38

2 Copyright Copyright(c) ThreatSTOP, Inc. All Rights Reserved NOTICE: All information contained herein is, and remains the property of ThreatSTOP, Inc. and its suppliers, if any. The intellectual and technical concepts contained herein are proprietary to ThreatSTOP, Inc. and its suppliers and certain aspects thereof are protected by United States Patent No. 8,533,822 and United States Patent No. 8,869,237, and are protected by trade secret or copyright law. US Government Entities: The ThreatSTOP service, software and documentation, as applicable, are "commercial computer software" and "commercial computer software documentation" developed exclusively at private expense by Threatstop, Inc. ("Threatstop"). Pursuant to FAR or DFARS and their successors, as applicable, use, reproduction and disclosure of the software and documentation is governed by the terms of Threatstop's commercial agreement. 2

3 Table of Contents Overview 5 Step-by-step guide 6 In the ThreatSTOP Portal 6 In the DNS Firewall Device 7 Logging and Restarting the Service 11 Sending Log Information to More Than One Destination 14 Testing 15 Index 16 3

4 Integrating with an Existing BIND 9.8+ Deployment 4

5 Overview The purpose of this document is to describe the integration process for ThreatSTOP DNS Firewall into an existing BIND 9.8+ deployment. This document is written under the condition that you have an existing DNS deployment and are looking to add the ThreatSTOP DNS Firewall to your existing network infrastructure. This is done by placing the DNS Firewall between your existing DNS configuration and your external connection. This will allow ThreatSTOP DNS Firewall to guard against hostile connections. A birds-eye view of the setup procedure is: Open a ThreatSTOP account if you have not already done so. Specify that you are setting up a DNS Firewall in order to receive any needed materials. In the Device section of the Portal, configure a new device with the following settings: Manufacturer: DNS Server Model: BIND 9.8+ Note: More information about setting up Devices in the Portal can be found in the Introduction You will then need to configure the rest of the Portal to service a ThreatSTOP DNS Firewall as explained in ThreatSTOP DNS Firewall. Configure BIND itself to act as a slave server for the zone that contains your policy. 5. Configure the client machines to be protected to use the ThreatSTOP DNS Firewall for address resolution. 5

6 Step-by-step guide The following steps will walk you through the configuration of BIND to serve you ThreatSTOP DNS Firewall. Note that these steps begin after the account creation process has finished. In the ThreatSTOP Portal 1. In the ThreatSTOP portal add a DNS Firewall policy. To do this: Click on Policies & Lists. Then on the DNS FW Policy tab. Select + Add Policy. Set a Policy name: in the corresponding field. If you want to change the default behavior of the RPZ Target Lists being used set it in the Default Behavior field. Note: The available behaviors are: NXDOMAIN NODATA PASSTHRU DROP Select the RPZ Target Lists you want to block. For our example we'll use the BASIC list with the default behavior. If you want a specific list to be treated differently from other included lists, change the Behavior dropdown to the desired action. Caution: This dropdown will override the Default Behavior field. Click on Submit to save your changes. 6

7 2. Click on Devices and then on + Add Device. Enter a Nickname for the device, this should probably be something descriptive of the device. Set the Manufacturer and Model to: Manufacturer: DNS Server Model: BIND 9.8+ Set the IP Type as defined by your network needs. Warning: Using a Dynamic IP address is far outside of best practices and is not recommended. Unexpected results can occur if this setting is used. The IP Address of the device is the external IP address (unsecured side of the firewall). This can be determined by visiting: Select the DNS Firewall policy you defined previously in the Policy drop down. In the DNS Firewall Device Login to the device as normal. Change to the BIND configuration directory cd /etc/bind Enter cat named.conf Verify that named.conf contains the following lines. If they are not present they will need to be added to the file: 5. /etc/bind/named.conf.options /etc/bind/named.conf.local After verifying that named.conf has the needed entries (or adding the same) you will need to adjust named.conf.options. To do this: Enter sudo vi named.conf.options Then add the following to the file: response-policy { zone "<RPZ Zone Name>"; 6. You'll also need to add the following information to named.conf.local 7

8 zone authorization (secret/key) logging Caution: You can only use one master IP. You will also need to contact ThreatSTOP support to receive your TSIG key. This is required to complete deployment. // // Do any local configuration here // key threatstop-threatstop { algorithm hmac-md5; secret "<insert TSIG key here>"; server { keys { threatstop-threatstop ; zone "<RPZ Zone Name>" { type slave; masters { ; file "/var/cache/bind/zones/<rpz Zone Name>"; allow-query { localhost; allow-transfer { localhost; allow-notify { none; logging { channel normal-log { file "/var/log/named/named.log" versions 3 size 1m; severity info; category default { normal-log; 8

9 channel named-rpz { file "/var/log/named/rpz.log"; severity debug; print-time yes; category rpz { named-rpz; Note: Eventually you'll want to change allow-query to something similar to the following: allow-query { localhost; our_clients; You can then add a section similar to the following above the zone policy definition: acl our_clients { /24; This will allow your internal client DNS servers to update their lists based on our RPZ data. 7. After adding the information above to named.conf, you will need to add the following line into a file called logrotate-ts in the /etc/cron.hourly/ directory. To do this enter the following from the command prompt: Type cd /etc/cron.hourly and press ENTER. Type sudo vi logrotate-ts and press ENTER. This may require you re-enter your login password. Tap the i key to enter Insert mode. Add the opening statement #!/bin/sh and tap ENTER Type /usr/sbin/logrotate -f /etc/logrotate.d/threatstop Tap Esc, then press :wq and ENTER 9

10 8. The following commands will setup the directory structure for deployment, and set the appropriate permissions for each directory: sudo mkdir /var/cache/bind/zones sudo chmod 755 /var/cache/bind/zones sudo chown bind:bind /var/cache/bind/zones sudo mkdir /var/log/named sudo chmod 755 /var/log/named sudo chown bind:bind /var/log/named This will be useful if you decide to uninstall, and choose to remove BIND completely. 9. Finally, enter sudo service bind9 restart and press ENTER. Note: sudo is not required for users logged in with administrative privileges. 10

11 Logging and Restarting the Service After configuring the BIND server to use ThreatSTOP's Threat Intelligence lists, you can start sending your logs to ThreatSTOP, which will then be used to help re-enforce our community's Threat Intelligence. Before starting in on this section, certain prerequisites need to be met: Your system will need to be configured to run logrotate, and must have curl, stat, md5sum, and cut utilities. Note: The following packages are available for these utilities on Ubuntu 14.04: curl: sudo apt-get install curl logrotate: sudo apt-get install logrotate stat, md5sum, and cut are all part of the core Ubuntu distribution, and should automatically install with the OS. After ensuring these programs are present you can start uploading logs back to ThreatSTOP using logrotate to do this: 1. Change directory to the logrotate.d folder and create a new file called threatstop cd /etc/logrotate.d sudo vi threatstop 11

12 2. Copy and paste the example below to /etc/logrotate.d/threatstop /var/log/named/rpz.log { rotate 7 size 100k missingok notifempty delaycompress compress create 0644 bind postrotate /usr/sbin/service bind9 restart > /dev/null /usr/bin/curl -v -F "upfile=@$1.1" -F "upfile_size=`/usr/bin/stat -c %s $1.1`" -F "md5_client=`/usr/bin /md5sum $1.1 /usr/bin/cut -d' ' -f 1`" -F "fw_ip=<device IP>" pl #insert command to send to SIEM system endscript } Adjust the value fw_ip to match the IP address entered on the portal. This is typically the external IP provided by Note: The curl solution above assumes the following: The system has curl, stat, md5sum and cut and they are located at the paths specified logrotate, rotates logs and the latest rotated log is $1 with ".1" appended. In this example it would be: /var/log/named/rpz.log.1 The user will update the fw_ip value to the actual value for their device 3. Enter sudo service bind9 restart and press ENTER. 12

13 4. Enter sudo service bind9 reload and press ENTER. Note: sudo is not required for users logged in with administrative privileges. 13

14 Sending Log Information to More Than One Destination The configuration above will upload the rotated file to ThreatSTOP and if specified wherever the second command in the postrotate section sends it. If the data is to be sent to a syslog server however, the process is simplified by adding a second BIND channel in rpz.log as shown in the configuration below: /etc/bind/named.conf(.local) logging { channel remote_syslog_rpz { syslog local4; severity debug; print-time yes; category rpz { named-rpz; remote_syslog_rpz; Follow this up with forwarding the syslog configuration to the SIEM (based on your setup). For example, with rsyslog: /etc/rsyslog.d/50-default.conf 14

15 Testing To test that your configuration is up and running you'll need to setup a temporary test policy in the ThreatSTOP portal. Any policy added to this list should have the RPZ behavior set to NXDOMAIN or DROP. After setting this: 1. Go to known good website (i.e., to verify that you are able to connect. 2. Go to a known bad website (i.e., bad.threatstop.com). Based on your testing policy's settings you should receive a rejection screen (for NXDOMAIN) or have your connection time out (DROP). 15

16 Index 16