Inbound, outbound and on site

From my anti-spam background I have the experience that as long as a spammer remains under the radar of national authorities, e.g. by making sure that he never targets end users in his own country, he is pretty safe. The international cooperation between national authorities is so low, that seldom that something happens in cross border cases. Priorities are mainly given to national cases as cooperation is near existent. (If priority is given to spam fighting at all.)

The same will be the case for the spreading of malware. National authorities focus on things national. Cross border issues are just too much of a hassle and no one was murdered, right?

Of course it is true that if the allegation is right and we are talking about 157 command and control servers for botnets on thousands and thousands if not millions of servers in The Netherlands, the 157 servers is a very low figure. This does not mean that we can ignore this figure if our country is the number 3 spewing malware country in the world. Something needs to happen. Preferably through self-regulation and if not that way, then through regulation.

If it is also true that it is the same few hosting providers that never respond to complaints, it is time to either make them listen or shut them down. There is no excuse for (regulatory) enforcement bodies not to do so. Harm is being done, the economic effects are huge and the name of The Netherlands is mentioned negatively again and again.

In January 2005 at OPTA we were very proud that we had dropped from the number 3 position worldwide for spamming to a position out of the top 20. In six months time! I do not think it is much harder to do so for sending malware.

A suggestion for an action plan

Here's an action plan:

1. Give it priority
2. Start a national awareness campaign
3. Provide a final date to the hosting community
4. Preferably coordinate on 1 to 3 with DHPA (Dutch Hosting Providers Association)
5. Start acting against those that do not mend their ways.

And if anti-botnet infection centre ABUSE-IX starts doing its part on disinfecting end users' devices, The Netherlands may have a winning combination this way.

Of course this can be duplicated in your respective countries also for spam, malware, phishing, cyber crime, etc.

International cooperation

Of course the topics surrounding cyber security calls for international cooperation and coordination. In 2013 it is still virtually impossible to cooperate on cross border cyber crime, spam, the spreading of malware. This needs addressing on EU and world level. National institutions can not afford not to do so. Even if it is hard to give up a little national jurisdiction. There are in between forms, like coordination.

Conclusion

Let's push the boundaries for cyber threats back. It all starts with ambition. Experience shows that (the threat of) enforcement works. This isn't rocket science, it is about political will and insight.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

Although the idea originally was to hack into untraceable servers that could (most like would) be based abroad, now it appears that the Dutch government has used its imagination some more. Hacking devices, the obligation to cooperate in an investigation against oneself by providing passwords, tapping devices and e.g. Skype, it's all in the concept. Not surprisingly there is a lot of commotion from privacy advocates and organisations.

Anyway, I've had my say in the mentioned blog post and reiterate that this is a very, very sensitive topic, that could cross boundaries that we as society may not want to cross. Let me provide you with some links, so you can study it yourself. Unfortunately everything is in Dutch. Below you find links to the law texts, including explanations/intentions and a link to a blog post by PHD student Jan Jaap Oerlemans of the University of Leiden who provides some excellent observations.

Here's the official government publication on the law with links to the actual texts.

Here's the link to Jan Jaap Oerleman's blog.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

These "Geo-locking" technologies are in hot demand as organizations try desperately to regain control of their networks, applications and data.

Over the past 9 months I've been asked by clients and potential investors alike for advice on the various technologies and the companies behind them. There's quite a spectrum of available options in the geo-locking space; each start-up has a different take on the situation and has proposed (or developed) a unique way in tackling the problem. Unfortunately, in the race to secure a position in this evolving security market, much of the literature being thrust at potential customers is heavy in FUD and light in technical detail.

It may be because marketing departments are riding roughshod over the technical folks in order to establish these new companies, but in several of the solutions being proposed I've had concerns over the scope of the security element being offered. It's not because the approaches being marketed aren't useful or won't work, it's more because they've defined the problem they're aiming to solve so narrowly that they've developed what I could only describe as tunnel-vision to the spectrum of threat organizations are likely to face in the BYOD realm.

In the meantime I wanted to offer this quick primer on the evolving security space that has become BYOD geo-locking.

Geo-locking BYOD

The general premise behind the current generation of geo-locking technologies is that each BYOD gadget will connect wirelessly to the corporate network and interface with critical applications. When the device is moved away from the location, those applications and data should no longer be accessible.

