Ok to let all ICMP traffic through firewall?

seems there's a debate. But I can't see Robin Walker's arguments being addressed by those that say block ICMP.

it is my understanding that stealthing ports has absolutely nothing to do with ICMP. So they are different issues.

A computer has a port stealthed if the port doesn't respond to say whether it's open or closed. Online scanners that say 'stealth' are really saying "could not determine" since perhaps the port is open but the packet got lost! So some online port scanners can be be misleading. These is all TCP segments we're dealing with. They are a load of fields deep with within the Frame's contents.

A computer that blocks ICMP is a different kettle of fish. These are frames carrying ICMP packets and have no TCP segments anywhere in them or deep in them at all. Blocking ICMP packets breaks the ICMP protocol. Whereas Stealthing ports breaks the TCP protocol. I think both go against the RFCs which require correct implementation of ICMP and TCP.

A computer of course may stealth ports and block ICMP. But they're not related. The only similarity is that both are bad practice since they go against RFCs, and it does not make you safer from attack. (Does it really matter if somebody can ping you or not?!!!) IT's that argument again. That if an attacker is put off by the fact that he can't ping you, then he isn't much to worry about, and he will can easily be put off by other proper stronger security measures. Like, not having open ports unless necessary, and if they must be open, then use a firewall to restrict access to the correct individuals, and apply patches to the daemons(services/servers) to avoid exploits.

In principle, you don't really want to go around breaking protocols and going against RFCs, and you dont' gain much from doing it. If you just say "bset not to allow somethign in if you don't know what it is" it reminds me of a middle aged woman in a school using a computer who doesn't want to move an icon, and whose main phrase is "put it back to how it was before". If you nkow what an icon does then you would know there's no harm in moving it a fraction to the left or to the right.

Similarly, the people that wrote the RFCs are clever people, and there's a huge number of technical people in the know, and none of them have indicated any danger from allowing ICMP packets (or if they have, then nobody has given their argument in this thread!). The protocol has been around for donkeys' years, and nobody has sounded off any alarms about it. So there's no need to start breaking protocols and going against RFCs. It all looks like a lot of FUD to me.

I only learnt about this recently so I may be wrong, fortunately this is a public forum, where people correct each others' mistakes!

and they'd still work fine if you allowed ICMPs. If allowing ICMPs were dangerous then alarms would've been sent off long ago. ICMP has been aroudn for ages, there are no new developments to the ICMP protocol. People that know all about how it works also know of no alarms saying it can be attacked. People that know ICMP presumably allow it because they know it's as dangerous as moving an icon slightly (which might be very scary for a middle aged woman). (though against me, perhaps an OS may rewrite teh part that repsonds to ICMP and there might be an exploit in their code, but similarly there may be an exploit in their code that is rejecting ICMP)

As that article argued, besides breaking RFCs and breaking the protocols,

Besides all those arguments in the article and the technical problems with not responding to ICMP (just because your setup doesn't include situations where you'll run into the problems, does not mean the problems do not exist).

Suppose you want to know if a computer is online. A safe way is to ping it. you don't want to set up a service running on the computer and conect to it. ping tests that other comps can communicate with the comp. it's a necessary diagnostic test. What's the alternative? user makes an outgoing connection? suppose he can't for some reason. you want to know if he is online

ping is a very convenient diagnostic tool.

Some ICMPs are needed for proper TCP/UDP/IP functionality. I typically allow icmp source quench and destination not reachables through and block everything else (incoming)....

Imhotep

Yes it is, ever heard of PING NMAP?

Google it and security and firewalls.

The common sense rule is to LET NOTHING IN that doesn't have a good reason to be let in.

Why do you want to take a minimal risk if you don't have too?

In practice, you need to let a few ICMP messages through, then. For example, source quench and destination unreachable.

No, because some ICMP messages aren't useful. However blocking all ICMP is throwing the baby out with the bathwater and will cause more bother than not blocking anything.

I would suggest allowing ICMP Echo and Echo Reply (so ping works), Destination Unreachable (which includes "fragmentation required", essential for PMTUD to work) and Time Exceeded (so traceroute works.) Everything else looks to be fair game to drop.

While I'm suggesting firewall rules, can people also not silently drop SYNs to port 113 please? All sorts of servers try RFC1413 lookups and stall while waiting for a response. The firewall user is usually the first to complain that it's taking ages to connect to a certain remote server.

In article , Bob Eager wrote: :In practice, you need to let a few ICMP messages through, then. For :example, source quench and destination unreachable.

In practice, crackers will send you unsolicited source quenches, either as a side effect of them DoS'ing the host with forged packets, or else with the hope of DoS'ing you by interfering with your flow of traffic to other locations.

