Brian Steele writes:
> Not really a firewall issue - more of a security issue, but as there are a
> few security experts on the list..:-)
>
> Situation: Company consisting of two independently operating business units,
> let's say A and B. The operations of each unit is governed by its own
> internal security procedures, A's being more stringent than B's. The two
> business units are connected via a WAN.
>
> B want to install a software package in A's LAN to meet a "critical business
> requirement". However:
>
> 1. pcAnywhere has to be installed on the server running the
> package to allow staff from B to remote control the
> server (a Windows NT4 box, btw) when it's installed on
> A's LAN.
Badness Number 1: Allowing someone other than an employee to have
administrative control of a internal 'trusted' resource is a Bad Thing.
>
> 2. The software on the server will be interfacing with a critical
> system on A's LAN. And also with Internet users (via a
> firewall - port 80 only).
Badness Number 2: Letting a resource, which is not in your control,
interface with a critical system is another Bad Thing. Even if we
discount the possibility of an intentional attack, we must consider
what might happen if an error is made. A Company B admin may make
administrative changes that blow away your critical resource, since
they likely don't have a deep understanding of your network and
configuration.
Badness Number 3: I might be misunderstanding this, but it sounds like
the NT box has direct access to critical resources, and attackers have
direct access to the box via port 80. If the http deamon gets
compromised, will attackers have access to your resources?
> 3. The software requires that the Administrator account be
> left logged on on the server's console.
Badness Number 4: This is bad and evil. I don't think anyone needs to
explain it :-)
> 4. The password for remote access via pcAnywhere (and
> thus the Administrator password) will be known to several
> persons in B.
Badness Number 5: The greater the number of people who know the
password, the greater the likelyhood that one of them is clueless, and
just might break something in your network
> Now, if you were the sysadmin for A's LAN, would you consider this
> arrangement secure enough for internal business use? If not, are there any
> steps that you'd take to minimize the risk to your LAN? Or would you be
> raising the strongest protests to ensure such a system is not deployed on
> your LAN because of the security threat that it poses?
First fight it. From the looks of things you've got a losing hand.
If sopmething has to be put in place, try to design a better solution.
Like:
B's Box goes into a DMZ. They can maintain control, port 80 can be
opened. Consider the box untrusted.
Use a message broker between that DMZ and the corporate network. This
means that B's Box (and by extention those who crack said box), never
talks directly to your network. The best it can do is send a message
requesting information.
In this example, a piece of software on B's Box would broadcast a
packet requestion resources from A's critical system. Listening on
that subnet (though itself not directly addressable) sits a message
router. It sees the broadcast, inspects t and passes it into the
trusted network. Inside, a second message router gets it, and
forewards it to your critical resource, which sends the data out to
the untrusted system.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
