Yandex launches public DNS service with malicious URL filtering

Russian Web search firm Yandex launched a public DNS (Domain Name System) resolution service on Thursday that leverages the company’s existing website scanning technology to block access to malicious and adult-rated sites.

The DNS acts like a phone book for Internet domain names. Before accessing any website, a computer must first find out its corresponding numerical Internet Protocol (IP) address. This is done by querying servers that act as DNS resolvers.

By default, most computers use the DNS resolvers of their ISP, but they can be easily configured to used third-party DNS servers. Companies that provide public DNS resolution services include Google and OpenDNS, which offers additional options like malicious URL filtering and parental controls.

Yandex’s new service is accessible via three separate IP addresses, each of them determining a different level of filtering.

Yandex.DNS Standard (77.88.8.8) provides completely unfiltered access, Yandex.DNS Secure (77.88.8.88) blocks access to harmful websites, while Yandex.DNS Family (77.88.8.7) blocks adult content websites in addition to infected and phishing websites.

Interested users can manually configure their computers, wireless access points, routers or mobile devices to use the service by following instructions on Yandex’s site — currently only available in Russian. However, the company is also working with home router manufacturers to create customized firmware that have a built-in option to use Yandex.DNS.

Such firmware has already been released for several router models from ZyXEL’s Keenetic series and work is being done to release it for D-Link’s DIR-615 and DIR-620 models, which are popular in Russia.

Yandex.DNS is primarily directed at Web users in Russian-speaking countries like Russia, Ukraine, Kazakhstan and Belarus where the company’s Web search and other services have a large market share.

The DNS service can technically be used from anywhere in the world, but at the moment, using it from other countries might slow down Internet connections because the DNS servers are based in Russia, Yandex spokesman Vladimir Isaev said Thursday via email. For the long term, there are plans to also deploy DNS servers in the company’s data center in Amsterdam, which would decrease latency for users in Europe, he said.

As far as detecting and blocking access to malicious websites goes, Yandex.DNS uses the behavior-based anti-malware technology also used by the company’s Web search engine to flag potentially harmful links in search results.

“We have great knowledge of dangerous/adult websites in Russian, Turkish and English,” Isaev said. However, the company is not sure of how well its technology would work for detecting malicious and adult-rated Web content other languages when compared to other DNS-based services available on the market, he said.

Some users favor Google’s public DNS service over OpenDNS’s because the latter responds with a custom search page when users try to access a non-existent domain name.

Yandex.DNS does not currently do that, Isaev said. However, the company is considering adding a search box to the warning pages displayed by the service when blocking access to a website, he said.

Yandex has launched a series of new products and services in recent years in order to remain competitive and preserve its market share lead over Google in Russia.

For example, last year the company released its own Web browser based on Google Chrome. Also, the company’s website scanning technology is offered as a stand-alone library called Yandex Safe Browsing API, which is similar to how Google makes its own Google Safe Browsing API available for integration into third-party applications.

Article source: http://www.computerworld.com.au/article/458111/yandex_launches_public_dns_service_malicious_url_filtering/?utm_medium=rss&utm_source=taxonomyfeed

Secure64 Doubles Performance and Attack Resistance of DNS Cache Product

Improved performance on the latest HP Integrity servers delivers total cost of ownership savings of 48 percent

Denver, CO (PRWEB) April 03, 2013

Secure64 Software Corporation announced that its DNS Cache product has increased its performance and resistance to denial-of-service attacks 100 percent on the new HP Integrity rx2800 i4 and BL860c i4 servers running on the Intel® Itanium® 9500 processor series. (1) By leveraging faster clock speeds, improved bus architecture and increased onboard L3 cache, Secure64 is able to offer up to double the performance while keeping its software cost the same, resulting in a savings of 48 percent in total cost of ownership. (2)

The HP Integrity rx2800 i4 and BL860c i4 platforms are reliable and secure entry-class rack-mount and blade servers supporting a range of mission-critical workloads. Based on HP enhancements and the Intel® Itanium® processor 9500 series, transactions are processed up to three times faster than previous generations, while using 21 percent less energy. (3)

“DNS performance and attack resistance have always been important, but is especially critical for mobile operators who are experiencing explosive growth in IP traffic,” said Joe Gersch, COO of Secure64. “Unlike appliance vendors, Secure64 is able to offer up to double the performance on the latest HP Integrity servers compared with previous generation servers at the same software cost. This gives customers a very cost-effective upgrade path and maintains our commitment to offer the best total cost of ownership of any carrier-grade DNS solution on the market”.

“Like many of our mission-critical clients, Secure64 was facing ever-increasing demands for uptime, performance and security in order to grow their business,” said Lorraine Bartlett, vice president of marketing, Business Critical Systems, HP. “HP’s expanded Integrity portfolio offers Secure64 the scalability, continuous availability and efficiency needed to achieve their mission-critical business goals and improve productivity.”

“Secure64 is a long-time partner of HP, and is committed to leveraging the unique security and performance characteristics of the HP Integrity server platforms and Intel Itanium microprocessor,” said Bill Worley, CTO of Secure64. “Our carrier-grade DNS solutions continue to offer unique solutions to the security challenges posed by today’s cybercriminals.”

Secure64 continues to offer full support for its software products on the previous generation HP Integrity servers, even those that have reached end-of-life status.

Secure64Â’s entire line of DNS products is now compatible with the HP Integrity rx2800 i4 and BL860c i4 servers. For more information about Secure64 DNS Cache, please visit http://www.secure64.com/fast-secure-DNS-caching.

Notes

1 Based on Secure64 lab tests that compared performance and DDoS attack resistance of Secure64 DNS Cache and Secure64 DNS Authority running on an HP Integrity rx2800 i4 with Intel Itanium 9500 processor series versus the same application software running on HP Integrity rx2800 i2 with Intel Itanium 9300 processor series.

2 Based on three year costs of hardware, software and software maintenance for the Secure64 DNS Cache product running on an HP Integrity rx2800 i4 Server versus an HP Integrity rx2800 i2 Server.

3 Based on HP internal lab testing that compared HP Integrity rx2800 i2 Severs, with Intel Itanium 9300 processor series and 24 8GB DIMM memory cards versus HP Integrity rx2800 i4 Servers, with Intel Itanium 9500 processor series and 24 8GB DIMM memory cards. The difference was 162 watts or 21.4 percent less energy consumption for the Intel Itanium 9500 processor series -based system. ENERGY STAR qualification based on published qualification data for the HP Integrity rx2800 i4 Server, in the category for Enterprise Server. Testing done June 2012.

About Secure64 Software Corporation

Secure64 is a software developer with the most secure DNS products available. Secure64Â’s patented technology provides mission-critical security and reliability, built-in protection from DDoS attacks, high throughput and low latency. It has been shown to be immune to compromise from rootkits and malware and resistant to denial of service and other network attacks. The company offers a suite of trusted and secure DNS software appliances for caching, signing, blacklisting, management, and authoritative use. They also host a testbed for detection of IP Route Hijacking. Secure64Â’s products are sold and serviced worldwide through Hewlett-Packard and their reseller network and directly by Secure64. For more information, visit http://www.secure64.com.

###

Secure64 Company Contact

