Chapter 12. Endpoints

Endpoints, devices that an end user operates such as a desktop, laptop, tablet, or cellphone, are increasingly becoming a target for malicious individuals who seek to compromise a network. With an increasingly mobile workforce, growing numbers of knowledgeable workers, and rapidly falling prices for storage, the availability of vast quantities of data that are either stored on endpoints or available to endpoints via the repositories that they access (i.e., shared drives) is becoming more and more substantial by the day.

In what may appear to be a counterintuitive response to this increased availability of data, demands are high for ease of access to that data to be increasingly low friction, often in the name of productivity or agility of the organization.

Endpoints are, of course, also the location at which most people conduct activities such as web browsing, instant messaging, reading email, and clicking any random links or attachments that seem appealing to them at the time. The number of vectors available to attack the endpoint is large, and they are filled with targets for whom security is not necessarily the number one priority.

This has unsurprisingly led to endpoints being increasingly targeted, not only by malware and ransomware, but in more precise spearphishing and hacking campaigns.

In this chapter we will explore steps you can take on most endpoint devices to drastically reduce the chances of an endpoint being compromised, and to minimize the impact to you should this ever happen.

Keeping Up-to-Date

As with the server estate, ensuring that patches are installed on endpoints is critical to limiting the number of bugs, and thus vulnerabilities, on any one system. By minimizing the number of vulnerabilities on endpoints, the number of technology-based options open to an attacker are reduced. The same can be said of automated attacks by certain types of malware.

The method of patching will vary from platform to platform; indeed, it will vary depending on the style of management used by an organization. A “bring your own device” (BYOD) system of device selection and management will be very different from a more traditional set up whereby an employer will provide and manage a device in terms of hardware, operating system, and often applications.

Microsoft Windows

Ever since the launch of Windows 95, Microsoft has provided the Windows Update service, which has undergone a number of different incarnations, but ultimately serves the purpose of distributing patches to endpoints in a semi-automated way. This website allows desktop PCs running Microsoft Windows to download updates and patches based on which version of the operating system is being run. However, this service has been mostly aimed at the consumer and BYOD markets and has often been rather self-service, with the user being provided the opportunity to decline and defer updates, and no visibility provided to system administrators with regards to the deployment status of various patches.

Microsoft has, in the past, provided what are effectively enterprise versions of this system in the form of Systems Management Server (SMS), Microsoft Operations Manager (MOM), and Windows Server Update Services (WSUS), to allow systems administrators to deploy patches to workstations within the environment without relying on Windows Update or Microsoft Update. These systems are, however, no longer the standard.

At the time of writing Microsoft recommends the use of Windows Update for Business for endpoints running Windows 10. You can use either Group Policy or Mobile Device Management (MDM) solutions to configure devices to use the Windows Update for Business service, as opposed to the consumer-style Windows Update service.

macOS

macOS clients can be centrally patched using the Software Update Service in macOS Server. This is achieved by using a configuration profile that directs the client on which update server to use, as opposed to using the general-use update server provided by Apple across the internet.

The Profile Manager tool is distributed by Apple and can be used to configure a number of configuration options for iOS and macOS devices in your estate. It is not a central management system, per se, but can be used to deploy policies.

For unmanaged devices—that is, devices for which you have not installed a configuration profile—the change of update server can be made manually using the following command:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate 
 CatalogURL http://my.update.server.tld:8088/index.sucatalog

It is worth remembering that as with other operating systems, macOS allows users with suitable privileges to install software outside of this ecosystem, and as such, they will not be automatically patched via a system such as this. In these types of cases, the onus may well be on the user to perform regular updates and to ensure that the system is functioning as expected.

One of the most popular methods of distributing third-party software to macOS hosts is homebrew. Users of this system can update their repository by running the command:

brew update

And then upgrade any packages that have been updated in the repository by running the command:

brew upgrade

Unix Desktops

As is often the case, Unix desktops vary depending on Unix flavor, and between distributions within each flavor. But there are some high-level approaches that can be researched for suitability depending on the environment:

Use similar management tools to those that may be used for Unix servers to run commands on desktops causing the local package management software to perform the desired upgrades. Management tools such as Puppet and Ansible can be used to centrally automate these tasks.

Ensure that desktops are configured to run the automatic update and upgrade processes, if available, via a scheduled job, typically via cron.
Entrust patching to the desktop owner.

Third-Party Updates

Not all software will be managed by the operating system’s own update mechanisms. Users with suitable privileges can install third-party software that is not covered by the central patch management systems previously described. Thankfully, an ever-increasing number of applications are implementing automatic or semi-automatic update mechanisms to aid users with this process. The use of these automatic update systems is often more of a challenge with regard to user education than it is for technology. Security teams spend a lot of time telling users not to click on things—unless it’s a patch, in which case they should really really click on them.

