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.

 

Azure Portal Setup

Setting up the ThreatSTOP IP firewall on Microsoft Azure is a straightforward process that should take less than an hour to fully complete. After initial setup and testing, your ThreatSTOP IP Firewall can be in place, and defending your network by blocking inbound and outbound connections to malicious IP addresses.

  1. Log into portal.azure.com
  2. Click New.

  3. Search for ThreatSTOP.

  4. Click on the ThreatSTOP IP Firewall link.

  5. Click Create.

Provisioning an IP Firewall

Basics

  1. Enter a ThreatSTOP Firewall VM name
  2. Provide an Admin username
  3. Select an authentication type:
    1. Provide a Password or SSH Key.
  4. Select a subscription model
  5. Create a new resource group and provide a name.
  6. Select a datacenter location for your virtual environment.
  7. Click OK.

Network and Storage Settings

  1. Select your virtual machine size
  2. Create a Virtual network, or select one that exists in the datacenter to which the network is being deployed.
  3. Create a subnet.

    Caution:

    A new sub-net will need to be created prior to deployment for the IP firewall if one does not already exist. For testing purposes you may wish to deploy a new virtual net alongside an existing vnet, and then roll the servers into the existing vnet if they meet approval.

  4. Create a new public address

  5. Provide a DNS Prefix.
  6. Configure a Storage Account.

Firewall Configuration

  1. Enter the License/API key you copied in ThreatSTOP Account Setup above.
  2. Click OK.

Summary

  1. Verify that everything looks correct and click OK.

Buy

  1. Review the Terms of Use and Privacy Policy then click Purchase.
    This will begin deploying the ThreatSTOP IP Firewall into your Azure instance, including creating a Resource Group, firewall VM, and adding your new device to your ThreatSTOP account. You can verify that the deployment to your account was successful by logging into https://www.threatstop.com and looking for a device that has a numeric nickname and has its Manufacturer / Model set to Microsoft / Azure IP Firewall.

    If this appears then the deployment was successful and you can move on to Testing the IP Firewall or Final Subnet Configuration.

Testing the IP Firewall

Before deploying the IP Firewall into your live environment, it is advisable to test that the firewall is performing as expected. One way of doing this is to deploy a temporary VM into the Clients subnet, connect to both it and the firewall, and monitor for traffic flowing across the firewall.

  1. In Azure deploy a new Ubuntu clientVM into the same resource group as the IP firewall. For our example we are going to use the existing TSProtectedVnet but make sure the clientVM is assigned to the Clients subnet.
  2. The default settings are OK with two exceptions:
    1. Choose none for Public IP address as this will be a private subnet.
    2. Choose none for Network Security Group (NSG) for simplicity.
  3. Click on OK to bring up the Summary of the VM device.
  4. Click on OK again begin deploying the test VM.
  5. While the clientVM is being deployed, it's safe to add it into the routing table.To do this:
    1. Open the Resource Group you just created.
    2. Click on the Route Table () created by the solution template
    3. Click on Subnets.
    4. Click + Associate.
    5. Choose the Virtual Network.
    6. Select TSProtectedVNet.
    7. Choose Subnet.
    8. Associate it with the Clients subnet.
    9.  Click OK.
        
  6. To test, open up two SSH sessions to the firewall's public IP. In one window ssh into the private IP of the client vm (the firewall is a jump box to the client): 
  7. Run the following command on the firewall:

    sudo tcpdump -i eth0 proto ICMP -n

     

  8. On the clientvm, ping bing.com or similar and watch for the packets passing through the firewall. If you get a response on the client and also see packets flowing, the setup is complete. The examples below show a test ping for reference of what you should see:

     ServerClient
    Test One:
    admin@DocumentationTest1:~$ sudo tcpdump -i eth0 proto ICMP -n
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    00:25:04.569136 IP 10.7.0.4 > 204.79.197.200: ICMP echo request, id 6065, seq 1, length 64
    00:25:04.569762 IP 204.79.197.200 > 10.7.0.4: ICMP echo reply, id 6065, seq 1, length 64
    00:25:05.571144 IP 10.7.0.4 > 204.79.197.200: ICMP echo request, id 6065, seq 2, length 64
    00:25:05.572268 IP 204.79.197.200 > 10.7.0.4: ICMP echo reply, id 6065, seq 2, length 64
    admin@DocumentationTest1:~$ ping bing.com
    PING bing.com (204.79.197.200) 56(84) bytes of data.
    64 bytes from a-0001.a-msedge.net (204.79.197.200): icmp_seq=1 ttl=121 time=0.637 ms
    64 bytes from a-0001.a-msedge.net (204.79.197.200): icmp_seq=2 ttl=121 time=1.14 ms
    64 bytes from a-0001.a-msedge.net (204.79.197.200): icmp_seq=3 ttl=121 time=0.645 ms
    64 bytes from a-0001.a-msedge.net (204.79.197.200): icmp_seq=4 ttl=121 time=0.839 ms
    
     ^C
    --- bing.com ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 11002ms
    rtt min/avg/max/mdev = 0.591/0.780/1.596/0.289 ms
    
    Test Two:
    admin@DocumentationTest1:~$ sudo tcpdump -i eth0 proto ICMP -n
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
    00:26:02.636465 IP 10.7.0.4 > 64.87.3.133: ICMP echo request, id 6072, seq 1, length 64
    00:26:02.648962 IP 64.87.3.133 > 10.7.0.4: ICMP echo reply, id 6072, seq 1, length 64
    00:26:03.637502 IP 10.7.0.4 > 64.87.3.133: ICMP echo request, id 6072, seq 2, length 64
    00:26:03.652238 IP 64.87.3.133 > 10.7.0.4: ICMP echo reply, id 6072, seq 2, length 64
    admin@DocumentationTest1:~$ ping bad.threatstop.com
    PING bad.threatstop.com (64.87.3.133) 56(84) bytes of data.
    64 bytes from fadc-c3.fa01.fa2-23.host4.24101.americanis.net (64.87.3.133): icmp_seq=1 ttl=52 time=12.5 ms
    64 bytes from fadc-c3.fa01.fa2-23.host4.24101.americanis.net (64.87.3.133): icmp_seq=2 ttl=52 time=14.7 ms
    64 bytes from fadc-c3.fa01.fa2-23.host4.24101.americanis.net (64.87.3.133): icmp_seq=3 ttl=52 time=12.9 ms
    64 bytes from fadc-c3.fa01.fa2-23.host4.24101.americanis.net (64.87.3.133): icmp_seq=4 ttl=52 time=12.3 ms
    [...]
     ^C
    --- bad.threatstop.com ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 7010ms
    rtt min/avg/max/mdev = 12.270/12.795/14.771/0.777 ms
    

