From owner-freebsd-questions@FreeBSD.ORG Fri Dec 2 16:36:02 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35CD3106566C for ; Fri, 2 Dec 2011 16:36:02 +0000 (UTC) (envelope-from tundra@tundraware.com) Received: from ozzie.tundraware.com (ozzie.tundraware.com [75.145.138.73]) by mx1.freebsd.org (Postfix) with ESMTP id D20068FC18 for ; Fri, 2 Dec 2011 16:36:01 +0000 (UTC) Received: from [192.168.2.180] ([12.106.254.160]) (authenticated bits=0) by ozzie.tundraware.com (8.14.5/8.14.5) with ESMTP id pB2GZocb035764 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 10:35:50 -0600 (CST) (envelope-from tundra@tundraware.com) Message-ID: <4ED8FE61.100@tundraware.com> Date: Fri, 02 Dec 2011 10:35:45 -0600 From: Tim Daneliuk Organization: TundraWare Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: Jon Radel References: <4ED80CD0.8070709@tundraware.com> <4ED811AC.4040901@radel.com> In-Reply-To: <4ED811AC.4040901@radel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ozzie.tundraware.com [75.145.138.73]); Fri, 02 Dec 2011 10:35:50 -0600 (CST) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: pB2GZocb035764 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No Cc: FreeBSD Mailing List Subject: Re: ipfw And ping X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tundra@tundraware.com List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 16:36:02 -0000 On 12/01/2011 05:45 PM, Jon Radel wrote: > > On 12/1/11 6:25 PM, Tim Daneliuk wrote: >> >> I have a fairly restrictive ipfw setup on a FBSD 8.2-STABLE machine. >> Pings were not getting through so I added this near the top >> of the rule set: >> >> ##### >> # Allow icmp >> ##### >> >> ${FWCMD} add allow icmp from any to any >> >> >> It does work but, two questions: >> >> 1) Is there a better way? > > Consider allowing only the ICMP that does things you want to do. Google something like "icmp types to allow" for some hints and opinions. Just as an example, you can independently control being able to ping others and others being able to ping you. > >> 2) Will this cause harm or otherwise expose the server to some >> vulnerability? > > Well, if you allow all ICMP types, it's possible to make your little packets go places you didn't really want them to go, and similar network breakage. You can also find those who feel strongly that allowing others to ping your machines gives them way too much information about what you have at which IP address. On the other hand, working ping and traceroute can be very handy to figure out what's wrong when the network breaks. But do you open up access on your server?---well not so much, though having said that I'm ready for somebody to remind me of some obscure attack that uses ICMP for more than information gathering. :-) > > --Jon Radel > jon@ratdel.com I have been so advised by a number of people to do just this and I am investigating. I am not horribly concerned about this, though, because the machine in question is a NATing front end for a private, non-routable LAN and the associated nameserver uses split-horizon DNS to make all the internal name-ip associations invisible outside the LAN. So ... I don't really see much threat here. I am throttling ICMP rates via sysctl because - AFAIK - the only overt ICMP attack is to flood a target in hopes of getting Denial Of Services. As with you, I remain open to someone presenting a scenario wherein a particular ICMP protocol could actually cause harm... Thanks for your time. -- ----------------------------------------------------------------------- Tim Daneliuk