I have gotten a question from my colleagues that I wanted to put out to the community to get some response. When using tunnels from the main hub to a dmz hub where the dmz hub is the server and the main hub's the client and sets up the tunnel. Is it then possible for robots connected to the dmz hub to initialize traffic through this tunnel and execute code on the main hub or on robots connected to the main hub?
And also, what would be, in your opinion, the safest way to connect the dmz hub to the main hub? Simply no tunnel and one way get-queues on the main hub and attach queues on the dmz hub?
What you describe in your first paragraph should indeed be possible. As long as a communication path (e.g. tunnel) exists, then you should have no trouble. The UIM address (/Domain/hub/robot/probe) is automatically translated by hubs into network addresses and the hub can distinguish between tunneled and non-tunneled connections and route the traffic appropriately.
As far as connecting your DMZ hub to the main hub -- it's up to you, really. If they're in the same LAN then a tunnel is not necessary (and will in fact create additional overhead), you can either use broadcast or a "static hub" connection to connect the DMZ and primary hubs. If security is a concern, it is certainly possible to create a tunnel here for an additional layer of SSL protection but most users do not find this necessary since the traffic will not be leaving the local network.
Thanks for a quick response. Actually what I in no way want to be possible is for robots connected to the DMZ hub to talk through the UIM solution to the robots connected to the MAIN hub. But using tunnels this is enabled per default? I find that very questionable from a security point of view.
- Kjetil Raasholm
I think this could be pretty difficult to accomplish; this is essentially intentional, by-design behavior. In a correctly configured and fully operational system it is assumed that any robot/probe/hub can reach any other robot/probe/hub.
If you're looking to avoid having the robots *directly* talk to each other you could perhaps accomplish this via a firewall - but if a robot can talk to its hub, and its hub can talk to another hub, and that other hub can talk to its robots... then generally speaking those robots will be able to talk to each other (by way of the hubs.)
It is helpful to think of a UIM domain as a "security domain" - all elements within a single domain are assumed to be "safe" to communicate with each other because they're in the same domain.
Account Contact users can be configured to be able to access only certain elements by Origin, but I don't think there's a good way to prevent robots from one hub from talking to robots from another hub -- at least not without affecting the hubs' ability to communicate with each other, which of course has implications for configuration, queues and message routing, etc.
I think for our case that is something we need to implement. We have several security zone's in our environment as well as a large internet presence. As it stands now both systems in the DMZ zones and systems in different secure zones behind multiple FW's are monitored by the same UIM installation. This is set up in a star fashion where the main hub is talking to each of the remote hubs. Our main priority is to get alarm and QoS data to the main hub from the robots. We do not often move robots from one hub to another.
In order to block this robot to robot communication between security zones would it be enough to set up queues on the remote hubs that the main hub will connect to and drain?
I think we should perhaps back up a bit--
Under normal circumstances, robots will not generally directly talk to each other. QoS/alarms/etc won't "pass through" different robots. Queues control the flow of messages from hub to hub; there is not any reason why a robot would normally 'need to' talk directly to another robot. Also, it would be relatively difficult to arbitrarily execute "any code" on the UIM environment unless you were already authenticated to the environment (e.g. you know the UIM administrator password). If there are firewalls in between, then robots would not be able to directly talk to each other point-to-point.
But, for an example of how the UIM routing works, try the following in your UIM environment:
1. Pick any two hubs which are separated by one or more tunnels.
2. choose any controller probe on a robot under hub #1 and highlight it in IM
3. press CTRL+P for the probe utility and run the "nametoip" callback.
4. provide the full UIM address of any controller probe under the second hub (e.g. /Domain/hub2/robotname/controller) and click the green 'arrow' button.
5. An IP:port will be returned, which is most likely the IP address of the hub you're on, or the nearest tunnel hub, and a port in the 48*** range.
Anything connecting to the given IP:port in this result will be "proxied across" the tunnel(s) and ultimately delivered to the UIM address you've given.
So in this way, any robot could interact with any other robot -- but only in the context of UIM, e.g. executing callbacks and so forth. (You could, for example, put a LUA script on a NAS on Hub A that runs a get_info callback vs. a robot under Hub C and this would work fine as long as you provided the appropriate full UIM address of the robot.)
Thanks for your answer, its getting late here in this part of the world but I'll try your suggestion tomorrow morning and post back the results.
Thanks a lot again for your time. We do get challenged with security issues so it is important for us to be aware of the risks and possibilities in the products we use.
Of course if you should experience any kind of problem, open a case with support.