April 2012 archive

Digium Releases 3 Asterisk Security Advisories

Asterisk logoThis week Digium released three security advisories allowing remote authenticated sessions to either crash an Asterisk server or escalate user privileges.  The advisories are:

In all cases the solution is to upgrade to the latest releases of Asterisk Open Source (1.6.2.24, 1.8.11.1 or  10.3.1 ) or Asterisk Business Edition (C.3.7.4).

 

Microsoft Security TechCenter: DNSSEC and DNS Amplification Attacks

Security Tech Center LogoWhat are the security risks related to using DNSSEC with regard to “DNS amplification attacks”? In a recent article at Microsoft’s Security Tech Center, Greg Lindsay dives into exactly that question.

First, though, he explains how a DNS amplification attack is a form of a Distributed Denial of Service (DDoS) attack that uses DNS queries combined with source address spoofing to send a large volume of traffic at a target system. He provides some examples of exactly how such an attack could be carried out.

Nicely, we get to see some examples of how DNSSEC will be implemented in the forthcoming Windows 8, both at the command line and in the GUI.  (I will be curious as Windows 8 rolls out to learn more about the “DNSSEC zone signing wizard” apparently available in the DNS Manager.)

He ends with a note that:

Signing a DNS zone and adding DNSSEC records to a DNS response increases the total size of a response, but does not increase the risk for DNS amplification past the existing limit placed on the server for UDP response size. 

Since the TCP conversation cannot be easily spoofed, these additional records do not inherently increase the severity of DNS amplification attacks.

and concludes with useful advice about how to help prevent DNSSEC amplification attacks.

I found it a very useful article regardless of whether you use Microsoft DNS servers or not.  Good to get this kind of information out there so that IT security teams can understand how to address and mitigate potential risks.

 

Want To Make Your Web Content Available over IPv6? Check Out The Excellent RFC 6589

IETF Logo Are you a “content provider,” such as a website operator, seeking to understand how to ensure your content is available over IPv6? Would you like to know what challenges you can expect? What kind of migration strategies you can use?  What you should do for an implementation plan?

If so, the IETF recently published an excellent guide in RFC 6589, “Considerations for Transitioning Content to IPv6 available at:

http://tools.ietf.org/html/rfc6589

The primary author is Jason Livingood of Comcast but many others have contributed to creating an excellent document! It explains both the issues with moving content to IPv6 and offers suggestions for migration plans and implementation tactics. With World IPv6 Launch fast approaching on June 6, 2012, it is excellent to have this document available to help content providers understand what they need to do!

From the introduction to the RFC:

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. The issues explored herein will be of particular interest to major web content sites (sometimes described hereinafter as “high-service-level domains”), which have specific and unique concerns related to maintaining a high-quality user experience for all of their users during their transition to IPv6. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. Some sections of this document also include information about the potential implications of various migration tactics or phased approaches to the transition to IPv6.

You can see from the table of contents the range of topics covered in the document:

1. Introduction
2. Challenges When Transitioning Content to IPv6
3. IPv6 Adoption Implications
4. Potential Migration Tactics
5. Potential Implementation Phases
6. Other Considerations
6.1. Security Considerations
6.2. Privacy Considerations
6.3. Considerations with Poor IPv4 and Good IPv6 Transport

The document is an excellent guide for content providers and anyone seeking to understand how to make their content available over IPv6. We’ve now added RFC 6589 to our list of resources and look forward to learning how it may help many of you get your content ready for IPv6!

Contrasting Mercurial vs Git: Two Opposing Blog Posts

GitvsmercurialWhich should you use for a distributed version control system (DVCS) – git or mercurial? That was the question taken up recently by two opposing blog posts on Atlassian’s blog:

Admittedly this is a bit of a “religious” issue with adherents on either side being extremely passionate about the topic. In my own case, my writing here (as well as my Github account) definitely show that I fall down on the side of git… but I’m also always interested to learning more about the various tools.

The two blog posts are written by passionate advocates for each tool and so naturally have that flavor. Regardless, they make for interesting reading. I don’t see myself switching to Mercurial any time soon… but it’s interesting to see the pros and cons of each. We still don’t have the “perfect” tool… but will we ever?

Given that I started working with version control systems back when RCS was the only option I had… and then CVS was a huge step forward… and then SVN was viewed as excellent… all I can say is that we’ve come a loooonnngg way and it’s greatto see both git and mercurial out there.