Users should accept updates and thereby keep applications patched and up-to-date; however, they should be taught not to blindly click Accept on everything, as this will naturally expose them to several types of social engineering attacks, such as FakeAV malware, for example. It is recommended that users update their applications, but be aware of how to discern a valid update as opposed to a browser popup.

Applications that do not have an automatic update mechanism should be monitored for new releases, typically by subscription to mailing lists and such, as well as applying upgrades manually as new releases become available.

Keeping an inventory of applications installed within the environment is worthwhile. This way in the event of an advisory being released for software, it is immediately apparent if you have a problem, how large it is, and how many desktops will need to be visited in order to mitigate it. This sort of information is typically kept in your asset register, as mentioned in Chapter 2.

Hardening Endpoints

As with servers (discussed in Chapters 10 and 11), hardening is the art of making the most secure configuration possible, without compromising the ability of the system to perform its primary function. Patching, as mentioned, is the first critical step to hardening an endpoint, but there are other steps that should be taken in order to reduce the opportunity for compromise.

Disable Services

Every service (daemon) that runs is executing code on the endpoint. If there is a vulnerability within that code, it is a potential weakness that can be leveraged by an attacker. It also consumes additional resources in the form of RAM and CPU cycles.

Many operating systems ship with a number of services enabled by default, many of which you may not use. These services should be disabled to reduce the attack surface on your servers. Of course, you should not just start disabling services with reckless abandon—before disabling a service it is prudent to ascertain exactly what it does and if it is required.

On Microsoft systems, there is a GUI-based administration tool within Control Panel that can be used to list, start, and stop services, either temporarily or permanently. There is also a command-line option to list running services, which is:

sc query type= service

Services can also be stopped or started from the command line. For example, to stop the Task Scheduler, which as it happens, you should not do, you can type:

sc stop "Task Scheduler"

And to start it again:

sc start "Task Scheduler"

This only stops and starts a service for the duration that the endpoint is booted up, however. To permanently enable or disable a service you should use the following command:

sc config "Task Scheduler" start= disabled
sc stop "Task Scheduler"

In addition to the built-in commands, there are other Microsoft tools that will provide a more in-depth view into services and their hooks into the operating system. Both Process Explorer and Process Monitor from the Sysinternals suite of products can assist in research into service and process activities.

There are a number of ways to ascertain which services are running on a Unix system, the easiest of which is to use the ps command to list running services. Exact argument syntax can vary between versions, but the ps ax syntax works on most systems and will list all currently running processes. For minor variations in syntax on your operating system, check the manual page for ps using the command man ps.

Services should be disabled in startup scripts (rc or init, depending on operating system) unless your system uses systemd, in which case you can refer to the following discussion on systemd. Using the kill command will merely stop the currently running service, which will start once more during a reboot. On Linux the commands are typically one of rc-update, update-rc.d, or service. On BSD-based systems, you typically edit the file /etc/rc.conf. For example, on several flavors of Linux the service command can be used to stop the sshd service:

service sshd stop

To start sshd (one time):

service start sshd

And to disable it from starting after a reboot:

update-rc.d -f sshd remove

Some Linux distributions have moved toward using systemd as opposed to SysV startup scripts to manage services. Systemd can be used to perform other administrative functions with regard to services, such as reloading configuration and displaying dependancy information. To stop sshd (one time):

systemctl stop sshd

To enable sshd upon every reboot:

systemctl enable sshd

And to disable sshd upon further reboots:

systemctl disable sshd

Older Unix operating systems may use inetd or xinetd to manage services rather than rc or init scripts. (x)inetd is used to preserve system resources by being almost the only service running and starting other services on demand, rather than leaving them all running all of the time. If this is the case, services can be disabled by editing the inetd.conf or xinetd.conf files, typically located in the /etc/ directory.

macOS is based upon FreeBSD, a Unix system, and thus the ps and kill commands work in the same fashion as previously described. The preferred route is to use the launchctl command to control launchd, which can be invoked with the list, stop, or start arguments to stop or start enabled services.

To disable a service, use the command:

launchctl disable <servicename>

It should be noted that there are a wide range of options when using launchctl, so it is recommended that you consult man launchctl before proceeding.

Desktop Firewalls

