Ok to let all ICMP traffic through firewall?

But a decent firewall will be stateful - so eg outbound ping will enable the reply to be received. No-one 'out there' has any business pinging me so they don't get to do it.

I am well aware it's against the rules, but I block all unsolicited inbound icmp - never noticed any problems. I'm afraid the rfc's were drawn up in a less dangerous internet age :-(

Agreed. A real pain for some smtp servers in particular. My firewall just sends a reset.

So, you're saying that it doesn't break any functionality that we use to block it, so we should allow it because the designers of it are almost positive that there is no exploit for it, but, since it's not going to hurt anything that even though I don't need it, I should allow it, even though I don't need it......

If I don't need it I don't allow it - it's a very simple matter of security - never expose anything that you don't need to expose.

Be sure to deny Echo Request that is sent to the broadcast address for your subnet (.255 and .0 for /24 subnets). If a malicious person sends several hundred of those per second, you'll wind up with a lot of ICMP traffic on your subnet as each host tries to send back the reply.

that is indeed a logical reason to block ping. One wouldn't expect An error in the ICMP protocol. But, ping of death, is probably an error in the software handling ICMP, rather than the ICMP protocol itself.

and - as you said - if you did want ICMP responses, you could rsetrict ICMP responses to hosts of your choosing.

but what if an ISP or non ISP telephone computer tech is diagnosing a non technical home user. The user doesn't have the ability to block ICMP on only certain hosts. The homse user isn't running any services either(may be behind a NAT device). Ping is ideal in this instance. what other option is there to see that he is online,. as a first step in diagnosing the problem?

It does not need to let _all_ ICMP traffic through. But it would be a good idea not to deny every ICMP traffic.

It is a good idea to allow at least ICMP messages of the types 0, 3, 4, 8, 11, 12, see RFC 792.

F'up2 comp.security.firewalls.

Yours, VB.

Mike Scott wrote: [...]

That's your local policy, but not mine. I allow some remote sites to ping me as part of mutual reachability testing.

You block Destination Unreachable as well?

Oh yes, it has. Please read RFC 792, or just read

F'up2 comp.security.firewalls

Yours, VB.

Thank you. Finally a straight answer.

Leythos sez:

Your 100 networks are not, strictly speaking, a part of the Internet since they don't comply with the Internet standards.

HTH, HANL Dima

Sounds like you're allowing them proper access. Fine by me :-)

I believe (may be wrong though) that ipf is pretty clever about what it lets through or not. Dest ureachable must match existing outbound packets before it's useful, and I believe ipf will let appropriate (ie implicitly "solicited") ones through. No doubt someone will correct me if I'm wrong!

The there are many users/companies that are not part of the Internet as many companies block many of the services provided for in the RFC's. Blocking Ping is very common, as is blocking inbound 135~139, 445, FTP, etc...

The net is more than your narrow definition, there is a Use side, a Provide side, and a shared side.

While you may think we're not part of the internet, we are part of a Narrow segment that provides ICMP only between our partners and block the rest.

As a matter of fact, we offer web services at many locations, but we have block lists that block most IP's outside our country, does that means we're not part of the Internet, NO, it means we believe in security.

No where in the RFC's does is say that it's mandated that I must offer services in order to use the Internet networks.

Sorry, that's not a good reason. The ISP can see if the modem is on- line, and the ISP can see if there is a connection between the modem and the NAT device or PC at the hardware level. You don't have to allow ping for any testing/reason, there are always ways around it.

Leythos sez:

....

Which part of "standard" do you not understand? Here's hint: it does not mean "flag" in this context.

Dima

I'm curious .... how does the ISP know?

In that vein, I noticed Sygate alerting on the kernel (I think it was) calling out. Using the traffic log I found that the attempts were to my ISP. Blocking the attempts has no effect on my internet activity, as near as I can tell. I wonder what the purpose of this attempted outbound might be. I don't use any software supplied by my ISP, so it's not spyware (which some ISPs do use).

Art

As with most ISP provided devices, you get a Cable or DSP modem when you get service from them - or a router if a T1, but not many home users have T1's.

The modem device has ports, it's easy to see if the port is active once you connect to the device using the ISP's passwords and such. The ISP can tell if you have a device (or more if your device has multiple ports), how many bytes you've sent, how many you've received, when the device was last power-cycled, and other status indicators (signal levels).

While ping is a simple test, it does not clearly indicate the presence of any device on the other end.

I completely understand the standards, and I understand the idea of networking, the idea of security, and that most of the RFC's didn't for see many of the uses of the internet that we have today.

So, you've failed to show why I must allow ANY form of ICPM, other than you whining about the RFC's - my network designs do not require any public exposure of ICPM, don't break anything that our partners or our network needs, and provide one less exposure (actually many less, ICMP is just one example)....

So, show me where our decision to not allow ICMP hurts our ability to provide the services we do, impacts our ability to use Internet services, or our ability to share information with our business partners, or stuff it.

Here is the RFC's introduction to the ICMP - and it even includes statements that indicate that it's not foolproof, some datagrams may still be lost, and that other protocols may not use it, that communications can be unreliable.....

The internet protocol does not provide a reliable communication facility. There are no acknowledgments either end-to-end or hop-by-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is no flow control.

Errors detected may be reported via the Internet Control Message Protocol (ICMP) [3] which is implemented in the internet protocol module.

From another section:

The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required.

Which ones incoming and which ones outgoing? Thanks, Casey

You are confusing two different layers. Blocking ICMP is one thing, but not supporting an application protocol is quite another. It worries me that you don't appear to understand the difference.

ICMP isn't a service, but part of the underlying protocol stack; a fact which you ignore because you apparently don't know any better.