Ok to let all ICMP traffic through firewall?

Discussion in 'Computer Security' started by Franklin, Sep 22, 2005.

  1. Franklin

    Franklin Guest

    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
    http://snipurl.com/hvox he writes the following section. I have cut
    it down a bit.

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


    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):

    " 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
    Franklin, Sep 22, 2005
    1. Advertisements

  2. Franklin

    Leythos Guest

    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?
    Leythos, Sep 22, 2005
    1. Advertisements

  3. Franklin

    Bob Eager Guest

    In practice, you need to let a few ICMP messages through, then. For
    example, source quench and destination unreachable.
    Bob Eager, Sep 22, 2005
  4. Franklin

    Peter Guest

    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
    Peter, Sep 22, 2005
  5. :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.]
    Walter Roberson, Sep 22, 2005
  6. 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


    Wolfgang Kueter, Sep 22, 2005
  7. :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.
    Walter Roberson, Sep 23, 2005
  8. Franklin

    Leythos Guest

    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.
    Leythos, Sep 23, 2005
  9. Franklin

    Leythos Guest

    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

    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.
    Leythos, Sep 23, 2005
  10. 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:


    Hairy One Kenobi

    Disclaimer: the opinions expressed in this opinion do not necessarily
    reflect the opinions of the highly-opinionated person expressing the opinion
    in the first place. So there!
    Hairy One Kenobi, Sep 23, 2005
  11. Franklin

    Leythos Guest

    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

    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
    Leythos, Sep 23, 2005
  12. Franklin

    Bob Eager Guest

    You're wrong. But that's fine. You just carry on.
    Bob Eager, Sep 23, 2005
  13. Franklin

    Leythos Guest

    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.....
    Leythos, Sep 23, 2005
  14. Franklin

    Imhotep Guest

    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, Sep 23, 2005
  15. 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
    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!
    jameshanley39, Sep 23, 2005
  16. 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

    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.
    jameshanley39, Sep 23, 2005
  17. Franklin

    Mark Guest

    Yes it is, ever heard of PING NMAP?

    Google it and security and firewalls.
    Mark, Sep 23, 2005
  18. Franklin

    Imhotep Guest


    Imhotep, Sep 23, 2005
  19. Franklin

    Imhotep Guest

    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, Sep 23, 2005
  20. or PING of Death?
    Peter Boosten, Sep 23, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.