70 lines
2.9 KiB
Plaintext
70 lines
2.9 KiB
Plaintext
At 11:00 AM 6/17/98 -0400, Don Kendrick wrote:
|
|
>Greetings,
|
|
>
|
|
>I'm being rushed into a project that will involve putting a component on my
|
|
>NT web server that will talk to various MS boxes internally. They are
|
|
>proposing to use DCOM. A quick look at DCOM shows me that they are basically
|
|
>doing RPC stuff and of course I'm not a real fan of RPC.
|
|
|
|
This probably deserves to have a book written on it (by someone other than
|
|
myself).
|
|
|
|
Last time I checked about DCOM, there were several issues that would make
|
|
me a little hesitant to use DCOM over public networks, for several reasons:
|
|
|
|
1. As you pointed out, DCOM uses MSRPC. RPC is pretty complicated; it's
|
|
also pretty new. This suggests that it's not well understood in general.
|
|
MSRPC can use a host of transports: names pipes, TCP, and Netbios over TCP.
|
|
Given that all the default services that ship in NT use named pipes, and
|
|
that named pipes use SMB, you have to open port 139 to allow your DCOM
|
|
stuff in from your web server. Having 139 open allows access in to a
|
|
number of services (like file and print, for example).
|
|
|
|
If you really want to do this, it's a good idea to specify TCP as the
|
|
transport and only punch holes in the firewall for specific services that
|
|
are needed. Also, it's better (from a security point of view) if the
|
|
developer specified static endpoints on the server - this way the client
|
|
doesn't need to connect to port 135. However, if the developer wasn't
|
|
security-aware, you may be stuck with dynamic endpoints. In this case,
|
|
your server's exposure will be much worse, and your firewall administrator
|
|
will find herself living in interesting times.
|
|
|
|
2. MSRPC currently only supports NTLM authentication, which is neither
|
|
amazingly strong or amazingly flexible. Make sure that both client and
|
|
server are running NT 4.0 Service pack 3: that way if you have to use named
|
|
pipes you can use the SMB message signing feature for integrity checking.
|
|
Again, if you want to use TCP for transport, the developer has to have
|
|
added support for fully encrypted RPC, or your sessions will be vulnerable
|
|
to insertion or hijacking attacks.
|
|
|
|
Overall, NT 5.0 is likely to be a win. Kerberos supports mutual
|
|
authentication and proxying of user credentials. You may be better off
|
|
stalling installation until 5.0 is out.
|
|
|
|
3. Don't have any hard evidence of this, but there's reason to suspect that
|
|
interesting RPC packets might cause Blue Screen Of Death. Opening up too
|
|
much through the firewall can potentially provide an avenue for DoS attacks.
|
|
|
|
Note that these are my opinion's not my employer's, and I might be nuts anyway.
|
|
|
|
- Ted
|
|
|
|
|
|
|
|
|
|
Microsoft's MSRPC uses TCP port 135 and requires high ports 1024-65535 to be open. An example of the conduit command statements are:
|
|
|
|
conduit permit tcp host 204.31.17.1 eq 135 any
|
|
conduit permit tcp host 204.31.17.1 range 1024 65535 any
|
|
|
|
|
|
|
|
/sbin/ipfwadm -I -a accept -c -W ppp0 -P tcp -S 0.0.0.0/0 135 -D 192.168.1.2
|
|
/sbin/ipfwadm -I -a accept -c -W ppp0 -P tcp -S 0.0.0.0/0 1024:65535 -D 192.168.1.2
|
|
|
|
|
|
|
|
|
|
|
|
|