What does ThreatSTOP do?
How does ThreatSTOP work?
How can I use ThreatSTOP?
What is special about ThreatSTOP?
What are users asking?
- Do I have to make ThreatSTOP my primary DNS?
- Can I have my nameservers query yours?
- What format should I send my logs in?
- How often do you update the feeds?
- IP v.x.y.z is in the feed, but I want to talk to it!
- My firewall isn't listed, can I use ThreatSTOP?
- How is ThreatSTOP different from OpenDNS?
- Suse Linux is freaking out!
- So, what's this going to cost me in the long run?
- Will adding your nameservers to my list of resolvers be enough to make it work?
- I have an IDS and use its alerts to put blocks in my firewall, why do I need ThreatSTOP?
- I don't have any servers on my network, is ThreatSTOP any use to me?
- How do I get delisted from your feeds?
- How do I contact you?
- I don't want anyone messing with my firewall!
- My firewall can't resolve the lists!
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; the Cyber-Threat Analytics research project, the SRI malware threat center; 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.
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.
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>@logs.threatstop.com. 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 https://threatstop.com/.
We use the logs to develop additional, more timely, threat feeds, and show you what lists the IPs blocked by your firewall came from.
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.
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: http://www.novell.com/coolsolutions/tip/15248.html
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
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.