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.
- I, BOT (Coming To A C&C Server Near You) (hackmageddon.com)
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.