uncompiled.com

D-Link enhanced its router security to a higher level of protection by incorporating both CAPTCHA and DNSSEC to guard against hacking, worms, viruses and other malicious Web attacks.

DNSSEC is a suite of Internet Engineering Task Force (IETF) specifications that adds security to the DNS to provide assurance that the information received from a Domain Name Server is authentic. The security extensions are designed to protect the DNS from man-in-the-middle and cache poisoning attacks, which can occur when hackers corrupt DNS data stored on recursive name servers to redirect queries to malicious sites.

DNSSEC applies digital signatures to DNS data to authenticate the data’s origin and verify its integrity as it moves across the Internet and can provide users with effective verification that their applications, such as Web or email, are using the correct addresses for servers they want to reach.

CAPTCHA is a challenge-response test that ensures that a response during a user logon is not computer-generated but instead is truly entered by a human hand, by requiring a user to manually enter a small amount of text displayed in an image to help prevent automated registration and fraud.

To further consider security while future-proofing its routers, D-Link is migrating to IPv6 certification. With the growing number of Internet-capable devices on the market the pool of IPv4 address has dropped to six percent and is expected to run out sometime in 2011. While this is a major motivation for IPv6, other improvements are also realized.

The IPv6 specification now specifies certain security measures that were not defined in IPv4, such as IPSec. IPSec is a method of authenticating and encrypting data transferred between pairs of hosts. Although it was possible to implement IPSec with IPv4, it was not part of the specification. IPSec is now a requirement, not an option, in the IPv6 specification.

Source

The dream of bolting security onto the Internet’s Domain Name System takes one step closer to reality Wednesday as Internet policymakers host a ceremony in northern Virginia to generate and store the first cryptographic key that will be used to secure the Internet’s root zone.

This key ceremony is one of the final steps in the deployment of DNS Security Extensions (DNSSEC) on the Internet’s root zone. DNSSEC is an emerging Internet standard that prevents spoofing attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption.

“The key ceremony will generate the master root key, the key that signs all the other keys,” explains Ken Silva, CTO of VeriSign, which operates two of the Internet’s 13 root servers along with the back-end systems that power the .com and .net top-level domains. “This is being done a month before the actual roll-out of DNSSEC so that we have a valid key and that we can test with it.”

DNSSEC is being deployed across the Internet infrastructure, from the root servers at the top of the DNS hierarchy to the servers that run .com and .net and other top-level domains, and then down to the servers that cache content for individual Web sites.

Once it is widely deployed, DNSSEC will prevent cache poisoning attacks, where traffic is redirected from a legitimate Web site to a fake one without the Web site operator or user knowing. Cache poisoning attacks are the result of a serious flaw in the DNS that was disclosed by security researcher Dan Kaminsky in 2008.

Today’s key ceremony is being hosted by the Internet Corporation for Assigned Names and Numbers (ICANN) in a secure data center in Culpeper, Va., outside of Washington, D.C. A similar key ceremony will take place in Los Angeles in early July.

The key ceremony will demonstrate the set of procedures that the Internet engineering community has created to generate and store keys for the root zone in a secure way. Attendees will include ICANN staff and DNS experts from around the world. The key generation and storage process will be audited.

“People from all over the world will be part of the process of creating the key for the top level of the DNS,” explains Steve Crocker, an Internet security expert and CEO of Shinkuro. “They will witness and be able to report that the proper procedure was carried fairly and scrupulously.”

The two key ceremonies are among the last steps before production-scale deployment of DNSSEC on the root zone, which is scheduled for July 15.

Between now and July 15, the root server operators will conduct additional testing of DNSSEC.

“We’re testing as many possible corner cases that we can imagine,” Silva says. “We’re trying to test every permutation of key sizes, key roll-over, key expiration and all those kinds of issues. We’re testing to see how the system responds and whether our monitors and detection can catch those sorts of things.”

Silva says the testing is going well, thanks to new monitoring capabilities that were added to the root servers.

“We’ve very pleased with the additional monitors that we put in the root infrastructure,” Silva says. “There are a lot more parts in the root zone now. We have keys in there. We have trust anchors in there. There’s a lot of new material in the root zone, and the traditional monitors were making sure that names were consistent and the syntax was right. Now we have additional information, so we’ve expanded the monitors to look for expired keys, invalid keys, keys that have not been properly signed and all of those kinds of things.”

