Supported Vendors

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.

For firewalls that we do not currently support directly, we recommend that customers deploy a software firewall (e.g. Vyatta or pfSense) in bridge mode behind the firewall. This deployment method has been used successfully by many of our customers to identify and block botted machines on their networks.

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 require a single lookup, 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 devices 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 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.

This includes all the UTM/NGX products.

A shell script is run on the firewall that does the DNS lookups, creates a dynamic object, and adds the results to dynamic object. Rules are then created to block traffic to and from the dynamic object.

We currently only support Checkpoint running on Unix systems. Versions runing on Microsoft Windows OSes are not supported.

Please register to view detailed instructions and to download the script.

The Cisco PIX and ASA firewalls do not have a DNS resolver so an external script must be used to work with ThreatSTOP. The script we currently have is written in Perl and is run on management server or other UNIX workstation. The script gets the block lists and puts the results into a network object group on the firewall. You would then create the appropriate rules to block traffic to and from the object group.

Unfortunately, the script does not run on Windows. We have created a VMware virtual machine that you can use to run the script.

This includes all 2.6 or later kernels, Smoothwall, IPCOP, and any netfilter derivatives. We provide a simple shell script that runs as a cron job. The script gets the block lists and adds the IP addresses to a chain. The rules in the chain are set up to direct matches to another chain that blocks and logs the connection.

You can view detailed instructions and download the script after signing up.

SRX firewalls are supported by means of custom scripts that run on the firewall. Blocklists are created using a Junos op script and are updated using an event script. These scripts and more complete documentation are available after you create your account and configure the device.

Netscreen firewalls limits the number of IP addresses to 28 for each list object that points to a hostname. This is because the Netscreen can only perform UDP DNS lookups, and a maximum of 28 IP addresses may be fitted inside a UDP DNS packet.

On the Netscreen a list object is created for each block list hostname, then these list objects are combined into a group object that contains all of the lists. Finally a policy to block and log traffic to and from the group object is created. The Netscreen will automatically update the list objects when the DNS TTL expires.

Detailed instructions on how to configure the Netscreen are available after login.

A simple setup script creates the required rules and the cronjob task to keep the list updated. Vyatta devices may be used in traditional routed mode or in transparent bridge mode to provide ThreatSTOP protection to networks that have older, less capable firewalls currently installed.

A simple shell script that runs as a cron job updates the allow and deny rules in a table. PF must then be configured to block traffic to and from the table.

You can view detailed instructions and download the script after signing up.

We can readily customize our scripts to support other non-firewall devices if there is a sufficient business case and the device has support for ACLs or equivalent. Please contact us for more details but many routers and a number of (layer 3) switches can support ThreatSTOP.

A simple setup script creates the required rules and the cronjob task to keep the list updated, subsequently a new page is added to the management GUI to control the ThreatSTOP service. pfSense devices may be used in traditional routed mode or in transparent bridge mode to provide ThreatSTOP protection to networks that have older, less capable firewalls currently installed.