Mark Beckett

Vice President, Marketing

Secure64

(303) 242-5899

mark.beckett(at)secure64(dot)com

Mark Beckett
Secure64
(303) 242-5899
Email Information

Article source: http://news.yahoo.com/secure64-doubles-performance-attack-resistance-dns-cache-product-122818911.html

DNS Made Easy Calls For The Cleanup Of Open DNS Resolvers To Reduce DDoS Attacks

DNS Made Easy, the leading provider of anycast managed DNS hosting, has requested that all responsible members of the Internet community make a concerted effort to close down the open DNS recursive resolvers that are frequently used for packet amplification distributed denial of service (DDoS) attacks.

Reston, VA (PRWEB) April 02, 2013

DNS Made Easy, the leading provider of anycast managed DNS hosting, has requested that all responsible members of the Internet community make a concerted effort to close down the open DNS recursive resolvers that are frequently used for packet amplification distributed denial of service (DDoS) attacks.

An open DNS resolver is a server that accepts Domain Name Service requests from clients outside of its administrative domain, meaning that any machine connected to the Internet can make a DNS request of these resolvers. The originating IP of the request can be spoofed so that responses are sent to the attack’s target rather than the originator of the request.

Open DNS resolvers are responsible for the bulk of the bandwidth produced in the recent headline-grabbing attack directed at the Spamhaus spam monitoring service, which created significant problems for its bandwidth providers and potentially caused slowdowns by impacting the throughput of major European hubs.

“We’re calling on all members of the Internet community to urgently act to reduce the number or fix the large number of open DNS resolvers,” affirmed Steven Job, President of DNS Made Easy, “The problems that open DNS resolvers are causing now outshine any purpose they might once have served.”

Open DNS resolvers have become an increasingly popular method of carrying out Distributed Denial of Service attacks. Often, such attacks employ botnets, but with the easy availability of open DNS resolvers, anyone with a minimal level of technical expertise can create an enormous flood of packets and direct it at their target, knocking sites offline and consuming a significant proportion of the bandwidth resources of Internet Service Providers.

“The fact that open DNS resolvers can be so easily exploited by anyone setting a few cloud instances and running a script that will cripple sites and degrade ISPs is an untenable situation,” said Job, “The Internet community needs to act to remove this menace as quickly as possible. In order to do this properly DNS and network administrators need to take three proactive steps. First we would like to see many of the open DNS resolvers shut down or closed as many are not intended to be open to the world. Secondary, rate response limiting (RRL) should be implemented where possible for appropriate name servers. Third, we would like to see ISPs and network administrators take a larger role in implementing BCP 38 network ingress filtering, which would help eliminate IP spoofing.”

DNS amplification attacks rely on the fact that DNS response packets can be much larger in size than the original request. For example, an initial request of 81 bytes may result in a response that is over 300 bytes, a quadrupling of bandwidth consumption. So for every bit the attacker has at their disposal they can create an attack of over 4 times the size by using the actual DNS response for the attack vector. Using DNSSEC for these attacks increases the amplification ratio near 20 times the size. In the recent attacks, the attackers appear to have been trying to use DNS amplification with DNSSEC for maximum bandwidth consumption and damage. Using open DNS resolvers an attacker with access to about 500 Mbps of bandwidth can flood their targets with over 10 Gbps, more than enough to crush most DDoS mitigation appliances.

The Spamhaus attacks claimed bandwidths of up to 300 Gbps. Last year DNS Made Easy has graphed statistics of an attack they successfully handled that was over 200 Gbps.

While the Internet as a whole is not put at risk by DDoS attacks because of its multiply redundant connections, they are capable of causing regional slowdowns, site service interruptions, and consuming the necessary capacity of bandwidth providers.

While methods exist to mitigate the effects of such attack, including anycast DNS hosting, DNS Made Easy believes that it is both more prudent and more efficient to tackle the root cause of the problem by closing down or fixing as many open recursive resolvers as possible and educating both those within the industry and the wider public about the negative consequences of running an open DNS server.

For further information, visit the Open DNS Resolver Project, and the DNS Made Easy blog.

###

About DNS Made Easy

DNS Made Easy is a subsidiary of Tiggee LLC and is a leader in providing global IP anycast enterprise DNS services. DNS Made Easy implemented the industry’s first triple independent anycast cloud architecture for maximum DNS speed and DNS redundancy. Originally launched in 2002, DNS Made EasyÂ’s services have grown to manage hundreds of thousands of customer domains receiving more than 6.0 billion queries per day. Today, DNS Made Easy builds on a proud history uptime and is the preferred DNS hosting choice of most major brands, especially amongst those comparing price and performance of enterprise IP anycast alternatives. For more information, or for a free trial of their DNS hosting services, visit http://www.dnsmadeeasy.com.

Media Relations
Tiggee LLC
(703) 880-3095
Email Information

Article source: http://news.yahoo.com/dns-made-easy-calls-cleanup-open-dns-resolvers-163649743.html

DrDoS DNS Reflection Attacks Analysis

The DNS Distributed Reflection Denial of Service (DrDoS) technique relies on the exploitation of the Domain Name System (DNS) Internet protocol. Malicious actors, or hackers, will spoof, or pretend to be, the IP address of their primary target and then send application requests to a list of victim DNS servers. When each DNS server receives the forged request, the server is tricked into responding to the spoofed IP address of the hacker’s primary target. The victim DNS servers will thus unwittingly send a flood of unwanted responses to the primary target.

This method of DDoS attack is disruptive to both the victim DNS servers and the primary target. The scale of the attack depends on the number of victim DNS servers on the attacker’s list. An attacker can build a list of DNS server IP addresses simply by scanning IP ranges and checking for responses on port 53, which is used for DNS messages. Furthermore, since the DrDoS attack uses spoofed IP requests to a legitimate DNS server, attributing the attack to the original malicious actor becomes a difficult task.

Prolexic has observed many DrDoS DNS Reflection attacks, targeting a multitude of industries. An analysis of these attacks is included in this report.

To read more, download the full report below.

Article source: http://www.bsminfo.com/Doc/drdos-dns-reflection-attacks-0001?atc~c=771%20s%3D774%20r%3D001%20l%3Da

How To Stop DNS Amplification DDoS Attack

Last week, the largest DDoS on record hit the Internet leveraging what is known as a DNS Amplification attack.

The U.S. Government’s US-CERT is now warning about the risks associated with DNS Amplification attacks and providing some guidance on how they can be mitigated.

The first step in preventing and mitigating against the risks of DNS Amplification attacks is to properly configure recursive DNS servers.

US-CERT advises that many DNS servers are intended to only be used for a single domain and should not enable recursion at all.

“For DNS servers that are deployed within an organization or ISP to support name queries on behalf of a client, the resolver should be configured to only allow queries on behalf of authorized clients,” US-CERT advises. “These requests should typically only come from clients within the organizationÂ’s network address range.”

Going a step further, DNS Amplification attacks use spoofed IP addresses. US-CERT suggests that Internet Service Providers deny any DNS traffic with spoofed addresses. The suggestion that ISPs deny spoofed IP addresses is not a new idea. The IETF issued a ‘Best Current Practice’ document in 2000, advising ISPs to filter traffic for forged IP addresses.