Kaminsky bug drives DNSSEC
DNSSEC has gained a groundswell of support since the Kaminsky bug was discovered in 2008.

A handful of countries — including Sweden, the Czech Republic, Puerto Rico, Bulgaria and Brazil — already support DNSSEC on their country-code domains as does the .org domain for non-profit organizations.

The U.S. federal government is in the midst of deploying DNSSEC on the .gov domain. Next up are .edu, which will be cryptographically signed in July, followed by .net in November and .com in March 2011, VeriSign said. Once the root zone is signed, top-level domains that support DNSSEC can offer end-to-end security to their Web site operators.

“We expect a flurry of activity as people in Sweden, Brazil and other countries deploy DNSSEC,” Silva says. He adds that as much as 50% of DNS queries can support the DNSSEC standard due to default settings on popular DNS software.
So far, Internet security experts have seen no technical roadblocks to the deployment of DNSSEC from the root servers on down.

“It’s been pretty smooth,” Crocker says of the DNSSEC roll-out on the root servers. “I haven’t heard of any issues” that would delay deployment of DNSSEC on .com or .net.

Source

Yesterday (Wednesday) the last of the 13 authoritative root servers for the domain name system switched over to the DNS Security Extensions (DNSSEC) security protocol. DNSSEC is intended to prevent DNS exploits such as cache poisoning. All 13 root servers are now serving a signed version of the root zone. However, it is not possible to validate these signatures at present as the public key remains undisclosed. This precautionary measure is intended to ensure that for the time being it remains possible to switch back to an unsigned root zone, should the need arise.

There have been no reports of any problems in the immediate aftermath of VeriSign’s J root server starting to serve DNSSEC signatures. Experts at the 60th RIPE meeting in Prague were almost unanimous in predicting a glitch-free switchover, following the successful switchovers of the other 12 root servers in recent months. The only apocalyptic note was sounded by a countdown to the demise of the unsigned root zone.

Yesterday’s changeover does mean the .root zone is now dead. VeriSign, which operated the master server for the root zone, has for several years used a single entry under .root, that served the purpose of checking that the bulky root zone had been transferred. According to Jaap Akkerhuis, a DNS expert at nl.netLabs, the creation of the .root entry was prompted by a complete outage of the .com zone following a data transfer error. Rigid DNSSEC procedures render this trick for root servers operated by VeriSign and the Internet Corporation for Assigned Names and Numbers (ICANN) obsolete.

There will also be a key ceremony in June, involving 21 volunteer ‘crypto officers’ and ‘recovery key share holders’. The 14 crypto officers must travel to the ceremony in two groups in order to authorise the generation of new zone signing keys for VeriSign operation using the ICANN master key. ICANN employee Rick Lamb reports that there were 61 applications for these posts, which, in addition to being voluntary, entail significant expense. Key holders must pay their own travel costs and are not compensated for lost working time. Tight budgets at ICANN may be one reason it has chosen to offload these costs.

As a result, only four candidates were forthcoming from Africa and only five from Latin America. Asia managed to put up 10 candidates, European and US businesses and organisations 20 each. Lamb adds that ICANN is now considering whether there should be fewer US officers and more from other countries to make up for the fact that all keys will be generated exclusively at two sites in the US. In the opinion of many RIPE experts, a non-US location is essential.

Daniel Karrenberg, Chief Scientist at RIPE 60 in Prague, asked Lamb if the US administration was blocking changes to the list of candidates, to which Lamb replied, “Block is a strong word.” According to Lamb, a third location is currently under discussion. For example, Sweden, which has signed its .se zone for many years and operates one of the 13 root servers, would be a logical source of potential candidates. “Imagine what would happen if US airspace was shut down by something like the recent incident in Iceland or a terror alert,” said Jim Reid, head of the DNS working group at RIPE. Without the correctly signed key material delivered on schedule, things could get pretty gloomy in the DNS.

Source

Internet users face the risk of losing their internet connections on 5 May when the domain name system switches over to a new, more secure protocol.