There are a number of approaches, but the most popular strategies can be categorized as follows:

1. Thick-client – A full-featured application is downloaded to the BYOD gadget and typically monitors physical location elements using telemetry from GPS or the wireless carrier directly. If the location isn't "approved" the application prevents access to any data stored locally on the device.
2. Thin-client – a small application or driver is installed on the BYOD gadget to interface with the operating system and retrieve location information (e.g. GPS position, wireless carrier information, IP address, etc.). This application then incorporates this location information in to requests to access applications or data stored on remote systems — either through another on-device application or over a Web interface.
3. Share-my-location – Many mobile operating systems include opt-in functionality to "share my location" via their built-in web browser. Embedded within the page request is a short geo-location description.
4. Signal proximity – The downloaded application or driver will only interface with remote systems and data if the wireless channel being connected to by the device is approved. This is typically tied to WiFi and nanocell routers with unique identifiers and has a maximum range limited to the power of the transmitter (e.g. 50-100 meters).

The critical problem with the first three geo-locking techniques can be summed up simply as "any device can be made to lie about its location".

The majority of start-ups have simply assumed that the geo-location information coming from the device is correct — and have not included any means of securing the integrity of that device's location information. A few have even tried to tell customers (and investors) that it's impossible for a device to lie about its GPS location or a location calculated off cell-tower triangulation. I suppose it should not be a surprise though — we've spent two decades trying to educate Web application developers to not trust client-side input validation and yet they still fall for web browser manipulations.

A quick search for "fake location" on the Apple and Android stores will reveal the prevalence and accessibility of GPS fakery. Any other data being reported from the gadget — IP address, network MAC address, cell-tower connectivity, etc. — can similarly be manipulated. In addition to manipulation of the BYOD gadget directly, alternative vectors that make use of private VPNs and local network jump points may be sufficient to bypass thin-client and "share-my-location" geo-locking application approaches.

That doesn't mean that these geo-locking technologies should be considered unicorn pelts, but it does mean that organization's seeking to deploy these technologies need to invest some time in determining the category of threat (and opponent) they're prepared to combat.

If the worst case scenario is of a nurse losing a hospital iPad and that an inept thief may try to access patient records from another part of the city, then many of the geo-locking approaches will work quite well. However, if the scenario is that of a tech-savvy reporter paying the nurse to access the hospital iPad and is prepared in install a few small applications that manipulate the geo-location information in order to remotely access celebrity patient records… well, then you'll need a different class of defense.

Given the rapid evolution of BYOD geo-locking applications and the number of new businesses offering security solutions in this space, my advice is two-fold — determine the worst case scenarios you're trying to protect against, and thoroughly assess the technology prior to investment. Don't be surprised if the marketing claims being made by many of these start-ups are a generation or two ahead of what the product is capable of performing today.

Having already assessed or reviewed the approaches of several start-ups in this particular BYOD security realm, I believe some degree of skepticism and caution is warranted.

Written by Gunter Ollmann, Chief Technology Officer at IOActive

Kenzie did not offer the domain names for sale, did not read the emails intended for the subject organization, and generally kept his whole scheme out of the public eye. Upon demand, he also offered to transfer the domain names to the organizations in question.

Nevertheless he was sued by Gioconda Law Group for registering Giocondolaw.com — with "o" instead of "a" [see: Gioconda Law Group v. Kenzie, 2012 US Dist LEXIS 187801 (S.D.N.Y. Apr. 23, 2013)]. In response to Gioconda's complaint, Kenzie, proceeding pro se, asserted a variety of defenses, including a critique of American privacy law. Gioconda moved for judgment on the pleadings.

The court struggles with the application of the Anticybersquatting Consumer Protection Act (ACPA) factors to this case. On the one hand, this is clearly not a case where the registrant is trying to profit by selling back the domain name. On the other hand, the court says, all non-commercial uses are not necessarily exempt from the ACPA. [Not a particularly speech friendly position.]

Ultimately, the court says that it's not a case that can be resolved on the pleadings:

