Page tree

Contents

ThreatSTOP Account Setup

Setting up a ThreatSTOP account for Azure is simple. The first thing you will need is a ThreatSTOP account, which you can sign-up for here. After providing your information and logging into your account you'll be presented with a pop-up similar to the one displayed to the right.

Click Copy Key to Clipboard to save this value, you will need it during the Azure side of the account creation process.

 

  1. Login to your Azure portal at https://portal.azure.com.

  2. Click New.





  3. Search for ThreatSTOP.








  4. Click on ThreatSTOP DNS Firewall in the search results.




  5. Click Create.













  6. There are five blades of information to provide prior to deployment. Fill out each blade in turn, click on OK at the end of each blade to save the new settings.
    1. Basics blade

      1. DNS Firewall VM name – choose a server name. Because TS recommends deploying two DNS firewalls (for redundancy), a suitable name is something like "TSDNSFirewall1" for your first deployment, or "TSDNSFirewall2" for your second deployment.
      2. Admin username – this is the root username for the DNS firewall, e.g. "tsadmin" or "dnsadmin", etc.
      3. Authentication Type - select Password or SSH public key
        1. Password – make this a complex password. You will use SSH to remote into your DNS firewall using this password.
        2. SSH public key - copy and paste an OpenSSH public key, which can be generated using ssh-keygen on Linux/OS X or PuttyGen on Windows

          After setup is complete you will want to change the SSH rule to only allow access from inside your network. This is covered in Add a Network Security Group to your client Subnet - Securing the SSH Login Method.

      4. Resource Group – you can select an existing Resource Group or create a new one for your DNS Firewalls.
      5. Location – the Azure location must match the location of the Virtual Network (vnet) you wish to protect.
    2. Network and Storage Settings
      1. Virtual Machine Size – select a virtual machine size. Your ThreatSTOP advisor can help you select an appropriate VM size based on your predicted workload. Cost varies by machine size.

        Note:

        Azure D2 is our default deployment VM, A3 is also acceptable.











      2. Virtual network – select the Azure virtual network on which you wish to add DNS firewall protection. If you create a new virtual network, you will also have to provide the address space in CIDR format, for example 10.1.0.0/16. For more information see: Azure vnet documentation (https://azure.microsoft.com/en-us/documentation/services/virtual-network/)







      3. Subnet - select or create the subnet where your DNS Firewall will reside. Best practices dictate that your DNS Firewall should be in a separate subnet (e.g. a DMZ) from the machines you wish to protect. You should select an existing subnet for the DNS Firewall. If you are using an existing virtual network and would like to create a new subnet for your DNS Firewall, you should create the subnet first through the Azure portal prior to installing this marketplace solution template.







      4. Public IP address - name of the subnet that will provide the public IP address for your DNS firewall.










      5. DNS Prefix - enter a custom prefix for the FQDN of the public ip address for the DNS firewall. It should be lowercase letters and numbers only, dashes allowed.











      6. Storage Account – select or create the storage account and storage type to hold the virtual machine. Because the DNS Firewall is not storing critical data, premium storage is not needed in most situations. For more information see: Azure storage documentation (https://azure.microsoft.com/en-us/documentation/services/storage/).









    3. Firewall Configuration

      1. License key – enter your ThreatSTOP license key. This is the API key you copied to the clipboard in ThreatSTOP Account Setup.

        Note:

        A license key can be obtained from our Sales team. To request a license key contact us through:





    4. Summary – review your deployment selections and click OK if no changes are needed.











    5. Buy – Review the Terms and Conditions, then click the Create button to start the deployment process. This process will take around 10 minutes to complete.












    This will close the setup windows and an icon similar to the following will appear on your Azure Dashboard. Once this changes your Resource Group will be available, and you'll be able to login to your new DNS firewall.

Deploying a Second ThreatSTOP DNS Firewall

To deploy a second ThreatSTOP DNS Firewall (for redundancy), follow the same steps above, ensuring that you:

  1. Enter a different name for your firewall, e.g. "TSDNSFirewall2"
  2. Select the same Resource Group as the first DNS Firewall
  3. Select the same Virtual Network
  4. Select the same Subnet
  5. Use the same license key and ThreatSTOP account credentials. ThreatSTOP DNS Firewall is licensed in pairs, so the same license key will work for up to two servers.

Note that your DNS Firewalls will be deployed into an Azure Availability Set named "TSAvailabilitySet".

Connecting to Your DNS Firewall via SSH

After your resource group has been successfully deployed, you will be able to login to your DNS Firewall using SSH. To find the IP address to login:

  1. Open the resource group by clicking on it's icon in the Azure Dashboard.

  2. Click on the icon for your Virtual Network () . This will open the Virtual network blade. The connected devices will list the IP address for your DNS Firewall device. This can be used with your favorite SSH program to access the server. The username and password provided in 6.a.iv will allow login to the server.

Configuring your clients for ThreatSTOP protection

The client machines must be configured to use your new ThreatSTOP DNS Firewalls for DNS resolution. The easiest way to make this configuration is by changing the DNS settings for your virtual network:

  1. In the Azure portal, click on the resource group containing the client subnet.

  2. Click on the virtual network () containing the client subnet.
  3. Click on DNS servers ().
  4. Click on Custom DNS.
  5. Enter the internal IP address of your primary DNS firewall. For new virtual networks, for example, this address is 10.0.1.4. Please verify the IP address in your installation.
  6. If you have deployed a second DNS Firewall, enter its internal IP address as the Secondary DNS server.
  7. Click the Save button.
    You may need to restart or reload the network configuration on your client machines in order to use the new DNS settings. In Ubuntu, the command to reload the network configuration without having to restart your virtual machine is:

    sudo ifdown eth0 && sudo ifup eth0
    


     

Add a Network Security Group to your client Subnet

Best practices include adding an Azure Network Security Group (NSG) to your client subnet so that DNS queries can only be made to the DNS Firewalls. You should only add a new NSG if your DNS Firewalls reside in a separate DMZ subnet and NOT in the same subnet as your protected clients. To add the Network Security Group to your client subnet:

  1. In your Azure portal open the Resource Group for your DNS Firewall, click on on the Add + button.

  2. Type "network" and select Network Security Group (NSG) when it appears as an option.



  3. Use the Resource Manager as your deployment model and click on Create.

  4. Enter a name for your NSG, e.g. "TSDNSClientNSG" and select the Resource Group containing your protected virtual network.
  5. Once deployment of the NSG is completed, select the new NSG.
  6. Click Outbound Security Rules









  7. Add the two following Outbound rules:
    1. Name: AllowToOwnDNS
      Priority: 120
      Destination IP address range: [enter the CIDR of your DNS Firewall DMZ, e.g. 10.0.1.0/24, or just the CIDR of your two firewalls, e.g. 10.0.1.4/31]

      Note:

      This will be the same IP address or CIDR range as you use to login to the DNS Firewalls.

      Destination Port Range: 53
      Source: Any
      Protocol: Any
      Source Port Range: *
      Action: Allow

    2. Name: BlockAllDNSQueries
      Priority: 130
      Destination: Any
      Destination Port Range: 53
      Source: Any
      Protocol: Any
      Source Port Range: *
      Action: Deny


    You may also want to click the Default rules button to add the Azure default outbound rules for Internet traffic. Rules are checked in the order of priority. Once a rule applies, no more rules are tested for matching.
  8. You should also create inbound rules in the NSG to allow whatever inbound access you need to your client subnet. Typically, you would allow RDP and/or SSH traffic from a jumpbox or other network, plus any other ports needed for your network. By default, the DNS Firewall allows SSH access from the entire Internet. You may wish to restrict access by customizing your NSG following installation. The process to do this is explained in Securing the SSH Login Method.
  9. Assign the newly created NSG to your client subnet by selecting the subnet in the Azure portal, clicking on the Network security group button, selecting the newly created "TSDNSClientNSG" and clicking the Save button. No reboot is required at this time.

Securing the SSH Login Method

After initial setup has been completed it's recommended to modify the SSH Login method to only be available from computers inside your network. To do this create an inbound security rule in the NSG with the following rules:

Name: AllowAccessToSSH
Priority: 100
Source: CIDR block
Source IP Address range: [enter the CIDR of your management device, e.g. 192.0.2.0, this will need to be a fixed address to allow the data from the management system to pass through to the DNS firewall]
Protocol: TCP
Source Port Range
: 22
Destination: [enter the CIDR of the firewall device, eg. 10.0.1.14]
Destination Port Range: 22
Action: Allow

Name: RestrictAccessToSSH
Priority: 130
Source: Any
Protocol: Any
Source Port Range
: *
Destination: CIDR block
Destination Port Range: [enter the CIDR of the firewall device, eg. 10.0.1.14]
Action: Deny

Using the ThreatSTOP DNS Firewall to protect networks outside Azure

By default, the ThreatSTOP DNS Firewalls are configured to restrict DNS queries to your Azure virtual network. You may modify the configuration of your DNS Firewalls to allow queries from networks external to Azure.

  1. Modify the TSDNSNetworkSecurityGroup – this NSG is assigned to your DNS Firewall subnet and restricts inbound DNS traffic (port 53) to just the ThreatSTOP Masters at 67.207.213.0/24 and 192.124.129.0/24. These rules should not be modified. You may add additional rules to allow inbound DNS queries on port 53 from the networks of your choice.
  2. The DNS Firewalls use BIND and are configured with an ACL limiting recursive queries to the Azure virtual network. You must also modify the BIND configuration file by adding your external networks to the ACL for recursive queries:
    1. SSH into your DNS firewall
    2. After logging in enter the following command:

      sudo vi /etc/bind/named.conf.options
    3. Modify the following line to include your external network in CIDR format, separated by a semicolon:

      acl "trusted" { localnets; 10.0.0.0/16; };
    4. Then restart the service by issuing the command:

      sudo service bind9 restart
  3. You will then need to adjust your network to use the Azure DNS Firewall as it's DNS service, using the Virtual Net's external IP address.

Changing your ThreatSTOP DNS Policy

Reconfigure BIND

Your BIND configuration needs to be told to use the new policy name. ThreatSTOP provides a script to assist with the reconfiguration. This script is called TS_change_policy.pl and has been placed in /usr/local/bin on the DNS firewall. To execute it, include the name of the new policy (as listed on the Policies tab in the ThreatSTOP Portal) as an argument, appending “.rpz.threatstop.local” to the policy name we selected. Be sure to use sudo when executing the command on the DNS firewall:

tsadmin@fwVM:~$ sudo TS_change_policy.pl <RPZ Zone Name>


Detected existing policy '<RPZ Zone Name>'.
Replace this with policy '<RPZ Zone Name>' (Y/N) ? Y

Troubleshooting

If you receive an error, your new policy may not have finished propagating to the ThreatSTOP servers. You can test if this is the case by issuing a dig command to manually request the RPZ from ThreatSTOP’s RPZ server at 192.124.129.51:

dig @192.124.129.51 -t axfr -y threatstop-threatstop:<API Key><RPZ Zone Name>

Note:

 The API key can be found in your ThreatSTOP account, in one of two locations:

  • My Account: Generated keys will be listed at the bottom of the screen, or new keys can be created. For Azure keys, allow full permissions or deployment errors can occur.
  • Dashboard: Generated keys will appear at the bottom of the Dashboard.

This dig command can come in handy for troubleshooting. If the above dig fails, but a dig request using “highseverity.rpz.threatstop.local” as the policy name succeeds, then it indicates that the policy is not available. Check the spelling of the policy name, and contact ThreatSTOP if it’s been more than a few hours since you created the custom policy.

You can also look at /etc/bind/named.conf.local and /etc/bind/named.conf.options to see how the BIND configuration has changed after running the TS_change_policy.pl script.