With an ever-growing mobile workforce, using a desktop firewall is becoming more of a necessity. The days of a workforce whose IT footprint is confined to the office environment are long gone for most organizations. The last time an employer gave me a desktop that was an actual desktop was 2002. Ever since then, irrespective of industry vertical or company size, my “desktop” has always been a laptop, even if it remained permanently at a desk. This means that users’ main computing device, the one that probably holds a large volume of your corporate information on it, is at best being plugged into home networks with partners, housemates, and children’s devices, and most likely into public wifi hotspots in hotels and coffee shops.

Of course, a firewall is far from a panacea, but being able to block all ingress connections—and ideally, blocking egress connections also—is very beneficial when on an untrusted network. Ingress filtering blocks those attempting to connect to the endpoint. By blocking egress connections, applications that are unsafe to use on a shared network, such as those that use unencrypted protocols, can also be blocked.

Windows systems have included a built-in firewall capability of one sort or another since Windows XP. We would hope that you are running something more recent than Windows XP, and so we should assume that this option is available to you. If you’re running a Windows system that is older than XP, then you have quite a number of other problems to address, and your endpoints should not be connecting to public WiFi at all.

The location of the administration interface varies from version to version, but it is consistently within Control Panel. In Windows 10, the current version of Windows at the time of writing, the interface is located in Control Panel→System and Security→Windows Firewall.

Since Leopard, macOS has included an application firewall that, rather than operating on IP addresses and port numbers, allows you to configure settings based on an application. For example, you could specify that the web browser can make connections, but that the PDF reader cannot. The administrative interface is located in System Preferences→Security and Privacy→Firewall.

Linux-based desktops will almost without exception have a host-based firewall available to them, although this will vary between distributions. The default for Ubuntu, for example, is “Uncomplicated Firewall” or ufw. Details on how to use ufw can be found by using the command man ufw. Other Linux flavors and Unix systems could use any one of a range of firewalls. It is recommended that specific documentation be consulted for determining the type of firewall per distribution.

Full-Disk Encryption

As we just discussed in “Desktop Firewalls”, the workforce is increasingly mobile due to the replacement of traditional desktop systems with laptops, which people carry around with them. This means that organizational data is also increasingly mobile, which of course is accompanied by the risk of a laptop being stolen or left somewhere.

Another change in desktop computing is the cost, capacity, and physical size of storage. This has led to large capacity disks being commonplace within the desktop environment, meaning that members of staff can store large volumes of data, which is often sensitive.

The combination of these trends means that the scope for potentially losing large volumes of data has increased dramatically.

For this reason, among many others, it is recommended to run a full-disk encryption solution in order to protect the hard disk or solid state disk in laptops and desktops. Modern hardware and operating systems are optimized for the use of full-disk encryption, so after the initial encryption of the drive, a performance overhead is not something that is noticeable in most cases. Modern full-disk encryption implementations are fairly transparent to the user, typically only requiring an additional boot-time password after initial encryption of the disk has taken place.

Forensics

It should be obvious, but for the sake of clarity, encrypting the storage on a laptop will, by design, render the data on it unreadable to anyone but the owner who is configured to decrypt the data. Thus, if you rely on the ability to perform disk forensics, for example, you should consider other solutions that include the option for centrally controlled keys to allow forensic examination by your team.

Current versions of most operating systems come with bundled full-disk encryption solutions that should serve perfectly well unless you have a requirement for centrally managed keys or the ability to use specific configuration, such as altering the cryptographic characteristics.

Windows includes a tool called BitLocker, which can be found in Control Panel→System and Security→BitLocker Drive Encryption. Enabling BitLocker is simply a case of clicking to enable and following the onscreen prompts.

On OSX there is a similar tool called FileVault. To enable FileVault use the administrative interface located in System Preferences→Security & Privacy→FileVault, and again click to enable and follow the onscreen prompts.

Full-disk encryption on Linux platforms is typically more difficult to accomplish after the installation of the operating system, so the documentation for the specific distribution should be consulted. However, if a new system is being installed, this is often as simple as an install-time checkbox (this is certainly the case in recent versions of Ubuntu, for example).

Locked Screens, Sleeping, and Hibernating

Full-disk encryption works by leaving the filesystem on the disk encrypted at all times, with a key stored in memory. This key is then used by a driver for the disk, which reads encrypted data from the disk, decrypts its memory using the key, and then passes the decrypted data to the operating system and applications. The OS and applications are, to all intents and purposes, completely unaware that the data is encrypted on the drive.

This decryption key is itself encrypted on the drive, but is decrypted using the passphrase entered by the user at encryption time, and again at each bootup. This allows for the key used to decrypt data on the disk to be substantially larger than the passphrases used by humans.

There is, however, one issue with this model—the key to decrypt the disk must remain in memory at all times. Memory is only cleared when the host is shut down. During normal operation, locked screen, sleep mode, and hibernate mode, the memory is retained. This means that leaving a laptop on the lock screen will not necessarily protect it from an attacker.

