RE: Q154596

[Russ <Russ.Cooper () rc on ca>]

-----BEGIN PGP SIGNED MESSAGE-----

The info on fixing port ranges for RPC so Firewalls can be configured,
um, not to block them, is interesting and no doubt useful in
constructing a more secure NT box...

however...;-]

There are a couple of caveats that shouldn't be overlooked.

1. If you're going to use an RPC service which dynamically assigns a
port, you've got to talk to an End Point Mapper first. In the case of
NT up to 4.0, that's via TCP135, so that has to be opened (in Win2000,
it may also use TCP445). There have been denial of service attacks
against certain versions of the RPC EPM.

2. So, now you can talk to the EPM, got assigned a port within your
defined range, so you figure...bingo, I'll just start talking. Not
exactly. Although any RPC service *could* do authentication itself,
most of the ones supplied with NT (DHCP Manager, DNS Manager, etc...)
rely on existing credentials. So if you haven't authenticated with the
box before you try and use the RPC service, it ain't going to talk to
you.

And how, pray tell, are you going to authenticate?? NT relies on that
authentication, typically, coming via...drum roll...you guessed it,
TCP139...;-[

3. Now there are some notable exceptions, of course. A common one is
Outlook and Exchange Server using the "Workgroups" configuration
(which is just an RPC implementation as opposed to POP or IMAP).
Exchange Server can be configured to statically assign the same ports
for its two entry points (the Information Store and the Directory
Service). More importantly, its able to authenticate you over those
ports. So while it still requires you to have the EPM open (be nice if
you could tell the client what ports it will use ahead of time so you
didn't have to leave the EPM open, but hey, it was hard enough to get
them to give us the ability to assign the ports statically in the
first place...but that's another story).

4. So one might be able to do those RPC things that don't support
authentication directly if one has pre-established authentication via
something like Outlook...or so the theory goes (haven't tested this
myself).

All wonderful stuff, isn't it.

After all this, you really need to remember that the channels aren't
likely to be secure despite them being on a "defined" set of ports.
Outlook supports encryption between the Exchange Server and the client
software, but DNS Manager doesn't, nor does DHCP Manager, or most any
other RPC service.

So in the end, you can punch a big hole through your FW for RPC, or
you can punch a series of smaller holes (you can use that registry
entry supplied in the earlier message to define several ranges), or
you can punch one hole (um, I think they call that PPTP). One thing
these methods have in common (apart from the fact they're all
regarding RPC), is that they're all HOLES!...;-]

I should also make a minor point of referring you to a recent
disclosure on NTBugtraq that is currently leading to, possibly,
hundreds of exploit tools targeting RPC. Have a look at
<http://ntbugtraq.ntadvice.com/rpcwoe.asp>.

If you'll let me, I'll present my meager list of demands.

a) All RPC services should permit themselves to be restricted to a
single port (or several single ports for defined purposes).

b) The contents of the traffic should be sufficiently documented so a
proxy can be developed for them for whatever given Firewall.

c) They should support, if not default to, encrypted traffic.

d) They should support authentication directly.

e) They should support the non-use of the EPM.

f) It should be possible to disable their use for LOCAL (ever wonder
why you can't do much on an NT box if you try and get rid of the RPC
service?)

g) They should be "permissionable", including whether or not, and to
whom, the EPM will report their presence.

I could probably go on, but its late and I want to see if Gary Cooper
is going to dance in Roberta.

Cheers,
Russ - NTBugtraq Editor
http://ntbugtraq.ntadvice.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2

iQCVAwUBOCeqihBh2Kw/l7p5AQHL6wQAxQp4PECMoojMIJkQ4DdlW4bTKhm/bZyP
4QEyqTEp67Yui2YqRY3KavcsLISXBn8NpIi9M6jdEVB60dZ51SR9nN10A1RflyvN
eLHFbF2Ao2rNkS9nBoS2APKEdG6otQfpYTXW9fJUSrh7NbLbiD3bBEJtudtGeAOC
sN42K+sBuAM=
=MgYD
-----END PGP SIGNATURE-----