ThreatSTOP just updated our Vyatta install script to fully support the latest Vyatta version: 6.2. The new script is backwardly compatible to earlier Vyatta versions however an upgrade is not required for earlier versions of Vyatta. This is just a part of our ongoing Vyatta relationship to fight bots and criminal malware - as mentioned in this press release that came out today. The combination of ThreatSTOP and Vyatta provdes an extremely cost effective method of stopping bots calling home and blocking the servers that deliver bots and other malware that may be used either as a standalone solution or as a method to augment an existing firewall.Read More
Thanks to an email from one of the folks evaluating ThreatSTOP, I did a quick comparison check to see how much quicker ThreatSTOP is to report bad IP addresses. This is very important as new, unknown IP addresses, can wreak havoc until they are tracked down.
A brief aside: once an IP address becomes known as, say, a botnet C&C host it will start to get blocked. In fact we quite often see IP addresses fall down the slippery slope of recividism. First they start out as malware droppers or C&C hosts, then they become phishing sites or spammers, finally they become recon bots searching for open ports and vulnerabilities in servers. The key to this progression is that the IP address gradually becomes better known as bad and that the things it does first, when it is unknown, are the most dangerous to the Internet. Hence the quicker they are picked up the quicker people can protect against them.
So, getting back to the responsiveness question. Our evaluator compared us to McAfee's Trusted Source (which is BTW an awesome resource) and noted that we appeared to report IP addresses faster. That is to say we'd report an IP address as bad and then some time later Trusted Source would also report it as bad. Well this was something that needed a bit of confirmation so I took our current list of the botnet C&C hosts and compared it with the list from 24 hours earlier. Of the 1911 ip addresses currently in that feed 44 were new (I'll append the list to this post) and I checked all 44 with Trusted Source.
16 were either 'unverified' or 'minimal risk' for both web and email.
12 were listed as bad for email but either 'unverified' or 'minimal risk' for web
6 were listed as bad for web but either 'unverified' or 'minimal risk' for email
10 were listed as bad for both web and email.
Of the 22 that were listed as bad for email and hence could be assumed to have history, ThreatSTOP knew about half (13) as being definitively bad and 11 we had no knowledge of other than as botnet C&C. However I'm unclear about the accuracy of McAfee's Email rating since a number of those (in fact it was probably all 11 but I gave up checking) had no email data graphs of history so it seems likely that the email report was as fresh as the the botnet one and probably related.
Finally I did a sample of the 41 that were between 24 and 48 hours old and McAfee's Trusted Source appeared to know about almost all of them as bad for web. That is to be expected.
So to recap. 44 new addresses in 24 hours of the most dangerous sorts on the Internet - that is botnet C&C hosts. Of those ThreatSTOP in fact already knew of 11 as did McAfee. We were blocking 16 that McAfee had no idea of. We blocked 6 at about the same time that McAfee knew about them and 11 more may have been known by McAfee first, but not necessarily as botnet C&Cs.
I imagine I'll run this test again in a week or two to confirm this finding but it looks like yes ThreatSTOP is faster to identify bad IP addresses, and since they get automatically downloaded onto our subscriber's firewalls, far faster to provide protection against bots calling home with stolen data.
The Register has an article today about how IPv6 will make (spam) blocklists fail. The article is correct that current DNSBL techniques - as developed by Paul Vixie & co - will struggle but that doesn't in fact mean that IPv6 kills IP (or DNS) reputation, all it means is that the exact technique used by the current DNSBL solutions is not IPv6 compatible.Read More
This is a follow up to the previous post where we noted the emergence of a new 'conficker'-like threat. Thanks to research by our colleagues at Shadowserver it looks like the threat is actually more closely related to the Waledac/Storm worm malware rather than conficker, however that does not stop us from blocking it.Read More
Over the last couple of days we've seen an increasing number of outbound DNS queries to ip addresses on our block lists - principally to ones on the DShield 4000. Since the destination servers are frequently in China and the subscribers have little to do with China this looks unlikely to be genuine traffic. It is however somewhat suggestive of Conficker and other similar fastflux DNS malware which "call home" via a DNS lookup to some randomly generated subdomain of an otherwise apparently genuine domain. The DNS lookup resolves (usually) to a fastflux intermediary that communicates with the botmaster, The DNS server itself is generally not 'bad' per se but it will be under the control of the cyber crooks because they have to feed it the zone changes so frequently and this level of activity would raise a flag in any legitimate DNS hosting service.Read More
Our fellow security professionals at Damballa have written a pretty good explanation of IP reputation and the benefits of applying it. Since our business at ThreatSTOP is to provide IP reputation perhaps we should ask them to write more copy... However, while the article, as a whole is good, there are a few places where I think it could be improved.Read More
The recent release of the firesheep plugin, which makes it trivially easy for anyone running it to "sidejack" anyone else on the same unsecured public wifi network, highlights how insecure many popular websites (including social media sites such as Facebook) are. Even if the actual login is encrypted, typically subsequent data is sent unencrypted and that includes the key login session cookie. Firesheep allows its users to capture those cookies and use them themselves.Read More
Researchers at TrendMicro - and elsewhere - have identified changes to the infamous ZeuS trojan and how it is propagated. The new method involves another piece of malware named Licat, which uses techiques pioneered by the "conficker" worm to try and contact its Command and Control hosts. When Licat successfully finds a C&C host it downloads a new variant of ZeuS from them.Read More
Via my friends at Control Global, I've found and started to read the summary analysis of the STUXNET worm by Ralph Langner. Langner shows what looks like fairly strong circumstantial evidence that STUXNET was a deliberate cyberwar attack - presumably on the Iranian nuclear program, with possible spin offs to also affect nuclear research in other countries as well. Politically, this is fascinating stuff, but as this blog is about cyber security I prefer to look at some of the security issues it raises.Read More