Conference noted::seal

1829.0. "Firewalling NT Exchange - Feedback Please!" by GEC013::ZIGLER (Tom Zigler DTN 435-7979) Mon Mar 03 1997 10:19

Hello,
    
    After doing a sniffer analysis of Exchange Client to Exchange Server
    communication, I discovered that their RPC protocol exchange is
    compatible with a Start-of-Connection packet filtering model.
    
    If you determine that a Start-of-Connection packet filter is an
    "acceptable level of risk" for your firewall situation, then you can
    enable an Exchange Client(s) to talk to an Exchange Server(s) through
    a firewall by following the procedure below.  Note that this solution
    approach can be used with or without tunneling!
    
    Microsoft has requested that I submit the following "Firewalling
    Exchange" solution procedure to them to add to their database. 
    However, I thought that it would be prudent to first post it to this
    conference for a critique before I submit it to Microsoft.
    
    For this posting, I have included the exact AltaVista SYN/ACK bit
    manipulation syntax that works for us.  However, in the
    document submission to Microsoft, I shall make the syntax rules more
    generic.
    
    Please provide me with feedback!
    
    				\Thanks in Advance
    
    
    
    =======================================================================
    
    
			Firewalling Exchange
    			--------------------
    
    
    The purpose of this document is to explain an alternative solution
    approach for enabling a Microsoft Exchange client to communicate with
    an Exchange server through a firewall.  

    Procedure:

    Determine if your firewall packet screening rules allow you to
    manipulate the ACK and SYN bits--for example, by letting you include
    these keywords in a packet filtering rule.  If so, then place the
    following three lines as the last rules in your screend.conf:

    
    from host EXCH_NTS to host EXCH_NTC tcp port any flags syn flags-not
    ack reject log;
    from host EXCH_NTS to host EXCH_NTC tcp port any accept;
    from host EXCH_NTC to host EXCH_NTS tcp port any accept;

    (Note: The EXCH_NTS is outside the firewall and EXCH_NTC is inside the
    firewall.  Replace the EXCH_NTS and EXCH_NTC with their respective IP
    addresses.)

    
    The above three lines constitute a Start-of-Connection packet filter
    that allows an internal Exchange Client to connect to an external
    Exchange Server, but prevents the external Exchange Server from
    initiating a connection inbound to the Exchange client.  Exchange
    Client attackers cannot subvert this approach simply by turning on the
    ACK bit in their start-of-connection packets, because the absence of
    the ACK bit is what identifies these packets as Start-of-Connection
    packets.  However,  be aware that a Start-of-Connection filter can be
    defeated by more sophisticated TCP/IP sequence number attacks.  Thus,
    only the parties responsible for security can decide if this technique
    constitutes an acceptable level of risk.

    Advantages:

    1.. Direct manipulation of the SYN and ACK bits is provided by most
    commercial firewall vendors in their packet filtering implementations.

    2. No changes to either the Exchange Server or Exchange Client (as
    specified in the Microsoft document, "Microsoft Exchange Server
    Internet Connectivity" -
    http://www.microsoft.com/Exchange/techsupp/exchsec.htm) are required. 
    Thus, the port mapper on the Exchange Server can continue to allocate
    random ports for both the Information and Directory Store without
    modifications to the registry.
  
    Disadvantages:

    1. A Start-of-Connection packet filtering mechanism may not necessarily
    constitute an acceptable level of risk.

    2. The Start-of-Connection model may not be compatible with future
    releases of Microsoft Exchange.

    Summary:

    Enabling NT Client/Server TCP/IP communication through a firewall with
    an acceptable level of risk as an objective is greatly enhanced when
    TCP/IP application protocol exchanges are firewall compatible.

    I would encourage Microsoft to keep this objective in mind for future
    releases of Microsoft Exchange so that we can continue to utilize the
    above firewalling technique!

I would strongly suggest that you point out that you are
opening up far more communication between the client and
the server than just Exchange.  You are opening up all
tcp communication in the one direction, I think.

You could (and probably should) improve on that, in that
many (all?) of the places that you have "tcp port any"
could have "tcp port-not reserved", I think.

Also, I guess somewhere the write-up should point out
that this arrangement goes against the whole philosophy
of an application proxy firewall, because it requires
direct network-level communication across the firewall,
along with all the routing and security implications
that this brings with it.

T

    re: .1
    
    Excellent observations - thanks for the feedback!

Below is how I setup a client so their Exchange 
client can get their mail from the Exchange server 
through the firewall.  Note the following note at the
bottom about the ports 3000 and 3001.  Below are
the entries from the /etc/screend.conf.

NOTE:  10.40.254.22 is a test host.  You could replace the IP 
       address with any.
       10.40.253.82 is the exchange server	
       

#  Exchange  
#
from host 10.40.254.22 to host 10.40.253.82 tcp port 135 accept log;
from host 10.40.254.22 to host 10.40.253.82 tcp port 139 accept log;
from host 10.40.254.22 to host 10.40.253.82 tcp port 3001 accept log;
from host 10.40.254.22 to host 10.40.253.82 tcp port 3002 accept log;
#
#  Exchange  
#
from host 10.40.253.82 to host 10.40.254.22 tcp port-not reserved accept log;
from host 10.40.253.82 to host 10.40.254.22 tcp port 135 accept log;
from host 10.40.253.82 to host 10.40.254.22 tcp port 139 accept log;
from host 10.40.253.82 to host 10.40.254.22 tcp port 3001 accept log;
from host 10.40.253.82 to host 10.40.254.22 tcp port 3002 accept log;
#

This following note was taken from TechNet:

Since enabling client access from the Internet 
requires that you enable RPC access to the server 
that holds their mailboxes, it is slightly riskier 
than just allowing SMTP access through a dedicated 
Internet mail server. A mistake in configuration 
that lets an attacker gain access to the server 
could compromise mailbox and public folder contents, 
among other things.
By default, Microsoft Exchange Server dynamically 
assigns TCP/IP port numbers to be used for RPCs to 
the Microsoft Exchange Server directory or information 
store. Clients always connect to port 135, which is 
the Windows NT RPC End-Point Mapper service. This 
service tells the client which dynamic port numbers 
to use to access the Microsoft Exchange Server directory 
and information store.
If you are using a packet filter, you can force Microsoft 
Exchange Server to use a fixed port for RPC by creating 
a REG_DWORD registry value called TCP/IP port. This 
value must be a port number which you also configure 
in your packet filter. For the directory, the value 
should be under the following key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDS\Parameters\T
P/IP port

For the information store, the value should be under 
the key below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSy
tem\TCP/IP port

You must configure your packet filter to allow TCP 
connections to these ports plus port 135 (for the RPC 
End-Point Mapper service) on the Microsoft Exchange 
Server-based server.


[Posted by WWW Notes gateway]