[Courses] [Security] Firewall theory -- ICMP

[coldfire]

> > i'll mention now just for the sake of example .. on my very strict
> > firewall script, i only accept three types of ICMP messages.  i currently
> > accept ping replies, host unreachables, and network unreachables.
> 
> 	Time Exceeded is a good one to accept, too, so that traceroutes
> work.

i made a mistake ... i accept three types of icmp messages and i named
three specific messages.  i accept 'ping replies,' 'destination
unreachable' (host unreachable, networking unreachable, port unreachable,
etc.), and also 'time exceeded' messages.

> 	ICMP is a protocol within the TCP/IP stack that exist basically
> to provide control, troubleshooting, and error messages.  It runs over
> IP, like TCP and UDP do, but is a network-layer protocol, like IP,
> rather than a transport layer protocol like TCP and UDP are.

ICMP is considered as the same layer as IP because "it's actually an
integral part of IP." (RFC 792)

> > accepting ping replies is important if i would like to ping someone and
> > see the reply.  this doesn't mean that anyone is allowed to ping me.  the
> > other two are very important for the operation of TCP.  we can get into
> > that later :)
>  
> 	Two days later... [grin]
> 
> 	 When you ping someone, you are sending an ICMP packet with
> message code 8 (Echo Request) to them.  They reply with an ICMP packet
> with message code 0 (Echo Reply).  So if you want to allow people behind
> your firewall to ping external systems and get a reply, you have to
> allow ICMP message code 8 packets incoming, like Coldfire said.  If you
> want to allow people to ping you, you have to allow ICMP message code 0
> requests incoming.

it's the reverse .. in order to ping someone and recieve the response, you
would want to accept ICMP Type 0 messages on the external (incoming)
interface.  if you would like to be able to be pinged, you should accept
ICMP Type 8 on the external interface.

> 	When you traceroute to someone, you send (under most
> implementations; we'll get to tcptraceroute and its friends later) three
> UDP packets with a time-to-live of one towards your destination.  The
> first system it hits sees the packets, sees the expired TTL, and sends
> back three ICMP message type 11 (Time Exceeded), message code 0
> (Time-To-Live Exceeded in Transit) packets to the originating system.
> The system notes that, and sends out three packets with a TTL of 2.  It
> gets the ICMP errors from the next system down the line, and sends out
> three UDP packets with a TTL of three... and so on until it gets back
> the ICMP errors from the destination system.

traceroute is simply a tool to see the route that an IP datagram traverses
on the net.  it uses the Time-To-Live (TTL) field in the IP header.  the
TTL field is used to say how long the datagram should "live."  the olds
RFCs required that the TTL be decremented by the number of seconds that a
particular router held the datagram.  since it's typically less than a
second (for a single router to hold on to it) it was decremented as one.
the new RFCs now make this optional.  most OSes now just use this field as
a "hop" counter.  every router the packet hits decrements the field by 1.
when a machine recieves a datagram with a TTL of 1 or 0, it should discard
the packet and send a "time exceeded" message back to the originator.
this is to prevent a datagram from entering routing loops.

just a fyi, it is possible that during the run time of traceroute, the
route to the destination host can actually change (be means of dynamic
routing protocols, like OSPF or RIP. i usually do at least two traceroutes
to get a more accurate idea of where my datagrams are going.

> 	You also want to know when you can't get to something.  So you
> probably want to allow ICMP message type 3 (Destination Unreachable)
> error messages through your firewall.  Of particular importance is ICMP
> message type 3, message code 4 (Fragmentation Required but DF Bit Is
> Set).  This error message is necessary for Path MTU discovery.

nitty gritty stuff :) ... maximum transmission unit (MTU) is the maximum
size a datagram can be on a particular link.  for example, the MTU on
ethernet is 1500 bytes and the MTU on FDDI is 4352.  the MTUs for
point-to-point links isn't usually restricted by the physical link.
rather, it's usually set to allow an "adequate response time for
interactive use."

the Path MTU is defined as the smallest MTU of any link that a datagram
traverses between two hosts.  different segments may have different MTUs.

now fragmentation.  if the datagram being sent is larger than the MTU, it
has to be fragmented.  IP is a nice guy, so he takes care of this for us.
when a packet is fragmented, it isn't put back together until it reaches
it's destination host.  it can get really wierd when fragmented datagrams
require further fragmentation of their own.

when a datagram is fragmented, each fragment becomes it's own datagram and
has it's own IP header.  since routing is dynamic, the packets can arrive
out of order.  but IP is a pretty intelligent fellow and can take care of
that for us making fragmentation transparent to the application layer.  if
any of these fragments are lost, tcp will time out and send a retransmit
for the whole tcp segment.  you can't resend just a fragment of a
datagram.

finally, there's a bit field called the "don't fragment" bit (DF).  when
this is set, IP won't fragment the datagram .. rather, it'll send back an
icmp error, "Fragmentation Required but DF Bit Is Set."

> 	IMO, most of the rest of the ICMP error messages can be safely
> blocked.  (Anyone with arguments to the contrary, please chime in.)

i would say it's also generally safe to accept most icmp error messages.
they're not useful for attacks unless someone is just trying to flood you
with junk.  there are usually much more effective ways to do this though
:)  there is one exception, i wouldn't normally advise anyone to accept
ICMP Type 5 messages.  they are the Redirects.

redirects are used ... well, here's an example.  let's say some client
sends a packet to it's default router (a commond decision that's made).
well, if when that router decides how to route that datagram and discovers
that it's sending it out on the same network interface that it arrived on,
then it never needed to see that packet in the first place.  the
router would then send an ICMP redirect that tells the client to send 
future packets directly to that destionation.  well, obviously, the client
has a pretty crappy routing table setup in the first place.  redirects are
usually used to help build routing tables.  but obvious security issues
incur.  well, i gotta run .. more later :)


coldie