Frequently Asked Questions


ThreatSTOP stops botnets and criminal malware stealing from you by plugging the holes in your firewall.

ThreatSTOP is a cloud-based IP reputation service that automatically delivers a real-time threat list to your firewalls to enable them to block both inbound and outbound traffic to and from known botnet and criminal malware sites.

IP reputation is the identification and profiling of IP addresses to determine whether they are “good or bad” that enables network administrators to set a policy to manage, usually by allowing or blocking based on the reputation, communication to and from that address. In contrast to the currently dominant approach of security solutions, which tries to track the attack signatures, IP reputation tracks who is doing the attacking. The approach works due to the fundamental fact that all Internet communications start and end with an IP address. Instead of trying to chase after each attack signature which by definition is unknown a priori, IP Reputation profiles the history of a known item—the address.

You should care because botnets and criminal malware are the biggest information security problem today for three reasons:

1) Botnets are designed to steal your most valuable data, be it credit card numbers, your personnel data, or your engineering designs. They can also take control of your network resources (computers, databases, phones etc.) to do other nefarious activities without you knowing. The spamware (spam, phishing and viruses) we are all unfortunately used to is designed to be annoying, waste your time and slow down your machines.

2) Spam is an old problem that has plenty of solutions, and starting in 2010, show signs of decline. Botnets, in contrast, is a malicious and new problem that is growing rapidly. Cisco’s Q4 2010 Global Security Report shows that spam volume reduced by 75% in 2010 while botnets grew by 139%.

3) Why? Because that’s where the money is, and thus a breach is very expensive if you are the victim. To cybercriminals the Internet represents an infinite treasure trove of data that can be harvested for big illicit gains. In a well-known study by the Ponemon Institute, the average cost of a security breach for a large enterprise is almost $7 million, with a range of $750,000-31,000,000.

They address the old spamware problem, not this new class of botnets, which are much more malicious and sophisticated. Major surveys have all documented how current security solutions do not effectively combat botnets.

An analysis by NSS Labs shows that the chance of infecting a machine by standard web malware is 10-45%, but 25-97% by an active exploit such as a botnet. Depending on your perspective, that’s either 2X the likelihood, or near-certainty that you network will be breached.

Another study by Cyveillence shows the initial detection rate of confirmed active malware by leading AV products ranges from a low of 7% to a high of only 37%. As time goes on, detection rates improve over a 30-day period, with most of the improvement occurring within a week. While this is good, the top rate achieved is still only 90%, with many topping out in the 30-50% range.

So the question to ask is: is this an acceptable risk to you? We believe the answer should be a resounding “no”!

We won’t be so sure. Survey upon survey shows that botnet infestation is a pervasive problem, for organizations of all sizes, across all industries. To quote just one, in a survey of 130 large corporations by TrendMicro, it found them to have the following infestations:

Active malware
Information stealing malware
One or more IRC bots
Network worm
100 %
This phenomenon has also been seen by ThreatSTOP, where customers initially claim they have this or that network equipment, AV or IDS/IPS which should take care of the malware problem, but as soon as ThreatSTOP is installed, virtually all users find malware-infected hosts inside their network.

Our list is derived from public and proprietary malware monitors across the Internet and cross correlated and prioritized by our heuristics engine. This list is constantly monitored, renewed and culled to ensure the best coverage and accuracy. It is currently updated every 15 minutes, with the full list containing 30,000 entries (22,000 addresses + 8,000 /24 networks).

This capability is what makes ThreatSTOP truly unique. No other IP reputation service has it. The ThreatSTOP threat list is automatically distributed via DNS to your firewalls. We propagate lists of IP addresses as Multi-Host DNS A records, so that firewalls and other traffic management devices can use them as rules. This is particularly useful for dynamic lists that you want to propagate to multiple devices, but only change in one place. It also allows you to have your own custom allow and block lists. (For more details, please read Technical FAQ)

The current generation of firewalls and security devices don’t stop the latest breed of malware effectively in two areas:

1. Protocol and signature based. No way to keep up.

