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
[email protected]
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
