From owner-freebsd-net@FreeBSD.ORG Fri Jul 9 20:39:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9710E106564A for ; Fri, 9 Jul 2010 20:39:53 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 273378FC08 for ; Fri, 9 Jul 2010 20:39:52 +0000 (UTC) Received: by ewy26 with SMTP id 26so635315ewy.13 for ; Fri, 09 Jul 2010 13:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=sOAu0Yx/Hl1yYn/o/2u3t86UzNNEbEiAtmTRfa1zTIY=; b=i3B7bPVZ1mB29kPbJo0sTZbH6XUsuXqgnxhQorL2rl5ngVWd4FeHfzhuXBTwhRNKpj 0+noSZhqN+fmtczotje7wQejgQ6UTRnCUqY7LliPVjAxUznrdsWJj1EhLuZ0MVLRRLqF YltWM4arPIQwwtuZ7ZBwaI2zCsOT7h4jLvl+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vldcJinnu/yyD5PJu1e7poslCWwrkHIijoGc6lSHsAm7Hw5vT2y3Dh6bP+qYXZApSL EBjgFPZyfELMI/5N3AEma+qO4Sj9df+Py4dIW6+ip8ErvHwge3Dm8BTJt/PXu//LkM5R UixbPfOoW1XIPaQXyD5HCvWmwL8XMuu5n8lqA= Received: by 10.213.17.7 with SMTP id q7mr6842776eba.23.1278706522083; Fri, 09 Jul 2010 13:15:22 -0700 (PDT) Received: from localhost ([212.98.186.134]) by mx.google.com with ESMTPS id v59sm10395498eeh.10.2010.07.09.13.15.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 13:15:21 -0700 (PDT) Date: Fri, 9 Jul 2010 23:15:17 +0300 From: Gleb Kurtsou To: Paul Miseiko Message-ID: <20100709201517.GA3449@tops> References: <201007091810.o69IAAUG042124@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201007091810.o69IAAUG042124@freefall.freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@FreeBSD.org Subject: Re: misc/148463: [arp] ARP cache can be poisoned or polluted with ease. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:39:53 -0000 On (09/07/2010 18:10), Paul Miseiko wrote: > The following reply was made to PR misc/148463; it has been noted by GNATS. > > From: Paul Miseiko > To: "bug-followup@FreeBSD.org" , > "pmiseiko@gmail.com" > Cc: > Subject: Re: misc/148463: [arp] ARP cache can be poisoned or polluted with > ease. > Date: Fri, 9 Jul 2010 10:45:17 -0700 > > --_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > You are right that a static ARP entry would resolve the cache poison issue = > and that the suggested solution might be more complicated then desired to m= > itigate (only) some of the risk associated with the cache poison issue. > > What about the ARP cache pollution issue? The description described two po= > tential issues with how FreeBSD implemented the ARP cache. The first issue= > is that FreeBSD has no risk mitigation for an ARP cache poison attack (oth= > er than the acknowledged static ARP entries). The second issue is that Fre= > eBSD will create ARP cache entries when FreeBSD has not issued an ARP reque= > st. The second issue might overlap with the comment you made here "if I ch= > ange some hardware for example I can force update the ARP entry by connecti= > ng to the box that needs to be updated" but it is a valid security concern = > on an un-trusted network and FreeBSD has no risk mitigation for this issue = > (that I am aware of at this time). It would be helpful to see at the very = > least a configuration option (sysctl) to mitigate the risk associated with = > the ARP cache pollution scenario. In my opinion _mitigating_ such risks/attacks falls under security by obscurity category. It's ARP that is fundamentally broken and has no notion of security what so ever. I don't want to get into discussing ARP specifics, I'm just saying that your proposal won't improve situation in general, that is the question of attacker being more sophisticated to perform attack. Besides static ARP entries there are (were) also ARP firewalls available for FreeBSD. Search for it in freebsd-net@ archives. If you are using 7-STABLE or 8.0-RELEASE you can try l2filter patch, it adds ARP filtering options to ipfw, as far as I remember it also allows specifying list of MAC addresses for a given subnet, which may prove useful on a router. http://github.com/glk/l2filter http://glebkurtsou.blogspot.com/search/label/l2filter Thanks, Gleb.