Firewalls essentially use a static block list based on protocol and signature patterns of suspicious traffic. While they do a good job, they are reactive to what already exists and are always behind the “cat and mouse” game with cyber criminals who are constantly changing their methods to infiltrate and circumvent the defense. The reality is that there is no way to keep up with the infinite combinations of methods, applications and protocols used to attack the network. For example, Symantec alone is writing about 20,000-25,000 anti-virus signatures per day! And we all know how irregular, time consuming and cumbersome the update/patching process is. Thus firewalls are vulnerable to 0-day attacks or insufficient updating of the signatures. They can’t stop what they don’t recognize.

2. Do not stop outbound “call home” traffic

Botnets by definition need to connect to its command and control (C & C) hosts to be activated. Firewalls are not designed to stop outbound traffic, especially any encrypted traffic such as SSL. In fact, they can’t inspect the secure traffic without breaking the security model anyway. So this is a major vulnerability that cyber criminals are exploiting by burying the “call home” call in these secure packets. Once the “call home” is successful, your network is instantly breached, and data theft is near certain.

ThreatSTOP stops all “call homes” to C & C hosts on its threat list. Your log will show which device attempted the call to which IP destination so you can take remedial action after the attempt has been stopped. There are some much more expensive and complex hardware solutions that alert you to, but not block, suspicious outbound calls. Better than nothing of course, but it’s too late. By then your network has already been breached and your valuable data has been stolen.

We’d like to say ThreatSTOP is your 1st line of defense and your best last hope.

Current firewalls and security products are designed to mostly block malware from coming in. But by and large they don’t address what happens when malware is already in your network. They need to “call home” to be activated. This is a big problem because you have to be 100% right and the criminals are banking on just one slip.

Furthermore, the mobile workforce is a huge security problem from this perspective. Your office network might be absolutely protected, but when an employee goes on a business trip or goes home over the weekend and returns Monday, his laptop may contain untold amounts of malware ready to do mischief like a bunch of ticking time bombs. Would anyone know what’s on those laptops and smartphones? This is like locking the front gate but leaving the back door open. ThreatSTOP solves this big problem.

Yes, once ThreatSTOP is installed, it will block inbound and outbound "call home" traffic to and from the banned IP addresses. This adds another security blanket over your existing security measures.

Our approach to dealing with inbound traffic is also fundamentally different from that of other products in that our filtering decision is very simple: accept or reject the packet from this address. If yes, we pass it through; if not, we drop the first syn packet. In contrast, firewalls, IDS, UTM devices perform deep packet inspection (DPI) on every traffic stream. Bandwidth usage: 74 bytes vs. 800-4000 bytes, or 10-50X advantage for us.

This advantage provides several other technology benefits:


  • 1. 10-25% reduction in bandwidth utilization

  • 2. “Cloak of invisibility” reduces threats and junk traffic
    Since we drop the first packet from a bad site and don’t acknowledge it, it has the added benefit of making your network “disappear” from the attacker’s view, as if it doesn’t exist. So they will just go away and probe some other target. This reduces materially the junk and recon bot traffic hitting your network. In contrast, a network which has rejected a probe through a packet inspection approach has made itself known by accepting the traffic, and the attacker will attempt a series of other exploits to get in, so your network will be subject to constant probes and attacks.

  • 3. Reduce network capacity costs The combination of dropping the first packet and the “cloak of invisibility” reduces your bandwidth utilization and load on your firewall, mail server, load balancers etc. and the need for more of them.

  • 4. All protocols and applications covered (HTTP/S, VPN, P2P, PDF, FaceBook etc.) While practically every other security vendor approaches the problem from a protocol and signature perspective, we approach it from a simpler way via IP reputation. Our message is simple: we know where the criminals are, so we block all communications to and from those sites, regardless of what disguises, protocols or exploits they use. We constantly scrub the list to make sure it is accurate and distribute it every two hours to make sure we are up to date at every instant. Thus we don’t have to play catch-up with the criminals who have an infinite number of ways to fool network defenses.

  • 5. Prevents 0-day attacks Because we update our database in real time and distribute the updates every two hours, ThreatSTOP is an effective way to stop 0-day attacks, irrespective of the specific exploit used by the perpetrator. To stop such an attack without ThreatSTOP, it requires your vendor to discover the newest exploit, notify the appropriate people, and develop a patch and distribute it, and then have your IT staff implement it across the network. Oftentimes this takes days and weeks, so it’s too late.