While the vast majority of users are expected to endure the transition to DNSSEC smoothly, users behind badly designed or poorly configured firewalls, or those subscribing to dodgy ISPs could find themselves effectively disconnected.

DNSSEC adds digital signatures to normal DNS queries, substantially reducing the risk of falling victim to man-in-the-middle attacks such as the Kaminsky exploit, which caused widespread panic in July 2008.

The standard is currently being rolled out cautiously to the internet’s DNS root servers. In May, when all 13 roots are signed, anybody with an incompatible firewall or ISP will know about it, because they won’t be able to find websites or send email.

Why? Here comes the science bit. Normal DNS traffic uses the UDP protocol, which is faster and less resource-hungry than TCP. Normal DNS UDP packets are also quite small, under 512 bytes.

Because of this, some pieces of network gear are configured out of the box to reject any UDP packet over 512 bytes on the basis that it’s probably broken or malicious. Signed DNSSEC packets are quite a lot bigger that 512 bytes, and from 5 May all the DNS root servers will respond with signed DNSSEC answers.

Keith Mitchell, head of engineering at root server operator Internet Systems Consortium, said his biggest fear is for large enterprises with sprawling networks.

“There are a lot of firewalls and other middleware boxes out there that make the assumption that there are only small UDP packets,” he said. “Several times a month we receive reports of problems like this.”

Sometimes these devices will failover to TCP, which drains bandwidth and hardware resources because it uses handshaking to set up connections.

Mitchell said he’s also concerned about ISPs that rewrite DNS answers as they pass across their networks. Some ISPs do this to redirect their customers to cash-making search pages when they’re trying to find a non-existent website. In China, ISPs use the same method to censor websites.

“They’re doing a lot of fiddling along the way and it’s by no means clear to me that the fiddling is aware of DNSSEC,” he said.

The solution to the problem is Extension Mechanisms for DNS, EDNS0, a decade-old IETF standard that is not yet universally implemented. Mitchell said ISPs and enterprises need to ensure that their gear can handle EDNS0 to avoid problems with the transition.

You can test whether your current DNS resolver is capable of handling DNSSEC, by following the instructions at DNS-OARC or running a Java app that can be downloaded from RIPE.

Home users using residential hubs should not panic if these tests return scary results. According to Mitchell, it currently only matters that the ISP supports DNSSEC. A dodgy Netgear box is not enough to kill your internet… cross fingers.

Source

I’d like to call your attention to a new feature that we rolled out earlier this month. You can now provide us with a configurable Reverse DNS record for any of your Elastic IP addresses. Once you’ve supplied us with the record, reverse DNS lookups (from IP address to domain name) will work as expected: the Elastic IP address in question will resolve to the domain that you specified in the record.

If you are using an EC2 instance to send email, you’ll appreciate this one. Some other types of applications and protocols (FTP and Secure FTP come to mind), can also benefit from it, but most of our customers have asked for it after they tried to send email from Amazon EC2.

You can provide us with your Reverse DNS records using this form. We’ll set up the mappings as quickly as possible and we’ll send you an email once everything is all set up.

We count on our customers to provide us with the feedback needed to assign the proper priority to this and to other features. We’re always happy to hear from you; send your feature requests to awseditor@amazon.com and I’ll make sure that they are routed directly to the proper team.

– Jeff;

Source

A China-based root DNS server associated with networking problems in Chile and the U.S. has been disconnected from the Internet.

The action by the server’s operator, Netnod, appears to have resolved a problem that was causing some Internet sites to be inadvertently censored by a system set up in the People’s Republic of China.

On Wednesday, operators at NIC Chile noticed that several ISPs (Internet service providers) were providing faulty DNS information, apparently derived from China. China uses the DNS system to enforce Internet censorship on its so-called Great Firewall of China, and the ISPs were using this incorrect DNS information.

That meant that users of the network trying to visit Facebook, Twitter and YouTube were directed to Chinese computers instead.

In Chile, ISPs VTR, Telmex and several others — all of them customers of upstream provider Global Crossing — were affected, NIC Chile said in a statement on Friday. The problem, first publicly reported on Wednesday, appears to have persisted for a few days before it was made public, the statement says.