P.S. I should note that both of these articles are part of Atlassian’s “DVCS Guide” that has some other useful pieces about why distributed version control systems are worth investigating and using.

RFC 6589 – Transitioning Content to IPv6

Are you a “content provider,” such as a website operator, seeking to understand how to ensure your content is available over IPv6?  If so, the IETF recently published an excellent guide in RFC 6589, “Considerations for Transitioning Content to IPv6.  Written by Comcast’s Jason Livingood the document explains both the issues with moving content to IPv6 and offers suggestions for migration plans and implementation tactics.

From the introduction:

This document describes considerations for the transition of end-user content on the Internet to IPv6. While this is tailored to address end-user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. The issues explored herein will be of particular interest to major web content sites (sometimes described hereinafter as “high-service-level domains”), which have specific and unique concerns related to maintaining a high-quality user experience for all of their users during their transition to IPv6. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. Some sections of this document also include information about the potential implications of various migration tactics or phased approaches to the transition to IPv6.

The table of contents is as follows:

   1. Introduction ....................................................4
   2. Challenges When Transitioning Content to IPv6 ...................4
      2.1. IPv6-Related Impairment ....................................5
      2.2. Operational Maturity Concerns ..............................5
      2.3. Volume-Based Concerns ......................................5
   3. IPv6 Adoption Implications ......................................6
   4. Potential Migration Tactics .....................................6
      4.1. Solving Current End-User IPv6 Impairments ..................7
      4.2. Using IPv6-Specific Names ..................................8
      4.3. Implementing DNS Resolver Whitelisting .....................8
           4.3.1. How DNS Resolver Whitelisting Works ................11
           4.3.2. Similarities to Content Delivery Networks
                  and Global Server Load Balancing ...................15
           4.3.3. Similarities to DNS Load Balancing .................15
           4.3.4. Similarities to Split DNS ..........................15
           4.3.5. Related Considerations .............................16
      4.4. Implementing DNS Blacklisting .............................17
      4.5. Transitioning Directly to Native Dual Stack ...............18
   5. Potential Implementation Phases ................................19
      5.1. No Access to IPv6 Content .................................19
      5.2. Using IPv6-Specific Names .................................19
      5.3. Deploying DNS Resolver Whitelisting Using Manual
           Processes .................................................19
      5.4. Deploying DNS Resolver Whitelisting Using
           Automated Processes .......................................19
      5.5. Turning Off DNS Resolver Whitelisting .....................20
      5.6. Deploying DNS Blacklisting ................................20
      5.7. Fully Dual-Stack Content ..................................20
   6. Other Considerations ...........................................20
      6.1. Security Considerations ...................................20
      6.2. Privacy Considerations ....................................21
      6.3. Considerations with Poor IPv4 and Good IPv6 Transport .....22

The document is an excellent guide for content providers and anyone seeking to understand how to make their content available over IPv6.

Internet Society Launches "Internet Hall of Fame" Celebrating Early Pioneers

InternetHallofFameOne of the very cool announcements coming out of the Internet Society's Global INET event in Geneva this week was the creation of an "Internet Hall of Fame" that recognizes many of the pioneers who started this amazing journey we've been on. The full site is available at:
internethalloffame.org
Wired also had a great writeup:
The Internet Gets a Hall of Fame (Including Al Gore!)
As is noted in the Wired article:
The inductees fall into three categories: Pioneers who were key to the early design of the internet; Innovators who built on the net’s foundations with technical innovations and policy work; and Global Connectors who have helped expand the net’s growth and use around the world.

Both the site and the Wired article are well worth a read. It's an amazing journey we've been on since those early days of the Internet... and it's great to see folks like those listed here getting the recognition they justly deserve!


If you found this post interesting or useful, please consider either:


New Internet-Draft: Security Implications of IPv6 on IPv4 networks

IETF LogoWhat are the security implications of having native IPv6 support on IPv4-only networks? What are the security implications of the automatic enabling of IPv6 transition mechanisms such as tunneling?

In a new Internet-Draft out this week, security researcher Fernando Gont of the UK’s Centre for the Protection of National Infrastructure seeks to explore those very questions:

http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets

As the abstract says:

This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on “IPv4-only” networks, and describes possible mitigations for the aforementioned issues.

and the introduction states in part:

Most general-purpose operating systems implement and enable by default native IPv6 support and a number of transition-co-existence technologies.  In those cases in which such devices are deployed on networks that are assumed to be IPv4-only, the aforementioned technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes.

For example, a Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/co-existence technology is leveraged for that purpose.  Additionally, an IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.  Finally, some transition/co-existence mechanisms (notably Teredo) are designed to traverse Network Address Translators (NATs), which in many deployments provide a minimum level of protection by only allowing those instances of communication that have been initiated from the internal network.  Thus, these mechanisms might cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.  That is, the aforementioned technologies might inadvertently allow incoming IPv6 connections from the Internet to hosts behind the organizational firewall.

In general, the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled traffic.  Among such controls is the enforcement of filtering policies, such that undesirable traffic is blocked.

Fernando Gont goes on to discuss the various threats and the ways to mitigate the threats on the edge of the IPv4-only network.

This is only the initial draft of this document and while it certainly may evolve through the IETF process, it is already a good start for IT security staff seeking to understand how to allow IPv6 on internal networks while preserving network security.  Some of the advice to IT security teams out there on the Internet is just to “disable IPv6″… but the reality is that with World IPv6 Launch in June and the continuing IPv4 address depletion, turning off IPv6 is no longer a smart answer.  Far better to look at documents like this and understand how to secure your infrastructure while enabling IPv6 experimentation and usage.

Kudos to Fernando Gont for putting this document together and we look forward to seeing it develop further. He is seeking comment so if you do have feedback on the document, his contact information is at the end.

IPv6 Training (and Courseware) Available At RIPE NCC

Interested in learning more about IPv6?  In Europe, RIPE NCC, the Regional Internet Registry (RIR) for the region offers an IPv6 training course for staff of Local Internet Registries – and perhaps more relevantly, they make their course materials and exercises available to all for free.

You can see the outline for the RIPE NCC IPv6 training class at:

https://www.ripe.net/lir-services/training/courses/ipv6

If you are a member of the RIPE NCC, you can attend any of their upcoming courses listed here:

https://lirportal.ripe.net/training/courses

If you are NOT a member of the RIPE NCC, they very nicely do make their IPv6 training courseware available to all for free at:

https://www.ripe.net/lir-services/training/material/ripe-ncc-training-material/#IPV6

The slides they use are there and are updated periodically.  They also provide a number of exercise worksheets that can be used in training classes as well as a very handy IPv6 Subnetting Card and a very useful guide on “Preparing an IPv6 Addressing Plan.

Additionally, RIPE NCC provides an e-learning page with a few video case studies relating to IPv6 as well as a list of other IPv6-related resources.

Photo: Still Time To Meet The Deploy360 Team at Global INET

Deploy360 Team at Global INETIf you are at the Internet Society’s Global INET event happening in Geneva right now, you still have a chance to meet Richard Jimmerson and Megan Kruse from the team behind the Deploy360 Programme.  Here’s a photo of them (looking sharp!) by the banner for our program.

Megan and Richard have been having great conversations with people about IPv6 and DNSSEC and are still very interested in talking to more folks.  If you are there at Global INET, please do say hello to them!

Also, IF YOU ARE A GLOBAL INET ATTENDEE, please check out the IPv6-only network available at the event. If you connect to the network and go to ipv6.internetsociety.org you will be able to register for a raffle we’ll be doing after the Global INET is over.  The site is ONLY available over IPv6, so you’ll need to get on the IPv6-only network.  Information about how to connect is available at the Internet Society booth there at Global INET.

The Global INET event has been great so far and Megan and Richard are looking forward to continuing more discussions about how to deploy IPv6 and DNSSEC. If you haven’t met with them yet, please do seek them out!

P.S. Please note that the raffle on the ipv6.internetsociety.org site is only for Global INET attendees, but anyone else is welcome to connect to that site over IPv6 and see the links to resources.

When Will We Hit 100 DNSSEC-Signed TLDs?

In looking at ICANN’s TLD DNSSEC Report for today, I noticed that the number of top-level domains (TLDs) signed with DNSSEC is creeping very close to 100:

  • 313 TLDs in the root zone in total
  • 94 TLDs are signed;
  • 86 TLDs have trust anchors published as DS records in the root zone

Who will be the next 6 TLDs to be signed?

That will put us that much closer to one-third (104) signed… and then of course the next step is getting all the DS records in the root zone.

Excellent to see the growth in signed TLDs.  Looking forward to seeing the percentage growing even higher!