Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings

Niranjan U <niranjan.u@gmail.com> Sat, 08 March 2014 17:18 UTC

Return-Path: <niranjan.u@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACAB1A02C2 for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 09:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCZLKMyczGHX for <dnsop@ietfa.amsl.com>; Sat, 8 Mar 2014 09:18:51 -0800 (PST)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 93E781A0164 for <dnsop@ietf.org>; Sat, 8 Mar 2014 09:18:50 -0800 (PST)
Received: by mail-we0-f182.google.com with SMTP id p61so6709490wes.27 for <dnsop@ietf.org>; Sat, 08 Mar 2014 09:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vCpu7iFhl05mUtO7HfBe73zmIEgrHO+SO5oeGcrmdCM=; b=Lx6ZlyY3gX5Sd2QDtDnPVwGpO4juiuhYtEzT79EvbR3nm+09HVlFEhVag1JL4BIVJz 12/5bV1OGFyR055LErSS9PILb4vMXwG+Sd2MDfreF2zkaYkRE1jmj01s+un90ptypbAI Mz4PF88VDuhW9y68+JdI+ejd1QtLBfupNRGdl/momrJzvr4Lj9XWktYj0YYDkJlIKuV4 Rrob6LoCsndNfcReGjD2fA37Zfbl2kJ+rK7V4nYby69nbDQNKwpNVRmfd7wiOiKqryTu e4kYiRLkhp1iP3LJRDPDNSf3uxAPbEa9zB4JRuJ3Noxeh7HIAQeJNGwe6+o0OVxa5ocq MpYQ==
MIME-Version: 1.0
X-Received: by 10.195.13.234 with SMTP id fb10mr53255wjd.50.1394299125217; Sat, 08 Mar 2014 09:18:45 -0800 (PST)
Received: by 10.194.18.147 with HTTP; Sat, 8 Mar 2014 09:18:45 -0800 (PST)
Date: Sat, 8 Mar 2014 22:48:45 +0530
Message-ID: <CANz4LKcJA8tyAHpLVFAQ0Sc2dq4UbDJAOy-J=+uzcC=3Dz4E4w@mail.gmail.com>
From: Niranjan U <niranjan.u@gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary=047d7bb03afc11c12904f41b90c5
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/n4rCGJjzEvvmwDG3rS3Nr6ZqtFg
Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Mar 2014 17:18:55 -0000

> ?I don't even see DNSSEC helping much here, either, given that the
attacker could just strip out the DNSSEC
> info (unless, perhaps, the home computers were running full (vs stub)
recursive resolvers that also did DNSSEC-validation).

