Strategies For Attacking Cyberattacks Before They Happen
Strategies For Attacking Cyberattacks Before They Happen
Responses - Stakeholder Private Sector
Ram Mohan, Vice President & Chief Technical Officer, Afilias
While Estonia was one of the first known targets of a politically motivated cyberattack in April 2007, it was not the last. There are many examples that have, unfortunately, happened since then: in 2010, there were major DDoS attacks associated with territorial disputes between China and Japan, as well as the ongoing political turmoil in Burma and Sri Lanka. In 2011, the Hong Kong Stock Exchange had to suspend trading in well-known companies such as HSBC and Cathay Pacific because their systems were under a massive DDoS attack. In 2012, the Spamhaus Project website and email systems were plagued with yet another massive DDoS attack.
I can speak from direct experience that vigilance is required in monitoring for – and protecting against – DDoS attacks. My company manages a significant portion of the domain name system and operates authoritative directories in dozens of locations around the world. We are no stranger to DDoS attacks. But this awareness of the threat, and the need to prepare against it, has yet to fully permeate governments and mainstream companies. Many times, these entities are unaware of DDoS attacks until it is too late to prevent them.
Recently, I noted during a panel presentation hosted by the Public Interest Registry and the Internet Society’s New York chapter that an enormous DDoS disaster is waiting to happen. Staying ahead of potential attacks is a huge, expensive challenge on literally a global scale.
That is why I fully support the position of Toomas Hendrik Ilves in preparing against the threat of DDoS attacks rather than addressing them as they happen. Cooperation among all infrastructure providers to support the Network Working Group’s Best Current Practices on defeating DDoS attacks (BCP038) is critical to the world’s ongoing success in preventing future attacks. BCP038 outlines a simple, effective and straightforward method for using ingress traffic filtering to prohibit DDoS attacks that use forged IP addresses to be propagated from behind an aggregation point of an Internet Service Provider (ISP).
Building on that work is ICANN’s Security and Stability Advisory Committee (SSAC), specifically the “Securing the Edge” memo (SAC004) that discusses DDoS security issues with recommendations for improvement. Of special note from this document: “From the point of view of almost any single purveyor – or consumer – of operating system and application software, convenience will almost always have more perceived value than security. It is only when viewed in the aggregate that the value of security becomes obviously higher than the value of convenience.”
That is why, despite my support of Toomas Hendrik Ilves’ take on preventative security against DDoS, I disagree with him in that a single unified identity is essential to online security. Ilves says: “Identity lies at the core of security online … The key to all online security is a secure online identification system.”
End users’ preference for ease of use is the greater issue. Users tend to take the simplest route with their technology. For example, do you enter a password each time you open your smartphone or wake your computer from a screen saver? Until you’re participating in security – whether it’s locking a phone when it’s not in use or signing into a device with a password or fingerprint swipe – you don’t fully appreciate its value until you lose your phone or someone steals important information from your computer. Then you’ll be glad about the seconds you spent securing your device. There is no better way to help governments and organizations acknowledge the importance of security than by having its members participate actively in it. Reducing that participation to a single identity, though, does not necessarily help prevent larger security issues.
I counter Ilves’ thoughts in regard to a secure online identification system. I believe that idea is contrary to the fundamental privacy tenets of the Internet; an online identification system eliminates anonymous access and reduces privacy. Further, there is no evidence that the world needs a single identity scheme to prevent DDoS attacks or other Internet mischief.
A distributed denial of service attack is every organization’s worst nightmare. One minute, everything is as normal. The next, the infrastructure is hit by a tsunami of spurious traffic from across the Internet. Legitimate users find themselves locked out; government and private business grinds to a halt, and there‘s not a great deal to be done about it.
Rather than focusing on the issues of identity, I urge all organizations to take the following steps in order to mitigate the risk of users and customers suffering disruption during a DDoS attack.
Over-provisioning: Many DDoS attacks are brute force in nature, and over-provisioning is a brute force defense. Your opponent simply needs to throw enough traffic at you to overwhelm your capacity. You can reduce the chances of success and limit the impact on users by provisioning for far more traffic than you would expect to receive during normal operation. Prepare for traffic many multiples of what you experience in normal operations.
Remote/redundant monitoring: In-house monitoring systems can be of limited utility if you are under a DDoS attack. You should subscribe to a third-party service that monitors your site around the clock, evaluating your site’s responsiveness from an end-user perspective and providing alerts to your phone when problems are found.
Dump the logs: Your Web server logs can‘t tell the difference between a genuine visitor and a botnet node. Both visits will usually be recorded in the same way. While the log data could possibly be used for forensic purposes after the attack is over, its value is limited. If you find log files growing large quite quickly, you‘re faced with the choice between keeping the data and losing the server, or losing the data and keeping the server. If your Web server is mission critical and large log files are preventing you from recovering, your choice should be clear: dump the logs.
Know the people at your providers: While it is technically possible to locally configure network hardware to drop some malicious packets, ideally you‘ll want the unwanted traffic throttled as close to the source as possible. This means that coordination with your upstream providers is a must. It’s essential to have the direct telephone numbers of contacts at your ISP‘s network operations center. If you know how to contact the right person to help shut down the attack, regardless of the hour, you‘ll experience far fewer headaches when a DDoS strikes.
MIND-Multistakeholder Internet Dialog