Read the full story at eSecurity Planet:
US-CERT Warns about DNS Amplification Attacks

Sean Michael Kerner is a senior editor at InternetNews.com, the news service of the IT Business Edge Network, the network for technology professionals Follow him on Twitter @TechJournalist.

Article source: http://www.internetnews.com/security/how-to-stop-dns-amplification-ddos-attack.html

Fix your DNS servers or risk aiding DDoS attacks

Fix your DNS servers or risk aiding DDoS attacks

Although this week’s large-scale DDoS attack against Spamhaus may not have been as crippling as early reports suggested, they were noteworthy in that they shined spotlights on a couple of the Internet’s many underlying weaknesses. Among them are open DNS resolvers, which enable a technique called DNS amplification wherein attackers bombard target servers with as much as 100 bytes of network-clogging traffic for every one byte they send out.

It remains to be seen whether the parties with the know-how and clout will start addressing these shortcomings in a holistic and meaningful way to make the Internet more secure. Unfortunately it will probably take an incident even more devastating and damaging to get that ball rolling.

Threat Post has a good writeup about open resolvers and DNS amplification and their role in the DDoS assault on Spamhaus:

The underlying and percolating issue at play here has to do with the open DNS resolvers being used to DDoS the spam-fighters from Switzerland. Open resolvers do not authenticate a packet-sender’s IP address before a DNS reply is sent back. Therefore, an attacker that is able to spoof a victim’s IP address can have a DNS request bombard the victim with a 100-to-1 ratio of traffic coming back to them versus what was requested. DNS amplification attacks such as these have been used lately by hacktivists, extortionists, and blacklisted webhosts to great success.

Jared Mauch of the Open DNS Resolver Project told Threat Post that the botnot involved in the Spamhaus attacks used more than 30,000 unique DNS resolvers, and “in a larger attack scenario, the collective power of these resolvers could have been used to keep much larger segments of the global network offline.”

The solution: “The Open DNS Resolver Project and others, such as DNS service providers Afilias, recommend the implementation of source address validation,” according to Threat Post. “An IETF RFC, BCP-38, exists that spells out how to use source address validation and build such an architecture to defeat IP source address spoofing.”

Separately, system administrator Trevor Pott has a detailed blog post on The Register in which he confessed to unwittingly contributing to the DDoS attacks, resulting from “a simple configuration error when setting up a DNS server” residing on the edge of his network. He dubbed it an “edge scrubber” that functions as a router, handing out IP addresses to servers and routers within the data center. It also “serves various ‘scut work’ functions on behalf of all the other devices on the network. It is the data center-local network time server, external DNS server, IDS, edge firewall, and bandwidth limiter.”

The problem, he said, was that he neglected to disable recursive lookups on the server, which made it a tool for DNS amplification. “DNS servers can be configured in one of two basic ways,” he explained. “In one possible configuration, a DNS server serves only domains for which it is responsible (authoritative),” he wrote. “In the other configuration the DNS server serves those domains and goes looking on the wider Internet for any domains it isn’t personally set up to manage (recursive)…. Recursive DNS servers are what allow the Internet to work. They are also an attack vector.”

He explained in detail how he remedied the configuration problem with his server. In short, the problem stemmed from an assumption that BIND (an implementation of the DNS protocols) disabled recursion by default; the fix entailed “instructing BIND to only honor recursion requests from servers inside [his] data center.”

More details on configuring your DNS servers to prevent DNS amplification attacks are available at the Open DNS Resolver Project website.

This story, “Fix your DNS servers or risk aiding DDoS attacks,” was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.

Article source: http://www.infoworld.com/t/security/fix-your-dns-servers-or-risk-aiding-ddos-attacks-215510

Flaw leaves servers vulnerable to denial-of-service attacks

A flaw in the widely used BIND DNS (Domain Name System) software can be exploited by remote attackers to crash DNS servers and affect the operation of other programs running on the same machines.

The flaw stems from the way regular expressions are processed by the libdns library that’s part of the BIND software distribution. BIND versions 9.7.x, 9.8.0 up to 9.8.5b1 and 9.9.0 up to 9.9.3b1 for UNIX-like systems are vulnerable, according to a security advisory published Tuesday by the Internet Systems Consortium (ISC), a nonprofit corporation that develops and maintains the software. The Windows versions of BIND are not affected.

BIND is by far the most widely used DNS server software on the Internet. It is the de facto standard DNS software for many UNIX-like systems, including Linux, Solaris, various BSD variants and Mac OS X.

Attack can crash servers

The vulnerability can be exploited by sending specifically crafted requests to vulnerable installations of BIND that would cause the DNS server process—the name daemon, known as “named”—to consume excessive memory resources. This can result in the DNS server process crashing and the operation of other programs being severely affected.

“Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions,” the ISC said. The organization rates the vulnerability as critical. (See also “4 ways to prepare for and fend off DDoS attacks.”)

One workaround suggested by the ISC is to compile BIND without support for regular expressions, which involves manually editing the “config.h” file using instructions provided in the advisory. The impact of doing this is explained in a separate ISC article that also answers other frequently asked questions about the vulnerability.

The organization also released BIND versions 9.8.4-P2 and 9.9.2-P2, which have regular expression support disabled by default. BIND 9.7.x is no longer supported and won’t receive an update.

“BIND 10 is not affected by this vulnerability,” the ISC said. “However, at the time of this advisory, BIND 10 is not ‘feature complete,’ and depending on your deployment needs, may not be a suitable replacement for BIND 9.”

According to the ISC, there are no known active exploits at the moment. However, that might soon change.

“It took me approximately ten minutes of work to go from reading the ISC advisory for the first time to developing a working exploit,” a user named Daniel Franke said in a message sent to the Full Disclosure security mailing list on Wednesday. “I didn’t even have to write any code to do it, unless you count regexes [regular expressions] or BIND zone files as code. It probably will not be long before someone else takes the same steps and this bug starts getting exploited in the wild.”

Franke noted that the bug affects BIND servers that “accept zone transfers from untrusted sources.” However, that is just one possible exploitation scenario, said Jeff Wright, manager of quality assurance at the ISC, Thursday in a reply to Franke’s message.

“ISC would like to point out that the vector identified by Mr. Franke is not the only one possible, and that operators of *ANY* recursive *OR* authoritative nameservers running an unpatched installation of an affected version of BIND should consider themselves vulnerable to this security issue,” Wright said. “We wish, however, to express agreement with the main point of Mr. Franke’s comment, which is that the required complexity of the exploit for this vulnerability is not high, and immediate action is recommended to ensure your nameservers are not at risk.”

This bug could be a serious threat considering the widespread use of BIND 9, according to Dan Holden, director of the security engineering and response team at DDoS mitigation vendor Arbor Networks. Attackers might start targeting the flaw given the media attention surrounding DNS in the recent days and the low complexity of such an attack, he said Friday via email.

Hackers target vulnerable servers

Several security companies said earlier this week that a recent distributed denial-of-service (DDoS) attack targeting an anti-spam organization was the largest in history and affected critical Internet infrastructure. The attackers made use of poorly configured DNS servers to amplify the attack.