Defendants's alleged ideological, scholarly, and personal motives for squatting on the [domain name], while perhaps idiosyncratic, do not fall within the sphere of conduct targeted by the ACPA's bad faith requirement, If anything, given that defendant aims to both influence plaintiff's behavior and shape public understanding of what he perceives to be an important vulnerability in cyber security systems, this case arguably falls closer to cases involving parody and consumer complaint sites designated to draw public attention to various social, political, or economic issue.

It's possible plaintiff can prevail, but it would have do to so under a more fact-specific totality of the circumstances inquiry.

This is an interesting case that highlights the problems faced by security researchers generally. While the risk of liability here is less than what security researchers generally face (e.g., liability under the Computer Fraud and Abuse Act), it still shows a judge reluctant to grant the researcher's conduct full protection as a non-commercial, First Amendment-protected venture.

Written by Venkat Balasubramani, Tech-Internet Lawyer at Focal PLLC

Brian Krebs reports: "A 35-year-old Dutchman thought to be responsible for launching what's been called 'the largest publicly announced online attack in the history of the Internet' was arrested in Barcelona on Thursday by Spanish authorities. The man, identified by Dutch prosecutors only as 'SK,' was being held after a European warrant was issued for his arrest in connection with a series of massive online attacks last month against Spamhaus, an anti-spam organization."

Neustar Second Annual DDoS 2012 Survey
Download full survey: PDF

In comparing threats to readiness, the answers weren't encouraging:

• DDoS attacks continue to grow in frequency and impact
• While a handful of massive attacks dominated the headlines — especially in the banking industry, where many suspect the hand of unfriendly nation-states — most DDoS attacks are less than 100Mbps in size
• As in 2011, over 1/3 of attacks lasted longer than 24 hours, extending downtime, customer complaints and mitigation costs
• Connecting the dots: it doesn't take a mega-attack to cause lasting damage, merely well-planned strikes on poorly defended websites
• While more companies are investing in some type of DDoS protection...
• Most still rely on firewalls and other traditional solutions that get bottlenecked during attacks and accelerate outages

Most Frequent Ddos Victims – As in 2011, financial and ecommerce businesses were the most frequent DDoS victims. Last year, 32% of financial organizations reported being attacked. In 2012, the number increased to 44%. Starting in Q3 2012 and continuing to the present, banks in particular have suffered large, disruptive attacks, with specialized botnets such as "itsoknoproblembro" amplifying the destructive impact.
(Source: Neustar 2012 DDoS Survey)The data reported here is from a wide-ranging survey, not from Neustar's network monitoring or DDoS mitigation efforts. The data reflects the realities faced by diverse IT professionals across numerous industries, among companies large and small. It shows the real challenge most companies face today: how to gauge the threat clearly and respond within their means.

Among the key findings from the survey, 35% of organizations experienced a disruptive DDoS attack in 2012. Of those surveyed, 39% of retailers and 41% of ecommerce businesses experienced an attack last year. Additionally, more than a quarter of respondents (26%) indicated a DDoS outage could cost between $50-100k per hour, further showcasing the need for a strategy around DDoS protection and mitigation.

Additional survey findings include:

• Key sectors reported higher rates of attack: The number of retailers experiencing an attack increased by 144% from 2011 levels to reach an overall level of 39% in 2012; financial organizations experienced a 38% increase in attacks year-to-year with 44% of financial organizations being victimized in 2012.
• Though more companies are deploying DDoS protection — only 8% had no protections in place compared to 25% in 2011 — few have invested in purpose-built hardware or third-party expertise.
• The latter is alarming; while 66% of companies use firewalls, routers and switches for DDoS protection, these networking products create bottlenecks that actually aid attackers.

How long did DDos attacks last?

2012 Annual DDoS Attacks & Impact Infographic – To see how DDoS attacks affected businesses in 2012, Neustar surveyed over 700 IT pros. Comparing 2012 results with out 2011 survey, it's clear that many people are still hoping and wishing and praying they can solve a complex problem with old-school solutions. (Click to Enlarge Image)Tracking with last year’s results, survey found over a third of all DDoS attacks lasted more than 24 hours: 37% in 2012 versus 35% in 2011. Some attacks stretched out for several days or even longer — with 20% of attacks lasting between 3 days and 7+ days. The longest attacks, those lasting over a week, increased from 10% in 2011 to 13% in 2012.