This is not any different than normal operation on a network. However, users often expect that when a host screen is locked or in sleep mode (for example, when it’s left unattended in a hotel room), it is safe from a physical attacker. There are attacks which can be used to dump the memory over one of the ports on an endpoint, and from that memory dump the decryption keys can be acquired.

Endpoint Protection Tools

Endpoint protection tools, such as antivirus, are often a contentious point, especially with regards to their effectiveness versus any potential new vulnerabilities that they can introduce into a system while performing their tasks. At the same time they are fixing issues, they are themselves running additional code on a host which can, and does, contain bugs.

A general rule of thumb is that until you are suitably advanced in matters of security to make this determination for yourself, you are probably better off running the software than not. Antivirus, anti-malware, and other endpoint protection tools are far from complete coverage, but they do catch low-hanging fruit, and they in turn reduce the noise in the data that you are analyzing, which in turn makes it easier to spot other issues that could have been lost in the noise.

Mobile Device Management

Mobile device management (MDM) is the generic term used to describe a number of possible technologies that can be used to provide centralized management of mobile devices—typically smartphones, but also including tablets and other mobile computing devices.

An MDM is used to enforce policy on a device, typically taking the form of a server running MDM software, which has been configured as an MDM on the mobile device prior to delivery to the user. Examples of policies that can be enforced are:

Enforce PIN/password
Enforce VPN use
Application installation
Remote erase
Enforce configuration options (ban or enforce the use of certain applications or configuration options)

Unlike many other technologies mentioned in this book, there are not any prevalent open source MDM solutions. There are, however, a number of commerical solutions. The largest differentiators between solutions, other than cost, are which devices are supported, and which sort of policies you wish to enforce upon each device type. Before purchasing a solution, it would be advisable to understand which devices you are going to support and what you would like to manage on them. This will instantly narrow down the number of contenders to evaluate.

Endpoint Visibility

Endpoint visibility tools allow the collection of key data on how an endpoint is operating. Details such as which network connections it has open, running processes, open files, and so on, can be helpful information for many reasons. This information can often be used to detect compromised hosts, malware, or members of staff deliberately acting in a malicious way. When aggregated across the enterprise, it can not only be used for detection and blocking purposes, but also potentially to reconstruct lateral movement and data exfiltration in the event of a larger compromise.

Endpoint visibility can be a potentially contentious topic, however, as to the expectation of privacy employees have within your organization. This often comes down to a number of factors: the organization itself, the industry vertical, the country in which you are located, and a number of other similar cultural factors. It is often wise to speak to human resources prior to deploying endpoint visibility tools in order to ensure that they are permissible under the contract of employment. Having staff trust the security team is crucial to being effective, and this small act can pay large dividends later on.

Various tools are available, however OS Query is a well-established and respected open source tool that supports Windows, macOS, and Linux out of the box.

Other Endpoints

Not only should endpoints with full operating systems be considered, but also other devices such as printers and heating, ventilation, and air conditioning (HVAC) systems that interact with heating, cooling, and other infrastructure equipment.

Printers will ship with default passwords and may store Active Directory credentials on them for authenticating to LDAP to send scanned/printed documents to file shares. Printers are inherently insecure and can also often be coaxed into providing LM hashes. It is best to lock down logins that printers use as well as segmenting them as much as possible.

SCADA systems are not only insecure, but can also be extremely fragile when interacting with modern technology. The third-party vendors that supply or manage the systems may have security protocols specific to their devices or they may have a backdoor into the system that has zero security. Any SCADA equipment should be treated just like any other part of the network—documented, secured, and tested as a precautionary measure.

Other items to consider:

Heating and ventilation control systems
IP-enabled cameras
IP-enabled thermostats
Door locking systems
IP telephony systems

Centralization

One of the goals with endpoint management is to centralize resources as much as possible. Central management consoles, central authentication systems, centralized logging, and centralized file stores all bring economies of scale, ease of management, consistency of configuration, minimization of management overhead, and typically a simplified architecture. By aiming for a centralized infrastructure that makes sense for your organization, life will be made easier both for yourself and for the end user.

Conclusion

Endpoints are the new go-to system for an attacker as remote or mobile workforces grow, and access to often-sensitive company data becomes more ubiquitious. Securing these endpoints is a must for any organization. There are several fairly simple steps you can take to vastly reduce the risk of compromise and to increase the chances of detection if it does occur. Patching, hardening, and using endpoint tools are achievable goals for most organizations.

Previous Chapter

11. Unix Application Servers

Next Chapter

13. Password Management and Multifactor Authentication