“There is a fine line between targeting DNS servers and using them to perform attacks such as DNS amplification,” Holden said. “Many network operators feel that their DNS infrastructure is fragile and often they go through additional measures to protect this infrastructure, some of which exacerbate some of these problems. One such example is deploying inline IPS devices in front of DNS infrastructure. Designing appropriate filters to mitigate these attacks with stateless inspection is near impossible.”

“If operators are relying on inline detection and mitigation, very few security research organizations are proactive about developing their own proof-of-concept code on which to base a mitigation upon,” Holden said. “Thus, these types of devices will very rarely get protection until we see semi-public working code. This gives attackers a window of opportunity that they may very well seize.”

Also, historically DNS operators have been slow to patch and this may definitely come into play if we see movement with this vulnerability, Holden said.

Article source: http://www.pcworld.com/article/2032526/flaw-leaves-servers-vulnerable-to-denial-of-service-attacks.html

Critical denial-of-service flaw in BIND software puts DNS servers at risk

A flaw in the widely used BIND DNS (Domain Name System) software can be exploited by remote attackers to crash DNS servers and affect the operation of other programs running on the same machines.

The flaw stems from the way regular expressions are processed by the libdns library that’s part of the BIND software distribution. BIND versions 9.7.x, 9.8.0 up to 9.8.5b1 and 9.9.0 up to 9.9.3b1 for UNIX-like systems are vulnerable, according to a security advisory published Tuesday by the Internet Systems Consortium (ISC), a nonprofit corporation that develops and maintains the software. The Windows versions of BIND are not affected.

BIND is by far the most widely used DNS server software on the Internet. It is the de facto standard DNS software for many UNIX-like systems, including Linux, Solaris, various BSD variants and Mac OS X.

The vulnerability can be exploited by sending specifically crafted requests to vulnerable installations of BIND that would cause the DNS server process — the name daemon, known as “named” — to consume excessive memory resources. This can result in the DNS server process crashing and the operation of other programs being severely affected.

“Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions,” the ISC said. The organization rates the vulnerability as critical.

One workaround suggested by the ISC is to compile BIND without support for regular expressions, which involves manually editing the “config.h” file using instructions provided in the advisory. The impact of doing this is explained in a separate ISC article that also answers other frequently asked questions about the vulnerability.

The organization also released BIND versions 9.8.4-P2 and 9.9.2-P2, which have regular expression support disabled by default. BIND 9.7.x is no longer supported and won’t receive an update.

“BIND 10 is not affected by this vulnerability,” the ISC said. “However, at the time of this advisory, BIND 10 is not ‘feature complete,’ and depending on your deployment needs, may not be a suitable replacement for BIND 9.”

According to the ISC, there are no known active exploits at the moment. However, that might soon change.

“It took me approximately ten minutes of work to go from reading the ISC advisory for the first time to developing a working exploit,” a user named Daniel Franke said in a message sent to the Full Disclosure security mailing list on Wednesday. “I didn’t even have to write any code to do it, unless you count regexes [regular expressions] or BIND zone files as code. It probably will not be long before someone else takes the same steps and this bug starts getting exploited in the wild.”

Franke noted that the bug affects BIND servers that “accept zone transfers from untrusted sources.” However, that is just one possible exploitation scenario, said Jeff Wright, manager of quality assurance at the ISC, Thursday in a reply to Franke’s message.

“ISC would like to point out that the vector identified by Mr. Franke is not the only one possible, and that operators of *ANY* recursive *OR* authoritative nameservers running an unpatched installation of an affected version of BIND should consider themselves vulnerable to this security issue,” Wright said. “We wish, however, to express agreement with the main point of Mr. Franke’s comment, which is that the required complexity of the exploit for this vulnerability is not high, and immediate action is recommended to ensure your nameservers are not at risk.”

This bug could be a serious threat considering the widespread use of BIND 9, according to Dan Holden, director of the security engineering and response team at DDoS mitigation vendor Arbor Networks. Attackers might start targeting the flaw given the media attention surrounding DNS in the recent days and the low complexity of such an attack, he said Friday via email.

Several security companies said earlier this week that a recent distributed denial-of-service (DDoS) attack targeting an anti-spam organization was the largest in history and affected critical Internet infrastructure. The attackers made use of poorly configured DNS servers to amplify the attack.

“There is a fine line between targeting DNS servers and using them to perform attacks such as DNS amplification,” Holden said. “Many network operators feel that their DNS infrastructure is fragile and often they go through additional measures to protect this infrastructure, some of which exacerbate some of these problems. One such example is deploying inline IPS devices in front of DNS infrastructure. Designing appropriate filters to mitigate these attacks with stateless inspection is near impossible.”

“If operators are relying on inline detection and mitigation, very few security research organizations are proactive about developing their own proof-of-concept code on which to base a mitigation upon,” Holden said. “Thus, these types of devices will very rarely get protection until we see semi-public working code. This gives attackers a window of opportunity that they may very well seize.”

Also, historically DNS operators have been slow to patch and this may definitely come into play if we see movement with this vulnerability, Holden said.

Article source: http://www.cio.com.au/article/457667/critical_denial-of-service_flaw_bind_software_puts_dns_servers_risk/?utm_medium=rss&utm_source=taxonomyfeed

How to Freak Out, Appropriately, About the Internet War Apocalypse

There has been a wave of skepticism about the severity of this month’s “biggest ever” denial-of-service attack — that a fight between website hosts and spam fighters may or may not have sunk the DNS servers that run the entire Internet — and, well, it’s OK to be a little scared of the enormity of this thing. Just not that scared. The New York Times‘s source compared the DDoS attacks to “nuclear bombs,” while the BBC quoted the head of the spam company, Spamhaus, as claiming that their attacks would be strong enough to bring down a major government’s Internet infrastructure “instantly.” Gizmodo and Venture Beat both countered with no-big-deal posts, with Gizmodo’s Sam Biddle going so far as to call the “Internet War Apocalypse” a “lie.” Not everyone agrees. So, if even the tech nerds are fighting over the fight that maybe slowed down the whole Internet, how should regular Internet users approach this thing? Like this:

RELATED: ‘Non-Humans’ Account for 51% of All Internet Traffic

Think Local, Not Global

The “nuclear bomb” analogy seems to have paint a picture that this DDoS attack leveled the entire web, and world-wide. That’s not what happened. Parts of the Internet, however, did see some down time as a result of the attack. The Verge’s Russell Brandom pointed to the following chart showing a dip at the London Internet Exchange, which is legally designated as “critical infrastructure”:

RELATED: The 10-Year-Old Security Sink Hole Slowing the Entire Internet, Explained

Akamai’s Real Time Global Web Monitor also showed congestion Wednesday in The Netherlands, where this whole fight originated, and in the U.K, per this chart:

RELATED: Group Sex Is a Great Way to Weed Out Snitches

A Sophos analyst also confirmed these European outages to ZDNet. And, according to Naked Security, there were reports of 21.7 million insecure/misconfigured DNS servers on the IPv4 yesterday. So, some people did see a slow down in their usage yesterday. Those people just don’t live in America, where a lot of the scary media reports originated.

Be Scared in Theory, Not in Practice