Beyond preventing significant damages from data theft, ThreatSTOP delivers several other business benefits:

1. Lowest cost of ownership

Software as a Service is simple and easy to use, without complex reconfiguration of your existing infrastructure. It is also cost effective from total cost of ownership perspective. One annual subscription covers everything.

2. No need for forklift upgrades

The major security vendors still have a “box” mentality that supports their business model. Whatever you need comes in another box, plus the reconfiguration, retesting, recertification and training that goes with it. ThreatSTOP is connected to your firewalls by a simple script or direct rule changes. That’s it.

3. Extend life of existing equipment

ThreatSTOP plugs the holes in your firewall and enhances its functionality. It protects your existing investment and extends its useful life.

4. No vendor lock in

ThreatSTOP works with most enterprise firewalls from major vendors, and thus doesn’t require you to lock yourself in with any vendor.

5. Automation reduces maintenance drudgery

Since ThreatSTOP’s updates are distributed automatically via DNS into the firewall, there is no need for manual updates. This not only saves time but is much more effective and allows the CSO/network admin to do higher-level work.

On November 8, the FBI, the NASA-OIG and Estonian police arrested several cyber criminals in “Operation Ghost Click”. The criminals operated under the company name “Rove Digital”, and distributed DNS changing viruses, variously known as TDSS, Alureon, TidServ and TDL4 viruses.

The botnet operated by Rove Digital altered user DNS settings, pointing victims to malicious DNS in data centers in Estonia, New York, and Chicago. The malicious DNS servers would give fake, malicious answers, altering user searches, and promoting fake and dangerous products. Because every web search starts with DNS, the malware showed users an altered version of the Internet.

Under a court order, which expired July 9, the Internet Systems Consortium operated replacement DNS servers for the Rove Digital network. These servers meant that infected computers could continue to access the Internet until they could be cleaned up. This has now stopped and the IP address space has been recycled. Some of it is now in the hands of suspicious characters which means any computers still infected may get reinfected with new malware.

More info from the DNS Changer Working Group at
Conficker has been around in various forms since 2008. There are at least 5 variants (usually called A, B, C, D and E respectively) and it affects all Microsoft OSes prior to Windows 7 including Windows Server 2008. It has spread widely using a variety of vulnerabilities and there are sill millions of computers infected with it today. Thanks to efforts of a number of technology companies who formed the Conficker Working Group the domains it tries to call home to are all sinkholed, but it remains a threat because it foils many security updates. Moreover Conficker E installed a spamming bot (Waledac) and other malware and through these it is possible that a conficker infected PC is also infected with other actively malicious software.
We are offering to parse logfiles from firewalls, IDSes and so on to see whether any computers on your network are using the DNS Changer IP addresses for their DNS or are attempting to contact the sinkholes for other malware such as conficker. We do this by parsing logfiles uploaded to us and extracting lines that contain the DNS Changer or Sinkholed addresses. We then give you a report that tells you what IP addresses on your network are communicating with these servers.

You should make sure that your firewall or IDS is logging all outbound attempts on port 53 (DNS). It may be simplest to log all traffic. You can either log this data on the device itself or use a separate syslog server and if you have a tool like splunk or Juniper's STRM you can use that too.

Then once you have some log data you should upload the logfile to us via the main webpage. We will parse it and give you are report that you can download and use to clean up infected computers. You can see a sample report here.

If you are using splunk or similar then you should export the data from the system either in raw format or as a summary in CSV format. We only need the source and destination IP addresses and will ignore anything else (name, port, count, time etc.) but you may find it useful to include a timestamp.

Any IP address which is listed on the results page has attempted to contact an IP address used by DNS Changer. These IP addresses are not used by anything except the DNS changer servers hosted by ISC so it is highly likely that the computer at that IP address is infected with DNS changer. Using your internal address management tools you can identify the computer and then clean it up. We put the raw log line on the report so that you can see the time(s) of the event(s) which will help if you have relatively short DHCP leases on your network.

One reason why there are so many computers still infected is that it is hard to clean them up. This page ( ) gives a lot of information and recommends that users follow one of the guides in the table below.