According to Christian A. Christiansen, Chris Liebert and Charles J. Kolodgy of IDC Research, in a February 2013 report, entitled The Business Value of Hybrid Cloud-based Compromise Intelligence Monitoring and Threat Mitigation, "Given the complex nature of today's threats, enterprises can achieve a strategic advantage by employing a new layer of security that is services based. Cloud-based services are an important aspect of this approach to security and provide always-on monitoring without the added expense of buying and maintaining on-premise equipment."

Download a copy of the full survey here.

About Neustar siteProtect
Learn How Neustar Technology Can Block DDoS AttacksNeustar SiteProtect offers intelligent DDoS protection, blending the people, processes and technologies to stop today's complex attacks. Using battle-tested procedures and best-of-breed equipment, the experts in the Neustar Security Operations Center work swiftly to eliminate downtime and protect your brand.

Based in the cloud, SiteProtect offers 24/7 on-demand traffic scrubbing. Immediately accessible through DNS or BGP redirection, it provides instant relief from DDoS attacks involving network Layer 3, application Layer 7, IPv6 and/or encrypted traffic — or any combination of these takedown methods. SiteProtect reroutes traffic to unclog your network, filters malicious traffic and permits valid traffic to return to your infrastructure.

Built on a dedicated, globally distributed Anycast network, SiteProtect can be instantly deployed and remains activated until the danger is gone. With SiteProtect handling the DDoS, your responses remain nimble and in sync with customer requests. Online business continues even as the attack unfolds.

For larger organizations, SiteProtect is an ideal complement to in-house mitigation hardware. As a cloud-based failover solution, SiteProtect provides the bandwidth to absorb malicious traffic and enables you to launch countermeasures in real time. Using a hybrid approach, you can leverage your investments in DDoS detection and alerting, avoid outages and minimize disruptions.

The SIPNOC 2013 agenda includes talks on:

• VoIP and communications security
• Business strategies for service providers
• Regulatory and policy issues
• Multiple sessions about WebRTC and how that will change IP communications
• IPv6 and VoIP
• HD audio
• Standards relating to VoIP and SIP

The main sessions begin tomorrow with a keynote presentation from FCC CTO Henning Schulzrinne where I expect he will talk about some of the challenges the FCC has identified as they continue to push the industry to move away from the traditional PSTN to the world of IP communications.

I've very much enjoyed the past SIPNOC conferences and will be back there again this year leading sessions about: IPv6 and VoIP; how DNSSEC can help secure VoIP; and a couple of sessions related to VoIP security. I'm very much looking forward to the discussions and connections that get made there — and if any of you are attending I look forward to meeting you there.

SIPNOC 2013 will not be livestreamed, but if you are in the DC area (or can easily get there), registration is still open for the event. I suspect you'll also see some of us tweeting with the hashtag #sipnoc.

Written by Dan York, Author and Speaker on Internet technologies

The link directs users to a webpage that includes iframes that load content from several YouTube videos plus content from an attacker-controlled site. Reports indicate the attacker-controlled sites host malicious .jar files that can compromise vulnerable machines.

On April 17th, a second botnet began using a similar spam campaign. Instead of simply providing a link, the spam messages contained graphical HTML content claiming to be breaking news alerts from CNN.

Cisco became aware of a range of threats forming on April 15th when hundreds of domains related to the Boston tragedy were quickly registered. Regarding the botnet spam-specific threat – from a volume perspective – peaks approach 40% of all spam being sent. (Source: Cisco)

Read full story: Reuters

Until recently, ICANN, which is responsible for maintaining the root domain servers at the heart of the DNS system, had no specific guidelines for the reporting of vulnerabilities, leaving responsible disclosure protocols up to the researchers who discovered the bugs. With the release of the Coordinated Vulnerability Disclosure Reporting [PDF] document they hope to instigate a more unified and consistent process for disclosure.

The guidelines are intended to:

"define the role ICANN will perform in circumstances where vulnerabilities are reported and ICANN determines that the security, stability or resiliency of the DNS is exploited or threatened. The guidelines also explain how a party, described as a reporter, should disclose information on a vulnerability discovered in a system or network operated by ICANN."

