Re: how to block ICMP tunneling?

["Sean Costello" <xlate () home com>]

hello everyone...

-src.

Jason wrote:

> > Unless you have an application based firewall! Where the firewall 
> > is actually scanning the contents of the pay load to check which 
> > commands for that associated application protocol are coming in.

Before we continue to Marcus's comments I wanted to interject this... 
in regards to comments made by Jason.... I defy anyone to really 
find any difference in something like CP's FW-1's in.ahttpd, in.aftpd,
etc., etc. "security servers" (FW-1 being a "statefull inspection 
firewall") and any competing "proxy based firewall' equivalent which
is in more than just an item in the feature set.  Thus equating any
given feature to just form (ie: URL caching) rather than an actual
difference in function....

I'll come back to this further down so for now let's just continue....

Marcus wrote in responce to Jason's comments:

> Most of the application proxy firewalls I know (I wrote a couple,
> in the past) don't _really_ do much content/payload scanning.  Most
> of that stuff was theoretical, rather than actually implemented.

Being that it's the firewall I'm most familiar with as I've already made 
refference, I thought I'd address FW-1 ver 4.0's behaviour in my 
response...

The user mode process named in.pingd (Note: On NT it's one of
the various 'fw.exe process' in the task list...this commented on
 later) was introduced by CP in FW-1 ver 4.0.  The addition of this
user mode daemon was mostly driven by the need to handle the
stateful inspection of ICMP packets generated by intervening routers
when establishing a connection through a NAT'd address.  

The in.icmpd provides stateful inspection for all ICMP packets 
including the intervening routers even when handling a NAT'd 
exchange.  The need for NAT support was primarily to alleviate 
issues with the MTU discovery process used by most vendor's 
(another topic recently discussed on this forum).  

One particular issue I ran into with the MTU size negotiation that a 
number of MS's IP stack implementations seem to have various 
inherent problems which have already been patched or remain yet
to be patched specifically dealing with packet fragmentation.   
Problem can range from issues with PPTP all the way to Win95's 
DUN 1.3 Update.  All this not to mention a few introduced by
vendor's like CP in a specific version of SR4.0 in their encryption 
and encapsulation algorythms (mostly ecnountered when using the
original SR40 client connecting to FW3.0b firewall but is mostly
resolved by the SR4005 release.  I say mostly because there are
just some inherent design inconsistancies between the two which
can't be avoided).

Although many of the MS problems are overcome by the FW-1's 
fragmentation  engine there are still issues with "blackhole routers"
as MS calls 'em to deal with.  These are network devices which will
sometimes silently discard packets when the given device incures 
heavy congestion.  This forces a retransmit which under some MS 
stack implementations turns out to be a 14 packet exchange 
between endpoints (MS to MS) before everything is corrected and
the originally dropped packet is finally resent.

'in.pingd' tracks elements in ICMP providing FW-1 the ability to 
enforce as well as distinguish direction.  Meaning that you can 
allow clients to ping out but not get ping'd as well as an ICMP 
responce wouldn't make it through the firewall to a given client
unless an outbound request had been tracked.  Currently 
(xlate)src IP, (xlate)dst IP, and the ICMP packet id are all 
tracked in a FW-1 state table.

Ultimately, these ICMP exchanges make it to the the connections
table once they're properly qualified which means that subsequent 
all packets are identified at the kernel level.  How long it takes to 
reach this point is dependant on the type of ICMP discussion in 
progress.

This is also an opportunity to refference the note above regarding 
the process name on NT, you can identify the various user mode 
componants by checking the '$FWDIR\tmp\*.pid' files.  An example 
would be fwd.pid would represent the pfm daemon or the fwm.pid 
would be the management server.  These files are updated each
time each specific process is started... the restarting of a process
can happen for any one of a number of reasons.  The most obvious
being that the former died...

> Originally, the myth of proxy firewall superiority was partially
> driven by the "content scanning" concept, even though most of

Not only regarding the "proxy firewall's" superiority but ultimatetly 
it's design.  Actually, IMHO CP's implementation gives the best of
both worlds.  FW-1 not only gives you the higher level inspection 
capabilities and packet manipulation of a proxy but also the
advantage of possible increases in performance through the use
of kernel mode qualifications used in evaluating connections.  This
aspect is avoided by CP because of the legacy already created 
though the rivalrybetween the two types. 

Even so I still don't see in any way how this this could be a 
detriment to the FW-1's overall design.  It's just all too convenient
to capitalize on this position from all of the marketing material and
arguments in trade rags generated over the years.

> the proxy firewalls did only a tiny bit more content scanning
> than a router does. Now that I'm not in the firewall business
> anymore, I like trying to get proxy firewall vendors to enumerate
> the checks they actually do make. I've had little success. I
> suspect because they make laughably few checks.

In comparing FW-1's qualifications to those enumerated by an 
excellent technical update provided by Jason regarding Raptor's 
behaviour I can only identify two significant difference in the various
elements of ICMP used in qualifying a connection.  Only one of
which could be a potential security risk in using FW-1's default
configuration.

In looking at the differences let's consider Raptor's tracking of the
ICMP's checksum on the data portion of the packet, I don't see this
as being all that big of a deal for two I believe to be very good 
reasons...

A.  With the use of FW-1's Inspect language the tracking of this 
property could most likely be added though updates to the 
$FWDIR/lib/"appropriate".DEF file (most likely the base.def).  

B.  If this aspect is taken into consideration by the hacker developing 
the ICMP tunneling software... couldn't they imbed the neccessary
fill into the data portion thus achieving a responce with the same
payload's crc?  If so wouldn't this negate any relevance of tracking
this porperty by a firewall, proxy or otherwise.  The only way short
of tracking the actual packet contents would be to implement
something like an MD5 algorythm on an ICMP packet's payload.
Which IMHO would most likely prove to be more overhead than it
would be worth.

Ultimately, I would think that the best solution to this issue would be
to either salt a given clients ability to maintain extensive ICMP
conversations through the firewall with untrusted machines.  Possibly
acomplished through Inspect...

But, given the impressive slection of attacks which can be launched
through the devious use of ICMP...isn't it a given that most available
IDS solutions automatically consider any node's extensive use of
ICMP a potential attack or comprimised machine anyway?  The
former not being a rhetorical question at all since this area really
isn't my forte....comments...?

The second item is possibly the only potential short coming which
might constitue a security threat.  This being that I don't believe
that FW-1 currently rewrites the seq #'s of ICMP packets coming
in to either routed or statically NAT'd address' behind the firewall.
It would be of interest in regards to Raptor as to whether or not
inbound ICMP packets are proxied.  If not this would be similiar
behaviour to FW-1's Hide NAT implementation (which are also
rewritten) but Seq#'s on outbound ICMP packets usually aren't a
threat. 

This is just my opinion, but to take advantage of predictive
sequencing vulnerabilities...you would have to have a process
which generated the ICMP packets intially and if you can do that
then you would have more than predictive sequencing weaknesses
since the box has already been comprimised anyway.

Although it might be possible to use this information to possibly hijack
another users connection, but I would think that this would more than
just the average connectivity available unless utilizing additional insight
about services availble on the target possibly from other means.  But
this kinda seems like a long shot as well as possibly move the issue
beyond the normal scope of a firewall.  In my opinion the only potential
threat from the predictive seq. weakness would be from outside nodes
generating ICMP traffic to internal machines thus gaining insight to the
possibility to monitor other network related events.  An example of it's
use is the ability to port scan a victim's network through spoofing you're 
machines IP.  Seq #'s are then monitored though ICMP to watch for a
reaction by the box you're spoofing.

This is yet another way to perform port scans while not only remaining 
anonymous but also leaving incriminating trail of evidence pointing to
just about any innocent bystander.  The end result being a question like
"Why is COMPAQ port scanning our site...?".  Or any number of other 
amusing sources of third parties while leaving still the victim without any
hope of ever locating the real attacker.

I mention this because in a default configuration of FW-1 ICMP is
accepted through Rule 0.  This inherent problem can be elliminated 
through only allowing clients to ping out and dropping attempts from
outsiders to intiate pings in.  As previously mentioned, FW-1 does
provide the ability to accept or discard an ICMP conversation by
distinguishing the direction although it is not configured to do this by
default.  My opinion on this is that all pseudo or implied rules should be
replaced with explicit rules in a rulbase anyway.  At the very least be 
sure to enable viewing of implied rule in you're policy in an effort to
make sure you completely understand each traffic type you currently
allow into you're network.

When in production environment, anything short of attempting to
understand each and every rules impact to your network whether it's
implied or not is at best poor attempt to administer a FW-1 box. 

Hope this helps...

and as always comments or corrections are welcomed...

Sean Costello
Network Engineer
xlate () iname com