[Courses] [Security] Firewall theory -- ICMP

[Raven, corporate courtesan]

Heya --

Quoth coldfire (Fri, Mar 15, 2002 at 04:03:09PM -0500):
> ICMP is considered as the same layer as IP because "it's actually an
> integral part of IP." (RFC 792)

	For the newbies: an RFC (Request For Comments) is a standards
document.  These are the docs that define how protocols work.  When you
hear people trumpeting about how their programs are standards-compliant,
these are the standards.  You can read the RFCs online at:

http://www.rfc-editor.org/rfc.html

	They can be tough going, but if you really really want to know
the canonical "how something works", this is where you go.  And some of
them have a sense of humor, too.  Every year on April 1st, there's a
great one.  Check out the packet over carrier pigeon RFC at:

http://www.ietf.org/rfc/rfc1149.txt
 
> > 	 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.

	Gak.  Thanks for catching that; that's what I meant to say.
Sorry if I confused anyone.  

> nitty gritty stuff :)

	Yeah.  [grin]  I dig protocol headers.  And Path MTU discovery
is something that a lot of people don't know that they shouldn't
firewall out, and I've seen it break things in weird and seemingly
inexplicable ways.  So I figured it was good to save y'all some pain.

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

	On some backbone Internet links, the MTU can be pushed up to
9000 bytes or so.  (Weird SONET stuff.)  But 1500 is far and away the
most common.

> when a packet is fragmented, it isn't put back together until it reaches
> it's destination host.

	Usually.  This is what's supposed to happen.  But some firewalls
will reassemble fragmented packets for you and then forward them to the
destination host.  I dislike this; I think following the standards is a
better idea.

	The reason that some firewalls do this is because when you're
filtering based on TCP headers, and your TCP segment has been
fragmented, you don't have the header information in all fragments to
filter on.  Take this, for example.

           |TCP header|-------TCP payload---------|

When this gets encapsulated into an IP packet, you'll have:

           ||IP header||TCP header|-------TCP payload---------|

The TCP header and the TCP payload are the entire payload for the IP
packet.  So we could also represent the above packet as:

           ||IP header||---------------IP payload-------------|

Now, when this IP packet gets fragmented (say it was sent over a FDDI
link, but the next hop is over an Ethernet link), we get

  |New IP header|IP payload, part 1|
  |New IP header|IP payload, part 2|
  |New IP header|IP payload, part 3|

which could just as well be represented

  |New IP header|TCP header|-----TC|
  |New IP header|P payload---------|
  |New IP header|------------------|

So the TCP header information is only in the first fragment.  If your
firewall is filtering based on TCP header information (like port number,
for example), it will correctly handle the first fragment, but won't
really know what to do with the rest.  You can specify what you want
done with fragments if you like, but there is no easy way to
differentiate FTP fragments from SSH fragments if they don't have the
header in there.  So some firewalls reassemble the packets so that they
can then drop or allow the whole thing.

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

	I generally block ICMP message types 9 (Router Advertisement),
10 (Router Solicitation), 13 (Timestamp Request), 14 (Timestamp Reply),
17 (Address Mask Request), 18 (Address Mask Reply), and 5 (Redirects) to
the external world, even on my non-paranoid firewalls.  I guess paranoid
is a relative term.  [grin]

Cheers,
Raven
 
"Sed, sed, awk.  Like duck, duck, goose.  Sync, sync, halt.  It's the
 order of nature."
  -- me, after too long a day at work