The document outlines procedures that ICANN will follow in various roles, including as an affected party, where the vulnerability directly impacts ICANN's operations; as a reporter, when ICANN researchers discover vulnerabilities; and as a coordinating party.

Security vulnerability reporting is a controversial topic, with some researchers advocating immediate full disclosure, and others opting for responsible disclosure where vendors and stakeholders are notified privately before a full release is made only following the patching of relevant software. There is also a thriving black market for security vulnerabilities, where the information is disclosed only to the highest bidder for use in hacking attacks.

As an essential and ubiquitous part of Internet's infrastructure, the security of the Domain Name System is of particular interest to hackers and those engaged in industrial or state-sponsored espionage. ICANN is advocating a system of responsible disclosure with ICANN itself acting as a coordinator in some cases. Bugs that impact DNS can be reported directly to ICANN, who will then inform affected vendors or service providers.

Public disclosure is strongly discouraged until vendors have been informed of the vulnerability and have fixes in place. However, the methodology recommended by ICANN makes it clear that in the case of vendors who fail to respond to attempts at coordination, researchers may choose to disclose vulnerabilities.

None of these recommendations is binding, and researchers are still free to choose how to react to discovered vulnerabilities. However, the creation of these guidelines is a positive move towards a unified and coordinated system for handling security vulnerabilities in the DNS.

Written by Evan Daniels

ICANN President Fadi Chehadé opened the meeting by announcing that it was ICANN's "season to evolve," and setting forth a series of programs, restructuring efforts and policy initiatives intended to make ICANN more responsive to the needs of its stakeholders, and by extension, to the needs of all Internet users, everywhere in the world.

Mr. Chehadé's ambitious agenda provides a unique opportunity for ICANN to holistically review and strengthen its role in upholding the safety of Internet users.

Historically, ICANN's focus has been on Internet security almost to the exclusion of Internet safety. During the early stages of ICANN's evolution this narrow focus on security was both natural and likely necessary, given the organization's resources and scope.

The threats against the Internet's core technical infrastructure are significant, and ICANN's work in mitigating them is critical. But as ICANN's scope and resources expand, so to does its obligation to address the more granular threats to Internet users that arise from systemic abuse and exploitation of the Domain Name System.

Global cybercrime is at an all-time high, and shows no signs of abating. An independent study conducted by eight researchers for the U.S., UK, Germany, and the Netherlands presented at the Workshop on the Economics of Information Security (WEIS) 2012 placed the global cost of cybercrime at just over $225 Billion per year. And it could get much worse — a 2012 survey by the National Cyber Security Alliance (NCSA) and digital security firm Symantec showed the 83 percent of U.S.-based small businesses have no formal cybersecurity plan, even though the 2011 NCSA/Symantec survey showed that cyberattacks cost small and medium-sized business an average of $188,242. Almost two-thirds of the victims were shut down within six months after the attack.

The vast majority of the fraud and scams conducted by international cyber-syndicates shares a common characteristic of gaming the openness and accessibility of the Internet's addressing system to exploit the most vulnerable users.

Within its existing technical scope, ICANN has a tremendous platform to address these significant safety challenges. Simply enforcing existing contract terms with registrars and registries could have a dramatic global impact on cybercrime. Strengthening those contracts, and their enforcement mechanisms, would only magnify that effect.

ICANN is already making significant strides in the right direction. The new registrar accreditation agreement seems to hold great promise for Internet users globally, as does the registrants "bill of rights and responsibilities" that Chehadé discussed in his speech.

But part of ICANN's evolution should be systematizing these efforts so that Internet safety is not addressed piecemeal, but as part of a broader effort to address the safety needs of Internet users, including the millions who lack the wherewithal to participate in ICANN's policymaking process.

When the ICANN community sets its will to something, history demonstrates that it can be remarkably effective at accomplishing it. We've seen that in its strides on Internet security, and will likely have another demonstration soon in the form of new gTLDs.

If the community can embrace the Internet safety challenge with the same vigor with which they approached new gTLDs, we will look back years from now and mark the critical importance of ICANN's "season to evolve."

Written by Tom Galvin, Executive Director at Digital Citizens Alliance

