Ok to let all ICMP traffic through firewall?

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

  1. Franklin

    Leythos Guest

    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.
     
    Leythos, Sep 25, 2005
    #61
    1. Advertisements

  2. Franklin

    Art Guest

    Art, Sep 25, 2005
    #62
    1. Advertisements

  3. Franklin

    Juha Laiho Guest

    said:
    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.
     
    Juha Laiho, Sep 25, 2005
    #63
  4. Franklin

    Juha Laiho Guest

    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.
     
    Juha Laiho, Sep 25, 2005
    #64
  5. 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
     
    Hairy One Kenobi, Sep 25, 2005
    #65
  6. Franklin

    Mike Civil Guest

    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
     
    Mike Civil, Sep 25, 2005
    #66
  7. Franklin

    Leythos Guest

    Errors are not fixed by ICMP and are not going to cause a failure in
    communications. You can still get the data.
     
    Leythos, Sep 25, 2005
    #67
  8. Franklin

    Dave Dowson Guest

    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.
     
    Dave Dowson, Sep 25, 2005
    #68
  9. Franklin

    Leythos Guest

    I agree, but since we allow ICMP to approved sites/connections, but
    block it to the rest of the world, it doesn't really matter if there is
    a problem for the blocked ones - see the point now?
     
    Leythos, Sep 25, 2005
    #69
  10. Franklin

    Steve Welsh Guest

    You totally missed the point of what Dave Civil was trying to say!!
     
    Steve Welsh, Sep 25, 2005
    #70
  11. Franklin

    Mike Civil Guest

    What the hell are you talking about, or are you being deliberately
    obtuse? At some time in the future your company may be in a position
    where data isn't getting through because of a problem in the intervening
    path, and the the only way an intermediate device can advise you of the
    reason is by sending ICMP. Which it sounds like you are filtering out.

    Mike
     
    Mike Civil, Sep 25, 2005
    #71
  12. Franklin

    Steve Welsh Guest

    Oops - sorry - Mike Civil

     
    Steve Welsh, Sep 25, 2005
    #72
  13. Franklin

    Leythos Guest

    No I didn't, we are just talking about two different methods/needs. My
    needs require that I provide ICMP responses to the world, and in many
    cases, neither do most that don't provide public services to the world.

    If I had a website I would allow "some" forms of ICMP, but you have to
    ask yourself why you need to provide communications with people you
    don't want to communicate with.
     
    Leythos, Sep 25, 2005
    #73
  14. Franklin

    Leythos Guest

    If that happens, then "at some time in the future" I will adjust the
    settings. Until a time when it causes a problem we will leave it
    unavailable.
     
    Leythos, Sep 25, 2005
    #74
  15. :What the hell are you talking about, or are you being deliberately
    :eek:btuse? At some time in the future your company may be in a position
    :where data isn't getting through because of a problem in the intervening
    :path, and the the only way an intermediate device can advise you of the
    :reason is by sending ICMP. Which it sounds like you are filtering out.

    If the routing infrastructure he is using enters a routing loop, then

    a) there is a substantial chance that the ICMP TTL Exceeded won't
    get back either; and

    b) the NOC for the intrastructure is likely going to find out and act on it
    faster than he would get a page saying "TTL exceeded" and log in
    and track down the cause and call the NOC.

    If the routing infrastructure does not enter a routing loop, but loses
    the route, then if he has multiple routes then his routing protocol
    is going to notice the problem and adjust automatically. There are no
    routing protocols that I can think of that use icmp to determine whether
    the routing is working or not.

    If the route is lost and he has only a single route, then his monitoring
    software is going to stop hearing back from the other side, and he
    will get an appropriate notification and will investigate. That
    investigation might be helped by the availability of icmp; if so
    then he can turn reception of icmp on at the time.
     
    Walter Roberson, Sep 26, 2005
    #75
  16. Franklin

    Peter Guest

    Peter, Sep 26, 2005
    #76

  17. Maybe not all ICMP, but I'm inclined to allow ping unless there is a
    good reason not to.

    When ping and traceroute are allowed it saves a great deal of time and
    effort. This eventually saves $$. Fewer people are involved in
    troubleshooting, fewer phone calls, etc. etc.

    For example, "I can't FTP to x.x.x.x" is now a ticket which is likely to
    involve the "firewall guy" since there is no ping. This could be a very
    simple matter if only you could ping the server.

    When the network get very complicated some security is lost. Mistakes
    are made because not everyone understands all aspects of the network.

    Ping of death is quite old now and not likely to resurface. I would
    make a judgment call on this issue. If you need very high security then
    I'd turn it off, otherwise I'd focus on more pressing issues like
    silencing my telephone and shuffling my email. :)

    Scott R. Haven
    Sr. Systems Engineer
    Paisley Systems Inc.
    managed services, consulting, and support
    www.paisleysystems.com
     
    Scott R. Haven, Jan 5, 2006
    #77
  18. Franklin

    Leythos Guest

    The first rule of security is that you don't allow traffic in either
    direction UNLESS YOU HAVE A NEED.
     
    Leythos, Jan 5, 2006
    #78
  19. Franklin

    2 Guest

    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.