Block ping from wan side

Is this a good idea to leave the wan side ping open?
I know when I used other firmware I was not able to ping my wan IP from outside.
What is pros and cons?

If I want to block ping which one do I disable, Ping or IGMP?

This question is not specific to OpenWrt, there are tons of resources on the internet about the pros and cons of filtering IGMP in general and PING in particular.

IGMP != ICMP

Ping == ICMP-Echo-Request

2 Likes

Blocking ICMP altogether is a bad idea as you will break things in fun ways and is considered bad pratice. If you're paranoid just apply rate limiting.

3 Likes

It should not break anything...

  • ICMP is not allowed by default anyway (only ICMP-Echo-Request/ a.k.a. Ping is, see the default firewall rule) - hence it's already blocked
  • It should not block valid Related ICMP responses to problems experienced
  • No one suggested blocking it (it already is)

Path MTU Discovery for instance is something you most likely want working (uses ICMP)
In general icmp_types = "{ 0, 3, 4, 8, 11, 12 }" are "good" to allow for IPv4 and ICMP is required for IPv6 for it to work as expected.
https://security.stackexchange.com/questions/22711/is-it-a-bad-idea-for-a-firewall-to-block-icmp and so on

1 Like

I agree; and:

:bulb: This already works on a default OpenWrt config...and again,for IPv6 there is a firewall rule (again, see the default config)...so I'm not sure what you mean. And BTW, since you mentioned it, I did some editing to the IPv6 rule (which is not related to the OP's IPv4 question BTW):

config rule
	option name 'New_Allow-ICMPv6-Forward'
	option src '*'
	option dest '*'
	option proto 'icmp'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'

(And you actually miss why the rule is required for IPv6...it's because there is no NAT :wink:)

I would concur with @dizzy that especially for echo responses rate limiting is a better approach than blocking. Sure this slightly increases the attack surface on the router's wan side, but IMHO it also increases a link's debuggability by a lot.
For example, together with a dynamic DNS provider (like the free duckdns.org) one can use thinkbroadband's nice and free RTT monitoring service (after a free registration).

The results look like this
https://www.thinkbroadband.com/broadband/monitoring/quality/share/2f5724590960e0d5b22c153b756b176bff90de88-28-12-2020

and allow you to assess the connectivity of your home link and the London (UK) based measurement servers. IMHO that is a reason for allowing ICMP responses by the router....

1 Like

Thanks all.
I have kind of got lost here being a network novice, so I'll leave it alone until I understand the logic myself.

1 Like

I'm lost at why one thinks I noted Echo Reply as blocked (I never mentioned Echo Reply, and as you see it's Accepted on the IPv6 rule). [Plus with NAT] If you send an Echo request from a client, the firewall permits the related response. I'm quite confused on what you're saying too.

I can only imagine with my actual suggestion that Echo Request-based tests from WAN only would fail. Here is an example of a test that would not work: https://ipv6-test.com/pingtest/

I did not actually want to say that, instead I wanted to respond to the OP's question.

I am clearly stating that having the router itself respond to ICMP echo requests is IMHO valuable, I had not even entertained the notion that anybody would consider blocking ICMP packets traversing the router at all. IMHO if ICMP packets create a risk, that should be plugged in the end host's networking stack and any blocking in the router should only be applied as a stop gap measure until the root cause is fixed.

Now, this is just my personal opinion, and I am open to be convinced otherwise, by facts and gentle explanation where I am off my rocker :wink:

3 Likes

I think many, myself included, blocks everything, because we dont know better, maybe you can explain why not in laymans terms?
I see your point about debugging/troubleshooting, but other then that, why expose stuff we dont need to?

1 Like

Blocking ICMP traversing over the router (forwards) is a really bad idea. Its not uncommon for services for things like gaming, server connectivity, server selection and such to use ping to determine the best server for a service to run off of. Blocking pings that were not solicited is not a bad idea.

Blocking Pings to the router (aka someone on the internet using ping IP) can be valuable to prevent network scanning. Its well understood that scanning occurs towards every delegated IPv4 address exposed to the internet regularly. This, by itself, is not dangerous. However, an automated script may later come back and attempt to fingerprint the system, discover the software running on the machine and create lists of devices and their software version. These lists can then be used to exploit vulnerable versions of software. This is nothing personal, no one is deciding "I am going to attack so and so." Its all automated, and designed to harvest system information for future exploitation.

It is never a bad thing to have your gateway device act in a "stealth mode." This is where the device does not respond to unsolicited or whitelisted connection attempts (drop). I see no good reason for a typical consumer level device to respond to ping.

TL;DR: Drop unsolicited network connections occurring from outside the router. IPv4 ping being dropped should have no impact for a majority of consumers. Try not to drop connections solicited (an internal client pinging a external service)