A NIC Chile server in California was also hit with the problem, NIC Chile said. While it’s not clear how this server was getting the bad DNS information, it came via either Network Solutions or Equinix, according to NIC Chile.

Network Solutions wasn’t to blame as it does not offer backbone provider services to NIC Chile, said Rick Wilhelm, the company’s vice president of engineering. Equinix and Global Crossing could not immediately be reached for comment.

Netnod, which maintains a copy of its root DNS server in China, has now “withdrawn route announcements” made by the server, according to company CEO Kurt Lindqvist. This effectively disconnects the server from the Internet. In an e-mail interview, Lindqvist said he could not recall when his company took this action.

Netnod insists that its server did not contain the bad data that redirected Internet traffic, and security experts agree, saying that its data was probably being altered by the Chinese government somewhere on China’s network, in order to enforce the country’s Great Firewall.

Source

Internet infrastructure and services company OpenDNS has reached a major landmark by snagging one percent of all Internet users worldwide, according to analytics firm Quantcast.

While it doesn’t sound like very much, that adds up to 18 million global users, and given that most organisations get their DNS services from their ISPs, OpenDNS is the largest single provider of DNS services. Furthermore, its use has doubled in the past year, despite the emergence of a powerful new competitor after Google launched its own DNS service last December.

According to Allison Rhodes, OpenDNS’s director of marketing, the growth in customers has been “stealthy and consistent” around the world, ever since the company’s 2006 launch. The company’s progress was not knocked off course by the Google announcement, quite the reverse in fact. “The launch of Google DNS absolutely raised awareness about DNS in general. We saw a surge in growth immediately following Google’s announcement. We saw Google’s introduction of its DNS service as a very positive thing for OpenDNS,” she said.

OpenDNS is used particularly by organisations looking for additional security and better web content filtering. It numbers 25,000 schools among its customers. The recently expressed concerns about social media sites, has helped drive up those numbers. “OpenDNS is the easiest way for parents to create a controlled, safer Internet experience in their household. We have a high adoption in the UK among parents looking to keep kids safe online and we attribute it to that reason,” said Rhodes.

The company is looking forward to further strong growth in the coming year, despite the continuing lack of awareness about the need to change DNS providers. Rhodes remains optimistic however. “We have no reason to believe our growth won’t continue to climb at the current rate, or even faster. Our user count has more than doubled in the past year and as awareness spreads about the value of safer, more reliable DNS service, we fully expect that growth to move toward 2 percent of the world’s Internet users,” she claimed.

Source

The leading domain name registrars in the United States appear to be dragging their feet on the deployment of DNS Security Extensions, an emerging standard that prevents an insidious type of hacking attack where network traffic is redirected from a legitimate Web site to a fake one without the Web site operator or user knowing.

DNSSEC prevents cache poisoning attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption. Cache poisoning attacks are possible because of a serious flaw in the DNS that was disclosed by security researcher Dan Kaminsky in 2008.

In order for Web site operators and end users to benefit from DNSSEC, the standard must be supported at every level of the DNS heirarchy.

At the top of this heirarchy, the DNS root servers will support DNSSEC on July 1.

Next are the registries that operate the back-end servers for the various top-level domains. The registries have announced rolling deadlines for their DNSSEC deployments: .org and .edu in June; .net in December; and .com by March 2011.
However, none of the top 10 domain name registrars in the United States has committed to a deadline for deploying DNSSEC.

“It’s sad that the registrars are not keeping up with the registries in their deployment schedules for DNSSEC,” says Paul Hoffman, director of the VPN Consortium and an active participant in DNSSEC standards development at the Internet Engineering Task Force. “If my registrar can’t tell me when they will support DNSSEC, then I can’t do the planning I need to do to upgrade my DNS software.”

U.S. corporations — such as banks and e-retailers — won’t be able to deploy the extra layer of security provided by DNSSEC until their registrars offer it as a service.

“It is a roadblock,” Hoffman says. “If my registrar doesn’t know how do to DNSSEC, I have to change registrars…Whichever registrar announces first is going to see people switching to them.”

Of the 10 largest domain name registrars in the United States, only four responded to queries about the status of their DNSSEC deployments. None of these registrars would commit to a deadline for when they will support this new security mechanism.

Network Solutions and Dotster appear to be furthest along with DNSSEC.