The next day new malfunction of banks' websites were reported. For the first time it was openly admitted that all our banks' and payment intermediary iDeal's website were down, due to an attack in the form of a DDoS attack, making the website of the respective banks unreachable for regular traffic. The assailants tried to log in also.

This resulted in headlines, Tweets, blogs and opening news items, the one at the 8 o'clock news on the public channel ending with: "in the USA this happens nearly every day". In the following I'd like to take a look at a few related comments, a tweet by a politician, before coming to some questions. The main one reflects the title most: "Who's responsible for cyber security?"

Public outcry

If anything the chaos or perceived chaos in banking transitions led to angry or confused people, famous short fuses and loads of attention from the media. The cyber security world is waiting for years for a major cyber incident. One causing great damages, in the hope governments and companies start moving in the right direction. Some experts are even totally resigned to this way of thinking. This is not that incident. Sure, it shocked end users, led to some reactions from politicians, but in the end nobody seems to have lost money and there are so many other issues calling out for attention.

The news

Tax evasion
In the past week high level tax evasion by multi nationals, top-executives, politicians, etc., let's say the top of societies, was prominent in the news. A conclusion in a column in NRC Handelsblad stated, to this problem decisions at world level are needed. (If I'm cynical, look at the list at the start of this section and ask yourself the following question: Who decides on worldwide solutions?) What struck me, also, is that this is the exact same conclusion that is derived at when talking about Internet governance, international cooperation against cyber crime, spam and malware enforcement, etc., etc. In short, what I recently heard someone call "the glass ceiling of Internet governance". Most discussions stop here. Another variant to this discussion is: "we need to break own silos!". Okay, but who is "we"? Is someone made responsible for this breaking down, silos or ceilings? What are the right questions to ask here? Questions that lead to answers that could take the discussion forward and actually change the outcome? A topic for the upcoming IGF in Bali I'd say.

The near future
The comment in the 8 o'clock news cited above, caught my attention most. "This happens nearly every day in the US". I read somewhere that 267 out 365 days there were problems accessing major banks' websites. In other words this is something we are to expect also? Are there contingency plans? Do governments allow that payments can't be made (parts of) 267 days in the year? The economic impact is gigantic. Does it matter then whether the attacks stem from criminals, free speech advocates, "fun hackers" or state-to-state activities? I'd say not.

How can banks ever guaranty the safety of our money?
...is the question Dutch parliamentarian Kees Verhoeven (D66) asked on Twitter. (This is the Tweet: "Heftig. De storing blijkt nu een #DDoS aanval! De vraag is hoe banken de veiligheid van ons geld kunnen blijven garanderen. #cybersecurity"). I responded to him that this was totally the wrong question to ask. There is nothing banks can do against DDoS attacks, beyond preventive measures. The attackers, the tools they use, the infected PCs and other devices used, the command and control servers hosted anywhere in the world, are all far beyond the control of banks. As long as banks run state of the art security measures (even if they don't), they are victims and not attackers. Perhaps the banks need support from other entities on and around the Internet to solve this problem.

The tools used are infected PCs of end users, companies, governments, industry, etc. and other devices like smart phones, smart TVs, up to a hacked chip in your cat's collar (and this is no joke). There are a million reasons why these devices are infected. From irresponsible use by end users, flawed software, a lack of security by design in anything with "i" in front if it, negative incentives to deal with botnet mitigation or notice and take down requests, a lack of understanding in general, right up to a lack of government regulation, enforcement or incentives. All measures or better a lack of measures, banks have no influence over at all. They have an influence over the quality of the products they buy themselves in the future, over internal policy and security measures and perhaps they can reach out more to discuss Internet governance actively, which I advice them to do, but it stops there.

So, taking this all in, can banks guarantee the safety of our money? Answer this question yourself and continue to ask yourself the question who is responsible for cyber security? A virtual plethora of parties involved and where to start? What I have to conclude is that almost every single decision is to be made in the private sphere. In a competitive world. Where does that leave governments? Where does this leave decisions consciously made with the common good in mind?

So, who's responsible?

I'm not going to answer this question here. Those who follow me on my blog, here on CircleID or read my articles in Virus Bulletin know my points of view. What I'd like to ask you is to think about this question for one minute and share your thoughts with me here on within an(y) other context. It may just get a discussion going.

Written by Wout de Natris, Consultant international cooperation cyber crime + trainer spam enforcement

Learn about the diverse technologies Neustar uses to Mitigate DDoS attacks quickly and effectively. The seasoned DDoS fighters in the Neustar Security Operations Center explain the need for a full toolset to combat complex attacks. Listen as some of the world's top DDoS experts break it down in plain English to help you grasp your options.

Transcript

DDOS can happen, it can strike at anytime, around the clock, 24/7.

There's so much out there. There are so many unknowns. Everyday there's some new variant of some new botnet coming out. You have to be constantly on your toes at this job

The reality is that the technology and the threat have changed so much over the last year and a half that anything you bought 2 years ago is pretty much irrelevant. A lot of people fall for the marketing if I have a firewall I think I can automatically withstand a DDOS, if I have an IPS or an IDS I believe that I can deal with these things.

However this doesn't always work and it's not the best solution because the largest floods and types of attacks can actually overwhelm a firewall or an intrusion detection service and just pass right through.

What people need to realize is their hosting company isn't going to protect them if they get a large enough attack. That hosting company is going to shut you off so that they can protect their overall infrastructure and that's the one great thing about SiteProtect is we are solely invested in protecting you.

The model that we use for SiteProtect and what differentiates it versus what else is in the market and often what we hear from customers is our architecture is far reaching. The technology that we use is diverse in nature. So we're not just using firewalls, we're not just using IPS, we're not just using purpose built gear. We're bringing all of that to the forefront to fight attacks on behalf of our customers.

Neustar takes all of the devices and all of the technologies that we have and can kind of mesh them together and to blend them together to get the most effective mitigation in place.

Attacks continue to evolve every day. Everyone knows that in the industry so it's important that you bring to the table technology that can deal with those sophisticated often application layer attacks. And that's what we offer with SiteProtect.

While 1) is unavoidable simply due to the additional data that DNSSEC produces, and 2) "should" be practised as part of any provider's network configuration, it is 3) that requires "you and I" ensure that systems are adequately configured.

