Hi,
I was woundering if the Comodo fire wall can be configured to ignore or block Ping (ICMP Echo) requests.
In the NetworkMonitor, set up a rule with the following parameters;
Action : BLOCK (and log if you want)
Direction : IN
Protocol : ICMP
Source IP : ANY
Destination IP : ANY
ICMP Details : ICMP Echo request.
Hope this helps,
Ewen 
What will happen if PING is blocked? Thats the only thing that is stopping the shields up from getting a 100% stealth rating.
If you are behind a router, then Shields Up is actually testing the port status on your router, as it is the first responding device on the IP that is being tested.
Cheers,
Ewen
Thanks for your help Ewen,
I added a Network Monitor rule with the parameters you specified (made it the first rule), but my computer is connected to the internet via DSL. So I guess the Shields Up test (service port test) at Shields UP!! — System Error is testing the service port status of the DSLAM (Digital Subscriber Line Access Multiplexer), or some other device. I?m finally starting to learn a little bit about the internet. For years I naively thought the windows XP firewall provided adequate protection.
P.S. - I really like the Comodo firewall.
Yes… the Internet works in mysterious ways.
(:NRD)
The stated firewall rule for universally blocking ping requests, which I also found for myself, fails. The firewall refuses to accept the rule, responding with a most unhelpful message “invalid parameter” . Since I simply entered the obvious parameters as shown in this FAQ also, I am mystified. It is also very unhelpful that the actual parameter(s) objected to are not stated, as this would clearly assist in diagnosing the error.
I entered, on the Firewall → Advanced → Network security policy → Global rules → Add →
Action…Block
Protocol…ICMP
Direction…In
Source address…Any
Destination Address…Any
ICMP Details…Icmp Echo Request
then “apply” and the result is: “An invalid argument was encountered”…but the argument in question and its value was not stated. MOST UNHELPFULLY, in my opinion. What am I doing wrong ??
Product version 3.0.25.378
serial 597C982825654012B916842669D7DE34
That specific rule already exist in the Network Security Policy, under Global Rules. Might be a conflict that’s causing this, and that the error message is supposed to state this. Have you tried to remove it and re-enter it again?
3.2.2.6 Echo Request/Reply: RFC-792 Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. ... An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.
I wonder if this Shields Up ping madness will ever end… 
There is no such pre-existing rule in the “Global” section, that is why I wished to create one myself. My point about an invalid argument being detected, but the argument in question not being stated explicitly-perhaps with a range of allowable values, wouls I hope be answered by one of the Comodo software designers. Of course this kind of unhelpful error reporting is not particular to Comodo, and I don’t wish to sound ungrateful by pointing it out. If it is noticed then perhaps the fine Comodo product may be further improved.
As to the person who mentioned RFC-792, it is kind of you to point out that optional ICMP echo request response, but surely, if I choose to go further and have my PC remain invisible to unwanted scanners/hackers, that is up to me.
1/ It is NOT optional, note the word MUST.
2/ Kindly note that dropping ICMP packets does not make you invisible to the hackers - in fact it does the exact opposite. 88)
With regards to RFC 792. It was written in Sept 1981, and reflected the must do’s and don’ts of that time. Since that time, the Internet has gone public, and some number of the requirements from the original ARPA days no longer apply. (ARPA had teeth, with funding and access control. Is your ISP going to pull your machine because of ping? No?) Today, it’s your machine, and your policy as to what to abide by or not.
A dropped ICMP is indistinguishable from a disconnected machine, or a non-existent machine. As a LAN admin, I’m quite happy to have somebody hammer an IP address that isn’t assigned to any hardware. They waste their time, and I get a good bit of useful information in my logs.
While I understand what you’re saying about the “host unreach” and “net unreach” ICMP codes, in day-to-day practice those codes almost never occur. And then it’s some firewall doing to work, and not a router.
There’s a real easy test for what happens: run Wireshark, or some other network monitor, and see what is on the wire. If there is no hardware at the IP address in question, then what is there that can send the ICMP packet?
A router? A firewall? That takes some specific configuration to do, which makes it a policy decision per site. Otherwise there’s just the dangling cat-5 connector, and it doesn’t send packets.
This is completely untrue.
The router of course!!!
Yeah, there’s totally easy test. Drop the ICMP packets and ping a box. Note the outcome (Request timed out). Now disconnect the cable, flush the router’s ARP table or restart it (or wait until it happens itself, takes a while) - and then ping that box again. Note the outcome (Destination host unreachable).
A stateful firewall, let alone HIPS has absolutely zero to say about unplugged network cable, it’s entirely different OSI layer.
Yeah, there's totally easy test. Drop the ICMP packets and ping a box. Note the outcome (Request timed out). Now disconnect the cable, flush the router's ARP table or restart it (or wait until it happens itself, takes a while) - and then ping that box again. Note the outcome (Destination host unreachable).
ARP is useful only a LAN. It’s how hardware MAC addresses map into IP addresses. Send a packet over to the Internet thru a router, and the ARP is useless. On the Internet, there are no ARP’s to give the response. The packet times out, and it’s a blank.
On the LAN, the router is keeping track of what packet goes where. You ping out, the ping goes to the router, the router issues an ARP “Who has”. If it gets an answer, or knows the answer already, the packet is forwarded to the hardware that’s present.
If no answer to the ARP, then the router may, or not, depending on its configuration, send back an ICMP “unreachable”. That’s for a LAN host query only.
But cross router boundaries on the Internet, and the answer most likely to get is a timeout. No ICMP at all. That’s the way the routers on the dayjob are set (site security policy), and the way the dayjob upstream routers are set (their site security policy). If network reconnaissance was that easy, it’d be done as a matter of course these days, and we wouldn’t be having this conversation.
OMG; I hope you are not doing any networking-related job, that’d be a genuine disaster. A bit of required reading before we continue this (so far completely absurd) debate:
RFC-1812 - - Requirements for IP Version 4 Routers
4.3.3.1 Destination UnreachableIf a router cannot forward a packet because it has no routes at all
(including no default route) to the destination specified in the
packet, then the router MUST generate a Destination Unreachable, Code
0 (Network Unreachable) ICMP message.…
If a packet is to be forwarded to a host on a network that is
directly connected to the router (i.e., the router is the last-hop
router) and the router has ascertained that there is no path to the
destination host then the router MUST generate a Destination
Unreachable, Code 1 (Host Unreachable) ICMP message.
Unfortunately, yes. I’ve been doing Internet routing as the dayjob for the last dozen years or so.
Yes, standard textbook stuff. While hardware may, or may not, support the ICMP unreachables, the routing policy as to what happens to such ICMP packets is a site decision. To my knowledge, and experience, almost nobody lets such packets out to the Internet.
Another simple test, run a ping scan of your upstream ISP with Wireshark watching the reply traffic. Then run a ping scan of some other IP address space. Expect it to take a while. I’d expect very few, if any, ICMP unreachable reply packets.
Great; hope I won’t be forced you use your network and any services hosted there anytime soon. :o
I’ve run a bunch pings of IP addresses hosted at various places which I know are not assigned to existing machines - and they all reply with standard ICMP Host Unreachable message. Thanks God sanity and standards are still respected in some parts of the world… Those who consider standards to be “textbook stuff” that can be freely ignored because they know better and have “site policies” really deserve to be abandoned by their customers. :-TD
Their site, their policy. If it works for them, great. Such is not the case here, and that, so far, has worked as desired here.
I think we’re at the point now, where we can agree to disagree, and go on to other things that need our respective attention at the moment.