Re: ODBC in DMZ

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

This has been an ongoing issue over the years and I thought I'd
descibe some of the results of my experience.  Hopefully it will
shed some light on the issue at hand and possibly lead some of
you to a solution recently introduced.  As always, any corrections
and/or comments are welcomed.

Todd Johnson wrote:

>       If it is MS Sql Server, you might want to take a look at the MS
>       Knowledge Base article #: Q164667
>
>       You can essentially hack the NT registry to MAKE MS
>       Multi-Protocol listen on what ever port you want.
>       The knowledge base explains how to to it.  This give you (at
>       least) MS trusted connections (& what MS
>       calls encryption) through a firewall/router

Agreed...but IMHO this is just plain bad form as a requirement to lock
a connection down...

By hacking the registry to restrict the behaviour of a normally random
high port assignment  on the client which ultimately connects to a
predefind port on the server is enough to get through even ACL's on a
router let alone a firewall with stateful inspection capabilities.

Considering the very nature of the RPC locator's role in the scheme of
things, it's ironic that the only way to lock down a connection is to
disable all of it's high-port mapping capabilities.

>       This give you (at least) MS trusted connections (& what MS
>       calls encryption) through a firewall/router (if you really want it).

Yep...standard NTLM performed through MS-RPC immediately after
receiving the initial packet containing the applications UUID being
requested from the client.  Immediately after the auth is successful
the RPC locator notifies the application to expect the next connection
on port X from the client addr of Y using high-port Z.  The last packet
from the locator service sends tells the client the server's IP addr
and PORT number now waiting for it's connection.

NOTE:  I wanted to point out for later refference that this information
('this' being the server's IP address and port number) is passed to the
client in a text string.  Hence MS-RPC's inherent problems with most
forms address translation.

>       The only other Hypothetical way is to make MS re-code their IP
>       Stack ;)...

I disagree, but before we continue let's touch on some additional
information regarding the evolution of MS-RPC first...

Given the two types of connectors you can define in ODBC (at least the only
two which can be used w/ IP) Named Pipes and/or TCP/IP Sockets are
available, both connectors utilize different forms of the MS-RPC protocol.

Named Pipes: utilizes netbios (this connection requiring 138 UDP as part of
session establishment) runs over port 139 using at least TCP.  The 'at
least' being that MS-RPC by default chooses TCP, but if unavailable has
been known to also use UDP as an alternate in later versions.  Microsoft
even admits that due to the command/responce orientation of MS-RPC,
using UDP as a connection type is actually faster than TCP in any given
scenerio.

Inside the Netbios connection on 139 an older version of MS-RPC  is used
which is equivalent to the one defined by the original COM specs.

COM was used by the likes of usr mgr, srvr mgr, and wins mgr although
distinctions still remain which are resource specific.  Overall it was for
the most part only used internally by MS themselves.

MS-SQL TCP/IP Sockets:  This connector utilizes the DCOM configuration
options to bind to the MS-SQL listener to a specific port.  The DCOM
object always being bound to port 1433 is using a mode in which does
not require participation of the RPC port mapping service on either UDP
or TCP port 135.

The DCOM spec is the next generation of COM and likewise uses
MS-RPC as it's primary transport.  The later spec is also the one which
first defined the DCOM objects and their use in MS's VC++ and VB.  This
introduced the whole concept of a DCOM object which eventually became
known under it's current lable "DCE/RPC".

To make a long story short... all of the specifics regarding DCE/RPC
behavior boil down to this... until now no one has supported it through it's
various state changes thus achieving stateful inspection on the
connection until now...

Support is now provided in FW-1 ver 4.0 Sp3...

Check Point now supports specific types of port negotiations used by
DCE/RPC connections in Ver. 4.0 SP3 (but I reccomend waiting for the
update due at the end of this month...this one recently labled as SP4).

This means that connections can be followed through port 135 to random
high ports randomly chosen (not quite but works for now) by both the
server and client.  Limited support was first provided in SP2 which
resulted in the "Exchange" resource where DCOM support for objects
bound to a single port was demonstrated.

With MS-SQL using this same type of connector, I see no reason that
with updates to the INSPECT code for the Exchange resource, support for
MS-SQL couldn't also be provided.

Some additional advantages also include the ability to filter DCOM
connections by their application id (something similiar to the UUID in both
form and function).  This alone alleviates some fundamental concerns about
exposing the RPC locator service (port 135) to unreagulated traffic.  The
connection attempt is blocked if the right DCOM lable or app id isn't
requested by the client.

To date what I have yet to test is FW-1's ability to translate a server
address behind a static NAT.  The requirement here is to successfully
translate the  the afore mentioned IP addr & port numbers which are
passed in MS-RPC port negotiations.  Although untested I have found
refferences to kernel functions in INSPECT designed for this purpose.

Overall DCE/RPC has been a total nightmare to support as a
production service on any untrusted network.  But these new
enhancements to FW-1 will hopefully go a long way in smoothing
over some pretty rough edges....

I've also heard tell of an inventory agent for DCOM applications
which integrates into the management server.  If there's any interest
in something like this, I can look into it...

It's possible I might get in a couple tests to see about supporting the
MS-SQL connection through the support provided in SP2, or if it will
require the latest updates in SP3.

Comments....?

Sean Costello
Network Engineer
xlate () iname com