The fact is open DNS resolvers are nothing new and the open resolver project is tracking approximately 27 million open DNS resolvers. What I find interesting is that their database can be queried for an IP range to see how many open resolvers are listed.

Out of curiosity, I entered the /24 prefix that my personal IP address resides on, 81.174.169.0/24. This range belongs to Plusnet, a popular ISP located within the UK. I was quite surprised that a list of 9 IP addresses came back, I wasn't really expecting any, and fortunately, none of them were mine!

Out of further curiosity, I started using dig to fire off a DNS query for "www.bbc.co.uk" to each of the IP's. Most of them timed out, but as I worked down the list, sure enough, one of them returned an answer. I ran a port scan but couldn't detect any well known open ports other than DNS. So within a few minutes, I had found an open resolver being run on an IP address within the same /24 as my own. This ISP has hundreds of thousands, if not millions of customers, so if extrapolated, there could be thousands of open resolvers present via this one ISP. (Having said that, this list of open resolvers vs AS numbers only lists 7 open resolvers against Plusnet, so maybe I was just (un)lucky...) I would like to think my ISP has implemented BCP-38, but what if they haven't? And how many other ISPs out there haven't?

I have no idea whether CPE routers are providing this open resolver capability or whether people are genuinely running a poorly configured DNS server. The Measurement Factory perform regular surveys for open resolvers and network providers can get them to email a list of open resolvers. They have a useful page here.

I guess it's unfair to place the blame solely at sysadmins when the default setting for BIND up until 9.4 was to allow queries from anyone, and I am sure there are many *nix/*BSD distros that shipped with BIND versions <9.4 (RHEL 5 anyone?) — although you could argue "Why haven't they upgraded?" as we are talking pretty old code here. No, I think more culpable are the network operators who route spoofed traffic out from their network; it is inexcusable that they have not implemented BCP-38 (also known as RFC2827).

However, looking at that list of open resolvers vs ASNs again, the top offender is Brazil, followed by a big block in Asia-Pac, HINET is Taiwan, then Chile, Korea etc. To go to each of these providers, figure out which local networks are the offenders, and communicate all this in a meaningful, constructive way to the end customers, well, it's a gargantuan task!

