Introduction

Endpoints are the devices that run applications on a network, or that users operate every day to get their work done — desktops, laptops, servers, and, increasingly, containerized workloads. Understanding the different operating systems, how to secure them, and the different layers of defense involved is a critical part of overall network security.

This reference covers how to harden, monitor, and automate patching for Windows and Linux endpoints, along with the additional considerations required to secure container-based endpoints. Major topics include:

Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR)
File integrity monitoring for Windows and Linux endpoints
Endpoint hardening measures for all endpoint types
Automated patching solutions for Windows and Linux endpoints
Security considerations unique to container endpoints

A foundational understanding of security engineering concepts and terminology is assumed.

Course Scenario

Throughout this material, a running scenario illustrates each concept in practice. Globomantics is a large corporation expanding into new regions. As it opens new office spaces, its computer network has grown significantly. Globomantics evaluated its cybersecurity defenses and determined that its endpoints are vulnerable to attack and require a layered defensive solution. As the security engineer, the goal is to harden the endpoints, automate patching, and deploy monitoring systems to further secure the network.

The material is organized around securing three endpoint categories in sequence: Windows endpoints (desktops and servers), Linux endpoints, and container endpoints. For each type, the same set of endpoint security concepts is revisited — monitoring/detection, file integrity, hardening, and patch automation — so the parallels and differences between platforms become clear.

mindmap
  root((Endpoint Security Layers))
    Monitoring and Defense
      Antivirus
      Centralized Logging
      HIDS
      EDR
      XDR
    File Integrity
      File/Directory Monitoring
      Checksum Validation
      Encryption at Rest
    Hardening
      Least Privilege
      Separation of Duties
      Disable Unnecessary Services
      Exploit Protections
    Patch Automation
      Vulnerability Scanning
      Change Management
      Centralized Deployment
      Backout Planning

Module 1: Configuring Secure Windows Endpoints

This module covers securing, hardening, and setting up centralized monitoring of Windows endpoints — both desktops and servers running Windows software.

Lab Environment and Scenario Overview

The demonstrations throughout this material are illustrated using a small lab network consisting of an Active Directory domain for Windows, a patch management server for Ubuntu machines, a Wazuh server providing centralized security monitoring, and a Docker host for container workloads. The demos show example tools in operation on this network to illustrate a concept; they are not step-by-step walkthroughs for installing or configuring the tools themselves.

To replicate a similar lab, the following endpoints are useful:

One Windows Server (domain controller)
Three Ubuntu servers
Two Ubuntu desktops
A Windows 10 machine and a Windows 11 machine
A Docker host for container demos
A Wazuh server for centralized monitoring (optional but recommended)

A smaller setup — a single Windows machine, a single Linux machine, and Docker for containers — is sufficient to follow along with most of the concepts.

flowchart TB
    subgraph Lab["Example Lab Network"]
        DC["Windows Server<br/>(Active Directory Domain Controller)"]
        W10["Windows 10 Workstation"]
        W11["Windows 11 Workstation"]
        UServer["Ubuntu Servers x3"]
        UDesktop["Ubuntu Desktops x2"]
        Docker["Docker Host"]
        Wazuh["Wazuh Server<br/>(Centralized XDR Console)"]
        Landscape["Ubuntu Landscape<br/>(Patch Management Server)"]
    end
    DC -- agent --> Wazuh
    W10 -- agent --> Wazuh
    W11 -- agent --> Wazuh
    UServer -- agent --> Wazuh
    UDesktop -- agent --> Wazuh
    Docker -- agent on host --> Wazuh
    UServer --> Landscape
    UDesktop --> Landscape

Monitoring and Defense Systems for Windows Endpoints

Windows endpoint defense is built up in layers, each adding capability beyond the last.

Antivirus is the most common first layer of defense. Antivirus solutions use signature-based detection to detect, prevent, and remove malware on Windows and other operating systems. Solutions range from single-machine, home-use products to enterprise solutions with centralized management. Antivirus scans files on the endpoint and identifies known threats. This remains a valuable part of a layered defense, but it has an inherent limitation: the threat must already be known, and a signature must exist, for the antivirus to detect and remove it.

Centralized log monitoring is a second, complementary layer. While useful for security, it also serves purposes outside security, such as troubleshooting and identifying system issues. For security purposes, centralized log monitoring provides an audit trail of events that can be used to reconstruct an incident and identify who took what action on which endpoint.

