ipfw And ping

Ian Smith smithi at nimnet.asn.au
Sun Dec 4 07:05:01 UTC 2011

In freebsd-questions Digest, Vol 391, Issue 9, Message: 9
On Fri, 02 Dec 2011 10:35:45 -0600 Tim Daneliuk <tundra at 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)
        $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

More information about the freebsd-questions mailing list