GRC Shields up site: Ping Reply: RECEIVED (FAILED)
-
Hello I need to know how to block ping requests on my network. When I run the common ports test on the GRC Shields up test website, I get this message below.
Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation.
I have a Netgate pfsense box with an asus router plugged into is for wifi.
Its is to my understanding that Pfsense blocks ping by default but just to be sure I created firewall ICMP block rules for wan, lan, and my VPN interfaces. I also made sure ping is off on my Asus router. But I still get the Ping reply failed message.Can some people please explain to me as simple as possible why I still fail the test and what to do to resolve it? I'm new to this and I've gotten this far just by following many different guides.
-
You're wasting you time blocking pings. They take almost no bandwidth and are very useful for debugging network problems. pfSense by default blocks all from WAN.
Post a screenshot of your WAN rules. Do oyu have any floating rules?
-
-
@KOM said in GRC Shields up site: Ping Reply: RECEIVED (FAILED):
You're wasting you time blocking pings. They take almost no bandwidth and are very useful for debugging network problems. pfSense by default blocks all from WAN.
Post a screenshot of your WAN rules. Do oyu have any floating rules?
ok I posted a screen shot. I understand that they take up not much bandwith but Im more concerned agout an ICMP ping request attack which can expose my device on the network which is what it says on the GRC websites Shields up test.
-
Take that site with a grain of salt. Steve Gibson is known to be somewhat of an alarmist.
Your floating rules are irrelevant since there is an invisible block rule at the bottom of each interface's ruleset. so that traffic you're explicitly blocking would be already blocked. Delete them all.
Your WAN rules show you are rejecting ICMP packets instead of blocking. The difference is a block will just silently drop the traffic. A reject actually sends a RST to the other end, so they know something is listening but not allowing them in. That might be what Shields Up is detecting. Delete that reject rule. The default block will take care of it.
Now try your test again.
-
@KOM I appreciate your help but it still says it failed the ping test
-
OK, last step is to do a packet capture (Diagnostics - Packet Capture) on WAN with protocol ICMP. Start a capture and then go to SU and run the test again. Stop the capture and see what it says or post it here and I'll read it. If you're not replying to his pings then his site of full of shit.
Here is an example I just did:
Notice how my pings weren't returned, and the packet capture show the request but not the reply.
-
https://pastebin.com/C7R9B1w9
-
That's pfSense pinging its gateway. 192.168.11.43 is pinging 192.168.11.1, and its getting a reply. What you're looking for is anything from a public address, not something from your LAN.
Try your test again, but this time put !192.168.11.1 in the Host Address field to filter out the gateway monitoring.
I'm wondering if your modem is in bridge mode. It should be passing your public IP address to pfSense WAN, but yours is private. That is not unusual depending on how your ISP operates.
-
@KOM said in GRC Shields up site: Ping Reply: RECEIVED (FAILED):
!192.168.11.1
first I should tell you I have gateway groups set up for load balancing my vpn
when checking ping on GRC shields up common ports:
-packet capture is blank on wan-this is the packet capture on vpn server1
18:45:46.288679 IP 10.70.1.34 > 172.217.218.188: ICMP host 10.70.1.34 unreachable, length 83-packet capture is blank on vpn server2
-
If your modem is routing instead of bridging, then it's possible that your modem is what's replying to SU.
Your captures don't show any ping reply traffic. That Destination unreachable was to Google for whatever reason.
-
oh hold on, I just captured packets while testing with vpnserver 2 and got this.
https://pastebin.com/z0dCx9eV
do I have to do the !IP with a different ip for vpn server 2 since its a different gateway ip?
also, I dont have access to my modem because its a wireless ISP LTE radio and they never gave me the password. Im afraid to ask them for it since they've been so good to me so far.
-
And no replies. What's what you would expect to see when you're blocking the traffic. They knock on your door but you don't answer. You're fine. If anything is replying to those ping requests from SU, it's not pfSense.
-
I did the !vpnserver1_IP in the packetcapture and got this
https://pastebin.com/0cxdS32E
still no repliesOk. Yeah must just be the modem not in bridge mode is what grc is detecting as you said. So you're also saying hackers cant get any information about devices on my network since the requests never make it to my machine because they are blocked by pfsense? Could they get information about my modem though and attack my modem?
-
Either that or SU is giving a false positive. It can't be the modem or you would not see the requests at all. So nothing is replying, which makes me believe that SU is wrong.
Yes, you're protected by pfSense. As for your modem, there is nothing you can do about that.
-
@KOM said in GRC Shields up site: Ping Reply: RECEIVED (FAILED):
Take that site with a grain of salt. Steve Gibson is known to be somewhat of an alarmist.
I wish the GRCsucks.com site was still around..
-
Ok I understand now. Thank you very much for your help.
-
@KOM said in GRC Shields up site: Ping Reply: RECEIVED (FAILED):
somewhat of an alarmist.
Hehehe understatement of the week :)
The sky is falling is his moto for sure.. Back in the day raw packets were going to be the death of everything, hehehehe
Out of the box pfsense is "stealth" to use his stupid term..
I specifically allow pings on my wan, so I can actually have outside sites check if up ;) And I even reject the traceroute udp ports so I can get valid traceroute to my IP when remote - where it actually answers..
-
http://attrition.org/errata/charlatan/steve_gibson/
Don't get me wrong.. I think the guy is smart. To a point.
-
If you mean smart in selling snake oil to "users" sure ok ;)
