Secure Remote Access – Configuring and Session Recording
In today’s complex network and IT environments more and more people need to gain access to the corporate servers, applications, databases and management tools. Secure Remote Access allow secure access to corporate servers across the Internet, however can you see what these remote users are doing? While trying to minimize the human intervention with these critical services, the IT manager needs to consider how to allow the remote access and management of these services, who to allow access, and how to secure, audit and record this access and actions that are performed on the servers. As if not an issue on its own, lowering costs and maintenance fees has moved many large and medium corporations to using hired external experts or outsourcing services while trying to minimize their own internal IT department. Furthermore, with today’s compliance requirements, companies need to be able to proactively monitor, audit and record these remote access sessions. This poses an additional issue on the management scenarios, and now the IT manager has an additional concern on their mind.
In this article I will cover some of the most common remote access and management scenarios available, and I will try to show you what the benefits and drawbacks (or challenges) are for each scenario. I would also like to use the opportunity to tell you a bit about ObserveIT – A company which I have recently began working for (read more about my new job at my “My new job – VP Technologies for ObserveIT – Enterprise Scale Window Server Session Recording” article).
ObserveIT is a software solution that is designed from the ground up to be deployed in multi-server enterprise environments and provides visibility into all user activity such as Microsoft Terminal Services, Citrix (ICA) – including published applications, Remote Desktop (RDP), PC-Anywhere, VNC and NetOP.
Secure Remote Access recording with ObserveIT.
After going through the available options, I will describe some of the security issues that the IT manager faces when allowing remote access and management, especially focusing on controlling what these remote experts or vendors did while connected to the corporate servers, and on the ability to audit and record their actions.
Remote management options
These are some of the remote access and management options available today. Some of these configurations are more complex to set up and maintain, some are most suited for small environments, some are scale better to large enterprises.
Management on the servers – Internal management consists of IT professionals that use server-based management tools that are installed as part of the installation of the various infrastructure components that they need to manage. For example, managing an Exchange server can be done on the Exchange server itself by using the built-in management tools. Other examples include Active Directory, Virtualization software, monitoring software and database servers. All of these have build-in management tools that come as a part of their installation process.
The benefit of using this approach is the fact that the management tools are easily installed on the server.
However, the downside of this setup is the fact that you need to gain access to the server in order to manage it, and this requires physical access to the server room, not to mention the low temperatures and the lack of a suitable work space.
This approach does not scale well, the more servers you have, the more issues you will have managing them. Needless to say, not many enterprises use this approach, and it is only suited for small businesses.
Secure Remote management of the servers from the local area network via RDP – This implementation is most often used when one needs to perform a specific management task on a server running Windows operating systems. The management tools are already installed on the server (see above topic), and thus one only needs to remote access the server via Terminal services or RDP. Configuring the servers to allow RDP connections is easy and can be done either manually, or through an automation process like Group Policy or logon scripts. The configuration of RDP does not require additional licenses, and allows the connection of up to 2 separate sessions, plus one session to the console.
The benefit of using such an approach is the fact that you get all the benefits of the above scenario, plus you drop the need to actually gain physical access to the server. You can continue to sit in the comfort of your office, while remote-connecting to the servers and performing your tasks.
The downside of this approach is the fact that in most cases, the user connecting to Terminal services/RDP on the server needs to get specific permissions for the connection, and this is translated, in some cases, to adding him or her to the local admins group. Furthermore, allowing remote connections to the server might be considered as a less secure approach because of the fact that you are no longer able to physically restrict the access to the machine, and are practically allowing any machine on the LAN to connect to the servers.
This approach scales well within the corporate network. All you need is one management station with shortcuts to your servers’ RDP sessions.
Some of the freeware tools I use to manage my Terminal services/RDP sessions are:
Note that the Windows Server 2003 Administration Tools Pack and the Windows Vista/2008 administration tools include the Remote Desktops utility which lets you organize your RDP connections more effectively than creating single shortcuts to servers.
Remote management of the servers via MMC snap-ins – Many services and software that are installed on servers use MMC-based snap-ins to manage their settings. This is true for most Microsoft-based services and servers such as Active Directory, DHCP, DNS and so on. Some services or server applications require you to install their management tools on the remote machine that you’ll be using as your management workstation. This is true for servers such as Exchange and others.
One benefit of using this approach is the fact that the manager, expert or administrator that uses these tools only gains access to whatever they need to do the work done, and not to the entire desktop, as is the case with Terminal services/RDP connections. However, this is only true for internal management scenarios. As you’ll soon see, major security concerns prevent external access in this manner.
A major drawback of this approach is the fact that many management tools use different communication methods with their servers. Each tool might use different ports or authentication methods, and because of that, passing these tools through corporate firewalls might be more difficult that you think.
One more security concern when using this approach is the local logon issue. When using MMC snap-ins you need to either logon as a member of the right administrative group, or use RUNAS on the management tools. Both options might pose a security threat is the logged on user caches their credentials on the workstation. Hackers can easily gain access to this information, and use it to compromise your corporate network.
Another threatening issue with using this approach is the fact that unless you have full control of the management workstations, you do not know what types of threats these machines bring it when connecting to your corporate environment. I could be using a malware-infected machine, with a bunch of keyloggers and not to mention viruses or other nasty stuff, and by slowing me to connect to your network AND opening an almost unrestricted access to your servers, you will be introducing those things into your network. You don’t want to do that.
Needless to say, because of these security issues, using MMC-based snap-ins is hardly even an option in enterprise-wide environments.
Secure Remote access and management of servers from a remote network via RDP – This implementation is similar to the local Terminal services/RDP connection. There is no need to install any management tools on the management workstation, you simply connect via Terminal services/RDP to the servers and do whatever you’re supposed to do. This scenario uses remote connections from machines that are located either in remote branch offices, or virtually anywhere on the planet, and is most widely used with external consultants, vendors and outsourcing companies. In order to allow these connections you need to configure your corporate firewall to accept incoming RDP sessions (these typically use TCP port 3389), and to pass these sessions to internal servers running RDP.
The benefit of this scenario is identical to the internal scenario, however here we’re able to extend the support calls to experts outside our network. Imagine having Exchange issues and calling to get support from an expert like myself. All you need to do is to open your firewall and allow my IP address to remotely connect to the server in your internal LAN.
However, scaling this scenario is difficult. The more servers you have on your internal network, the more rules you need to open on your firewall. Furthermore, when you have more than one server being published to the outside world, you need to create specific port and IP address rules for them on your firewall, which might cause an issue when the expert needs to connect from a remote location that is behind another firewall (like in the example where the expert that needs to connect is currently located at a different client’s location, and that remote firewall is not configured to allow outgoing traffic to these special ports that you opened on YOUR firewall).
Remote access and management of servers from a remote network via 3rd-party tools – This implementation is similar to the previous remote RDP connection scenario, however, instead of using native RDP connections, you use 3rd-party remote management tools. Such tools might include Damware, VNC, NetOP, PCAnywhere and others. Each one of these options uses different connection settings and ports which you must be avare of.
Secure Remote access and management of servers from a remote network via a dedicated RDP gateway – Like the previous implementation, experts that need access to your internal servers now connect from the outside. However, the major difference is the fact that they do not connect directly to the managed servers, but instead connect to a dedicated Terminal Server placed either in the DMZ or in your LAN, and after successfully authenticating to that machine, they open a new RDP session to the internal servers.
This scenario scales well, better than any of the previous ones. When using it you only need to open one port for one type of RDP connection from the outside, and do it to only one internal server. From there, the experts can connect to any internal server. This traffic can be further secured by using specific IPSec policies that only allow certain RDP traffic to a dedicated set of internal server, and no more than that. These policies can be also configured to ONLY allow RDP traffic, and thus prevent the experts from doing anything that they were not meant to do in the first place. With this method is easier to audit and record remote terminal sessions.
Secure Remote access and management of servers from a remote network via a Windows Server 2008 Terminal Server Gateway – A feature now available in Windows Server 2008, TS Gateway allows the connection to internal Terminal servers and RDP-enabled machines from the outside, but unlike the term “gateway” used in the previous scenario, the Windows Server 2008 TS Gateway is a dedicated Terminal server using a specific service role called TS Gateway, that enables the external vendors to connect to it via SSL, pass a certain authentication process and policy evaluation, and only if allowed, it passes the RDP traffic to specified internal machines. These machines return the required data, and the TS Gateway then encrypts the data with SSL and passes it back to the remote user.
The benefits in this scenario include the ability to use SSL-based encryption, which easily passes through most firewalls without the need to open specific ports. Also, instead of running an RDP session inside and RDP session like in the previous scenario, the remote user only has one session to take care of.
Security issues and options
After selecting the scenario that most suits your needs you need to pay special attention to some security concerns:
Connection settings – For most RDP connections these can be easily enforced by using firewalls and other network device configurations. Remember that MMC-based snap-ins pose the most issues when needed to be configured on firewalls, thus causing them to be virtually unusable from outside of your network. That is why, for most cases, using RDP is considered to be much safer than MMC-based snap-ins.
Traffic encryption – As with other sensitive data, management traffic should be as secure as possible. RDP can be used with high-security encryption settings, and it can also use RDP over SSL. You can also use IPSec which is built-in in most Microsoft operating systems to further secure your traffic and restrict access to non-managed servers. 3rd-party management tools might offer their own set of encryption techniques that you need to be aware of. Another issue is the deployment of digital certificates or other means of authentication, and all this requires planning and testing.
Permissions – The permissions needed to be given to the managing user pose some difficulties. Some services or server software require the manager of that service or software to also be a local administrator on the server. In the hands of a non-competent user, or God forbid a malicious user, this can cause great pain. One needs to find a method of controlling, recording, and auditing what that expert or administrator actually did on the managed server.
Human errors – Given that the manager or external expert has enough power in his hands, human errors can cause your entire system to fail. Combine that with human fatigue, carelessness, lack of knowledge for the specific task, and lack of planning, and you got yourself a major security issue. You see, recent studies show that human errors account for approximately 34% of total outages when counting the number of outages. After calculating the total effect of each incident (as measured by Mean Time to Repair and amount of lost data), as much as 56% of total server outage impact comes as a result of human error. This is a large number, too large to neglect, however, up to now no solution existed that could help the IT manager monitor the human error factor. One of my clients has had this exact issue with an external vendor that was hired to perform an upgrade job. The vendor, although quite skilled and with proven knowledge, has managed to mess up the client’s Active Directory in such a manner that has brought down their entire corporate network and production stood still.
Auditing and Recording remote access sessions
When dealing with RDP and other terminal-based connections such as Citrix or CockpIT, a wonderful solution has been recently made available by the introduction of ObserveIT. While targeted at enterprise-wide deployments, ObserveIT allows the IT manager to have full control over the actions done by either local IT personnel, by power users, or by external vendors and specialists that were hired to perform a specific task.
The software allows the recording and capturing of the human interaction with the server/workstation, and the most cool part of it is that it indexes all the screenshots and allows easy textual searches through the database. This way, if you suspect that one of your administrators made a change on one of the applications that are installed on one of your servers (virtually ANY application), you can easily perform a search of all the human interactions with that server during the previous X hours/days, and easily see what where the actions that were performed on the server. Clicking on the action will bring you to the exact point in time of the captured video, allowing you to see exactly what that user did, and what he did right before and after that point.
Even more so, you can easily search for all the similar actions that the user performed across your entire enterprise, because you may rightfully assume that if he did it once, he might have done it again elsewhere. This feature allows you to be sure he did not do it, and if he did, you can easily find out about it BEFORE your servers go down due to this misconfiguration.
Secure Remote Access recording with ObserveIT.
Another recording option is available with Citrix SmartAuditor, a feature of Citrix XenApp (the new name of Citrix Presentation Server™) Platinum Edition. This solution records at the network protocol, therefore does not allow indexing of the recorded session and the only way to search for something is by replaying the recorded session from start till end. . Citrix SmartAuditor Auditing and logging – Many server-based applications have their own set of auditing or logging, some even allow extended logging by enabling diagnostic logging. However, auditing and logging can only show you error logs, not human actions. Auditing and logging might be useful when the need arises to debug an error or other issue, but do you really know what are users doing while using logged onto your Terminal or Citrix server? Even more, auditing in itself cannot prove what the users did while they were connected:
- Did they open files they were not supposed to touch?
- Did they read other users’ mail?
- Did they tamper with the system’s settings?
- Did they make changes to the registry?
- Did they delete files?
Some of these questions can be answered by enabling certain auditing features on the system, but their results lack in information and ease of interpretation.
Here too, recording tools can help you maintain your management environment in a more secure manner. Remote access recording tools such as ObserveIT record human actions on the server and allow you to view and replay any user actions. Here too, ObserveIT has some striking features that make the recording of human actions and management tasks easy to maintain. ObserveIT’s advanced indexing capabilities allow you to search for specific connection times, and see exactly what the external vendor or administrator did. The fact that the database is centrally stored allows you to easily capture recordings from many servers or management workstations, and perform an enterprise-wide search on them.
I will discuss some of the concerns related to external vendors in an upcoming article. Stay tuned!
In this article, I scanned the various remote access and management options available for current IT environments today. Each management option has its benefits and drawbacks, along with specific security issues that need to be taken into account. However, when using RDP connections to manage your network services you can leverage the use of 3rd-party tools such as ObserveIT, to help you get full control over what was done on these machines, who did it, and what else did they do.
Learn how to secure and audit Secure Remote Access with ObserveIT.