The next level of protection beyond simply centralizing log data is a Host Intrusion Detection System (HIDS). A HIDS monitors a system for malicious activity, usually through signature-based detection using rules. HIDS solutions may deploy agents installed on the host, or operate agentlessly to reduce performance impact on the endpoint. In both cases, analysis is conducted on a central server. When the HIDS detects activity matching its rule set, it generates an alert for investigation.

A similar but more capable solution is Endpoint Detection and Response (EDR). EDR enables centralized endpoint monitoring, which is especially useful for managing large networks. It collects and analyzes endpoint information, but unlike a HIDS, it also has a response capability — it can take action after detection. EDR solutions may also employ additional analytic capabilities, such as machine learning.

Beyond EDR is Extended Detection and Response (XDR). XDR solutions extend EDR capabilities to other infrastructure layers and incorporate additional data sources, such as threat intelligence feeds, to combine and correlate data beyond the endpoint alone.

Solution	Detection Method	Centralized?	Response Capability	Scope
Antivirus	Signature-based	Varies (enterprise editions can be)	Remove/quarantine known malware	Single endpoint file system
Centralized Log Monitoring	Log aggregation	Yes	None (visibility only)	All forwarded logs
HIDS	Signature/rule-based	Yes (analysis on central server)	Alerting only	Single host activity
EDR	Behavioral + signature, may include ML	Yes	Automated response actions	Endpoint
XDR	Correlated, multi-source, may include threat intel	Yes	Automated response actions	Endpoint + broader infrastructure

flowchart LR
    A[Antivirus<br/>Signature-based file scanning] --> B[Centralized Log Monitoring<br/>Audit trail + troubleshooting]
    B --> C[HIDS<br/>Rule-based activity monitoring + alerting]
    C --> D[EDR<br/>Detection + automated response]
    D --> E[XDR<br/>Cross-layer correlation + threat intel]

For the Globomantics scenario, Windows Defender (built in) provides antivirus. Wazuh is connected for extended detection and response capability. The Windows Event Collector is used for centralized logging.

Demo: Centralized XDR Monitoring with Wazuh for Windows

Wazuh serves as an XDR solution for monitoring Windows endpoints in the lab.

Open the Security Events dashboard, which shows events from all endpoints on the network.
Filter the output to a specific agent — for example, the domain controller.
Review the dashboard summary: the top five alerts, rule groups, and PCI-DSS compliance-relevant findings for the selected agent.
Drill into the Security Alerts section to explore a specific alert. Each alert shows the exact rule that was triggered — for example, a rule triggered by a match against specific Windows System event IDs.
Where applicable, select the associated MITRE ATT&CK technique linked to the alert to understand how adversaries use that technique, existing mitigations, and the associated ATT&CK tactic.
Review the agent summary view, which surfaces the top MITRE tactics observed, compliance alerts, recent events, and a Center for Internet Security (CIS) benchmark score for that endpoint.

sequenceDiagram
    participant Endpoint as Windows Endpoint (Agent)
    participant Wazuh as Wazuh Manager
    participant Analyst as Security Analyst

    Endpoint->>Wazuh: Forward Windows event logs
    Wazuh->>Wazuh: Match events against rule set
    Wazuh->>Wazuh: Generate alert + map to MITRE ATT&CK technique
    Wazuh-->>Analyst: Display alert in Security Events dashboard
    Analyst->>Wazuh: Filter by agent / drill into alert
    Wazuh-->>Analyst: Full log details, CIS benchmark score, compliance mapping

Demo: Centralizing Logs with Windows Event Collector

Windows Event Collector (WEC) is a free, built-in way to forward events from multiple Windows endpoints to a single console for review.

On each source endpoint, configure an event subscription that forwards events to a single collector workstation or server.
Select which event levels to forward (for example: Critical, Warning, Error, and Information) and how far back in time to collect (for example, the last hour).
Select which event logs to forward — commonly the Windows Application, Security, and System logs, along with the Windows PowerShell operational log.
Once configured, source machines begin forwarding matching events into the Forwarded Events log on the collector.
From the collector, build custom views to further filter the aggregated log — for example, a view sorted by event level, and a second view showing only events sourced from the Active Directory server.

File Integrity and Encryption on Windows Systems

File integrity, file integrity monitoring, and file system encryption are all important defenses for Windows endpoints.

File system integrity monitoring ensures that critical files are not modified for malicious purposes. Tools are available to monitor specific directories that contain critical files and alert on changes:

A lightweight, single-endpoint tool such as Artillery can monitor directories on one host and send alerts on detected modifications.
A centralized platform such as Wazuh can monitor directories across many agents and surface alerts on a central dashboard.

Whatever tool is chosen, it should detect changes to important files and alert administrators to potentially malicious activity.

