Ok to let all ICMP traffic through firewall?

Please read RFC 792, then you'll understand.

Yours, VB.

Are you telling me they can read your router's ARP table then?

Steve

I guess that you and your company would be quite happy then if your ISP, and other up-line carriers decided not to route any traffic from a network that was not RFC compliant?

Think not ;)

Steve

The passages you refer to are talking about _IP_ and the use of ICMP packets to report errors situations in IP. The words not foolproof etc refer to IP not ICMP.

Mike

Sorry to have confused you with other things I block. You said that I was breaking things by not allowing ICMP, I said that many security types block most things, not just ICMP and also indicated some things I block.

Nothing in the RFC indicates I have to permit ICMP of any type - please show where it's mandated if you want to continue this, oh, and don't quote the RFC since I've already read it, years ago, and it's not mandated that I permit any ICMP inbound to my network.

I already said we allow ICMP with partners and have no problems with VPN's, we do not allow ICMP with the world as a general rule, just with approved partners.

My ISP is in the business that requires they provide it - I don't see how you can't understand that part. We don't offer services to the world and have exceptions for our partners so that ICMP is not blocked to them. Why can't you seem to grasp the simple concept of allowing for business needs and blocking for all others?

Which does not change the fact that I can limit ICMP to my non-partners without impact on our communications.

By bundling the two together, you indicated a lack of understanding of the difference...

"Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP, etc..."

As I said before...do what you like...it'll be your problem, not mine. Oh, and I probably read the RFC long before you, anyway.

Well, you think you can.

I agree that people stealth beause they think it makes them safer. And it's pointless to stealth if they're not going to block ICMP too. If they're trying to make themselves invisible, and they stealth their ports, then blocking ICMP is very relevant. Fruthermore, perhaps blocking ICMP makes more sense in terms of invisibility than stealthing does. (I do not nkow how to check if one of my comps is online remotely without pinging it)

is that what you meant? if so then you misunderstood me

My point is that technically they are totally different concepts. Stealthing breaks TCP protocol. Blocking ICMP breaks ICMP protocol. Differetn layers. Technically they have absolutely nothing to do with each other. I'm sure I can set my firewall to stealth my ports(which most PFWs do automatically), and respond to ICMP.

By the way. how can nmap test if a port is stealthed, whereas people complain saying online scanners cannot say a port is stealthed? If stealth gives no response whatsoever, then surely 'unable to determine' is the best that either an onlien scanner or nmap can give. They can only say "most likely it is stealthed". and that assumes the comp exists, which if they can't ping it either , seems hard to tell

I should have clarified (thought that it was clear from the context.. ah well ;o)

This is monitorin my services from *outside* of the network.

Like most non-ISPs, I don't have a dedicated 24x7 staff to monitor systems (this is a home network, before someone starts slinging companies that *do* have this requirement).

On the Ping front, you'll find that the companies that you're hosting (assuming that's what your part of the network does) are unlikely to appear on many search engines - at least, that *used* to be the case - a "cheap" PING before even attempting an HTTP GET.

Together, those made a pretty compelling case for me to switch ICMP back on - I didn't (and still don't) see it as a major way threat to my firewall (and, after all, that's as far as the packet's going to get, right? Certainly not into the DMZ...)

H1K

I still can't understand why you would want to deliberately break a valuable feature of IP - and do so in a way such that a user will have no idea why their connection to a specific site on the Internet may work in some cases but not in others. It's your choice how you configure your network, of course, but it seems a rather idiotic configuration to me.

I think that it's a bit of a stretch to suggest that someone stating that blocking ping is very common, as is blocking inbound traffic to "135~139,

I like Chinese food as well as the occasional Indian but just because they are mentioned in the same sentence shouldn't lead anyone to the conclusion that I don't understand the difference between the two.

Of course, it is.

Yours, VB.

You may thing that it breaks things for "users on the internet", but since we don't really care about "users" on the internet, since we only care about partners being able to connect with our public facing services, we're not really breaking anything as they (partners) don't have ICMP blocked - so, back to reality, we're not breaking anything for our accepted/targeted audience, we're closing possible security holes that may or may not be a threat.

Now do you understand - it's actually rather simple - the "users" that need to have ICMP responses form our networks get it, ones that don't do not get it.

Like I've said many times before - ICMP is exposed to partner sites/companies, blocked to the rest of the world. If we have no communications need with you then we don't expose anything to you.

Your example of Ping would fall into a business need - so there would be a rule exception allowing PING from your designated monitoring service.

So even if you are ignorant enough to believe that "stealthing" your machine provides some sort of additional security then what do you gain by blocking inbound ICMP messages which don't require a response (i.e. the majority of them) and so provide no information back to the originator?

If a TCP connection cannot be routed to its destination then the response will be an ICMP message, so you cannot say they have "absolutely nothing to do with each other". Stealthing TCP (i.e. not sending an RST) has an impact on the originator, not you (although you may receive retries as a result of not responding) - blocking ICMP generally impacts on you, not the sender - so why would anyone want to impair their system by blocking informative inbound ICMP messages, particulary as such messages don't require a response and so provide no information back to the originator?

If your IPS's upstream router returns an ICMP host unreachable if you are offline then stealthing is completly pointless anyway since "no response" simply means that you are online.

Which goes back to the simple security concept -if you don't have a need to provide the service, then you don't provide it.

In our case, we only provide exposure for services that our clients, business partners, etc... need, we don't allow exposure to the world just because it might not be a current threat - we block ALL except that with a business need.