That “biggest ever” 300gbps figure is a “massive amount of bandwidth to a single enterprise or service,” as a spokesperson for NIT, a tier 1 Internet operator, told Biddle. And it is the biggest ever, which does mean something — these hacks are getting more serious, as this Arbor Network chart of previous DDoS attacks shows:

But the DNS servers that run much of the Internet can handle something like that. Even the LINX dip from above managed okay, as The Verge’s Brandom explains: “The web is built on redundancy, so the extra terabyte-per-second of bandwidth could be spread across the network without any catastrophic failures.”

Still, there is a reason for a little bit of alarmism: “The wake-up call for telecoms is real,” Brandom writes. “There’s never been a DDoS attack against an internet exchange before, and exchanges aren’t set up to protect against them.” As we pointed out yesterday, there is also a reason these DDoS attacks are possible in the first place, and it comes in the form of a security hole, which has to do with Open DNS resolvers, as opposed to closed ones. 

Give in, Because There Is Nothing You Can Do

You might as well going on Internetting as usual, to be honest. For the hyper nervous users out there, though, this particular issue doesn’t sound that hard to fix. CloudFare, the anti-DDoS firm Spamhaus enlisted to ward off the attack, suggests closing up these “openings.” NakedSecurity’s Chester Wisniewski reiterates this point: “If you are an administrator of DNS services, it is critical that you configure your recursive name servers to only reply to your own network.” Of course, the specific type of “reflection” DDoS attack is just one of the many possible ways to take down the Internet. But the hyper-awareness for this “biggest ever” attack might encourage higher security standards in the future. Still: Relax.

Article source: http://news.yahoo.com/freak-appropriately-internet-war-apocalypse-172157481.html

Misconfigured Open DNS Resolvers Key To Massive DDoS Attacks

Maybe this is over my head. But how would one rung a “safe” DNS server then? My interpretation of the article basically says to let only specific people use your DNS server, but then how would a company run a public resolver?

For example, Google runs open public name servers on 8.8.8.8 and 8.8.4.4, same with OpenDNS, and many, many more. What is to stop those servers from being used in this sort of attack? Is this article really advocating a situation where you MUST use only your own ISP’s resolver and trust them not to do what so many of them consistently do and mess with the results?

Or am I completely missing the point to this article?

Article source: http://slashdot.feedsportal.com/c/35028/f/647410/s/2a1be58d/l/0Ltech0Bslashdot0Borg0Cstory0C130C0A30C280C19382370Cmisconfigured0Eopen0Edns0Eresolvers0Ekey0Eto0Emassive0Eddos0Eattacks0Dutm0Isource0Frss10B0Amainlinkanon0Gutm0Imedium0Ffeed/story01.htm

How SpamhausÂ’ attackers turned DNS into a weapon of mass destruction

A little more than a year ago, details emerged about an effort by some members of the hacktivist group Anonymous to build a new weapon to replace their aging denial-of-service arsenal. The new weapon would use the Internet’s Domain Name Service as a force-multiplier to bring the servers of those who offended the group to their metaphorical knees. Around the same time, an alleged plan for an Anonymous operation, “Operation Global Blackout” (later dismissed by some security experts and Anonymous members as a “massive troll”), sought to use the DNS service against the very core of the Internet itself in protest against the Stop Online Piracy Act.

This week, an attack using the technique proposed for use in that attack tool and operation—both of which failed to materialize—was at the heart of an ongoing denial-of-service assault on Spamhaus, the anti-spam clearing house organization. And while it hasn’t brought the Internet itself down, it has caused major slowdowns in the Internet’s core networks.

DNS Amplification (or DNS Reflection) remains possible after years of security expert warnings. Its power is a testament to how hard it is to get organizations to make simple changes that would prevent even recognized threats. Some network providers have made tweaks that prevent botnets or “volunteer” systems within their networks to stage such attacks. But thanks to public cloud services, “bulletproof” hosting services, and other services that allow attackers to spawn and then reap hundreds of attacking systems, DNS amplification attacks can still be launched at the whim of a deep-pocketed attacker—like, for example, the cyber-criminals running the spam networks that Spamhaus tries to shut down.

Hello, operator?

The Domain Name Service is the Internet’s directory assistance line. It allows computers to get the numerical Internet Protocol (IP) address for a remote server or other network-attached device based on its human-readable host and domain name. DNS is organized in a hierarchy; each top-level domain name (such as .com, .edu, .gov, .net, and so on) has a “root” DNS server keeping a list of each of the “authoritative” DNS servers for each domain registered with them. If you’ve ever bought a domain through a domain registrar, you’ve created (either directly or indirectly) an authoritative DNS address for that domain by selecting the primary and secondary DNS servers that go with it.

When you type “arstechnica.com” into your browser’s address bar and hit the return key, your browser checks with a DNS resolver—your personal Internet 411 service— to determine where to send the Web request. For some requests, the resolver may be on your PC. (For example, this happens if you’ve requested a host name that’s in a local “hosts” table for servers within your network, or one that’s stored in your computer’s local cache of DNS addresses you’ve already looked up.) But if it’s the first time you’ve tried to connect to a computer by its host and domain name, the resolver for the request is probably running on the DNS server configured for your network—within your corporate network, at an Internet provider, or through a public DNS service such as Google’s Public DNS.

There are two ways for a resolver to get the authoritative IP address for a domain name that isn’t in its cache: an iterative request and a recursive request. In an iterative request, the resolver pings the top-level domain’s DNS servers for the authoritative DNS for the destination domain, then it sends a DNS request for the full hostname to that authoritative server. If the computer that the request is seeking is in a subdomain or “zone” within a larger domain—such as www.subdomain.domain.com—it may tell the resolver to go ask that zone’s DNS server. The resolver “iterates” the request down through the hierarchy of DNS servers until it gets an answer.

But on some networks, the DNS resolver closest to the requesting application doesn’t handle all that work. Instead, it sends a “recursive” request to the next DNS server up and lets that server handle all of the walking through the DNS hierarchy for it. Once all the data is collected from the root, domain, and subdomain DNS servers for the requested address, the resolver then pumps the answer back to its client.

To save time, DNS requests don’t use the “three-way handshake” of the Transmission Control Protocol (TCP) to make all these queries. Instead, DNS typically uses the User Datagram Protocol (UDP)—a “connectionless” protocol that lets the server fire and forget requests.

Pump up the volume

That makes the sending of requests and responses quicker—but it also opens up a door to abuse of DNS that DNS amplification uses to wreak havoc on a target. All the attacker has to do is find a DNS server open to requests from any client and send it requests forged as being from the target of the attack. And there are millions of them.

The “amplification” in DNS amplification attacks comes from the size of those responses. While a DNS lookup request itself is fairly small, the resulting response of a recursive DNS lookup can be much larger. A relatively small number of attacking systems sending a trickle of forged UDP packets to open DNS servers can result in a firehose of data being blasted at the attackers’ victim.

