Date: Sun, 4 Dec 2011 18:04:56 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Tim Daneliuk <tundra@tundraware.com> Cc: freebsd-questions@freebsd.org, Jon Radel <jon@radel.com> Subject: Re: ipfw And ping Message-ID: <20111204171900.N3548@sola.nimnet.asn.au> In-Reply-To: <20111203120031.55D471065772@hub.freebsd.org> References: <20111203120031.55D471065772@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 391, Issue 9, Message: 9
On Fri, 02 Dec 2011 10:35:45 -0600 Tim Daneliuk <tundra@tundraware.com> wrote:
> On 12/01/2011 05:45 PM, Jon Radel wrote:
> >
> > On 12/1/11 6:25 PM, Tim Daneliuk wrote:
> >
> >> ${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
> 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...
For one, google 'icmp redirect attack'
#% stock rc.firewall doesn't permit _ANY_ ICMP, even TCP-required!
#% see http://www.iana.org/assignments/icmp-parameters
#% from 19/1/99 freebsd-security (compacted):
# This is the ICMP rule we generally use:
# ipfw add 10 allow icmp from any to any in icmptypes 0,3,4,11,12,14,16,18
# This allows "safe" ICMP's to get in, so that ping, traceroute, etc.
# work, while blocking potentially unsafe ICMP's.
# See /sys/netinet/ip_icmp.h for definitions of the ICMP types.
# -Archie
# Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Since then I've used, on multi-host and NAT'd setups, more or less this:
recv_types='icmptypes 0,3,4,11,12,14,16,18' # reject most pings :(
#% can use keep-state for outbound icmp but then ANY icmptype matches!
#% 26/3/7 still need to generally deny inbound pings except friendlies
# pingok="{ was a list of IP addresses[/masks] allowed to ping }"
#% XXX better using a pre-loaded table (for OOB on the fly additions)
pingok="table\(8\)"
$fwadd pass icmp from any to any in recv ${ext_if} ${recv_types}
$fwadd pass icmp from ${pingok} to any in recv ${ext_if} icmptypes 8
$fwadd deny log icmp from any to any in recv ${ext_if}
$fwadd pass icmp from any to any # outbound, and inside
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111204171900.N3548>