“We are supportive of the DNSSEC initiative and recognize its technical importance and its efficiency in securing directory data,” sais Network Solutions spokeswoman Susan Wade. “We are working closely with the registries and are actively engaged in market research to determine the demand for DNS Security. At the present time, we do not have a launch date for our DNSSEC offering.”

“Dotster is working with a number of registries to implement DNSSEC,” said Dotster’s IT Director Aaron Bathum. “This is on our product road map, and availability is currently under review.”

Go Daddy, the largest domain name registrar in the United States, was vague about its DNSSEC plans.

Source

Hacker Ron Bowes has released various payloads that connect a shell’s standard input and output with a suitable online counterpart through DNS. This allows attackers to bypass many firewalls and even attack systems that have no internet connection themselves.

For a DNS tunnel, the host computer only needs to be able to resolve external host names such as www.h-online.com. It can then handle its network traffic via sent DNS queries and responses. This concept was already demonstrated by Julien Oster and Florian Heinz via the Name Server Transfer protocol (NSTX), which tunnels entire IP connections via DNS.

DNS tunneling requires a suitable server software to run on the DNS server responsible for a domain such as mytunnel.com. The host then simply sends DNS lookup queries such as -

d2Vpc2VuaGVpbWVy.mytunnel.com

The host name contains the packet data in a suitably encoded format. The request is sent to the local DNS server which will eventually pass it to the responsible name server; in the example this could be dns.mytunnel.com. The DNS server can then decode the hostname and respond. The server can add to its response using, for example, the TXT resource record field, which, together with the IP address, will be returned to the computer which made the request. While NSTX tunnels an entire PPP connection this way, DNScat, like netcat, only transports a raw data channel through the net.

Ron Bowes has combined this with a command line shell for Linux and Windows, packaging the shell code in such a way that it can conveniently be integrated into exploits. He has even created a metasploit payload. However, the code has not been tested for functionality by The H’s associates at heise Security; if anyone can confirm that it is functional, they would welcome a message to red@heisec.de

Source

Comcast unveiled on Tuesday an aggressive plan to deploy new DNS security mechanisms that are designed to protect Web site operators and consumers from a specific type of hacking attack that involves hijacking Web traffic and redirecting it to bogus sites.

In a blog post, Comcast said it has deployed DNS Security Extensions — dubbed DNSSEC — throughout its nationwide network and will immediately make validating servers available to any of its customers that want to experiment with this emerging security technique.

In addition to this public trial of DNSSEC validation services, Comcast says it will digitally sign all of its own domain names — more than 5,000 in total — using DNSSEC by the first quarter of 2011.

By the end of 2011, Comcast says it will have production-quality DNSSEC resolution services available to all of its business and residential customers.

“There is often talk about a chicken-and-egg sort of problem with DNSSEC. People don’t want to sign their own domains with DNSSEC until people are validating signatures,” says Jason Livingood, Executive Director of Internet Systems Engineering at Comcast. “We want to explain how we as an ISP have a road map for validating signatures with DNSSEC.”

DNSSEC is an Internet standard that prevents spoofing attacks by allowing Web sites to authenticate their domain names and corresponding IP addresses using digital signatures and public-key encryption. When DNSSEC is fully deployed, Internet users will be able to verify that the Web sites they visit are digitally signed.

Comcast is believed to be the first U.S. carrier to announce plans to support resolution of DNSSEC queries for its customers as well as to sign its own domain names using DNSSEC.

“There are no large U.S. ISPs that have been publicly resolving and signing using DNSSEC in a large trial. But there are lots of people doing small little tests of DNSSEC,” says Paul Hoffman, Director of the VPN Consortium and an active participant in DNSSEC standards development work by the Internet Engineering Task Force.

Hoffman says until now no U.S. carrier has committed to DNSSEC resolution, which could be a stumbling block to DNSSEC deployment.

“Many people have been worried that there would be a lot of people signing their domain names, and no one checking for the resolution,” Hoffman says. “A major ISP doing both halves of the equation with DNSSEC is a big deal.”