DNS amplification attacks wouldn’t be nearly as amplified if it weren’t for the “open” DNS servers they use to fuel the attacks. These servers have been configured (or misconfigured) to answer queries from addresses outside of their network. The volume of traffic that can be generated by such open DNS servers is huge. Last year, Ars reported on a paper presented by Randal Vaughan of Baylor University and Israeli security consultant Gadi Evron at the 2006 DefCon security conference. The authors documented a series of DNS amplification attacks in late 2005 and early 2006 that generated massive traffic loads for the routers of their victims. In one case, the traffic was “as high as 10Gbps and used as many as 140,000 exploited name servers,” Vaughan and Evron reported. “A DNS query consisting of a 60 byte request can be answered with responses of over 4000 bytes, amplifying the response packet by a factor of 60.”

But even if you can’t find an open DNS server to blast recursive responses from, you can still depend on the heart of the Internet for a respectable hail of packet projectiles. A “root hint” request—sending a request for name servers for the “.” domain—results in a response 20 times larger than the packet the request came in. That’s in part thanks to DNS-SEC, the standard adopted to make it harder to spoof DNS responses, since now the response includes certificate data from the responding server.

In the case of the attack on Spamhaus, the organization was able to turn to the content delivery network CloudFlare for help. CloudFlare hid Spamhaus behind its CDN, which uses the Anycast feature of the Border Gateway Protocol to cause packets destined for the antispam provider’s site to be routed to the closest CloudFlare point of presence. This spread out the volume of the attack. And CloudFlare was able to then shut off amplified attacks aimed at Spamhaus with routing filters that blocked aggregated DNS responses matching the pattern of the attack.

But that traffic still had to get to Cloudflare before it could be blocked. And that resulted in a traffic jam in the core of the Internet, slowing connections for the Internet as a whole.

No fix on the horizon

The simplest way to prevent DNS amplification and reflection attacks would be to prevent forged DNS requests from being sent along in the first place. But that “simple” fix isn’t exactly easy—or at least easy to get everyone who needs to participate to do.

There’s been a proposal on the books to fix the problem for nearly 13 years—the Internet Engineering Task Force’s BCP 38, an approach to “ingress filtering” of packets. First pitched in 2000  1998 as part of RFC 2267 , the proposal has gone nowhere. And while the problem would be greatly reduced if zone and domain DNS servers simply were configured not to return recursive or even “root hint” responses received from outside their own networks, that would require action by the owners of the network. It’s an action that doesn’t have a direct monetary or security benefit to them associated with it.

ISPs generally do “egress filtering”—they check outbound traffic to make sure it’s coming from IP addresses within their network.  This prevents them from filling up their peering connections with bad traffic.  But “ingress” filtering would check to make sure that requests coming in through a router were coming from the proper direction based on their advertised IP source.

Another possible solution that would eliminate the problem entirely is to make DNS use TCP for everything—reducing the risk of forged packets.  DNS already uses TCP for tasks like zone transfers. But that would require a change to DNS itself, so it’s unlikely that would ever happen, considering that you can’t even convince people to properly configure their DNS servers to begin with.

Maybe the attack on Spamhaus will change that, and core network providers will move to do more to filter DNS traffic that doesn’t seem to match up with known DNS servers. Maybe just maybe, BCP 38 will get some traction. And maybe pigs will fly.

Article source: http://arstechnica.com/information-technology/2013/03/how-spamhaus-attackers-turned-dns-into-a-weapon-of-mass-destruction/

Spamhaus attacks expose huge open DNS server dangers

Massive distributed denial of service attacks on Spamhaus this week focused widespread attention on the huge security threats posed by millions of poorly configured Internet Domain Name System (DNS) servers.

The attacks on Spamhaus that began March 19 were apparently launched by a group opposed to the Geneva, Switzerland-based volunteer organization’s antispam work.

Several security firms described the attacks on the organization as the largest — by far — ever publicly known DDoS attacks to date.

In DDoS attacks, hackers typically try to take down a network by directing huge volumes of useless traffic to it. The traffic is usually generated using large botnets of compromised computers.

Large DDoS attacks have typically tended to involve between 4 gigabits per second to 10 Gbps of traffic.

The Spamhaus attacks involved traffic volumes that reached a staggering 300 Gbps — said to be three times larger than the largest DDoS traffic seen to date and magnitudes greater than the traffic involved in a majority of past denial of service attacks.

The perpetrators behind the attack employed the well known, but infrequently used method DNS reflection to generate the huge stream of DDoS traffic directed against Spamhaus.

DNS servers are used primarily to look up and resolve domain names such as www.computerworld.com and www.idg.com to their corresponding IP addresses. If a DNS server does not have the domain information in its database or cache. it queries other nearby DNS servers for the information.

Ideally, DNS servers should be configured only to handle look up requests coming from within a specific domain or IP address range. So a DNS server belonging to an ISP should handle only requests coming from within the its IP address range.

In reality however, millions of DNS servers are configured by default to be open DNS resolvers that accept and respond to queries from outside their own domain, making them vulnerable to exploitation by attackers because virtually anyone on the Internet can use an open DNS server to handle genuine or malicious queries.

For instance, to generate DDoS traffic, the attackers behind the Spamhaus attack sent queries with a spoofed source address to tens of thousands of open DNS resolvers, said Matthew Prince, CEO of CloudFlare, which has been helping Spamhaus deal with the recent attacks.

The lookup requests were made to appear as if they came from Spamhaus. So the responses to the requests from the tens of thousands of open DNS resolvers were sent to Spamhaus, generating a huge volume of traffic.

To magnify the volume of traffic, the attackers crafted the look up queries in such a manner as to get each open DNS servers to respond with much larger volumes of data than normal, Prince said.

Denial-of-service attacks that take advantage of open DNS resolvers are not new.

As far back as in 2006, more than 1,500 organizations around the world were hit by a series of similar attacks, prompting wide concern from security experts.

Then, as now, many security experts warned that ISPs and others operating DNS servers must ensure that their systems are properly configured to prevent attacks such as the one launched against Spamhaus. The problem remains as pervasive as ever despite the warnings, experts note today.

The Open DNS Resolver Project , an effort by a group of security experts to draw attention to the issue, estimates that there are currently about 27 million DNS servers that are open resolvers. About 25 million of those pose a significant threat, according to the project’s website.

According to Prince, barely 100,000 of the open resolvers were used to direct 300 Gbps of traffic against the organization. “What’s spooky here is that only a tiny fraction of the open resolvers were used,” he said. The attackers could easily have co-opted more DNS servers, Prince noted.

“This is a situations where some configuration changes on the DNS server side can help prevent the attacks,” said Alex Cox, a principal security researcher with RSA Security’s FirstWatch team.

But the required changes are difficult to get without a broad collaboration among ISPs. “The problem with a DNS attack is you can’t really turn your DNS servers off,” without causing widespread disruption, Cox said. “Once this thing blows over it will be interesting to see how some of the folks whose infrastructure was used, will respond.”

The perpetrators of this week’s attacks knew that Spamhaus had a good infrastructure in place to deal with denial of service attacks and therefore had to do something really big, said Dan Holden, director of the security and engineering response team at Arbor Networks.

Such attacks are not fully defendable but can be mitigated by ensuring that DNS servers are configured properly, he said. “The good news is that these open DNS resolvers will get a lot more visibility,” following the attacks he said. “So hopefully the issue will get fixed.”

Several standards are readily available to help ISPs and others operating DNS servers to configure systems to ensure they respond only to requests from their own users, said Mike Smith director of the customer security incident response team at Akamai.