A related but distinct concept is verifying downloaded software integrity. Before installing an application, a checksum of the downloaded file is computed and compared against the value published by the software vendor. This process relies on a one-way hash function to confirm that the file received is correct and was not modified in transit.

File integrity monitoring detects potentially malicious activity, but it does not by itself protect data on the system from unauthorized access. That is the role of file and file system encryption:

File/folder-level encryption provides an additional safeguard in the event of a system compromise or data loss, helping to prevent unauthorized access from both external attackers and internal personnel.
Full file system (whole-disk) encryption goes further, preventing access to any information on the endpoint even if the physical device itself is lost or stolen.

flowchart TD
    A[Endpoint File System] --> B{Change Detected?}
    B -- Yes --> C[File Integrity Monitoring Tool<br/>e.g. Artillery, Wazuh]
    C --> D[Alert Administrator]
    A --> E{Software Downloaded?}
    E -- Yes --> F[Compute Checksum]
    F --> G{Matches Vendor-Published Hash?}
    G -- No --> H[Reject / Investigate File]
    G -- Yes --> I[Trusted for Installation]
    A --> J[Encryption at Rest]
    J --> K[File/Folder Encryption<br/>protects specific sensitive data]
    J --> L[Full Disk Encryption<br/>protects entire endpoint if lost/stolen]

Demo: File Integrity Monitoring with Wazuh on Windows

Open the Wazuh File Integrity Monitoring dashboard filtered to Windows agents.
By default, Wazuh agents monitor directories containing critical files and track change type: added, deleted, and modified.
Drill into a specific agent (for example, the domain controller) to review the users making changes, the proportion of each change type, and the specific files affected.
In the lab, most detected changes were registry modifications, which Wazuh treats as file integrity events on Windows.

Using a centralized tool like Wazuh, the file system integrity of every Windows endpoint can be monitored from a single console, surfacing potentially malicious activity across the fleet.

Hardening Measures for Windows Endpoints

Endpoint hardening reduces the attack surface of a system by changing its default configuration. Several concepts apply broadly across all endpoint types, and Windows adds some platform-specific protections as well.

Limiting administrator access and privileges. Access should be limited to the minimum required to accomplish a given task. In a Windows domain, privileges such as domain administrator can make changes across every system joined to the domain. That level of privilege should be reserved for administrators who genuinely need domain-wide control, and should not be used for tasks such as installing an application on a single workstation, where a local or workstation-level administrator account is sufficient.

This leads to separation of duties. In a Windows domain, this can mean creating administrator accounts scoped to different functions, and maintaining separate standard-user and administrator accounts for the same person. System administrators should log in, read email, and browse the web using their standard user account, reserving the administrator account strictly for actions that require elevated privileges, such as installing software. The goal is to limit the blast radius of a single compromised account — for a Windows domain, this means limiting the number of systems any one account administers to only what is essential for its role.

Reducing the attack surface. Disabling unnecessary services limits what is exposed to attack, and preventing anonymous enumeration limits the information an attacker can discover about the system without authenticating. Example services to disable when unused include the Fax service and the Bluetooth service.

Windows exploit protections. Windows endpoints include several built-in protections against common exploitation techniques:

Protection	Full Name	What It Defends Against
DEP	Data Execution Prevention	Executable code running from memory regions intended only for data
SEHOP	Structured Exception Handling Overwrite Protection	Buffer overflow exploitation techniques that specifically target the Structured Exception Handler (SEH)
ASLR	Address Space Layout Randomization	Buffer overflow attacks, by randomizing memory addresses so attackers must guess the correct address to succeed

All three of these protections are enabled by default on Windows 10 and later, but they can be configured domain-wide using Group Policy.

mindmap
  root((Windows Hardening))
    Access Control
      Least Privilege
      Separation of Duties
      Scoped Admin Accounts
    Attack Surface Reduction
      Disable Unnecessary Services
      Prevent Anonymous Enumeration
    Exploit Protections
      DEP
      SEHOP
      ASLR
    Delivery Mechanism
      Group Policy Objects

Demo: Hardening a Windows Endpoint with Group Policy

Group Policy Objects (GPOs) let an administrator apply a standard set of configuration changes to every machine in an organizational unit at once.

Open the Group Policy Management console and select the computer policy that applies to the Windows machines in the Globomantics lab domain.
The example policy in the lab is modeled on publicly available Department of Defense hardening guidance, aimed at protecting endpoints against Category 1 (highest-severity) vulnerabilities.
The policy enforces several of the practices described above, including:
- Preventing anonymous enumeration of accounts and shares
- Disabling unnecessary/exploitable services, such as Remote Assistance, Autoplay, and AutoRun
- Enforcing stronger encryption of stored passwords
- Enforcing the use of more secure authentication protocols

