ThreatSTOP addresses the distribution and freshness problems by providing a patent-pending delivery mechanism using the standard DNS protocol. DNS is a well-understood scalable protocol that is supported by practically every network security device, and it allows ThreatSTOP subscribers to secure their networks by adding little more than a couple of simple rules to their firewalls. The firewalls then query the ThreatSTOP DNS servers to resolve the appropriate name and block all traffic to and from the addresses that the name resolves to. When the DNS TTL expires (typically every 2 hours) the firewall requeries the DNS server for an updated list. Finally the firewall logs are automatically uploaded to ThreatSTOP for analysis so that compromised computers can be identified and so that ThreatSTOP can determine which IP addresses are still untrustworthy. This closed cycle is described in more detail below. If you have questions regarding how ThreatSTOP can be deployed in your network please call (760) 683-8121 or email sales [at] threatstop [dot] com.
The first step is to register the firewall's IP address with ThreatSTOP and determine what block lists it should use. The choice depends on what sorts of computers the firewall is protecting and on its general capacity. Expert users are able to customize blocking based on the source of the data while standard users can select based on whether the devices behind the firewall are user PCs or servers.
Having configured the firewall at ThreatSTOP, the subscriber then applies the new rules to the firewall. For some firewall types, such as Vyatta, ThreatSTOP supplies a configuration script that is downloaded and run by pasting a line into an SSH terminal session.
For others the subscriber must add the rules himself. Typically the rules are
DROP and LOG FROM
DROP and LOG FROM firewall.organization.threatstop.local TO
The subscriber also needs to follow the instructions provided by ThreatSTOP to set up DNS resolution of threatstop.local and log upload for firewalls without a setup script.
No matter whether a script is used or not, setting up a firewall to use the ThreatSTOP IP Reputation service to block attacks is a one time event that takes no more than an hour or so from start to finish. In cases where a script is used, the process takes no more than a few minutes and the answering of a dozen or so questions and for many of them the default suggestion is correct.
Once the firewall setup has been committed the firewall looks up the name configured in the setup phase and the ThreatSTOP DNS server returns a list of IP addresses. This list is then placed in the firewall's memory and every packet passing through is checked against them. Unlike an RBL, the DNS lookup occurs before packets are received.
When a packet arrives on the external interface it is passed through the ThreatSTOP rule (and any other rules that have been configured). If the source address of the packet is currently known to be bad by ThreatSTOP then it will match against the ThreatSTOP block rule and be dropped.
By rejecting unwanted traffic as soon as possible network utilization is saved. Take the packet trace in the picture below. With ThreatSTOP the initial 74 byte TCP SYN request is ignored. Relying on the webserver, email server or an IDS to forbid access could result in anywhere from 800 to 4000 bytes being transferred, just to say "no". This is the other problem with the RBL approach. By sending a 'reject' error code back the server confirms that it exists.
With ThreatSTOP, because all packets from the attackers’ reconnaissance (which are the most “noisy”) bots are dropped you appear invisible to the most active attackers. This lack of visibility means that attackers cannot use port scans or other tricks to identify vulnerabilities because, to the computers under their control, your networks simply do not exist.
Finally this invisibility means that subscribers are protected against 0-day vulnerabilities. It doesn't matter if a hole is found in, say, the SSL or SNMP implementations their computers and network devices run because the computers used by the attackers to exploit these holes will be stopped before they ever have a chance to connect to the vulnerable system, and so won’t discover that they can use the attack on it.
For outbound traffic a similar process occurs. If the destination address of the packet is currently known to be bad by ThreatSTOP then it will match against the ThreatSTOP block rule and be dropped.
This is critical if the outbound connection is a “call home” to one of the botnet C&C hosts that ThreatSTOP knows about. The connection attempt is completely blocked so there is no data loss and no compliance issue. It is also logged so that remedial action may be taken. However since the attempt has been blocked this is not a time-critical task.
In addition ThreatSTOP includes data about the currently live phishing drop-boxes, which are generally a relatively small number of systems at any one time, but change rapidly. Since ThreatSTOP updates just as rapidly as these change, if a user on a network protected by ThreatSTOP is conned into visiting a known phishing server the connection will not work. This makes it impossible for the user to unwittingly provide the criminals with passwords and other sensitive data.
Likewise ThreatSTOP protects against the accidental download of malware from a visit to an otherwise reputable site that has been hacked so as to direct visitors to downloading malware from a different location using an unpatched vulnerability. Because ThreatSTOP blocks known malware servers - and keeps the list updated as new servers are discovered and old ones cleaned - computers on a network protected by ThreatSTOP are far less likely to become infected by malware.
Every few hours – the precise frequency depends on the firewall and the volume of hits but it is at least once per day and may be as often as once evry 20 minutes or so – the firewall uploads its logs to ThreatSTOP for analysis. Upload is secure and is performed in a number of different ways depending on the firewall. Once a log has been uploaded ThreatSTOP analyzes it for blocked IP addresses. This analysis helps to identify which IP addresses on the block lists are still attacking and to provide us with information about new attackers.
In addition to providing feedback to ThreatSTOP, the log upload process also lets ThreatSTOP provide a reporting service to its subscribers. Subscribers can visit the reporting pages at ThreatSTOP's web site and see what inbound attacks and outbound leaks ThreatSTOP blocked. Drill down reports enable the subscriber to determine what sort of attack each particular block was and, in the event of outbound connection attempts to identify machines that should be examined for potential infection. infection.