Ok to let all ICMP traffic through firewall?

Hang on a minute, so now you are saying that you block outgoing ICMP (i.e. responses) ito selected parties - earlier you said you blocked incoming ICMP. So maybe you block both.

Tell me - what is the risk of sending an ICMP packet to anyone? You've said that you block such responses - but why? What is the risk you perceive in sending a messages which (in general) does not require a response and so cannot have any impact on your network? Or are you suggesting that your networks are so insecure that you need to protect them from things that would not even be a threat to the clueless newbie home computer user? I haven't a clue what services you provide, but please let me know - just so I can make sure I never use them.

And no, I don't understand your screwed up interpretation of the risks associated with what is a relatively simple out-of-band signalling protocol.

Actually, it's not that simple (I'll stress again that this is *my* particular need, but not one that is particularly uncommon)

My monitoring service is me, with either my phone or a laptop.

I need to be able to connect from a variety of countries, and a (for my purposes) essentially random series of ISPs and routing networks.

I understand completely that this isn't the same as /your/ need - you are obviously providing a specific service to a very geographically limited set of known users. Although I'd be wary, once one of them attempts DR. 'Tis amazing what comes out of the woodwork when that happens... I've had to do it for real, courtesy of the PIRA.

H1K

In article , Dave Dowson wrote: :Tell me - what is the risk of sending an ICMP packet to anyone? :You've said that you block such responses - but why? What is the risk :you perceive in sending a messages which (in general) does not require :a response and so cannot have any impact on your network? Or are you :suggesting that your networks are so insecure that you need to protect :them from things that would not even be a threat to the clueless :newbie home computer user?