Recursive resolvers, if run responsibly can help alleviate some of the
problems. For example, one can use IP address-based authorization and the
inbound interface (where queries arrive) to limit recursion to authorized
clients (BCP 140 <http://www.ietf.org/rfc/rfc5358.txt>), apply response
rate limiting (DNS RRL <http://ss.vix.su/~vixie/isc-tn-2012-1.txt>), and
use traffic filters to prevent source IP spoofing (BCP
38)<http://tools.ietf.org/html/bcp38> on
your networks. For mobile clients, BCP 140 recommends that you have clients
connect to your network using a VPN, where they can use your recursive
resolver. BCP 140 also suggests that you might run a local caching
recursive resolver on mobile devices.

N


On 7 March 2014 22:11, <dnsop-request@ietf.org> wrote:

> Send DNSOP mailing list submissions to
>         dnsop@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/dnsop
> or, via email, send a message with subject or body 'help' to
>         dnsop-request@ietf.org
>
> You can reach the person managing the list at
>         dnsop-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of DNSOP digest..."
>
>
> Today's Topics:
>
>    1. Re:  DNS privacy and Team Cymru's report on 300, 000 SOHO
>       routers with compromised DNS settings (Paul Wouters)
>    2. Re:  DNS privacy and Team Cymru's report on 300, 000 SOHO
>       routers with compromised DNS settings (Tony Finch)
>    3.  Updating Parent Zones proposal - feedback from registries
>       and registrars (Francisco Arias)
>    4.  CPE devices doing DNSSEC (Mark Andrews)
>    5. Re:  CPE devices doing DNSSEC (Joe Abley)
>    6. Re:  pushing updates to the parent (Tony Finch)
>    7.  Passive DNS COF (Lawrence Conroy)
>    8. Re:  pushing updates to the parent (Joe Abley)
>    9.  I-D Action:
>       draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt
>       (internet-drafts@ietf.org)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 7 Mar 2014 04:00:34 -0500 (EST)
> From: Paul Wouters <paul@cypherpunks.ca>
> To: Dan York <york@isoc.org>
> Cc: "dnsop@ietf.org" <dnsop@ietf.org>
> Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000
>         SOHO routers with compromised DNS settings
> Message-ID: <alpine.LFD.2.10.1403070357140.10354@bofh.nohats.ca>
> Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15
>
> On Thu, 6 Mar 2014, Dan York wrote:
>
> > Now, in this case the attackers compromised the local network devices
> and took over control of the local recursive resolvers. ?In this
> > case of the attacker controlling the recursive resolver, I don't know
> that any of the various solutions thrown around today would do
> > anything to help with this.
>
> Run a local resolver and reconfigure it automatically (eg using
> dnssec-trigger and friends) to use the DHCP obtained DNS servers
> only as forwarders.
>
> > ?I don't even see DNSSEC helping much here, either, given that the
> attacker could just strip out the DNSSEC
> > info (unless, perhaps, the home computers were running full (vs stub)
> recursive resolvers that also did DNSSEC-validation).
>
> If the domains were signed, even if you used the rogue DNS as forwarder,
> you would at least notice you are under attack.
>
> Paul
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 7 Mar 2014 09:20:51 +0000
> From: Tony Finch <dot@dotat.at>
> To: Paul Wouters <paul@cypherpunks.ca>
> Cc: "dnsop@ietf.org" <dnsop@ietf.org>rg>, Dan York <york@isoc.org>
> Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000
>         SOHO routers with compromised DNS settings
> Message-ID:
>         <alpine.LSU.2.00.1403070910170.19416@hermes-1.csi.cam.ac.uk>
> Content-Type: text/plain; charset="utf-8"
>
> Paul Wouters <paul@cypherpunks.ca> wrote:
> > On Thu, 6 Mar 2014, Dan York wrote:
> >
> > >?I don't even see DNSSEC helping much here, either, given that the
> > > attacker could just strip out the DNSSEC info (unless, perhaps, the
> > > home computers were running full (vs stub) recursive resolvers that
> > > also did DNSSEC-validation).
> >
> > If the domains were signed, even if you used the rogue DNS as forwarder,
> > you would at least notice you are under attack.
>
> As I understand it from the CERT Polska report, the aim of the malware is
> to send people to a phishing site instead of to legit banking sites etc.
>
> http://www.cert.pl/news/8019/langswitch_lang/en
> (if you get a redirect try reloading the link)
>
> If properly deployed, with validation on the users' end hosts, DNSSEC
> would absolutely have prevented this attack from successfully stealing
> banking credentials.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Northwest FitzRoy, Sole: Northerly, backing southerly later, 4 or 5,
> increasing 6 or 7, perhaps gale 8 later. Rough or very rough. Rain or
> drizzle.
> Moderate occasionally poor.
>
> ------------------------------
>
> Message: 3
> Date: Fri, 7 Mar 2014 01:47:50 -0800
> From: Francisco Arias <francisco.arias@icann.org>
> To: Tim Wicinski <tjw.ietf@gmail.com>om>, Mark Andrews <marka@isc.org>
> Cc: "dnsop@ietf.org" <dnsop@ietf.org>
> Subject: [DNSOP] Updating Parent Zones proposal - feedback from
>         registries and registrars
> Message-ID: <CF3F4533.53D45%francisco.arias@icann.org>
> Content-Type: text/plain; charset="utf-8"
>
> A option to obtain feedback from gTLD registries and registrars would be
> to use the gtld-tech@icann.org mailing list:
> https://mm.icann.org/mailman/listinfo/gtld-tech
>
> Regards,
>
> --
> Francisco.
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 07 Mar 2014 21:05:24 +1100
> From: Mark Andrews <marka@isc.org>
> To: dnsop@ietf.org
> Subject: [DNSOP] CPE devices doing DNSSEC
> Message-ID: <20140307100524.2F42810CD58F@rock.dv.isc.org>
>
>
>         What do we expect CPE devices to implement to update parent
>         zones.  100 different things to cover all the update methods
>         registrar's come up with.  Or do we say do exactly one
>         method that works in all situations?
>
>         We already have a problem today were they can't do dynamic
>         update to every dynamic dns provider because they implement
>         non standard adhoc methods rather that one standardised
>         method.
>
>         I know Registrars don't like to be told what to do but this
>         is a case where interop from 100's of CPE providers and
>         1000000's of parent zones made up of RRR zones and non RRR zones
>         needs to work reliably without lots of choice.
>
>         Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE:  +61 2 9871 4742                         INTERNET: marka@isc.org
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 7 Mar 2014 10:21:34 +0000
> From: Joe Abley <jabley@hopcount.ca>
> To: Mark Andrews <marka@isc.org>
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] CPE devices doing DNSSEC
> Message-ID: <3E0DC692-7BA0-4672-BB10-82B854BB69CE@hopcount.ca>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 7 Mar 2014, at 10:05, Mark Andrews <marka@isc.org> wrote:
>
> >       What do we expect CPE devices to implement to update parent
> >       zones.  100 different things to cover all the update methods
> >       registrar's come up with.  Or do we say do exactly one
> >       method that works in all situations?
> >
> >       We already have a problem today were they can't do dynamic
> >       update to every dynamic dns provider because they implement
> >       non standard adhoc methods rather that one standardised
> >       method.
>
> https://xkcd.com/927/
>
>
> Joe
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 7 Mar 2014 10:49:50 +0000
> From: Tony Finch <dot@dotat.at>
> To: Joe Abley <jabley@hopcount.ca>
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] pushing updates to the parent
> Message-ID:
>         <alpine.LSU.2.00.1403071025270.19416@hermes-1.csi.cam.ac.uk>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Joe Abley <jabley@hopcount.ca> wrote:
> >
> > https://xkcd.com/927/
>
> So from the standards development point of view, I think what this is
> saying is that success is more likely to come from building on what people
> are already doing and nudging more of them to do it more similarly.
>
> The problem with the parent update process is that there's a hopeless zoo
> of more-or-less crappy APIs almost none of which are good foundations.
>
> For a push-style protocol there are two parts: finding out where to push
> the update; and how to push the update.
>
> The where question ought to be answered by whois or weirds or _update SRV
> records.
>
> The how question ought to be answered by EPP (from registrant to
> registrar) or DNS UPDATE. It would be nice if there were software to
> gateway between one and the other.
>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
> Humber: Southwest 6 to gale 8, becoming variable 4, then southeast 5 later.
> Slight or moderate. Rain, becoming fair. Moderate becoming good.
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 7 Mar 2014 11:23:05 +0000
> From: Lawrence Conroy <lconroy@insensate.co.uk>
> To: dnsop@ietf.org
> Subject: [DNSOP] Passive DNS COF
> Message-ID: <B40AC4BA-0C5D-417C-9FC8-71EBF310F7B6@insensate.co.uk>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Chaps,
>  stupid quick question, listening to the stream:
> How does this work with CDNs (I think you may need to capture the IP
> address; bailiwick could act as a proxy for that, but ...)
> all the best,
>   Lawrence
>
>
>
> ------------------------------
>
> Message: 8
> Date: Fri, 7 Mar 2014 15:39:37 +0000
> From: Joe Abley <jabley@hopcount.ca>
> To: Tony Finch <dot@dotat.at>
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] pushing updates to the parent
> Message-ID: <8C184518-2A56-42B6-BD63-3E50F8126664@hopcount.ca>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 7 Mar 2014, at 10:49, Tony Finch <dot@dotat.at> wrote:
>
> > Joe Abley <jabley@hopcount.ca> wrote:
> >
> >> https://xkcd.com/927/
> >
> > So from the standards development point of view, I think what this is
> > saying is that success is more likely to come from building on what
> people
> > are already doing and nudging more of them to do it more similarly.
>
> Sure, maybe.
>
> I think we have to consider our target audience. Part of that is to
> consider the existing menagerie and understanding the shape of the expected
> solutions space.
>
> While we in this group might find comfort in arcane binary protocols using
> UDP port 53, the habits of people who frequent the dyndns zoo seem to be
> far more tilted towards throwing JSON documents around over HTTP. It's hard
> to imagine unifying a pile of RESTish APIs with something that looks
> foreign and different.
>
> I'll +1 Andrew and say that I have my doubts (a) that the underscore
> scaffolding will ever appear in the top-most labels and (b) that anybody
> would use them if they did.
>
> My poorly-informed doubt is hardly a reason not to document the idea. But
> I think it's a stretch to expect anything more than an XKCD-927 result.
>
>
> Joe
>
>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 07 Mar 2014 08:41:53 -0800
> From: internet-drafts@ietf.org
> To: i-d-announce@ietf.org
> Cc: dnsop@ietf.org
> Subject: [DNSOP] I-D Action:
>         draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt
> Message-ID: <20140307164153.15062.39035.idtracker@ietfa.amsl.com>
> Content-Type: text/plain; charset="utf-8"
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Domain Name System Operations Working
> Group of the IETF.
>
>         Title           : DNSSEC Roadblock Avoidance
>         Authors         : Wes Hardaker
>                           Olafur Gudmundsson
>                           Suresh Krishnaswamy
>         Filename        :
> draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt
>         Pages           : 16
>         Date            : 2014-03-07
>
> Abstract:
>    This document describes problems that a DNSSEC aware resolver/
>    application might run into within a non-compliant infrastructure.  It
>    outline potential detection and mitigation techniques.  The scope of
>    the document is to create a shared approache to detect and overcome
>    network issues that a DNSSEC software/system may face.
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ------------------------------
>
> End of DNSOP Digest, Vol 88, Issue 21
> *************************************
>