DNS server operators also need to have egress filtering controls in place to ensure that the DNS traffic leaving their networks originated from inside their network, he said.

The Open DNS Resolver Project also calls on DNS server operators to consider implementing rate limiting software to prevent the sort of traffic amplification that was used in the Spamhaus attacks.

“There are things that need to get cleaned up. That is why we need some awareness of the problem,” Smith said.

Jaikumar Vijayan covers data security and privacy issues, financial services security and e-voting for Computerworld. Follow Jaikumar on Twitter at @jaivijayan, or subscribe to Jaikumar’s RSS feed . His e-mail address is jvijayan@computerworld.com.

Read more about cybercrime and hacking in Computerworld’s Cybercrime and Hacking Topic Center.

Article source: http://www.cio.com.au/article/457573/spamhaus_attacks_expose_huge_open_dns_server_dangers/?utm_medium=rss&utm_source=taxonomyfeed

IT Pro confession: How I helped in the BIGGEST DDoS OF ALL TIME

Sysdamin blog I contributed to the massive DDOS attack against Spamhaus. What flowed through my network wasn’t huge – it averaged 500Kbit/sec – but it contributed. This occurred because I made a simple configuration error when setting up a DNS server; it’s fixed now, so let’s do an autopsy.

The problem


I should start off by apologizing to CloudFlare and Spamhaus; my lapse contributed to a DDOS against their infrastructure. More damning than merely having been an unwitting participant is that I knew enough about this sort of attack to have set up rudimentary protections against it and yet I still forgot the critical component: actually disabling recursive lookups.

The way a DNS amplification attack works is simple. DNS servers can be configured in one of two basic ways. In one possible configuration a DNS server serves only domains for which it is responsible (authoritative). In the other configuration the DNS server serve those domains and goes looking on the wider internet for any domains it isn’t personally set up to manage (recursive).

Your DNS server at the office might be configured to be authoritative for localdomain.yourcompany.com. If you want to go to www.google.com then in a strictly authoritative configuration your DNS server won’t be able to provide an answer: it doesn’t know where www.google.com is.

In a recursive configuration the DNS server asks the list of root servers it has preconfigured who owns the “.com” domain. It then asks the .com servers who owns “google.com”. It then asks “google.com” who owns “www.google.com” and delivers that address back to you.

As you can see, recursive DNS servers are what allow the internet to work. They are also an attack vector. Let’s say that you leave your recursive server open to the internet. Now not only can you ask your DNS server for information about other DNS servers on the internet, so can anyone else. If someone asks your server “where is www.google.com” a whole bunch of times then your server starts flooding google.com’s DNS servers.

For every 1 byte of data sent to your DNS server 50 bytes of traffic end up directed at the target. This is a DNS amplification attack. The issue has been around for ages, but it has taken this latest over-the-top attack to get most DNS administrators to sit up and notice. Things aren’t great right now for Cloudflare or Spamhaus, but open recursive servers are finally starting to close. What follows is nerd detail on the problem.

My server

The server in question is what I term an “edge scrubber.” The system itself is nothing particularly special. It is an Intel Atom D510 with 2GB of RAM, 2 1Gbit Intel NICs running CentOS 5.9 with a real time kernel.

The scrubber sits on the very edge of my network and does what most Cisco networking folks would use a router for. It has an external IP address given to me by my ISP and a gateway on the ISP’s network.. I have a /27 block of IP addresses assigned me by my ISP and this device hands those out to servers and routers within the datacenter.

The scrubber also serves various “scut work” functions on behalf of all the other devices on the network. It is the datacenter-local network time server, external DNS server, IDS, edge firewall and bandwidth limiter. Every single packet in or out of the datacenter passes through this box; it handles 30Mbit symmetrical with some heavy deep packet inspection just fine. 45 Mbit seems to be the maximum it will do reliably.

The bad DNS configuration

The DNS server in question was one I had gotten halfway through setting up to “scrub” bad addresses. I hadn’t tested the setup as it had been copied directly from a testlab system but did not have any production servers yet pointed to it.

The goal is to use the malwaredomains DNS blackhole list to make sure that nothing in the datacenter can access the worst of the known “bad guy” websites out there. Cutting off DNS access to these sites effectively neuters a whole host of potential browser-based attacks and even helps thwart any botnets that might take hold. The config consists of three files:

Next page: Nuts and bolts time

Article source: http://go.theregister.com/feed/www.theregister.co.uk/2013/03/28/i_accidentally_the_internet/

The 10-Year-Old Security Sink Hole Slowing the Entire Internet, Explained

The largest known hack attack of its kind brought the Internet to a crawl for users all over the world, but don’t blame the hackers — the outage all stems from an increasingly vulnerable, decade-old security problem with the “Internet’s basic plumbing” that can be easily fixed. A fight between Dutch web hosting service Cyberbunker and a spam-fighting group called Spamhaus resulted in “retaliation” attacks of the distributed denial-of-service (or DDoS) variety on Spamhouse’s servers, all of which were possible because of what’s called an “open DNS.” While the hackers only meant to hurt Spamhouse, the method resulted in outages for the rest of the Internet at large — or at least millions of non-hacker users — because Cyberpunker went through a Domain Name Server, also known as the Internet’s main hub, which takes website names and turns them into the ISPs that computers can understand. Specifically, the hack worked like this, according to The New York Times‘s John Markoff and Nicole Perlroth:

In the latest incident, attackers sent messages, masquerading as ones coming from Spamhaus, to those machines, which were then amplified drastically by the servers, causing torrents of data to be aimed back at the Spamhaus computers.

Because the unusually aggressive hack — 300 billion bits per second were being sent by a network of computers, enough to take down government infrastructure — was initially aimed at a DNS, which hosts a bunch of Internet sites, it clogged traffic for more than just Spamhouse. 

RELATED: ‘Non-Humans’ Account for 51% of All Internet Traffic

This type of scheming is possible in the first place, however, because of one long known hole: “Many large Internet service providers have not set up their networks to make sure that traffic leaving their networks is actually coming from their own users,” explain Markoff and Perlroth. Certain DNS providers are “open,” meaning they respond to queries from any ISP rather than just “authorized” clients, as cloud based web security service Cloudfare explains in this post this post by Mathew Prince:

The problem is, many people running DNS resolvers leave them open and willing to respond to any IP address that queries them. This is a known problem that is at least 10 years old. What has happened recently is a number of distinct botnets appear to have enumerated the Internet’s IP space in order to discover open resolvers. Once discovered, they can be used to launch significant DNS Amplification Attacks.

In a separate post he calls DNS the “scourge of the Internet.” This hole has been known for “at least 10 years,” note Markoff and Perlroth, but hackers have only started exploiting it for attacks recently. Unfortunately, the method is an increasingly popular one with increasingly powerful attacks, says Prince: “The size of these attacks will only continue to rise until all providers make a concerted effort to close them.”

RELATED: Anonymous Knocks Australian Spy Site Offline in Digital Protest