The advantage of applying hardening through a GPO is that a single, versioned policy can be rolled out consistently to every machine in an organizational unit, rather than configuring each endpoint by hand.

Patch Automation for Windows

Selecting the right patch management approach involves weighing the number of endpoints managed, the software in use, and available budget.

Windows Server Update Services (WSUS) is a built-in tool that lets administrators manage patch deployment from a central server, deploying updates during defined maintenance windows. It also allows the organization to download each patch once for the whole network, rather than every machine reaching out to Microsoft individually.

Microsoft Endpoint Configuration Manager (MECM) goes further, providing capabilities beyond patching, such as installing new applications. MECM is well suited to managing large fleets of Windows endpoints but requires a specific license.

Third-party patch management systems are also available — examples include Tivoli BigFix and PDQ Deploy. Both let administrators deploy software and updates to Windows endpoints, plus perform additional tasks beyond patching.

Solution	Type	Notable Capability	Licensing
WSUS	Built-in (Microsoft)	Central patch deployment during maintenance windows; single download for the network	Included with Windows Server
MECM	Microsoft	Patch management + application deployment	Requires separate license
Tivoli BigFix	Third-party	Software/patch deployment + endpoint management	Commercial
PDQ Deploy	Third-party	Software/patch deployment, custom deployment packages	Commercial (free tier available)

Trade-offs of automated patching. On the positive side, automated solutions are essentially required to manage patching at scale — they are the best way to control and apply updates across large numbers of endpoints quickly, with minimal manual effort, while ensuring patches are consistently applied. On the negative side, these solutions require enabling remote access and administration on every managed endpoint, which itself lowers the security of each endpoint (in exchange for the greater benefit of keeping software patched). There is also risk to older systems that may not accept certain patches, or that encounter problems once patches are installed. Because automation accelerates rollout, additional testing procedures are necessary — if a patch introduces a problem, an automated rollout can quickly turn a small issue into an outage affecting hundreds or thousands of endpoints.

flowchart TD
    A[Identify Available Patches] --> B{Automated Solution?}
    B -- No --> C[Manual Patch per Endpoint<br/>slow, inconsistent, low remote-access risk]
    B -- Yes --> D[Central Patch Server<br/>WSUS / MECM / 3rd-party]
    D --> E[Deploy to Endpoint Fleet]
    E --> F{Patch Causes Issue?}
    F -- Yes --> G[Backout Plan / Rollback]
    F -- No --> H[Fleet Updated Consistently]
    D -.requires.-> I[Remote Access/Administration<br/>Enabled on All Endpoints]

Demo: Automating Windows Patching with PDQ Deploy

PDQ Deploy is a straightforward third-party tool for automating Windows endpoint patching.

From the main PDQ Deploy interface, select Deploy Once for a chosen software package (for example, Google Chrome).
Choose deployment targets from Active Directory — for example, the Windows workstations in the lab.
Confirm the package is ready to deploy; the deployment can either run immediately or be scheduled for a later time.
Custom packages can also be created in PDQ Deploy, including packages composed of custom steps that run Command Prompt or PowerShell commands directly.

PDQ Deploy illustrates the general feature set that many patch management tools for Windows share. The right solution for a given environment depends on budget, team skill set, network size, and the operating systems in use.

Module 1 Recap

At the end of this module, the Globomantics scenario has progressed as follows: an XDR solution (Wazuh) is selected and configured to monitor Windows endpoints from a central interface, alongside the built-in Windows Defender antivirus. Group Policy has been used to begin hardening the Windows endpoints, and a patch automation process has been implemented to centrally manage software updates. With Windows endpoints secured, the focus shifts to Linux endpoints.

Module 2: Configuring Secure Linux Endpoints

This module expands on the concepts from Module 1 and discusses how they apply to endpoints running a Linux operating system. As before, several tools are shown in the demos, but installing and configuring those tools in depth is outside scope.

Monitoring for Threats to Linux Endpoints

Antivirus solutions are available for Linux as well, and remain one valuable layer of endpoint defense, using signature-based detection to detect, alert on, and in some cases remove known malware.

EDR and XDR solutions are also available for Linux, typically providing the same monitoring capabilities described for Windows endpoints. In many cases, the same EDR/XDR platform can cover both Windows and Linux endpoints — Wazuh, used as an XDR solution for Windows in Module 1, is one example of a tool that also supports Linux.

