Re: how to block ICMP tunneling?

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

hello everyone...

sorry this is a resend but after a review I had to clear up a few
points.  The original being somewhat ambiguousing in certain 
areas, not that this version will fix every section I didn't present
clearly enough ;^)

-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. which I call "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 rather than an actual
difference in function.

Both type of firewalls bring the packet all the way up to a user mode 
process to be identified, at least initially.  But I'll come back to this 
later 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.

I'll address the firewall I'm most familiar with, FW-1 ver 4.0, which 
I've already made some refference too in this 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.

If you're having to fragment packets at the router level, for each
additional packet required to represent the oringinal you not only
increase the liklyhood of any given packet being dropped.  You 
also increase the number of packets it takes to recover from the
disarded packet by two, three, or even possibly more times.  

All this in addition to adding more inherent overhead on the 
network device requiring the smaller MTU (possibly increasing the
burden the same network gateway silently discarding the packet)

The '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 possibly means that 
subsequently 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 FW-1's packet filter module
daemon or the fwm.pid would be the management server.  

The current process ID for the security server specified by the name
is the entire contents of this text file.  If you're tshooting a DrWatson
the you do the $FWDIR\bin\fwstop.bat (or just C:\>net stop fw1svc...
You can the copy the /tmp directory and get a copy of the list of 
process ID's.  Later lookup the offending pid in the drwtsn32.log and
refference the information in this directory.  With this you can find out
the name of the offending security server.  Most likely a good step
toward helping to resolve the problem....


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.  Any 
refference to similarities between CP's "security servers" and 
"proxy servers" are avoided by CP I guess because of the legacy
already created though the rivalry between the two types of 
firewalls. 

Even so I still don't see in any way how adding user mode daemons 
could be a detriment to the FW-1's design.  I see as a way to
get more control over the stateful inspection process.

Unfortunately it's just all too convenient to capitalize on the 
established differences in opinion and take advantage of all the
marketing material and arguments in trade rags generated over the
past number of years.  Too bad cause presenting this aspect to 
customers help some engineers to get a better understanding of
overhead required for different features and why.

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