                    Using Distributed COM with Firewalls
                    Last revised Saturday, June 20, 1998

         Copyright 1997-1998 Michael Nelson. All rights reserved.
    You may link to this page from other pages, however, you must obtain
    permission from dcomfw@iapetus.com before you copy any part of this
                    article in print or electronic form.

     Please send comments and questions directly to dcomfw@iapetus.com.

 Special thanks to Mark Ryland and many others at Microsoft for their help
                         in writing this article.

Introduction

     This article is intended to provide the reader with information
     on how to configure Distributed COM to work through a firewall.
     It assumes that the reader is familiar with the TCP and UDP
     protocols, DCOM, and understands the basics of firewall
     technology. Please note that the port restriction procedures
     outlined below only work on Windows NT; Windows 95 does not
     include this functionality at this time (don't worry, it isn't
     necessary in most cases). Also note that much of the discussion
     in this article is also relevant for RPC applications which use
     dynamic ports. This makes sense considering that the features
     mentioned below are really implemented in the RPC subsystem which
     DCOM leverages to communicate across the network.

     Unlike most Internet applications which have fixed TCP and/or UDP
     ports, DCOM dynamically assigns -- at run time -- one TCP port
     and one UDP port to each executable process serving DCOM objects
     on a computer. That is, even if a process is hosting 2,000
     clients and 50,000 objects, any client wishing to communicate
     with objects owned by it will always connect to the same TCP or
     UDP port. Clients discover the port associated with a particular
     object by connecting to and using the services provided by DCOM's
     Service Control Manager (SCM). The SCM always operates at a fixed
     network port on every computer; in the Internet case this is
     always port 135 for both TCP and UDP. The SCM offers several
     RPC-based (not DCOM/ORPC-based) services which handle operations
     like: "create a new COM class object for me and tell me what TCP
     and UDP port it is on" or "I have an interface pointer, tell me
     where I need to go to actually use it", etc... A much more
     technical explanation of this process and of the DCOM wire
     protocol in general is documented in the DCOM/1.0 specification
     at http://www.microsoft.com/com.

     DCOM's dynamic port allocation feature offers great flexibility
     in that programmers and administrators alike are free from the
     burden of having to configure (or hard code) applications to
     specific ports, free from resolving conflicts between multiple
     applications attempting to use the same port(s), and so on.
     Unfortunately, because DCOM (by default) is free to use any port
     between 1024 and 65535 when it dynamically selects a port for an
     application, it is rather "firewall unfriendly" out of the box.
     Configuring your firewall to leave such a wide range of ports
     open would present a serious security hole. Microsoft's
     developers realized this and have implemented a feature which
     allows you to restrict the range of ports that DCOM will use to
     assign to applications.

     You should be aware that callbacks in DCOM are NOT handled on the
     same connection that is used for client->server method calls.
     When a server makes a callback to a client, it creates a new
     connection to the client and sends method calls over that
     seperate channel. In other words, DCOM treats callbacks just like
     any other client->server method call, except that your "client"
     is really a server and the "server" is really a client. In some
     circumstances (this is very rare), you may need to configure port
     restrictions on your clients if your firewall restricts what
     ports machines on the inside can connect to on the outside.

     Also note that if you want to use callbacks through a firewall,
     you must use TCP. The reason being that when the server makes a
     call to the client, the source port will not be within the range
     below and thus when the client sends a reply to the server's
     source port, it will not be able to penetrate the firewall. This
     is not a problem with TCP because most firewalls keep track of
     TCP connections and permit bidirectional traffic on connections,
     regardless of the source port, as long as they are opened from a
     machine on the inside.

     One last thing before I continue, the client must be able to
     reach the server by its actual IP address. You cannot use DCOM
     through firewalls that do address translation (i.e. where a
     client connects to virtual address 198.252.145.1 which the
     firewall maps transparently to the server's actual address of,
     say, 192.100.81.101). This is because DCOM stores raw IP
     addresses in the interface marshaling packets and if the client
     cannot connect to the address specified in the packet, it won't
     work.