Perhaps more disconcerting than the fact that many major ISPs have a major, gaping flaw, is that once the attacks occur it’s very difficult to stop their crippling effects. “You can’t stop a DNS flood by shutting down those servers because those machines have to be open and public by default. The only way to deal with this problem is to find the people doing it and arrest them,” security researcher Dan Kaminsky told the Times. The good news is there is a longer term solution: Close ’em up. “The best practice, if you’re running a recursive DNS resolver is to ensure that it only responds to queries from authorized clients,” adds Prince. 

RELATED: What Was the FBI Doing with 12 Million Apple IDs Anyway?

Image via Shutterstock by gualtiero boffi

Article source: http://news.yahoo.com/10-old-security-sink-hole-slowing-entire-internet-173316376.html

Google Dresses Up DNS Lookups with Enhanced Security Features

When we talk about DNS lookup, security becomes a common concern. Having considered the same, Google has fully implemented a security feature that ensures a person looking up a website isnÂ’t accidentally directed to a fake one.

Launched in 2009, Google’s Public DNS is a free DNS lookup service that helps translate a domain name, into an IP address that can be called into a browser. Due to increased problem of “cache poisoning” attacks, DNS systems can be tampered with by hackers, which leads to directing users to a different website, usually malicious.

To cope with the problem, ISPs and other network operators have been slowly implementing DNS Security Extensions (DNSSEC). This involves using a public key cryptography to digitally “sign” the DNS records for websites. But a lot of effort requires to be done to ensure that all sites are digitally signed. The sites which are not signed usually become a victim of cache poisoning.

With this update, Google is now checking the digital signatures on DNSSEC-formatted messages, an important step in ensuring correct DNS queries.

“Previously, we accepted and forwarded DNSSEC-formatted messages but did not perform validation,” wrote Yunhong Gu, team lead for Google Public DNS. “With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.”

As of now, GoogleÂ’s Public DNS answers more than 130 billion queries from more than 70 million IP addresses per day. Out of this, only 7 percent of queries request DNSSEC information.

Article source: http://siliconangle.com/blog/2013/03/21/google-dresses-up-dns-lookups-with-enhanced-security-feature/

10 Killer Open Source Networking Tools

Bangalore: Network administrator deals with many networks, related glitches like routing issues, slow network applications, DNS resolution problems and others. And the only thing which can bail out an administrator are a solid set of tools.

There are many such tools that exist for free. And few of them are incredibly good at keeping a close watch over your network and as well as meets many other needs of the busy network manager.  From monitoring, troubleshooting, and security analysis tools to utilities for keeping track of IP allocations, passwords, and router configurations, read on to know top 10 open source tools for network admin, as compiled by InfoWorld.

#10 Dig

Generally while trouble shooting a network; DNS (domain name system) problems are overlooked. So a reliable tool always gets prime importance here that can provide detailed information about how users’ DNS queries are being resolved and Dig fits the bill.

Dig is an open source networking tool developed by Internet Systems Consortium, the same group that produced the BIND DNS server software running the majority of DNS servers worldwide.

Dig is a command-line utility tool that performs DNS queries. It also tells you a lot about the queries and replies; the extra information that you will need to determine why you’re getting a strange reply from a DNS server.

The default output of Dig provides you with all the data you’ll require for troubleshooting like reply/error codes from the server, flags used in the query and others. Dig can be quite useful when you’re trying to diagnose slow network applications, by determining how long it takes a computer to get DNS resolution for the application server’s domain name.

Also Read: 10 Safest Internet Browsers For Enterprises and Meet Sundar Pichai, Google Android’s New Spearhead

Article source: http://www.siliconindia.com/news/enterpriseit/10-Killer-Open-Source-Networking-Tools-nid-143661-cid-7.html

Google enhances security for your website look-ups

Google has fully implemented a security feature that ensures a person looking up a website isn’t inadvertently directed to a fake one.

The Internet company has run its own free public Domain Name System (DNS) lookup service, called Public DNS, since 2009. DNS lookups are required to translate a domain name, such as www.idg.com, into an IP address that can be called into a browser.

But DNS systems can be tampered with by hackers. In an attack called “cache poisoning,” a DNS server is hacked and modified so that a user looking for www.idg.com is directed to a different website.

ISPs and other network operators have been slowly implementing DNS Security Extensions (DNSSEC), which use public key cryptography to digitally “sign” the DNS records for websites.

DNSSEC requires a fair amount of work to implement. Domain owners have to ensure their sites are digitally signed. About one-third of top-level domains are signed, but most second-level domains are not, according to Google. ISPs and other network providers must also configure their systems.

Google now checking

Google said it is now checking the digital signatures on DNSSEC-formatted messages, an important step in ensuring correct DNS queries.

“Previously, we accepted and forwarded DNSSEC-formatted messages but did not perform validation,” wrote Yunhong Gu, team lead for Google Public DNS. “With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.”

Google’s technical pages on DNSSEC state that if it cannot validate a domain, it will return an error response. But if a very popular domain is failing to validate, it may exclude the site from its blacklist until the problem is fixed.

Google’s Public DNS answers more than 130 billion queries from more than 70 million IP addresses per day, Gu wrote. Only 7 percent of those queries request DNSSEC information, however.

“Overall, DNSSEC is still at an early stage, and we hope that our support will help expedite its deployment,” Gu wrote.

Article source: http://www.pcworld.com/article/2031383/google-enhances-security-for-your-website-look-ups.html

Google fully implements security feature on DNS lookups

Google has fully implemented a security feature that ensures a person looking up a website isn’t inadvertently directed to a fake one.

The Internet company has run its own free public Domain Name System (DNS) lookup service, called Public DNS, since 2009. DNS lookups are required to translate a domain name, such as www.idg.com, into an IP address that can be called into a browser.

But DNS systems can be tampered with by hackers. In an attack called “cache poisoning,” a DNS server is hacked and modified so that a user looking for www.idg.com is directed to a different website.

ISPs and other network operators have been slowly implementing DNS Security Extensions (DNSSEC), which uses public key cryptography to digitally “sign” the DNS records for websites.

DNSSEC requires a fair amount of work to implement. Domain owners have to ensure their sites are digitally signed. About one-third of top-level domains are signed, but most second-level domains are not, according to Google. ISPs and other network providers must also configure their systems.

Google said it is now checking the digital signatures on DNSSEC-formatted messages, an important step in ensuring correct DNS queries.

“Previously, we accepted and forwarded DNSSEC-formatted messages but did not perform validation,” wrote Yunhong Gu, team lead for Google Public DNS. “With this new security feature, we can better protect people from DNS-based attacks and make DNS more secure overall by identifying and rejecting invalid responses from DNSSEC-protected domains.”

Google’s technical pages on DNSSEC state that if it cannot validate a domain, it will return an error response. But if a very popular domain is failing to validate, it may exclude the site from its blacklist until the problem is fixed.

Google’s Public DNS answers more than 130 billion queries from more than 70 million IP addresses per day, Gu wrote. Only 7 percent of those queries request DNSSEC information, however.

“Overall, DNSSEC is still at an early stage and we hope that our support will help expedite its deployment,” Gu wrote.

Send news tips and comments to jeremy_kirk@idg.com. Follow me on Twitter: @jeremy_kirk

Article source: http://www.computerworld.com.au/article/456804/google_fully_implements_security_feature_dns_lookups/?utm_medium=rss&utm_source=taxonomyfeed