File integrity and encryption carry the same goals on Linux as on Windows: detecting potentially malicious activity by monitoring critical files and directories for change. The Linux file system differs significantly from Windows, so some configuration differences — or in some cases, different tooling — should be expected. For encryption, most Linux distributions offer full-disk encryption that can be configured at install time.

For the Globomantics scenario’s Linux endpoints:

Antivirus: ClamAV, an open-source antivirus toolkit for scanning files and detecting threats.
XDR / File Integrity: Wazuh, the same platform used for Windows, extended to Linux via agents — this conveniently provides file integrity monitoring as well.
Centralized Logging: The Elastic Stack, used for log collection, searching, and visualization.

flowchart LR
    subgraph Windows["Module 1: Windows Endpoints"]
        WAV[Windows Defender]
        WXDR[Wazuh XDR]
        WLog[Windows Event Collector]
    end
    subgraph Linux["Module 2: Linux Endpoints"]
        LAV[ClamAV]
        LXDR[Wazuh XDR + FIM]
        LLog[Elastic Stack]
    end
    WXDR -.same platform.-> LXDR

Demo: Wazuh for Linux Endpoint Monitoring

Using the same Wazuh server from the Windows module, review the Security Events dashboard filtered to only the Linux endpoints (excluding the Docker host).
Drill into the Security Alerts section and open an alert — for example, the first time a user executed a sudo command on a given host.
The alert’s full log details show the user who issued the command (in the lab example, the administrator) and the exact command entered (a shutdown command on that host).
As with Windows alerts, a MITRE ATT&CK technique mapping is available where applicable, along with associated mitigations and tactics.
Agent-level views provide additional breakdowns of alerts, plus compliance information, recent events, and a CIS benchmark score for that Linux endpoint.

Demo: File Integrity Monitoring on Linux Endpoints

On the Wazuh Security Events dashboard, locate alerts for file integrity checksum changes (in the lab, several were found on the second page of alerts).
Open one of these alerts and review the full log in table view: the name of the changed file, the old and new checksums across three different hash functions, the size change, and the modification time.
By default, Wazuh monitors a defined set of directories containing critical files and uses checksums across multiple hash algorithms to detect any change within those directories, running regular checks and generating an alert in this format for each detected change.

Web Application Firewalls

Web servers must be exposed to the internet to provide their service, which makes them a natural target for attack. A Web Application Firewall (WAF) is an additional layer of defense for endpoints acting as web servers. Multiple WAF form factors exist, but endpoint-level protection requires a host-based WAF. Once installed, it monitors and filters web traffic arriving from the internet.

WAFs are particularly useful for protecting against attacks such as:

Path traversal — exploited to access parts of the file system outside the web root.
File inclusion — enables remote code execution on the endpoint.
SQL injection — another common path to remote code execution on web server endpoints.

flowchart LR
    Internet((Internet Traffic)) --> WAF[Host-Based Web Application Firewall]
    WAF -- filters --> Attacks{{Path Traversal / File Inclusion / SQL Injection}}
    WAF -- allows --> App[Web Application on Endpoint]

Hardening Measures for Linux Endpoints

Securing SSH access. SSH is the primary method for remotely administering Linux endpoints, so securing it is a priority:

Disable root login, using sudo instead for privileged actions. The root account has complete control over the endpoint, and actions taken directly as root cannot be traced back to an individual user. sudo allows temporary privilege elevation while preserving traceability to the user who ran the command.
Disable host-based authentication. Host-based authentication lets one host authenticate to remote devices and allows users to log in remotely without a key or password — a convenience that trades away accountability and security.
Disable empty passwords, and prefer key-based authentication over username/password authentication entirely. If passwords must be used, they should never be permitted to be blank, and remote login should never be permitted without entering credentials at all.

Reducing the attack surface. As with Windows, unnecessary components should be removed or disabled on Linux endpoints — for example, removing legacy remote-access packages like Telnet, which transmits session data without encryption. Unused packages in general should be removed: they provide no benefit while still expanding the attack surface and requiring ongoing patching. The strongest version of this principle is starting from a minimal install and adding only the software that is actually needed.

mindmap
  root((Linux SSH Hardening))
    Disable Root Login
      Use sudo for elevation
      Preserves traceability
    Disable Host-Based Auth
      Prevents passwordless remote login
    Disable Empty Passwords
      Prefer key-based auth
    Reduce Attack Surface
      Remove legacy services (e.g. Telnet)
      Remove unused packages
      Start from minimal install

Demo: Hardening a Linux Endpoint’s SSH Configuration