Configuring DCOM to use TCP only

     Here is a rundown of the transport protocols that DCOM will use
     depending on the client & server platform:

      Platform                     Protocol
      Windows NT 4 <-> Windows NT 4UDP
      Windows NT 5 <-> Any         TCP (*)
      Windows 95/98 <-> Any        TCP
      DCOM for UNIX <-> Any        TCP

     * When a Windows NT 4.0 client attempts to connect to a DCOM
     server running anything but Windows NT 4.0, there will be a 30-45
     second delay while it attempts to connect via the UDP protocol.
     Windows 95/98, Windows NT 5.0, and DCOM for UNIX (incl.
     Microsoft's DCOM for UNIX product and Software AG's EntireX
     product) always use the TCP protocol.

     The Windows NT 4.0 implementation of DCOM uses UDP wherever it
     can because benchmarks show that it can outperform TCP in certain
     scenarios. Unfortunately, it is very difficult to make UDP
     applications work through firewalls without exposing your network
     to unnecessary risks. Before continuing, be sure you make TCP the
     default protocol on all Windows NT servers by moving the
     "NCACN_IP_TCP" value to the top of the list in the DCOM Protocols
     named value of the HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
     registry key using regedt32.exe. To eliminate a 30-45 second
     delay when connecting to TCP only servers, the same change should
     also be made on Windows NT 4.0 clients. Note that this delay only
     occurs if you haven't connected to the target server in a while
     (RPC's connection caching features retain knowledge about the
     server so that multiple connections in a short period of time are
     resolved instantaneously).

     The Windows NT 5.0 implementation of DCOM will likely default to
     TCP because it is not possible to implement the SSL and SNEGO
     security protocols over UDP.

Restricting the Range of TCP Ports

     There are several registry settings which control the DCOM port
     restriction functionality. All of the named values listed below
     are located under the
     HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet registry key
     (which you must create). Remember, you only need to do this on
     the server machine, clients will automatically pick up the right
     port numbers when they connect to the SCM on the server machine.

     Note that you must use regedt32.exe to configure these settings,
     regedit.exe does not currently support the REG_MULTI_SZ type
     required by the Ports named value entry. Also, you must reboot
     your machine any time you make changes to any of the following
     registry settings for them to take effect.

      Name                  Type         Value         Description
                                         Specify one
                                         port range
                                         per line.     One or more port
                                                       ranges. The options
      Ports                 REG_MULTI_SZ Example:      below determine the
                                         3000-4000     meaning of this
                                         5141          named value.

                                         "Y" (don't
      PortsInternetAvailableREG_SZ       include       Always set this to
                                         quotes)       "Y".
                                                       If this value is
                                                       set to "Y", then
                                                       the Ports named
                                                       value indicates
                                                       which ports should
                                         "Y" or "N"    be used for DCOM
      UseInternetPorts      REG_SZ       (don't        applications. If
                                         include       this value is set
                                         quotes)       to "N", then the
                                                       Ports named value
                                                       indicates which
                                                       ports should NOT be
                                                       used for DCOM
                                                       applications.

Restricting the Internet Accessibility to Specific Applications

     An even greater level of security is afforded if you configure
     your system so that DCOM applications have to explicitly ask to
     be accessible through the Internet-accessible port range. To set
     this up:

     1. Change the UseInternetPorts named value above from "Y" to "N"
     so that DCOM object servers (and RPC servers) aren't reachable
     via the Internet-accessible ports automatically. Reboot your
     machine.

     2. Insert the following piece of code before CoInitializeEx()
     into every DCOM object server application that should be
     accessible through the Internet-accessible port range:

          RPC_POLICY rp;

          rp.Length = sizeof (RPC_POLICY);
          rp.EndpointFlags = RPC_C_USE_INTERNET_PORT;
          rp.NICFlags = RPC_C_BIND_TO_ALL_NICS;

          hr = RpcServerUseAllProtseqsEx (RPC_C_PROTSEQ_MAX_REQS_DEFAULT, NULL, &rp);

     3. Add 'rpcrt4.lib' to the link command line in your makefile.

Configuring Your Firewall

     The firewall between your server and the Internet should be
     configured as follows:

          - Deny all incoming traffic from the Internet to your
          server
          - Permit incoming traffic from all clients to TCP port
          135 (and UDP port 135, if necessary) on your server
          - Permit incoming traffic from all clients to the TCP
          ports (and UDP ports, if necessary) on your server in
          the Ports range(s) specified above
          - If you are using callbacks: Permit incoming traffic
          on all ports where the TCP connection was initiated by
          your server


