ICMP Packets.

Henry Hertz Hobbit hhhobbit@icarus.weber.edu
Sat, 6 Jun 1998 06:39:28 -0600 (MDT)

On Fri, 5 Jun 1998 john_smith@rd.qms.com wrote:

>         I knew I had seen this thread before.  Searched my personal 
>      archives and came across it in the Firewalls Digest (V6 #295, #299, 
>      #304 and #305) under the thread titled "what ICMP should i allow 
>      through?".  Based on that discussion we modified our filter rules as 
>      follows:
>      Inbound Allow:
>      - echo (type 8/code 0)

Shouldn't this really be?

       - echo reply (type 0/code 0)
         [ in other words, we want a response to our outgoing ping ]
         [ to come back in; the way you have it here it would be ]

       - echo request (type 8/code 0)
         [ this means somebody on the outside could ping you! ]

>      - paramter-problem (12/[0|1])
>      - source-quench (4/0)
>      - ttl-exceeded (11/[0|1])
>      Deny all other inbound ICMP.
>      Outbound we allow all ICMP packets.

For some reason, I think if I have this fine grained of control,
I would want at *least* the following given what I said above:

       Deny the following outbound (in case an echo request coming
       in somehowdid not get filtered out):
       - echo reply (type 0/code 0)

>         This complies with our policy of permit all outbound and deny all 
>      inbound except what is specifically permitted.  This list works *for 
>      us* and does not seem to cause any connection problems (at least no 
>      customer connectivity complaints).
>         If any of you spot any obvious problems with this please point them 
>      out.

Like I said, especially after what we just heard happened with
the hackers making it through the firewall at the India Nuclear
Research facility, things can and should be tighter than some
people have let themselves believe is good enough. Allowing ALL
ICMP packets to go both ways is NOT a solution. Thank goodness you
are thinking! I just think you said something you didn't mean to