Thoughts on a Minimalist Server Design

I would like to start with an analogy related to human behavior. I am assuming that we've all been in situations where we think we need something, spend money, buy it and some time later realize there was no need to buy and spend money on whatever we bought. As a result, you are just a bit poorer for spending money on something you didn't need.

I believe the same holds true for system services (We will use Microsoft Windows Server for this example). Microsoft ships the server software with a number of services enabled by default - whether you need them or not (i.e. in my human behavior analogy, you buy something which you may not need). And if you are not careful in terms of keeping an eye on all the services your server is running, you open your computing environment to hackers who are always looking for a window of opportunity. This becomes security vulnerability for your computing environment/servers

Attackers are always searching for remotely accessible network services that are vulnerable to exploitation. Common examples include poorly configured web servers, mail servers, file and print servers, and Domain Name System (DNS) servers installed by default on a variety of desktop and server operating systems, often without a business need. Many software packages automatically install services and turn them on as part of the installation process. It can be difficult for a user or administrator to keep track of these rogue services. Attackers scan for such services and attempt to exploit them, often by simply using the default user IDs and passwords or widely available exploitation code.

The following is an example to Illustrate potential security issues with system services. Windows has Xbox services on Windows Server. These services are enabled when you first install the OS. If someone is installing windows server in corporate/business/enterprise environment, There is a very small chance that they actually need this service.

Now, if the system admin on corporate environment does not know about the default Xbox service and, therefore, does not disables it, this service will remain active. Later on, if a vulnerability is discovered with the Xbox service, the system admin may not be aware that this is something they need to worry about because, well, it's for Xbox. Why would it be running on my servers.

With this shiny new vulnerability out in the world, a hacker can now exploit this vulnerability to find way to on to the corporate network.

The example above illustrates a problem with many modern Server operating systems. These systems are so vast and complex that it becomes a huge undertaking to disable unnecessary services and harden them against attack.

As I summarized earlier, this happens when Microsoft Windows Server (and other Server OS's) set different services to different default startup policies: some are started by default (automatic), some when needed (manual), and some are disabled and must be explicitly enabled before they can run. Microsoft takes this step because if the correct set of services are not enabled by default then some software may not run or not install properly. On the other hand, Microsoft may be enabling services which your "particular" computing environment may not require.

Some enterprise customers may prefer a more security-focused (hardened) setup for their servers, one that reduces their attack surface to the absolute minimum. This can be achieved by disabling all services that are not needed in their specific environments. Now, in this setup you have to disable/enable lots of services manually and if you do not have detailed knowledge of the services you need and end up disabling or misconfiguring a service, it has the potential to lead to major problems. Misconfigured services can lead to the server not operating properly or even opening up your environment to attack.

Key takeaway:

Ensure that only the minimum number of network ports, protocols, and services are enabled for proper operation of the server. Any additional unused services increases the attack surface of your environment and may expose vulnerability that an advisary could exploit.

https://www.cisecurity.org/controls/limitation-and-control-of-network-ports-protocols-and-services 

https://docs.microsoft.com/en-us/windows-server/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server

Breakdown of Citrix XenServer and XenApp

I've recently spent a some time working with VDI products and thought it would be helpful for me - and hopefully you - to document the interconnections between these various products. 

For this example we will use Citrix XenServer and Citrix XenApp as the carrier for VDI. In order to bring VDI to the end user, at the office or at home, other components are required. In order for an external user to connect to VDI, they are first met by a Citrix NetScaler Application Delivery Controller. The NetScaler is a networking appliance that determines the appropriate path for the best user experience. This appliance determines which StoreFront is currently the best server to provide a desktop. Data compression and load balancing are key features of the NetScaler. The user is then passed to a CloudBridge, which behaves similarly as the NetScaler. Multi-session compression, protocol acceleration, traffic shaping and TCP protocol acceleration. Internal users will not be confronted by a NetScaler, internal users will be provided compression and load balancing via the CloudBridge. Now that the networking aspect is complete, the user finally reaches the Data center. 

Within the Data center the VDI request initializes a StoreFront Server session. The StoreFront server simply provides a selection of desktops available to the user. All users will see the Standard Desktop. Some users will be able to select the Administrator Desktop. Select users may have Test Desktop available. Once a desktop selection is made the session request is pushed to a Provisioning server. This component houses the images used for each desktop. The Provisioning Server determines which desktop is available on which Delivery Controller and passes the request. The Delivery Controller ingest the desktop selection request and assigns a virtual desktop agent (virtual computer). The desktop is returned to the user and productivity for the day can begin. The NetScaler is hosted on a Linux operating system. Linux is also installed on the CloudBridge. The remaining components have software installed on a Windows Server 2008R2 virtualized platform. The Citrix XenApp server provides users with individualized access to software. Software with stringent licensing restrictions are hosted via the XenApp server. The company can then determine which users have a valid need for the limited licenses for applications like Adobe Creative Cloud products, Microsoft Visio or Project. The XenApp server also allows for access to be restricted to specialized personnel. For example, the Closed Circuit TV monitoring software can only be accessed by Security personnel.

On the user side, this change is really very minimul. However, it is a change, and change is seldom welcome. It has been noted there is an additional step during the login process. Users must authenticate with the StoreFront and again to login to the system. This additional step seems to be a bit more than people are willing to tolerate. Network performance is the other point of contention among users. Many users feel as though the old laptop they had to do their work was much faster than VDI. Performance wise, there is nothing to support this claim. Each VDA is configured to used 12GB of RAM and 160GB of space. A performance monitor indicates a similar transaction (updating a spreadsheet) occurs quicker within VDI. However, reading an encrypted email takes much longer in VDI.