About these ads

Archive

Posts Tagged ‘IP address’

Botnets, ISPs, and The Role of The Cloud

Data CenterOne interesting comment on my previous post on Botnets, gave me a cue for another consideration concerning the role of the cloud inside the fight against botnets.

The fact that ISPs are evaluating an Anti Botnet Conduct Code means  their are feeling responsible for what resides inside (and leaves) their networks, and hence are supposed to take technical, organizational and educational countermeasures.

Anyway, in order to be effective, anti-bot controls should be enforced inside the customers’ networks, or at least before any source NAT is performed, otherwise IP addresses of the infected machines would be hidden, making impossible to detect and block them directly. A huge task for an ISP unless one were able to centralize the security enforcement point where the traffic is monitored and compromised endpoints members of a bot detected.

Said in few words I believe that ISPs will soon offer advanced anti-malware (read anti-bot) services in the cloud by routing (or better switching) the customer’s traffic on their data centers where it is checked and the customers notifyed in real time about the presence of bots inside their networks. You may think to the same approach used for URL filtering services on the cloud with the difference that in this scenario the clients should arrive to the ISP’s Data Center with their original IP Address or a statically NATed address so that it could always be possible to recognize the original source. Another difference is also that in this scenario the purpose in not only to protect the customers’ networks from the external world but also (and maybe most of all) to protect the external world from the customers’ (dirty) networks.

Another contribution of the cloud against Botnets that I forgot to mention in the original post.

About these ads

Imperfect Cybercrimes

April 19, 2012 1 comment

Law Enforcement Agencies are taking their revenge against the Hacktivists who mostly targeted them during the last months. In a deadly and unexpected sequence, the last 40 days have seen the heads of three infamous hacking crews falling under the blows of FBI and Scotland Yard.

One after the other, the key members of LulzSec, CabinCr3w and Team Poison have been arrested and in all but one case (that is the arrest of the alleged members of Team P0ison for which no details are known so far), the events have unveiled some surprises and unexpected details. Moreover, at least three arrests have been possible since the hackers left behind them a trail of mistakes which allowed the investigators to connect the dots and link their twitter accounts to their real identities.

The following table depicts the facts which may be better summarized from the Criminal Complaints which are reported below for:

As you may notice, in two cases, W0rmer and ItsKahuna, the hackers were betrayed by two familiar technologies which are commonly considered dangerous for users’ privacy and identity: social networks and mobile devices. Sabu was the one who really did a “technical mistake” by connecting to an IRC without protecting his IP address with TOR.

Interesting to say is also the different approach of FBI and Scotland Yard. Once discovered the real identities of the hackers the Feds tried to “enroll” them as informants, at least in one case (Sabu) this strategy was winning. At the opposite the Britons immediately caught the alleged culprits without giving any detail about their identity, maybe hoping the arrest could act as a deterrent for the other hackers. Apparently it looks like this latter strategy was not completely successful since the CabinCr3w survivors are threatening authorities, inviting other Blackhats to join them for the revenge.

Last but not least, I cannot help but notice the tweet below for which I remember to have been particularly impressed when I first saw it since, at that time, I considered it a too much imprudent. Consequently I was not that surprised when I saw it quoted in the Criminal Complaint.

At the end we are becoming more and more familiar with mobile phones and Social Network, so familiar to forget their level of intrusiveness and the related dangers for our privacy. As an example try to verify how many of you and your friend toggle Geo-Tagging off from their phone cameras. (Un)fortunately, it looks like not even the bad guys are immune from this.

Read more…

Is It Time for DNSSEC?

September 5, 2011 2 comments

DNSSEC in European Country Code Top Level Domains (green=deployed, yellow=planning to deploy) Source RIPE NCC

The media are in a frenzy today, reporting a wave of attacks against popular websites such as Daily Telegraph, The Register, UPS, Acer, Vodafone.com and others. All the attacks utilized the same method (DNS Hijacking) and have been carried on by the same Turkish Group: Turkguvenligi.

Turkguvenligi is not new to such similar actions (early this August, the same crew defaced the web site of HSBC Korea), what is really new is the fact that in this last month the current DNS protocol is showing all its limits and security issues, recalling the need for a quick adoption of DNSSEC, the well known and long awaited evolution of the Domain Name System Protocol, which aims to prevent attacks such as DNS Hijacking or DNS Cache Poisoning by mean of digitally signing the records for DNS lookup using public-key cryptography.

Looking back to the last cyber attacks, DNS has been under pressure and has become a privileged direct and indirect target: at the end of August Anonymous Sri Lanka claimed (although not confirmed) to have hacked into the DNS servers of Symantec, Apple, Facebook, Microsoft, and several other large organizations by mean of DNS Cache Poisoning. Moreover DNS protocol was also involved on the propagation of the infamous RDP capable W32.Morto worm which established, according to Symantec, a new (DNS) record, since the researchers of the security firm discovered on the malware a communication mechanism using the DNS TXT records towards hard coded domains a customary to receive binary signature and an IP address where to download a file (typically another malware) for execution.

Of course not even the dramatic Diginotar affair (whose impact is much greater than expected since it looks like the attackers forged fake SSL certificates for more than 200 domains including Mossad, CIA, etc.) can be considered completely unrelated to the question since, if used in combination (and as a complement) with SSL, although not perfect, DNSSEC could provide an alternative method to validate that the surfer is connecting to the correct site (this attack is particularly meaningful, today we do not have DNSSEC and we cannot trust CAs anymore…).

Unfortunately, although designed to be fully backward compatible with the current protocol implementation, DNSSEC is not something which can be enabled by the user, but involves a reconfiguration at the server level (and introduces new concerns such as Zone Enumeration Issue and Key Management).

Nevertheless more and more ISPs and agencies are adopting this technology since 2005 (for instance RIPE NCC). A crucial step has been made on 2010 with the DNSSEC adoption at the root level, and also client applications are offering DNSSEC validation, as Google Chrome does, which provides full DNSSEC Validation in version 14.

And Italy? It looks like we will be slave of DNS Security issues for a long time: in the “DNSSEC Deployment Today” Document issued by NCC RIPE, Italy is sadly marked gray, indicating there is no adoption plan so far.

Follow

Get every new post delivered to your Inbox.

Join 3,172 other followers