We are in the process of setting up DCOM through a Gauntlet, by using Plug
proxies. Guantlet allows you to turn-off the address translation for these
proxies.
Like Craig said, for DCOM communications to be secure through a firewall one
really needs a custom proxy. Without a custom proxy, the whole idea of
opening up a large number of ports through your firewall makes me very
concerned.
Rama Kant
--- On Tue, 18 Nov 1997 12:33:53 -0500 (EST) "Craig I. Hagan"
<hagan @
cih .
com> wrote:
> > We are trying to determine which firewall products we can run our
> > Microsoft DCOM-based application through.
>
> right now, i'd hazard that your best bet would be a custom rolled dcom
> proxy. (heck, i've been looking for something that handles DCE/RPC and/or
> MSRPC -- aren't they the same on the wire?). Making a transparent version
> of the above would likely solve your problem.
>
> >
> > The challenges in sending DCOM through a firewall are that 1) DCOM
> > dynamically assigns port numbers to server processes, so clients connect
> > to different ports at different times, and 2) DCOM server writes its own
> > raw IP address in its outbound packets, and the client must send its
> > requests to that IP address, not the IP address of a proxy. We can run
>
> a smart proxy would be able to inspect the packet and alter the ip address
> and any relevant checksums. the hard part would be writing it.
>
> > DCOM through a packet filter if we open an appropriate range of ports
> > and tell DCOM server to limit its dynamic port assignments to those
> > ports (details at http://www.wam.umd.edu/~mikenel/dcom/dcomfw.htm ).
> > Because of the raw IP addresses in the packets, though, any firewall
> > that insists on doing address translation prevents DCOM from going
> > through.
>
> risk analysis: what is the risk of openning your DCOM ports
> to either the world or to the specific site? perhaps
> a reasonable method might be to do the following:
>
> inside DCOM host ---> packetfilter --> outside DCOM host -...- remote
DCOMhost
>
> the idea is that inside sends its requests to a forwarding agent
> (outside), which handles the actual conversation. then the pfilt can allow
> inside to talk with outside and vice versa, but, you aren't allowing
> anyone else to talk to inside. you can then construct your DCOM
> forwarding server on outside to handle things like access control, etc for
> inside.
>
> >
>
> > Am I right in thinking that an application proxy on a firewall will
> > *always* involve address translation? Some firewalls have 'generic'
>
> I'm not sure how address translation follows from a proxy server. They
> technically are very different animals. The idea of a proxy firewall is
> that the application proxies UNDERSTAND the application being proxied, so
> they can properly inspect the dataflow to make sure that it is safe. they
> also can alter the dataflow so that you inside machine can talk to an
> outside machine and vice-versa (if permitted) without problem.
>
> The trick is that you will need a proxy that specifically understands
> your protocol if it is to be handled in any sort of secure/reliable
> manner if it is to be proxied effectively.
>
> -- craig
>
>
-----------------------------------------------------------------------------
--
> Craig I. Hagan "It's a small world, but I wouldn't want to back it up"
> hagan(at)cih.com "True hackers don't die, their ttl expires"
> "It takes a village to raise an idiot, but an idiot can raze a
village"
>
> Stop the spread of spam, use a sendmail condom!
> http://www.cih.com/~hagan/smtpd-hacks
>
>
>
---------------End of Original Message-----------------
--------------------------------------------------------
E-mail: kant @
adeptech .
com
Date: 11/21/97
Time: 08:38:31
--------------------------------------------------------
References:
|
|
