On 10/08/2015 04:05 PM, Peter Lebbing wrote: ... > > That's a major part of the problem: the people who block all ICMP packets are > usually not the ones affected by the issue. They never notice, and it's other > people who get the issues when connecting to them. > > Just blocking echo-request (or reply) is just a hindrance when debugging > connections, but not a connectivity issue, so you can safely do it if you > want to. > ...
I decided to take a look at it since we were on the subject and I didn't specify anything for ICMPv4. The default chain policy is DROP and I didn't add any rules to allow ICMPv4, which explains why it does not respond to ICMPv4 echo requests. Whereas in the ip6tables chains, I specifically allowed ipv6-icmp, since (from what I understand) disallowing ipv6-icmp causes a lot of issues as well. Since I only want to disallow ICMPv4 echo requests (or replies), I'll adjust the configuration accordingly. Thanks for bringing it up. :) Mainly, I'm trying to avoid port scanners who ping first before proceeding with the scan, since the IP is part of a known range of a VPS service provider (I get a lot of port scans and service breach attempts). The loss of the ability to use the PING command is trivial since there are multiple other ways for me to determine its network status. Even when they do proceed with the scan, psad[1] is pretty good at picking it up and automatically adding a drop rule to the chain for the offending IP, as long as you have a LOG rule before the packet is dropped of course. [1]http://cipherdyne.org/psad/ -- Antony Prince Key ID: 0xAF3D4087301B1B19 Fingerprint: 591F F17F 7A4A A8D0 F659 C482 AF3D 4087 301B 1B19 URL: http://keyserver.blazrsoft.com/pks/lookup?op=get&search=0xAF3D4087301B1B19
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