In practice, you don't need to listen to source quench. If you are sending data too quickly for a router, the router will drop some of the traffic. If the traffic was TCP then the normal TCP recovery mechanisms will kick in and will act to slow down your rate of transmission. If the traffic was UDP or anything other "unreliable" protocol, then by definition the transmissions are expected to be unreliable so dropping the traffic should not be important. [If it -was- important, then you shouldn't be using an unreliable transmission protocol.]

In article , Peter wrote: :However blocking all :ICMP is throwing the baby out with the bathwater and will cause more :bother than not blocking anything.

"more bother" depends on whether you are being deliberately attacked or not.

:I would suggest allowing ICMP Echo and Echo Reply (so ping works),

Typically, outsiders have no business mapping out exactly which of your systems exist or are up right now, so dropping most incoming icmp echo is a common security precaution. Whether to allow icmp echo to public-facing servers varies with circumstance.

Wrong, you don't NEED to allow anything. You may FEEL that you do, but we've got almost 100 networks that don't allow ICMP or anything else inbound and they work just fine, and we'll not change them.

My question is Should a firewall let all ICMP traffic through because there is no real risk if they do?

+++++

Here is the thinking behind my question: Robin Walker's cable modem webpages at

look to me as if they are technically sound. But they are a few years old. I would like to know what people think about the advice he gives about ICMP traffic and if it is still true these days.

He suggests that firewalls should let all ICMP traffic through and that there is no real risk if they do that. At

he writes the following section. I have cut it down a bit.

------------------- START QUOTE -----------------

STEALTH-MODE FIREWALLS CONSIDERED HARMFUL

Some firewalls have a hiding mechanism they call stealth. ... In stealth mode, the firewall causes the PC just to ignore incoming connection attempts, rather than rejecting them, as would be normal for incoming connection attempts to closed ports.

.... causes some difficulties. For a start, Internet standard RFC 1122 states categorically about ICMP Echoes (ping):

"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."

So you are strongly advised not to apply stealth techniques to the ICMP protocol.

A commonly heard objection to allowing ICMP Echo Replies is that it gives away information to hackers that there is a live connection on this IP address. Such objections are not well-founded, and can be safely ignored.

There is no evidence in practice that any hacker has been aided by the presence of an ICMP Echo Reply.

Hackers do not typically write code that tests an address with ICMP Echo before launching a hostile probe: they always send the hostile probe directly: either it works or it doesn't, and information from ICMP adds nothing to the analysis.

------------------- END QUOTE -----------------

So Should a firewall let all ICMP traffic through? Is it ok to do that?

There is NO BOTHER - you set the rules and then let them work. You don't need to allow PING, in fact why the heck would you want to allow PING, it's not like it's a valid test that your network is alive - we've got tons of commercial networks that block PING and none of the users even notice.

Allowing anything inbound, even to the firewall, that doesn't specifically need to be let in is a bad move.

Allowing in minimal traffic that "might" not be a threat is like trusting Windows Firewall with File/Printer sharing enabled on a computer directly connected to the Internet with all of your financial data stored on it in a text file that is name "ALL MY FINANCIAL DATA.TXT" sitting in the root.

LOL...

Imhotep

Undoubtedly the case. Although one could quote lots of instances where it's been damned useful.

Well, *I* certainly can - usually when the web server has had a bit of a funny turn, and one needs to tell if it's the server behind the firewall (fat chance of fixing something from an adjacent continent), or whether it's the ISP playing silly buggers with the connection (marginally more hope of getting something sorted).

As goes firewalls - I'm sure that most have already seen it, but:

Funny, I don't expose our servers to Ping, and I seem to be able to monitor them all the time. If I need to expose PING to an external source I expose it to a specific IP and block all others.

If I have to manage a server, I only allow VPN access inbound to the firewall it self and use a different password/user than I use for the server.

Ping is only good when you don't know what else is available and how to secure it from the public. There is no reason to allow open access to ICMP or anything else that doesn't have a specific business need (like HTTP/SSL/FTP/etc...).

You're wrong. But that's fine. You just carry on.

Then, when we're running along for the last few years, blocking all ICMP inbound and at the firewall, what are we denying ourselves?

It seems that our networks work, that we can VPN into the office just fine, etc...

It seems that all of our dedicated IPSec tunnels to partners work fine, it seems that our systems with web servers, OWA services, etc.. all work just fine.....

No.

No. While the example you quoted from the web page is still correct and there is nothing wrong with echo request and echo reply and the various destination unreachable messages the are other icmp messages that should be filted.

Wolfgang

Honestly, you CAN block all ICMP types, however, it is not optimal. Some ICMPS are in fact needed for normal TCP/UDP/IP operations (well, efficient anyway)....ie without flow control, it will appear that things are "hanging" equating to those nasty users saying the "network is slow"...when in fact the host has not been informed to slow itself down and as such will keep on sending packets (which are only being dropped and retransmitted yet all over again)

Summary: In my opinion, allow a few ICMPS (source quench, and the misc unreachables) and deny everything else (incoming)....

Just my opinion though, Imhotep