DNSSEC is a hierarchical system, and it requires authentication at every step in the process of matching a domain name with the corresponding IP address. In order for a user to receive an authenticated response from a popular Web site such as www.amazon.com, DNSSEC needs to be deployed on the Internet’s root servers, the .com domain servers operated by VeriSign, and the DNS servers operated by Amazon or its Web-hosting company. Consumers who visit Amazon’s Web site also need their ISPs to validate the digital signature they receive.

DNSSEC is in the process of being deployed across the Internet’s infrastructure. The DNS root servers will be signed in July, and VeriSign has committed to supporting DNSSEC on the .com and .net servers by early 2011. The U.S. federal government is deploying DNSSEC across the .gov domain, and the Public Interest Registry is supporting DNSSEC in .org.

Once the DNS root servers as well as popular top-level domains such as .com and .net are signed, DNSSEC is expected to be widely adopted by Web site operators such as Amazon.

Until now, U.S. ISPs have been slow to commit to DNSSEC. That’s why Comcast’s DNSSEC announcement is significant.

“The intention of the trial is to see what things [happen] operationally with DNSSEC and to get ready to do this for the entire customer base once the root is signed and once the major top-level domains are signed,” Livingood says.

Comcast said its public trial of DNSSEC includes immediate availability of DNSSEC validating servers using an Internet addressing and routing scheme known as Anycast.

Comcast has 12 sites across its network that process and cache DNS queries, and all 12 of these locations will handle DNSSEC resolution during the public trial.

“Our subscribers should be able to expect the same level of service for our DNSSEC servers as with our regular DNS servers,” Livingood says. He added that “the critical difference with this trial is that DNSSEC will be on the servers that are very close to the customers just as the nomral DNS servers are so they won’t see a performance hit when they are using these on a trial basis.”

Until the DNS root servers are signed, Comcast will use what’s called a trust anchor repository to validate DNSSEC queries at the top of the DNS tree. Comcast is using IANA’s trust anchor repository for its public DNSSEC trial.

Comcast is promising an easy transition to production-level DNSSEC resolution services for its customers.

“When we turn on DNSSEC for all of our customers nationally in 2011, it will happen automatically,” Livingood says. “We will have tested it, and it will be seamless. People will not have to change their IP addresses. It will all occur behind the scenes.”

Comcast also revealed its roadmap for signing its own domain names by March 2011. Comcast already has end-to-end DNSSEC validation on several domains including www.comcast.org, www.mycomcast.org and www.comcastbusiness.org .

“We have 5,000 top-level domains that we manage like Comcast.net that we’re talking about signing,” says Chris Griffiths, manager for high-speed Internet engineering at Comcast.

Comcast is using Nominum’s authoritative DNS software for its DNSSEC trial and deployment.

“Comcast is one of Nominum’s largest DNS customers and has long been a model for the industry on how to do DNS right,” Nominum said in a statement. “Their plan to deploy our DNSSEC solution to combat cache poisoning and help mitigate other online threats is a significant milestone in the evolution of DNS technology and will help make the Internet a safer place for everyone.”

Comcast said that the cost of deploying DNSSEC for both resolving queries and signing its domains is minimal.

“It’s not a huge investment,” Livingood says. “We upgraded the hardware on the servers in the past six months to be able to handle the computational load for signing this number of domains. But it hasn’t required a substantial investment, although we have been working closely with our vendors to make sure the tools were easy to use and that it was not an onerous process.”

Comcast has been experimenting with DNSSEC since 2008, when a high-profile flaw in the DNS — commonly known as the Kaminsky Bug — was revealed. DNSSEC is the only long-term fix for preventing Kaminsky-style attacks.

“Back then, we started working on all the operational issues of how difficult it is to sign zones, how difficult it is to do key roll-over and what are the challenges related to validating domains,” Livingood says. “We sent a lot of feedback to the vendors we use…We think we’re at the stage where a lot of this stuffy is ready to use.”

Comcast is hoping that its public trial of DNSSEC resolution services and its commitment to signing its own domains will prompt other carriers to follow suit.

“What we’re really trying to do is announce our own plans so that we can be a catalyst for others to take action and get serious about DNSSEC,” Livingood says. “We’re trying to move the Internet community ahead on DNSSEC.”

Comcast’s residental and business customers can learn more about its DNSSEC trial by visiting www.dnssec.comcast.net.

Source