Guide How to Use
Microsoft's Safety and Security Center Microsoft's authoritative portal for all their security guidance, tools, and capabilities.
Apple's Security Page with pointers to keep your MAC safe Scroll down to the section on "Checking Security in your System." This has the pointers to insure your MAC is as secure as possible.
DSL Report’s Security Cleanup FAQ A community driven self help guide to fix malware problems on your systems.
Andrew K’s Malware Removal Guide Andrew K is an individual who share's his experience on-line. This guide is an often referenced guide to remediate malware problems on a computer.
Public Safety Canada’a Malware Infection Recovery Guide The Canadian Public Safety office ( has a malware removal guide updated and focused to help the general population.
Australia’s Stay Smart Online Factsheet to help Remove Malware Stay Smart Online Factsheet 11, Part 1 - You suspect your computer is infected with malicious software - what should I do?

We limit the size of log files that may be parsed to 1 Mbytes. If you have larger log files please either break them up or contact ThreatSTOP and we will provide you with an alternate access method. This can also be done if you have a lot of small log files. We reserve the right to block uploads from ip addresses that appear to be abusing our service. This may include uploading of logfiles that we are unable to parse, so please ensure that you upload a logfile that is in uncompressed plain text format.

We are using a fairly general purpose parser and all we need are source and destination IP addresses in standard IPv4 notation ( so pretty much any kind of text log file should work.

Supported Firewalls

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: and/or 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.

Whether you need to deploy a High Performance Data Center Firewall, an Enterprise Next Generation Firewall or a smaller UTM device for your Distributed Enterprise site or small business, there is a FortiGate physical or virtual appliance to fit your unique Network Security requirements.

We combine the FortiOS™ Operating System with custom FortiASIC™ processors and the latest-generation CPUs to provide advanced protection from sophisticated, highly targeted attacks, without becoming a network bottleneck.


ThreatCHECK monitors what IP addresses your computer is talking to by repeatedly running the ‘netstat’ command utility for a fixed period of time. This is a totally passive action that has no effect on communications to or from the computer.

When the time period is over, the ‘View full report’ option uploads the data to ThreatSTOP’s website where we cross correlate it with our database to find out if we know anything about the IP addresses your computer has been talking to. We store that data for 2 weeks so you can share it with others or revisit it for reference, then we delete it. After the first time you view the report, you will need to register with us (just a valid email address) to see it again. We do that primarily to stop abuse of our system.

Millions of computers around the world are infected with malware (sometimes known as trojans or bots) that take control of the computer without the user's permission, spy on the user's activities or steal the user's private data.

If you run ThreatCHECK you can find out if you have a bot on your computer and hence you can prevent cybercriminals from stealing your financial data and identity, committing fraud against you and other crimes. This can save you thousands of dollars and lots of hassles in restoring your online data and identity. Get a peace of mind that you are NOT talking to cybercriminals.

If you are on a corporate network, it’s even worse. The entire network can be compromised if your computer is “botted”, and the cost of data loss, remediation, and even fines from failing to comply with data security regulations can run in the millions.

Download ThreatCHECK

Download ThreatCHECK by clicking the download button, and double click on the file to run it. Press OK if you get a security warning like the one shown below
Security Warning

Run ThreatCHECK for short, standard or extended times (see question below for which to choose) in the background while it discovers the IP addresses your computer is connected to. ThreatSTOP runs a query of those IPs on our database of known malware sites and compiles a report for you. You can see the report by clicking on "View Full Report". An example of a full report is here with all the features explained.

The Short test runs for 15 minutes which is generally long enough to catch the more noisy bots – and is quite long enough to check whether a particular website is trying to download malware onto your computer. It is probably not long enough to capture more stealthy sorts of attack. The standard test runs for one hour which is generally enough to catch most bots and other malware.

The extended test runs for 6 hours which is likely to produce a very large list of IP addresses if you run it while the computer is in use. On the other hand if you run it overnight, say, it gives you a good feel for what things your computer may be doing when you aren’t doing anything which is a great way to find the most stealthy forms of malware.

Tip: You can always choose the extended test and then stop it when you think you have gathered enough data

There are a couple of options that can be specified if you run threatCHECK from a command prompt.

These can be used by advanced users to automate its actions:

/t N run for N minutes
upload data to ThreatSTOP automatically once the time is up
/n skip the check to see if there is an updated version of the software

The ‘save to file’ and ‘copy to clipboard’ options are also useful to feed the same IP address data to some other application than ThreatSTOP’s database.

The result page tells you what IP addresses in our database your computer has been communicating with. Not all of these are necessarily bad - particularly if the only information is a country. For example communicating with IP addresses in Estonia may mean you are using Skype (which has some servers there) and communicating with the Czech Republic may just mean your anti-virus is looking for an update (both Avast and AVG originate in the Czech Republic). However if the IP address is listed as being known for something other than a country then that could be more problematic.

Take a look at our sample page to see what a really worrying report might look like and to get more explanation about what it means.

If your report shows nothing suspicious, you don't need to do anything. You should run ThreatCHECK periodically to ensure that your computer is still clean, as it is constantly being bombarded by cybercriminals. On the other hand, if you do have suspicious connections or a confirmed infection, then you should investigate further and possibly seek help.

If you are in a corporate environment you should contact your IT help desk for help. If not, the next section lists some tools you can use to clean up bots.

Microsoft and many antivirus companies have specific removal tools for some bots (e.g. this page from Symantec or this one by eset). In addition we recommend Malwarebytes ( ) as a good general tool.

Other sources of help:

However you should be aware that in many cases it is safer (and quicker) to back up critical data and then totally reinstall / reimage the machine.

What does ThreatSTOP do?

ThreatSTOP propagates lists of IP addresses as Multi-Host DNS A records, so that Firewalls and other traffic management devices can use them in rules. This is particularly useful for dynamic lists or lists that you want to propagate to multiple devices, but only change in one place. The most common reason for this is to propagate dynamic threat feed information, and custom allow and block lists.

ThreatSTOP currently provides threat feeds taken from the Internet Storm Center's DShield project, which gathers information about hosts connecting to closed ports on thousands of firewalls worldwide; Shadowserver Foundation, which runs honeypot servers to identify botherders; PhishTank, which identifies Phishing websites, and we are always looking for more sources to add.

The most common use of these lists is to block and log traffic to and from these IP addresses, but they can also be used for redirecting blacklisted users to a remediation server or directing attackers to a honeynet for research.

In order to create our feeds, ThreatSTOP pulls in data from sources where it is published, as it is updated, and stores it in a database.

Our core engine is an IP Reputation gathering and archiving database that is tied to a set of processes that take that information and turn it into a set of DNS files that can then be assembled into DNS lookups. These are made available using standard DNS protocols.

ThreatSTOP does not have to be limited to publishing data from our existing suppliers. We can serve as a publishing platform for any IP Reputation feed, provided the provider of the information allows us to, and users understand that it is the data provider, not us, that decides what data is in the feed.

In short, ThreatSTOP can be a community clearinghouse for actionable feed information.
If there are additional feeds that you think we should provide, please support [at] threatstop [dot] com (tell us).

ThreatSTOP's system allows users to create their own custom allow and deny lists, which they can then query from their devices. This simplifies the management of black and white listing the same IPs across multiple devices. It can be used to either implement a "Deny all except...." security policy, or "No matter what, I need to talk to ...." one. Other applications of this are an IP based Closed User Group (poor man's VPN) or special traffic handling such as IP wiretapping.

Logs submitted to ThreatSTOP are archived for users to run reports on.

ThreatSTOP produces reports that are easier to read, and make more sense, than typical firewall log reports.

Our first reports correlate firewall log entries with the entries in Threat Feeds, allowing users to characterize what type of entity was denied. If the IP was in a DShield list, it is probably a bot or network attacker; if in the PhishTank lists, a Phisher and so on.

support [at] threatstop [dot] com (Let us know) what additional reports you think would be valuable, as this is an area under active development.

ThreatSTOP came out of the collaboration between the founder of DShield, Johannes Ullrich, and two friends from the US Army, Marc Sachs and Tom Byrnes. It was originally created to close the loop, by making the data produced through the submission of firewall log data to DShield by the DShield community easily actionable. ThreatSTOP will continue to build this community, submitting data received from our users to DShield. and enabling users to consume additional DShield feeds.

How does ThreatSTOP work?

ThreatSTOP takes data that is published on the Internet, and using standard Internet Protocols, gets that data as it is updated, parses it, and puts it into a database. The database identifies the source, time of publication, IP address, and any additional reputation information that may be available in the feed.

Every 2 hours (currently, we set the update frequency to be 1/2 the update period of our feeds) ThreatSTOP creates a set of files that can be used to create DNS lookups.

ThreatSTOP takes the DNS files and assembles them into the 5 basic lookups, for the basic users, and custom lookups, for our advanced users. These are then loaded into a DNS server, and made available to authorized client hosts.

The client machines query the zones they have configured in rules, using TCP lookups for larger lists, and take the actions that the firewall administrator has programmed for the hosts in those lists.

ThreatSTOP uses DNSSEC and ACLs to only allow subscribers access to the content they have subscribed to. Basic users only have access to the basic zones, and only the devices configured by a particular user have access to the zones created by that user. No-one can see anyone else's custom zone, allow, or deny list.

Using either e-mail, to ip-address-of-your-firewall [at] logs [dot] threatstop [dot] com or a web upload form on our SSL secured UI, we gather log data from users, and identify that log data as to the firewall it came from. Log data is loaded into a database where it can be reported on.

Using the UI, users can create reports using custom date ranges that show what was blocked, when, and what threat feed it was in.

Users manage their feeds, subscriptions, and devices using an SSL secured website. This is also where they run reports.

We give back to the community by parsing data into DShield format and bulk submit it to DShield, where it contributes to better sensing of attacks. For users who are DShield contributors, or who would like to be, we are working on a specific userID submission mechanism, which will parse your log data and submit it on your behalf.

How can I use ThreatSTOP?

ThreatSTOP can be used by any device that can use a forward DNS (standard) lookup in a rule. There is no special software or hardware required.

ThreatSTOP requires a fully RFC-compliant resolver, since the longer lists require TCP queries to propagate. The longer lists are broken into multiple lookups of 4000 hosts each, so in order to fully use ThreatSTOP, your system needs to be able to handle lookups of up to 4000 IPs per FQDN. Any resolver based on recent and current GNU, ISC or BSD resolver libraries has this capabilitiy.

Threatstop is a pull, not a push, service. We make the DNS lookups available, but you have to resolve them and load them into your device. Many devices do this completely automatically, based on the TTL of the DNS lookup, some need to be told to flush and reload DNS periodically, others require a script and a cron job.

We secure our DNS infrastructure using ACLs that only allow configured devices to access our nameservers, and devices configured in an advanced user's account to access their lists. As a result, we need to know the IP address that the queries will be coming from. This is statically configured and is a limitation of the current BIND. If you have a dynamic address, you will need to periodically update your configured IP address.

You will need enough memory to load the lists you select. Currently, the basic list is about 15,000 IP addresses. You should allow at least 64K bytes for that many addresses, and keep in mind that your firewall will be comparing each connection attempt with these 15,000 addresses. While this may sound like a lot, a modern CPU can do a 32 bit compare in about 2 clock cycles, so the performance hit for all but the oldest, or most heavily loaded, firewalls should be negligible. If you are getting hit a lot by actors in the lists, it may well reduce load, by dropping the attackers at the first SYN, as opposed to requiring content inspection or a traditional RBL connection accept, lookup, 500 response block.

To use ThreatSTOP, you first have to subscribe to the service. The basic service is free. When you Sign Up, you create an account using your e-mail address as your userid, and a strong password. Then you configure the devices that you want to use the threat feeds. We need to know the IP address that the devices will be querying our DNS servers from, because we limit access to our DNS servers to subscribed devices, and for advanced users, limit access to their lists only to their devices.

You need to enter the IP addresses of the devices that will be using the service, and if you are a SMB or Enterprise subscriber, you will need to select your feeds and configure any custom allow or deny lists.

When you configure a device, you will be given the custom instructions for that firewall, to help you use the service. The basic steps consist of:

1. Making your firewall resolve the threatstop.local domain using our nameservers. The easiest way to do this is make our nameserver primary for your firewall. We will do recursive queries for you.

2. Configure your rules to use the lookups, specifying the action you want to take. This is covered in more detail in the help section of our UI.

3. Make any configuration changes or cron jobs necessary to have your device reload the lists every two hours, if your device doesn't reload on TTL expiration.

4. Configure your firewall(s) to send us your logs.

The easiest way to do this is via e-mail, using the automatic feature of your firewall or a cron job, to <ip-address-of-your- firewall> Alternatively, for some firewalls you may run a script that automatically uploads them via https (SSL) to our servers. However, if neither option works, you can always submit using the web interface once you have logged in to your customer area at

We use the logs to develop additional, more timely, threat feeds, and show you what lists the IPs blocked by your firewall came from.

What is special about ThreatSTOP?

ThreatSTOP provides sets of forward lookups where the NAME of the lookup is the reputation assigned to it. Unlike a traditional RBL, this lookup can be used directly in routing decisions. There is no messing around with reversing the quads, appending the zone, and then interpreting the measure of "badness" of the number that comes back. This seemingly simple idea is actually non-trivial to implement, due to limitations in the current nameservers. Also, it's only recently that firewalls have been powerful enough that having to compare connections to thousands of IP addresses wouldn't overwhelm their RAM and CPU.

Threatstop has filed a patent on this method, which is distinctly different from the current RBL method of disseminating IP reputation.

What are users asking?

No, that is simply the easiest configuration. As long as your devices resolve the domain threatstop.local and its subdomains using our servers, the service will work.

One of the easiest ways to use ThreatSTOP is to make our DNS servers a forwarder for the zone threatstop.local on your DNS servers, and leave everything else in your nameservers the same. Just make sure that you register whatever IP address your DNS queries come from as your device.

Alternative methods include doing a subdelegation from whatever nameserver you are using, or making our servers forwarders. All these methods will require that you configure the IP address of your nameservers (or whatever they are NATed to) as the "device" in our service.

Yes, as long as the IP address your queries come from is configured as the device in your account.

We are constantly working on parsing new formats, for which we need example logs. DShield format is obviously preferred, but it's more important that we get the logs, than the format they are in.

Every two hours. If your firewall doesn't automatically redo a lookup on expiration of TTL, then you will need to tell it, either in configuration or by using a cron job, to fetch the updated lists.

That's what white lists are for. If you are an advanced customer, add the IP/range to your custom allow list. If you are a basic subscriber, create a rule that has higher priority than our block list that allows the traffic. You can also contact the data provider, such as DShield, to request that the IP be removed.

One reason why a particular IP address is blocked is because it used by multiple servers or virtual hosts, one of which has been compromised. While it is likely that the one compromised virtual host is not going to infect others, if the hosting company/users have not correctly implemented their security system, then the compromise may well spread.

You can discover why a host is in our list using the Check IP Address tool on our website.

In most cases, yes. As long as your firewall, or it's management station, or any computer you can run a script that can configure your firewall from, has a DNS resolver that works, you can use ThreatSTOP. If you would like your firewall officially supported, contact us and leave your e- mail, and we will test and document firewalls based on user demand.

ThreatSTOP does not change what real names on the Internet resolve to, which is how OpenDNS works. We propagate private (local) names that express the reputation that the data provider assigns to the IP address. This has several advantages over OpenDNS:

1. OpenDNS is a one-size-fits-all system. If a URL is redirected by OpenDNS, it is redirected for everyone. ThreatSTOP allows the user to decide what to do with a given IP address list, and for our advanced customers, allows the user to decide which lists of IPs to use.

2. ThreatSTOP can be used for inbound, as well as outbound, connection blocking as well as other traffic routing decisions.

3. ThreatSTOP doesn't require that all your clients resolve all their names through our service. It doesn't even require that your firewalls do, as long as they resolve threatstop.local through it. As a result, it changes the configuration of less devices.

4. ThreatSTOP is not subject to the problem of the system with statically configured nameservers totally bypassing the protection. Even systems using alternate DNS providers are subject to the rules, if their traffic goes through your firewall.

5. ThreatSTOP can protect you against connections to numeric IP addresses in phishing, OpenDNS can't.

Suse has a bug with resolving addresses in the local TLD. This affects interoperability with Windows SBS, OSX, and others that use the convention of the local tld for internal DNS. There is a fix discussed here:

To anyone willing to submit their Firewall Logs, we welcome your log submission with open arms. If you wish to participate in our community by submitting your logs we will allow you to use a limited DShield Top 10 and DShield Block List for free.The idea is to get people to sign up, use it, and contribute their logs. For free accounts there will be ads on the reports, and the reports and configuration options will be limited.

For those users requiring access to our complete service offering there is an annual charge per device to use ThreatSTOP.

The cost of using ThreatStop's more advanced features is based on the number and size of the Firewalls/Devices configured and our current rates are shown on the pricing page

We charge for enhanced services such as:

- Customized and enhanced feeds.
- Personalized allow and deny lists.
- Management of multiple firewalls and firewall groups.
- Long term non-repudiable log archiving.
- Compliance/forensic quality reporting without ads.
- Other enhanced services as we come up with them.

If you are an MSSP, we will negotiate a contract allowing you to use and provide our services to your customers. Finally we are actively seeking to develop opportunities for Channel Partners and VAR\'s.

If you have other services you'd like to see, please support [at] threatstop [dot] com (tell us.)

No, if you aren't specifically telling your firewalls to use us a primary DNS or authoritative for threatstop.local, your lookups will fail. There are no NS records in the public Internet for .local, and there never will be. This is by design.

ThreatSTOP isn't a replacement for your IDS, but a service that helps protect against unknown attacks, which are frequently first detected by DShield/Internet Storm Center, and the worst current SPAM sources as detected by Spamhaus. ThreatSTOP offloads your IDS and SPAM filters by lettting you block the worst bots and spammers early, so that you don\'t waste time and CPU with more expensive (in terms of CPU, bandwidth, etc) defenses, like signature matching and RBL at the MTA

Taking IDS alerts and using the sources in block lists can be a great tool, as long as you are very wary of false positives. However, an IDS can only protect you against known attacks, for which there are signatures, or attacks that are similar in nature. And IDSes do nothing about SPAM.

If you aren't allowing any inbound connections to your network, then any tool that blocks connections from attackers, like an IDS or ThreatSTOP, can seem like it's not much use. The difference is that ThreatSTOP can block OUTBOUND connections to the systems on lists. The systems listed are, in general, pretty bad actors, and not sites you want to visit. In some cases, especially systems that can show up on the DShield lists, they can be malware seed sites, or bot masters. As a result, you will still probably get some measure of additional protection from using ThreatSTOP.

ThreatSTOP does not generate feeds. We take in information from other sources, and make it available in a format that can be used to make a routing decision. Since we represent to our users that our feeds come from the particular providers, and contain what is in those specific lists, ThreatSTOP does not in any way alter the actual content we receive.

If you believe that an IP is in the feeds incorrectly, you can discover why a host is in our list using the Check IP Address tool on our website. You should then contact the data provider to have them correct any errors.

Email: support [at] threatstop [dot] com

Phone: US +1-760-542-1550
EU +(44)-1223-970-150

ThreatSTOP doesn't mess with anything. All the changes are made by you, you control what lists you use, when you update them, and what you do with traffic identified by the lists. You aslo control the timing, method, and content of any submitted logs.

ThreatSTOP is a pull, not a push, service.

We pull in lists of bad actors published by others and make them available as DNS forward lookups using a private, secured DNS. Your devices query those lists.

To submit logs to us, you either e-mail them to us, or upload them to a web form. You initiate all communications to our servers, we never initiate communication to yours.

The two most common causes of this problem are that you aren't allowing TCP name resolution, or that you have put the wrong IP address in your device configuration.

Because the lists are so long, we have to use TCP to propagate them. You need to allow port 53 TCP queries from your nameservers and/or firewall. There is no need to allow them INBOUND, only TO our servers.

Our system uses a private, secure, DNS. If the source IP of your query is not in our ACL, you will be denied. Make sure that the devices configured in our UI match the IP addresses your queries come from.