There was an attack publicized within the last few years, in which attackers sent ICMP Network Redirect and Host Redirect (which don't require responses...) specifying IP addresses of major banking sites. Networks whose administrators were not blocking ICMP Redirects had their users redirected to clone sites made to -look- like the banking sites, but which copied the username and passwords entered; the perpetrators then proceeded to steal from peoples' bank accounts and credit cards.

I'm sorry but I don't think you know what you're talking about. As you've previously quoted, without apparently understanding it, ICMP is predominantly a mechanism for reporting an error in IP. If you block it, and don't (or rarely) have an error at the IP level, then your setup will work - beacause there are no errors and ICMP simply isn't involved. If an error should occur then your blocking of ICMP could then prevent you from detecting and diagnosing faults, or allowing your application(s) to handle them.

But it's your setup, and I think we'll just have to agree to differ.

Mike

Are you unable to connect via VPN of some form?

Hopefully I'm not going to stray too far from the subject of ICMPs, but I feel there could be a risk in allowing any IP packet to be sent to anyone. No, it's not a general risk to your network because they couldn't infect a machine on your network. But, they could be a liability risk or just a risk of embarrassment.

For instance, what if a user on your internal network has knowledge of malware that used covert channels to receive it's instructions about what to do? Then, that user used that knowledge to attack someone else's network. Or, a machine on your network is infected with this type of malware and is used in an attack because it received instructions over a covert channel.

That sounds like layered security to me. Why expose one thing just because you think everything behind it is secured?

There are ways to send information or instructions to processes listening on systems that allow any IP packet. It could be in an ICMP or TCP or UDP or ESP or GRE (doesn't matter) payload. But, it doesn't have to be in the payload. It could just be the timing between the packets. It could be a particular sequence of IP IDs. Or, the use of still undefined or experimental IP options.

But on a practical note, when it comes to ICMPs, I tend to block everything except errors that are related to established connections. But, that's just me. Obviously, there are many opinions on this subject.

Mark

It's pointless to "stealth" anyway. nmap -P0 exists.

No.

Because people are complaining wrong things.

Because there will come an ICMP type 3 with code 0 or 1, if there is no host, and there is coming no such packet, there is a host. Because there is no TCP RST and no ICMP type 3 with code 3 coming back, the port is "stealthed".

The ICMP packages are not send by the host itself, but by the router before.

Please read RFC 792.

Yours, VB.

Yes. This is the reason to filter redirects.

Yours, VB.

You just make diagnosis more difficult when things go wrong obviously, since you can't ping. Also some devices that use ping for link monitoring will be unhappy and need to be reconfigured or will have reduced functionality. If you can live with this, and many people can, there is no big cost to you, to block all ping at the firewall.

For example when ISP's block ping, it drives me crazy because when I deploy NetScreens in the field with failover internet connections, they need to use ping to determine if the link is up. So I can't enable failover when the ISP blocks ping. Inevitably somebody re-enables auto failover detection and it immediately fails over to dialup because it thinks the highspeed link is down...

-Russ.

If you understand this simple fact: If I block ICMP to non-partners, then I don't really care if they get ICMP messages, which means I don't care what NON-PARTNERS SEE.

If we allow ICMP with Partners then there is no issue with ICMP, so, we're back to you seeming to miss that we block EVERYTHING TO NON- PARTNERS, but we secure the network according to partner needs.

What parts are you missing about ICMP being permitted for PARTNERS?

But it's never made anything more difficult for our businesses or support methods - we've never counted on PING working in the first place. To many places and firewall setups block even the simple PING (as they should).

Since we don't use PING to monitor the firewalls or the web servers or the email servers, or anything, we are not missing anything. At any time a ISP could block ping and where would you be if you relied on PING as a means to determine alive or not?

So why don't you have PING setup to ping the default gateway on the ISP's side outbound from your firewall? - I've not seen a single isp that doesn't allow their default gateway to ping. Maybe you need to stop using residential networks for business if you're seeing ping being blocked to the gateway.

We were talking bout outgoing ICMP messages, not incoming ones, but never mind.

As far as ICMP redirects are concerned they provide a facility to inform a network node of the 'best' local gateway, i.e. which next hop router to use for a particular desinstation. If you sent a spoofed ICMP redirect to a workstation on my local network then (a) it would have to appear to come from the default gateway (easy to spoof if you know the internal network configuration, although maybe a little difficult to inject if ingress filtering is employed on external interfaces), (b) it would need to contain the first 8 bytes of the outgoing IP message it related to (not quite so easy to spoof unless you can monitor the traffic on my local network), and (c) it could only specify an IP address of a different node on the same LAN segment for the 'new' next hop router for that destination.

So god only knows how the compromise you mentioned above worked, but I can only assume that either the 'attack' was internal (i.e. the bogus servers were on the same LAN as the victims) or that the network was already compromised and that the ICMP redirects were of little significance to the true nature of the attack.

Speaking of pinging:

Art

Pretty often the protocols themselves are solid (protocols as in protocol definitions), but implementations are faulty - just as in the case of ping-of-death.

The same goes for various ftp implementations, some ssh implementations, some web server implementations, ... . Now, it's rather easy to disable an unneeded ftp server (as to why it was enabled anyway - f.ex. that was the vendor default, and the person doing the system installation didn't think enough to disable it). But how do you disable ICMP handling? You turn off the machine, more or less.

This is why you only let in those ICMP packets that affect your own communications. F.ex., inbound ICMP echo-requests are prohibited (unless you're facing a site that does an echo-request every time you connect to it); allowed are only such ICMP echo replies which correspond to a recent outbound ICMP echo request, and so on.

So, ICMP is good and needed (just as inbound TCP ack's are needed), for such sessions that are known to exist. Rest of ICMP is noise which is best ignored at network boundary. Just to give yourself a little more time to patch when someone finds a new critical fault somewhere in the network infrastructure code.

Speaking of allow/disallow, allow the things you know you need, don't deny things you know you don't need. If you go the "deny" path, you may overlook things like IP subprotocols other than the common three (TCP, UDP, ICMP) - just because you didn't pay attention to the multiple other values there can be in the subprotocol field.

By the way, that may vary a lot geographically. F.ex. here it's more common that customers buy their own hardware. ISPs may have recommendation lists (or lists of supported hardware), but the lists are not exclusive. Using something outside the list just means that the ISP support has never seen such a box, and doesn't have a ready configuration/help sheet for it.

Correct.

And, in any case, any way of swooping into the DMZ is a much more significant hole than allowing an ICMP Ping...

The network is generally stable (a daemon abend a year, if that), but is hosted via what is officially a dynamic IP address.

Some ISPs seem to block access on a variety of ports. Ping can be dead useful in those sort of situations... I managed to run the demo I needed (me in US, machine in UK) by running through a different port (technically hosting a different site, but running a near-enough software level to the "proper" demo).

I doubt that I would have remembered that redirected site was there, but for getting a positive Ping with a negative "Internet" response on ports 80 and

443. ISP-specific blocking as it turned out (broken in Dallas, fine in Chicago)

H1K

OK, perhaps I'm not explaining myself well. I'm assuming from your statements that you allow ICMP _only_ between permitted endpoints, yes?

If so, under what error scenarios do you think the endpoints are going to need to send ICMP packets to each other?

Now consider the routers along any one of the potential paths between your endpoints. In certain circumstances these devices could want to advise you of IP error events and will send ICMP packets to you. These ICMP packets will have an originating address not of your endpoints, and you will therefore block them. Correct?

Mike

Errors are not fixed by ICMP and are not going to cause a failure in communications. You can still get the data.

Errors may not be "fixed" by ICMP but ICMP may just tell you what you need to do in order to fix something - e.g. ICMP type 3 codes 4, 11 and 12. If you trash the ICMP response then you may end up with a failed connection which would have otherwise worked without any problem - so no - ignoring ICMP does not mean that you still get the data in all circumstances.