The SSH daemon configuration file (sshd_config) is edited directly to apply hardening changes.

# /etc/ssh/sshd_config

# Disable root login
PermitRootLogin no

# Disable host-based authentication
HostbasedAuthentication no

# Disable empty passwords
PermitEmptyPasswords no

# Limit authentication attempts to mitigate brute-force attacks
MaxAuthTries 3

# Close idle/unattended sessions after 300 seconds
ClientAliveInterval 300

Steps taken in the demo:

Locate the PermitRootLogin parameter and set it to no.
Locate HostbasedAuthentication and set it to no.
Locate PermitEmptyPasswords and set it to no.
Add MaxAuthTries 3 to limit authentication attempts and mitigate brute-force login attacks.
Add ClientAliveInterval 300 to automatically close idle or unattended sessions after 300 seconds.

A further improvement, not implemented in this specific demo but noted as a recommended next step, is switching from username/password authentication to public/private key authentication entirely.

Patch Automation for Linux

Linux patch automation shares most of the same considerations and security trade-offs already discussed for Windows. Beyond those, it’s important to define a testing and management policy and procedure covering the entire patch lifecycle: scanning for vulnerabilities and required patches, submitting and reviewing change requests, testing patches before deployment, and finally applying them to production systems.

A backout plan is an essential part of any patching process, in case a patch causes issues — this allows production servers and services to be restored, and should be built into the change request review and approval process.

Automated patch solutions for Linux vary by distribution. Ubuntu offers Landscape, a patch management system that provides a web console for managing systems centrally.

flowchart TD
    A[Vulnerability / Patch Scan] --> B[Change Request Submitted]
    B --> C[Change Request Reviewed/Approved]
    C --> D[Patch Tested in Non-Production]
    D --> E{Testing Successful?}
    E -- No --> F[Document Issue / Revisit Patch]
    E -- Yes --> G[Apply Patch to Production]
    G --> H{Issue in Production?}
    H -- Yes --> I[Execute Backout Plan]
    H -- No --> J[Patch Cycle Complete]

Demo: Ubuntu Patch Automation with Landscape

In the Landscape web console, review the endpoints registered with the server — in the lab, three Ubuntu endpoints are registered.
The Alerts section at the bottom of the window surfaces notifications, such as computers with available upgrades, computers that have not checked in with Landscape within a set window (for example, 5 minutes), or computers that need to be rebooted.
The Computers menu shows the last time each endpoint contacted the Landscape server.
The Packages submenu shows how many packages are installed on each endpoint and how many upgrades are available.
The Request upgrades button applies all available upgrades to selected endpoints.
To manage which upgrades are applied, select the upgrade count in the package information table and mark specific upgrades for delivery.

Using an automated tool such as Landscape lets administrators manage patching and other package-management tasks for Linux endpoints from a single central console.

Module 2 Recap

By the end of this module, Linux endpoint monitoring has been configured using Wazuh as the XDR solution, which also enables file integrity monitoring of directories containing critical files. SSH has been hardened to secure remote access, and a centralized automated patch management solution (Landscape) has been configured. With Windows and Linux endpoints secured, only one endpoint type remains: containers.

Module 3: Configuring Secure Containers

This module explores the security considerations for container endpoints and the configuration differences compared to traditional or virtualized endpoints.

Containers vs. Virtual Machines: Security Considerations

Understanding why container security measures differ starts with understanding the architectural difference between virtual machines and containers.

Virtual machines: starting from a VM host, a hypervisor is installed to serve as the platform for virtual machines (examples include VMware Workstation, VMware ESXi, Oracle VirtualBox, and Proxmox, depending on the chosen hardware). Each virtual machine requires a full guest operating system, on top of which applications run to provide services to the network.

Containers: starting from the same hardware, an operating system is installed that runs a container engine (such as the Docker engine) instead of a hypervisor. Containers only include the components necessary to run the application — they are not a full guest operating system like a VM. This allows containers to use far fewer resources and to run on virtually any platform that supports the engine.

