>This feature has been requested by many customers. The inability of
>DCOM to be used through HTTP-passing firewalls is considered by some to
>significantly reduce its utility as an Internet technology, since they
>want to use DCOM to talk directly between the COM objects making up the
>ActiveX web browser and the objects extending the ActiveX web server.
>Only admins can configure an NT server to use a new DCOM transport, so
>use of HTTP as a DCOM transport can be controlled by security-conscious
>users.
Exchange Server uses RPC, but allows for the Information Store and
Directory Service to be statically assigned port numbers that the
portmapper returns to a requesting client, why? So those ports can have
explicitly defined ACLs on port-based Firewalls. This is how the
industry has been doing it for years, and it works very well thank you
very much. Through MSX's mechanisms, full NT authentication is possible
and the client functions normally. So don't go telling me its what the
customers want or need, that's just marketing fluff. You wanna run
something over HTTP its typically because customers are not going to be
able to get their Firewall admins to open new and unknown ports for your
innovation, so you stuff it down HTTP where Firewall admins typically
have already given them access, hence your statement about "punching
holes through Firewalls", why else would you have said that?
Both the ActiveX web browser objects and the Denali objects can talk on
any port they want, so its not the technology that's saying it has to be
over HTTP.
As for security-conscious users being able to control the use of HTTP as
a DCOM transport, if that were true, then Firewalls would be virtually
unnecessary because we'd all be nice and never do anything we weren't
told we could do. We'd also never install something on our machines that
we hadn't completely tested and understood ourselves. Do you think that
every NT admin in a large organization is going to fully understand the
security implications of every aspect of every product they install on
their NT Servers? The question isn't whether or not they are supposed to
do it or not, its whether a Firewall administrator has some method to
>prevent it in the event that it does happen.
>
>This is a chimera -- there is no way you can hope to restrict the use of
>HTTP by these schemes such that malicious people can't use it
>maliciously. ASCII text is just source code for script engine, right?
Yes, which is why people scrutinize products to determine if they are
well written or not. If I can send a script through to a browser and get
it to do something, say, like opening a Word document *without* alerting
a user that its potentially dangerous, alarm bells start ringing
throughout the industry, or hadn't you noticed? And what are you
suggesting here, that there is no way to secure a site from malicious
people, and therefore we shouldn't try? Are you in the insurance
business?
>
>It is impossible in principle to write filters that can recognize all
>"bad code/data" coming through on a given port. If code can be place on
>the inside of the firewall (or a bad person can get access to the
>network to turn sent data into code, either directly or with some kind
>of VM/interpreter), then any data coming through can be malicious,
>period.
Which is why most Firewall'd sites don't allow inbound FTP or
connection-less protocols like UDP. Your statement is correct, but its
also precisely why Firewalls are built, to prevent such actions, and as
I said earlier, is why people look closely at each new feature for the
browsers to determine if an exploit exists. I've said before that
ActiveX does not provide any security for the user that can be relied
on, but I also said that something would have to be done to allow people
to control its use.
>I don't understand what this comment means. DCOM does not pass
>"instructions" in the sense that you seem to mean over the wire, it
>passes a packet with an method number and (typically) an opaque blob of
>marshaled that can't do anything unless there is, on the other side of
>the connection, a complex set of machinery (the DCOM runtime) as well as
>an instantiated object and stub corresponding to the requested method
>(and capable of unmarshaling the data, if any). It's just an
>object-enhanced RPC system, no different from a security perspective
>than ONC or DCE RPC. Unlike "mobile code" technology, there is no way
>in the base DCOM system to pass arbitrary instructions over the network
>that will blindly be executed by the runtime on the remote system.
>There must be corresponding code on the remote system that is ready and
>willing to perform the requested operations.
The comment did not mean what you think it did. The instructions I was
referring to were instructions to objects within the DCOM runtime, and
if my marketing information is correct, DCOM is going to become a
cornerstone of future versions of NT. How does a site administrator,
responsible for security, control LAN administrators throughout the
organization who each have administrative access to their machines? Are
you buying MissionCritical software to give us a finer granularity of
administrative control over NT's user model? If not, then every
organization typically allows their NT admins to do pretty much what
they want, and then use audits and Firewall logs to determine if people
are complying or not. If DCOM is running over HTTP, what information am
I getting as a site administrator to tell me what my LAN admins are
doing? The real world says that by far the majority of Firewall
administrators have no access to NT Event logs, nor would they know what
to do with them if they did.
If each product that used DCOM over IP, at least from Microsoft, were to
use its own port as Exchange does, what would be the problem with this?
>HTTP itself is essentially an RPC system. It encodes requests and
>replies, allows arbitrary commands and data to be sent both ways, etc.
>(It just doesn't do automatic data marshaling.) If you have malicious
>or buggy code on either or both sides of a "standard" (whatever that is)
>HTTP connection, then a malicious person may be able to do nasty things.
> Running DCOM over HTTP adds absolutely zero new security risks -- an
>RPC system running over an RPC system is not less secure than just an
>RPC system alone.
I didn't say it added a *new* security risk, I said it shouldn't be done
and Microsoft should not promote it. Running RPC over HTTP is just as
bad, and today, no NT product use RPC over HTTP, so why should DCOM
allow it? HTTP is not a transport protocol, IP is, and your statement
proves that you see HTTP as a transport protocol. HTTP doesn't have any
mechanisms to deal with differentiating traffic types as IP does.
>Fundamental fact is that port-base firewalls are of limited utility for
>creating a truly secure environment. The main reason is that it is
>impossible in principle to prevent people from using assigned ports for
>a completely different purpose. Let's suppose you decide to let only
>HTTP traffic through and, further, suppose you somehow mesmerize the
>vendors into not using HTTP for anything "illegitimate" other than
>"true" HTTP (whatever that means -- it whole point of these protocols is
>extensibility). So what -- a malicious person on the inside of the
>firewall will simply open the HTTP port with an entirely different
>program, and send/receive all the nasty things in the world to their
>accomplices outside. Worse yet, the nasty person sends their innocent
>friend within the organization a nice little "chess program" on a floppy
>that does everything the nasty person needs surreptitiously.
Fundamental fact is that port-based Firewalls are typically only one
part of a Firewall solution, but their value should be ignored as you
suggest. Your scenarios are all true, I could use HTTP for anything,
that's not my fear. If a port-based firewall directs HTTP traffic to a
proxy server, then its the proxy servers job to determine what the
traffic is doing and send or reject appropriately. The more stuff we
cram down HTTP and call acceptable, the harder it will be to filter out
the unacceptable stuff. I realize that you say this is impossible and so
we shouldn't try, but far too many CEO's disagree with you for us to
ignore. So, as a customer, I say that vendors should pay heed to the
needs of Firewall administrators and make an effort to assist, not
destroy, the tools we have. You obviously disagree and so I ask, what do
you think we should do?
>
>(True, if you have a secure environment where only secure operating
>systems are allowed to connect to the network, and you configure those
>operating systems to allow only admins to installed executable code, and
>you don't allow your users to be admins of their machines, and you test
>all the executable code you install carefully to make sure it doesn't
>have any backdoors, then you have a fighting chance. But how many
>organizations don't allow DOS/Windows/Mac on their networks? And how
>many don't allow NT and UNIX users to admin their own machines?)
Again, you're restating your point that hackers will always get in no
matter what Firewall admins do.
>
>Port-based firewalls prevent some bad behavior by UNSOPHISTICATED users
>and hackers. Like car door locks, they're very worthwhile for that
>reason. But the a pro can get through your port firewall as fast has a
>pro can get into your car with a slim-jim.
They typically act as the front line in a Firewall solution, so are you
saying that they should be tossed? If you have a car alarm then don't
lock your doors, it will only cause more damage if their locked? Look,
your limiting your remark to port-based Firewalls does not solve the
issue that proxy servers have with trying to sort out and allow ACLs to
be placed on the different data traversing HTTP. I'd be saying the same
thing if you build an NT Administration tool that used RPC over HTTP, so
its not a DCOM thing here.
Cheers,
Russ
>
Follow-Ups:
|
|