Final Subnet Configuration

At this point if testing proved successful you may associate your Clients Subnet with the Route Table created during deployment.

Caution:

These instructions are a simulation of the steps you will perform to go live in a production environment.

  1. Click on the Route Table () created by the solution template and associate it with your production subnet.

    Caution:

    Implementing the route table is a critical step, as it routes all traffic from your network through the new firewall VM. Due to this, all testing needs to be completed and verified as working. If your setup is not correct changing this association can impact your Internet access.

  2. Click OK to finalize deployment of the IP Firewall.

Changing your IP Tables Policy Name

Changing the policy used by the IP firewall is achieved by logging into the ThreatSTOP portal, changing the policy internal to the portal, and then running an update script on the firewall to update the block list and allow list.To do this:

  1. Login to the ThreatSTOP portal.
  2. Click on Devices.
  3. Click on the Edit Icon () next to the device undergoing the policy change.
  4. Select the Policy you want to use, then click Next, and close the window.
  5. Click on the Documentation icon (), to open this document in the portal.
  6. Use SSH to login to your IP Tables firewall.
  7. Copy and paste this command into the SSH session and press enter:

    sudo -u threatstop perl /opt/threatstop/TS_change_policy.pl <block list name>..threatstop.local <allow list name>..threatstop.local

  8. A display similar to the following should scroll by press Y when prompted to proceed:

    tsadmin@tsiptest2:~$ sudo -u threatstop perl /opt/threatstop/TS_change_policy.pl <block list name>..threatstop.local <allow list name>..threatstop.local
    [INFO ] : Loading existing configuration
    [INFO ] : Initializing data from conf file
    [INFO ] : Successfully queried for policy '<block list name>..threatstop.local'
    [INFO ] : Successfully queried for policy ' <allow list name>..threatstop.local'
    [INFO ] : Detected existing policies :
    [INFO ] :     block : basic.threatstop.local
    [INFO ] :     allow : dns.threatstop.local
    [INFO ] : Proposed replacement policies :
    [INFO ] :     block : <block list name>..threatstop.local
    [INFO ] :     allow : <allow list name>..threatstop.local
    [INFO ] : Proceed (Y/N)?
    y
    [INFO ] : Done

    This will update the policies on your IP firewall device to match your ThreatSTOP account.