@meazz1 If you want to block ping, uncheck ONLY "Allow-Ping" and save. By Default the router will reply by telling the external source "I am not accepting pings". You likely want to set the firewall to drop unsolicited connections by setting "WAN Input" to drop under "Firewall-> General settings-> Zones". DO NOT set "WAN Output" to anything but accept. Doing so will block connections to WAN.


Sure, assuming you do not want to use remote pings to monitor your network or for reverse traceroutes (to localize bottlenecks). Personally, I consider being able to offer services from my home network valuable, and that automatically means accepting unsolicited packets, but I accept that this is a policy decision where both options are valid.

Barely, ISPs typically generate differential responses depending on whether an IP is actually in use or not. So dropping ICMP packets will not really "hide" that IP.

Sure, but a standards compliant network stack would not reveal anything useful in its ICMP responses. IMHO the real issue to fix would be ICMP responses that actually allow fingerprinting of a system. For example many networks disable/block ICMP timestamps, but all these should reveal is the node's current time in UTC. That IMHO is not really a leak, unless the system actually return some other gunk instead... As I said before, as a stopgap measure, fine block ICMP timestamps, but then also go the full way and fix the network stack to actually fix the underlaying bug. :wink:

Except dropping ICMPs packets will not hide that an IP is in use or not...

I however, am often involved in debugging of the networks under my control and use reverse traceroutes (from an AS's looking glas servers to either my router or endhost). I also operate enough of my machines, like phones and laptops in unsecured hostile environments (like airport wifi networks) so accept that my networks security is only as good as its weakest node, and believing my router's firewall can change that significantly does not seem like a good idea in that context.

Only do this if you actually understand the consequences though.

"Should" this is exactly the kind of logic that essentially resulted in firewalls only allowing TCP or UDP packets through, making it exceedingly hard to use/deploy newer protocols over the internet.

1 Like

Thinking that blocking ping will "hide" anything is silly and doesn't make your network more secure in any way. Short version of the above :wink:

3 Likes

Sure, assuming you do not want to use remote pings to monitor your network or for reverse traceroutes (to localize bottlenecks). Personally, I consider being able to offer services from my home network valuable, and that automatically means accepting unsolicited packets, but I accept that this is a policy decision where both options are valid.

I personally don't use ping to monitor my current networks externally. The networks I do monitor use protocol level monitoring. Most consumers don't either. To be fair, it is more likely that if someone installed OpenWRT that they are edging away from the "typical consumer" group. In general, if you use it than allow it, If you don't then its best to reject or drop the packets. Why shouldn't that apply to ICMP as well?

Barely, ISPs typically generate differential responses depending on whether an IP is actually in use or not. So dropping ICMP packets will not really "hide" that IP.

Fair point. My ISP happens to drop any connections to it's consumers without a valid route. This is done specifically to inhibit networking scanning. So in my use case pinging an IP which ignores ping requests and one which is not delegated but are both owned by my ISP are both dropped. This is of course based off your ISP, and anything upstream. In a business environment its unlikely that this will be the case.

As I said before, as a stopgap measure, fine block ICMP timestamps, but then also go the full way and fix the network stack to actually fix the underlaying bug.

I agree. For example, some network admins still block ping for the sole case of blocking "ping of death" even though that shouldn't be an issue anymore. Blocking ICMP by itself is rarely going to increase the security of your network.

Except dropping ICMPs packets will not hide that an IP is in use or not...

Most likely not, that is correct. However, its rare for a scanner to care if the IP is delegate or not, it rather wants to know if a service is listening to the open internet. If you have a site which is only whitelisted for connections from three other sites, then the scanner likely isnt going to care about that target. Scanners look for easy targets.

Only do this if you actually understand the consequences though.

Fair point, I will add to that to my point because I really should have mentioned that. Whenever you block anything you should be aware of what that actually means for your network.

Thinking that blocking ping will "hide" anything is silly and doesn't make your network more secure in any way. Short version of the above :wink:

By itself, not likely. However, when considering the entire edge of your network and your goals, it can. Its one piece of the puzzle.


Really this all comes down to personal preference. If I can, I prefer to have edge devices act as if they don't even exist to unauthorized services. I also operate bare-metal hardware in a data center which spins up instances under virtualization which I specifically want to be seen, which pings to request and advertises its available services on purpose. It depends on use case and preference. My home network, for example, has no external uptime monitoring. I don't want any services being able to initiate connections externally, there is no reason for them to. Established connections and streams function well behind NAT and inside->out permitted firewall setups. I really only have a single service which listens externally and authenticates responses before permitting a response, otherwise its dropped.

1 Like