Provide the access to 3rd party in internal network? Needs some Design suggestions?

[Mubasher Sultan - 2x CCIE # 20149 (R&S | Sec)]

Hi Folks,

I have to provide the access to 3rd party in the internal network to repair their server...

How can we provide them the access? Needs some input as design perspective and working solution?

Thanks,

Regards,

MS

[Marvin Rhoads]

For network-based access it depends. For instance, do you have an existing ASA firewall with remote access VPN?

If so, you can create a userid just for their staff to log in which is filtered via an ACL to only be able to access the address of the server.

You can accomplish similar with an IOS-based router and the legacy Cisco IPsec client.

Another option is to simply log onto the server yourself and then let them control the keyboard and mouse via a WebEx / TeamViewer / join.me / etc. type of session.

[Mubasher Sultan - 2x CCIE # 20149 (R&S | Sec)]

Actually, need a more secure solution.

You are right to use a Remote Access VPN...I also presented a solution with Remote Access VPN with a Jump Server e.g., A remote User session will be land on jump server in one of the server in DMZ and then RDP to the intended server.... Here, i am wondering that how can we stop this user from being going forward? That Server will have access to internal network. How can we stop the user if he do any malicious activity? Any network based solution...

Any ideas or comments...

Thanks,

[Marvin Rhoads]

Well I would argue that if you distrust the remote user so much that you should seriously reconsider letting them work on equipment on your network at all.. Actually in that case, "watching" them during a remote desktop sharing session is actually a more secure solution as you can validate the actions they are taken are limited to those necessary to perform the tasks at hand. When I have had to work on systems in environments that were required to be secure to meet regulatory requirements, I was required to provide a step-by-step list of activities before hand and my performance of only those activities and verification of the expected outcome was done by staff of the client I was supporting.

If you want a purely network-based solution then put a temporary access list on the server's default gateway for the period during which the remote maintenance is ongoing allowing it to communicate only to/from the remote access VPN gateway.

A more sustainable setup would be to host the server in a DMZ on a private VLAN with an access list (or default setting) on the DMZ interface of the firewall that prohibits the server from initiating communication to the inside network.