Unfortunately I do not see a simple solution to this problem, and I fear that with the publicity the Spamhaus attack generated, we will ultimately see more of these kinds of attacks.

If you are curious like me, why not check your local ISP range and see if you can find any open resolvers? You never know what you might find! I'll buy a pint for the person who can find the most… at a date/time/location of my choosing… provided it's in the UK… in the South somewhere… near Reading or Basingstoke! ;-)

Written by Paul Roberts, CEO, Calleva Networks

While attacks of this nature are certainly nothing new, the scale of this attack was surprising, reported to hit 120Gbps. For a sense of scale, your average cable modem is only about 20Mbps, or about 0.016% of that bandwidth.

So how does one generate an attack of that size? The technique that appears to have been used is called DNS Amplification. The attacker will typically use a network of infected hosts, known as a botnet, to send DNS queries to servers, faking the source address to be that of their target. When the servers reply to these queries, they send the reply to that false address.

Since the response packet is bigger than the query packet, the DNS server is helping out in the attack by increasing the amount of bandwidth being used. This is not a new technique, and has been around since at least the late 1990s.

What has changed is how effective this attack is, mostly due to the introduction of DNSSEC records. For example, a DNS query for isc.org/ANY with DNSSEC is only 78 bytes, but the reply is 3,586 bytes — so big it gets fragmented and spread across three packets. This makes it very easy to use a little bit of bandwidth to make a huge attack, and since your compromised hosts don't need to send out a lot of data, it's less likely they'll be detected and shut down.

Open Recursives Are Not the (Only) Problem

A lot of these attacks make use of recursive resolvers to perform this amplification. These are the servers that are typically run by your ISP or by services such as Dyn's Internet Guide, OpenDNS, or Google's Public DNS.

It is intended that the end user will query these servers, they'll take care of finding the answer, caching it, and returning it to the user. In the case of an ISP's resolvers, these are usually locked down so only the ISP's customers can use it. It has long been considered a security risk to operate a resolver that will respond to just anyone (an "open" resolver) without taking special care to consider the consequences.

There has been a lot of renewed interest in finding and shutting down unintentional open resolvers, through things like the Open DNS Resolver Project. This is a good thing, but it only addresses part of the problem. These attacks do not need to use open resolvers; they can use the authoritative servers directly to do their amplification. The authoritative servers are the systems that ultimately serve the answers in DNS.

These are the sorts of systems operated by DynECT Managed DNS and Standard DNS. And since these servers must be open in order to function, it's much more difficult to secure them against abuse and the attackers are using them.

Dyn observed this activity back in December 2011, and it has only gotten worse since then. Other authoritative operators have seen the same behavior, typically DNS queries for "ANY" records on zones that have been DNSSEC signed. We have our own in-house tools for mitigating these attacks, but there has been public work to counter the problem, such as the Response Rate Limiting patches to the BIND nameserver software.

But these are really only temporary fixes in an arms race between DNS operators and the people who want to abuse their systems.

The Real Problem and its Solution

At its core, the problem that enables these attacks to work is source address spoofing. This is when a packet is sent from a computer using a source address that isn't actually on that computer, but instead belongs to some other system — usually not even on the same network, such as a home PC on a cable modem, sending traffic that appears to be from a popular website. This has been seen as a security problem for a long time, and yet there are still plenty of networks that allow it to happen.

The solution has also been around for a while, known as BCP38. This document, part of a series of Best Common Practices, describes a very simple concept of not allowing packets to pass through a router from hosts that shouldn't be sending from those addresses. It was published nearly 13 years ago, and is often brought up in tech circles as a solution to a number of problems, but there is still a lack of implementation on the Internet at large.

It boils down to a very simple logic, described in section 4:

IF packet's source address from within [its assigned space]
THEN forward as appropriate

IF packet's source address is anything else
THEN deny packet

There has been a renewed effort recently to push the adoption of this practice, with a boost from this recent DDoS attack on CloudFlare, with some new websites popping up, such as BCP38.info, and a lot of discussion in public forums. This is something that really needs to be done for the security of the Internet as a whole.

So, if you're a network operator, please consider implementing BCP38. If you're buying internet service, ask your provider about BCP38. The rest of the Internet will thank you.

Written by Chip Marshall, Network and Security Analyst