flowchart TB
    subgraph VM["Virtual Machine Stack"]
        VMHW[Physical Hardware] --> Hyp[Hypervisor]
        Hyp --> Guest1[Guest OS #1]
        Hyp --> Guest2[Guest OS #2]
        Guest1 --> App1[Application]
        Guest2 --> App2[Application]
    end
    subgraph CT["Container Stack"]
        CTHW[Physical Hardware] --> HostOS[Host Operating System]
        HostOS --> Engine[Container Engine e.g. Docker]
        Engine --> C1[Container #1<br/>App + minimal deps]
        Engine --> C2[Container #2<br/>App + minimal deps]
    end

This architectural difference drives security considerations. Because containers require very few resources, they have little headroom for extra software, so security agents generally should not run inside individual containers. Instead, agents are configured on the container host, monitoring the containers running on the installed container engine. This does limit what can be observed directly inside a container, but it still allows:

Capturing events related to the container engine itself
Capturing container resource usage and identifying anomalies that may signal malicious activity
Capturing container health status and uptime, to identify other operational issues

Aspect	Virtual Machine	Container
Isolation Layer	Hypervisor	Container engine (shares host kernel)
Guest OS Required?	Yes, full OS per VM	No — only application + minimal dependencies
Resource Overhead	Higher	Lower
Where Security Agents Run	Inside the guest OS	On the container host, not inside individual containers
Portability	Tied to hypervisor/hardware compatibility	Runs on any host supporting the container engine

Demo: Monitoring Containers with Wazuh

Container monitoring in Wazuh requires custom configuration files, which is outside the scope of this material, but a walkthrough is available from the Wazuh project’s own documentation for setting this up.

Following the referenced walkthrough, configure Wazuh to monitor a Docker host.
Install several Docker containers and trigger alerts to confirm monitoring is functioning, viewing the results in the Wazuh dashboard.
Filter the Wazuh Security Events dashboard to the Docker host to review Docker container events, container health events, and container resource alerts.
In the Security Alerts section, review individual alerts:
- Alerts with rule ID 100100 are resource-usage notifications.
- Alerts with rule ID 87924 correspond to container kill actions. Both of these are built-in Wazuh rules, not custom rules.
A separate view surfaces notifications confirming containers are healthy — for example, once a synthetic load-generation tool (stress-ng) is no longer running against the container.

sequenceDiagram
    participant Container as Docker Container
    participant Engine as Container Engine (Docker)
    participant Agent as Wazuh Agent (on Host)
    participant Wazuh as Wazuh Manager

    Engine->>Agent: Container engine events (start/stop/health/resource usage)
    Agent->>Wazuh: Forward events
    Wazuh->>Wazuh: Match against rules (e.g. 100100 resource, 87924 kill action)
    Wazuh-->>Wazuh: Generate alert
    Note over Wazuh: Dashboard shows container health,<br/>resource alerts, and kill-action alerts

Using this configuration, the status of containers on a monitored host can be tracked from the same centralized tool used for Windows and Linux endpoints.

Hardening Measures for Containers

Containers introduce one additional consideration not present with other endpoint types: container escape.

Container escape begins with an attacker gaining access to a container. From there, the attacker may exploit a vulnerability in the container engine to execute malicious code that grants access to the underlying host directly. Once on the host, the attacker can execute commands and additional code to pivot further into the rest of the network.

sequenceDiagram
    participant Attacker
    participant Container
    participant Engine as Container Engine
    participant Host as Host OS
    participant Network as Rest of Network

    Attacker->>Container: Gain initial access (e.g. via vulnerable app)
    Container->>Engine: Exploit container engine vulnerability
    Engine->>Host: Malicious code executes with host access
    Host->>Network: Attacker pivots / lateral movement

Several hardening measures reduce this risk, and also raise the difficulty of the initial container-level exploitation:

Do not run privileged containers, and do not run containerized workloads as root. This alone does not prevent container escape, but it forces an attacker to first escalate privileges within the container to obtain root-level capabilities before attempting to escape it.
Secure computing mode (seccomp) profiles for Docker. Seccomp is a Linux feature usable within Docker to restrict the system calls available to a container, enabling containers to run with least privilege. Docker ships a default seccomp profile out of the box.
Image signing / using signed images. Image signing uses a digital signature to validate the contents of an image and confirm it has not been modified. The image creator signs a hash of the image using their private key; anyone can then use the corresponding public key to validate that the image originated from that creator and was not altered afterward. Once validated using the public key, an image can be trusted to run, assuming the original creator is trusted.
Minimize unnecessary services and packages — the same general hardening principle applied to Windows and Linux endpoints applies equally to container images.

Hardening Measure	What It Does	Prevents Escape Alone?
Avoid privileged containers / avoid running as root	Forces privilege escalation within the container first	No, but raises the bar significantly
Seccomp security profiles	Restricts available system calls to the minimum required	Reduces exploitable surface
Image signing	Cryptographically validates image origin/integrity	Prevents running tampered/untrusted images
Minimize services/packages in the image	Reduces overall attack surface	Reduces exploitable surface

sequenceDiagram
    participant Creator as Image Creator
    participant Registry as Image Registry
    participant Consumer as Consuming Host

    Creator->>Creator: Compute hash of image
    Creator->>Creator: Sign hash with private key
    Creator->>Registry: Push signed image
    Consumer->>Registry: Pull image
    Consumer->>Consumer: Validate signature using creator's public key
    alt Signature valid
        Consumer->>Consumer: Trust image (if creator is trusted)
    else Signature invalid or missing
        Consumer->>Consumer: Reject image
    end

Demo: Verifying and Enforcing Image Signing in Docker

Docker ships with tooling to inspect and enforce image signatures.

# Inspect low-level signature information for an image:
# which tags are signed, who signed them, and who can sign new tags
docker trust inspect <image>:<tag>

If no signatures exist for the requested image, docker trust inspect reports that there are no signatures or that it cannot access the image.

Docker also provides a DOCKER_CONTENT_TRUST setting to enforce that only signed images may be pulled onto a machine:

# Enable Docker Content Trust enforcement
export DOCKER_CONTENT_TRUST=1

# Attempting to pull an unsigned image now fails
docker pull <unsigned-image>:<tag>
# Error: no trust data for <unsigned-image>:<tag>

# Pulling a signed, official image succeeds
docker pull ubuntu:latest

With DOCKER_CONTENT_TRUST enabled, an attempt to pull a random, unsigned image from Docker Hub returns an error stating there is no trust data for that image, while pulling a trusted, officially signed image (such as ubuntu) succeeds normally. This setting is a simple, effective way to enforce the use of signed images across an environment.

Summary

This material covered the monitoring, hardening, and patch-automation practices needed to secure Windows, Linux, and container endpoints — the three endpoint categories in the Globomantics scenario.

For Windows endpoints, an XDR solution (Wazuh) was configured to monitor endpoints and their file integrity from a central console, complementing built-in antivirus (Windows Defender). Group Policy was used to apply a consistent set of hardening changes across an organizational unit, and a third-party patch automation solution (PDQ Deploy) was used to manage software updates.

For Linux endpoints, the same monitoring platform was extended via additional Wazuh agents, providing equivalent visibility and file integrity monitoring. SSH access was hardened by disabling weaker authentication methods and root login, and Landscape was used to manage automated patching for Ubuntu systems.

For container endpoints, the architectural differences from virtual machines were reviewed to explain why container security agents live on the host rather than inside each container. Wazuh was configured to monitor containers on a Docker host, and Docker Content Trust was configured to enforce the use of signed images, guarding against tampered or untrusted container images.

Key Principles

Defense in depth applies at the endpoint level too — antivirus, centralized logging, HIDS, EDR, and XDR each add a layer of capability, and no single layer is sufficient on its own.
Least privilege and separation of duties reduce the blast radius of any single compromised account, on any platform.
File integrity monitoring and encryption solve different problems — integrity monitoring detects tampering; encryption protects confidentiality if a device or file is accessed or stolen.
Automation is necessary at scale, but it is a trade-off — automated patch and configuration management dramatically reduces manual effort and risk exposure, at the cost of requiring broad remote access/administration capability and the operational discipline (testing, backout plans) to avoid large-scale outages.
Containers are not “just small VMs” — their shared-kernel architecture changes where monitoring agents belong and introduces container escape as a distinct risk that virtual machines do not share in the same way.
Trust must be verifiable, not assumed — image signing and checksum validation replace “it looks fine” with a cryptographic guarantee that content has not been altered.

Quick Reference

Endpoint Type	Antivirus / EDR-XDR	File Integrity	Hardening Focus	Patch Automation
Windows	Windows Defender + Wazuh (XDR)	Wazuh FIM (registry + file changes)	Least privilege, disable unneeded services, DEP/SEHOP/ASLR, GPO-based rollout	WSUS, MECM, or third-party (e.g. PDQ Deploy)
Linux	ClamAV + Wazuh (XDR)	Wazuh FIM (checksum-based, multi-hash)	Disable root login, disable host-based auth, key-based SSH, minimal install	Distribution-specific (e.g. Ubuntu Landscape)
Containers	Host-level agent (not per-container)	Engine/health/resource monitoring on host	Avoid privileged/root containers, seccomp profiles, image signing	Image rebuild-and-redeploy pipeline; signed images enforced via `DOCKER_CONTENT_TRUST`

Endpoint Hardening Checklist

Search Terms

security · engineering · securing · endpoints · cybersecurity · fundamentals · networking · systems · windows · linux · monitoring · hardening · containers · endpoint · wazuh · automation · configuring · integrity · measures · patch · secure · scenario

Table of Contents