The ThreatSTOP threat intelligence Web service should work with any firewall, or other traffic management device, that can make a forwarding decision based on a DNS lookup. For systems without that native capability, it should be simple to write scripts on the management stations that update rules using lists retrieved from DNS. Below we have - as well as the generic overview - implementation details for a number of the most common firewalls

 

Generic Overview

ThreatSTOP operates by providing multi-host Fully Qualified Domain Name forward (A record), APL (RFC3123) and TXT record lookups. Each A lookup resolves to up to 4000 IP addresses. For firewalls that can use APL and TXT records, we propagate entire subnets, and typically only requre a single lokup, as we have a method for extending lists if necessary.

Because the lists are so long, TCP DNS queries must be enabled.

To use ThreatSTOP block lists, all the device that will use them must point to the ThreatSTOP DNS servers for name resolution.

This means setting the DNS client in the firewall to point to: 64.87.26.147, 67.89.120.20 and/or 24.249.204.58 and ensuring that the firewall can resolve names using UDP and TCP.

Then, rules that reference the block list, and take the desired action, must be configured. The lists are used in place of the IP address in the rule or object configuration on the firewall. The specific mechanism for doing this varies by device, but the general form of the rules is:

FROM LISTNAME.threatstop.local TO ANY DENY
...
FROM ANY TO LISTNAME.threatstop.local DENY

Typically a new user finds that the first firewall can be configured to use ThreatSTOP in under an hour, subsequent firewalls of the same type take minutes to configure and once configured the update process, which runs every few hours, is completely automatic.