On Sat, May 27, 2000 at 01:57 +0200, Roman Drahtmueller wrote:
Gerhard,
And to make it security relevant, again (that's what we're here for after all): ping can act as a tunnel transporting data from and to the outside *if* you have a relay station inside your LAN. That's why admins sometimes decide to block pings and traceroutes and no user should feel any real loss about it.
This is right, but it's also a good advice _not_ to filter ICMP packets coming through the firewall into the internal network or at least to the hosts that can take advantage of ICMPs (notably mailservers or such). Without these control messages long timeouts or inefficient bandwidth usage is the result.
That's why I wrote something along the lines of "decide to block pings and traceroutes" since I remember the discussions bubbling up time after time on blocking ICMP completely either breaks whole TCP stacks or important functionality thereof. The most popular feature suffering from missing ICMP seems to be MTU discovery, other problems include the timeouts you talk about. But looking at all the ICMP packet types one should at least block the redirect ones. And besides "dest unreach", "param prob", "source quench" and "time exceeded" everything else seems luxurious to pass through. The "unreach" could be filtered even more for its subtypes. And *if* you have to enable echo reqs and replies, you better block icmp to the network and broadcast addresses (remember smurf, tfn and the other DoSes?). To further protect against attacks, one would wish for a feature like FreeBSD's icmp bandwidth limiting -- is there something similar for Linux? virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.