Skip to content

Security#

Vulnerability Scanning Best Practices

Overview

Key Points

  • VergeOS is a purpose-built, hardened hyperconverged OS — not a general-purpose Linux distribution
  • The management IP (web UI) is the only externally-reachable scan target in a properly deployed environment
  • Traditional vulnerability scanners have limited plugin coverage for VergeOS
  • Patching is handled exclusively through the built-in VergeOS update system

This article covers how to approach scanning the VergeOS platform, what to expect from scan results, and how to demonstrate patching compliance for audits. For scanning workloads running inside VMs and tenants, apply your organization's standard scanning policies.

Prerequisites

  • Administrative access to the VergeOS web UI
  • Familiarity with your organization's vulnerability scanning tool (e.g., Nessus, Qualys, Rapid7)
  • Understanding of VergeOS network concepts

VergeOS Security Architecture

Before configuring scans, it helps to understand how VergeOS differs from a traditional hypervisor or Linux server:

  • Read-only overlay filesystem — VergeOS runs a specialized kernel with a read-only overlay. Unsanctioned packages or modifications are not persistent and can cause system instability. This significantly reduces the attack surface compared to general-purpose operating systems.
  • No traditional package management — There is no apt, yum, or similar package manager. All patching is delivered through the built-in update system.
  • SSH disabled by default — SSH access is not required for normal operation. The web UI provides full administrative access, and node diagnostics are available directly from the interface.
  • Minimal external surface — Only the management IP (web UI) is intended to be externally reachable. Node NICs handle internal fabric traffic (vSAN and inter-node communication) on the core network and are not exposed to external networks in a standard deployment.

Management IP (Web UI)

The management IP is the only externally-reachable surface in a properly deployed VergeOS environment. Scanning this address provides results for:

  • The VergeOS web application and API
  • TLS certificate configuration
  • Any exposed network services

Start Here

For most compliance requirements, scanning the management IP is sufficient to demonstrate hypervisor vulnerability assessment.

Individual Node IPs

Node IPs are used for internal fabric traffic and are not externally accessible in a standard deployment. Scanning them is unnecessary.

What About Tenant and VM Networks?

Vulnerability scanning of workloads running inside VMs and tenants is separate from scanning the VergeOS platform itself. VMs are standard operating systems and should be scanned according to your normal policies. VergeOS provides network micro-segmentation to isolate workloads at the network level.

Configuring Your Scanner

Use an uncredentialed network scan policy (e.g., Nessus "Basic Network Scan" or equivalent). Avoid Linux-specific audit policies — these rely on package enumeration via SSH and will produce misleading or empty results against VergeOS.

Recommended scanner settings:

  • Scan type: Uncredentialed / remote network scan
  • Target: Management IP address (HTTPS on port 443)
  • Disable: Linux/Unix credentialed patch audit plugins, local security checks
  • Enable: Web application checks, TLS/SSL auditing, service detection

Limited Plugin Coverage

Because VergeOS is not a standard Linux distribution, vulnerability scanners will return limited results. Many scanner plugins detect vulnerabilities in common OS packages (e.g., Debian, RHEL) and have no specific checks for the VergeOS platform. This is expected behavior, not an indication that the system is unscanned.

Typical scan results for a VergeOS management IP:

  • OS identification: unknown or inconclusive
  • Open ports: 443/tcp (HTTPS)
  • Findings: informational items related to the web server and TLS configuration

If your results look like this, the scan is working correctly. VergeOS has a minimal attack surface by design. If your auditor requires additional evidence beyond scan results, see Patching and Update Guidance below.

Scan Frequency

Align scan frequency with your compliance framework requirements (e.g., quarterly for PCI-DSS, monthly for internal policy). Because VergeOS exposes a minimal attack surface, scan results are unlikely to change between platform updates — schedule scans after applying updates to capture the current state.

Credentialed vs. Uncredentialed Scans

Uncredentialed scans against the management IP are the recommended approach. These scans identify exposed services and known vulnerabilities without requiring host-level access.

Credentialed scans require SSH access, which is disabled by default in VergeOS. Enabling SSH for routine scanning is not recommended.

If your compliance framework specifically requires credentialed scanning:

  1. Enable SSH only for the duration of the scan.
  2. Restrict SSH access to the scanner's source IP using firewall rules.
  3. Disable SSH immediately after the scan completes.
  4. Document the temporary access in your compliance records.

See Enabling System SSH Access for the full procedure.

Patching and Update Guidance

VergeOS nodes are patched through the built-in update system, not through traditional OS package management. This is an important distinction for compliance and vulnerability remediation workflows.

Demonstrating Patch Compliance

For audit purposes, the following evidence can demonstrate that your VergeOS environment is patched and current:

  • Current version number — visible on the main dashboard and in System > Updates
  • Release notes — each VergeOS release documents security fixes (e.g., CVE-2024-6387 was addressed in the 4.12 release)
  • Update history — the Update Server Dashboard shows when updates were applied
  • Snapshot records — VergeOS can automatically create system snapshots before updates, providing a documented rollback point

Responding to Scanner-Reported CVEs

When a scanner flags a CVE against the management interface:

  1. Check the release notes to determine if the CVE has been addressed in the current or a newer VergeOS version.
  2. If an update is available that addresses the CVE, apply it through System > Updates.
  3. If the CVE is not addressed in any available release, contact VergeOS Support to report the finding and request guidance.

Sample Compliance Language

When documenting your hypervisor security posture for auditors, you can adapt the following:

"VergeOS is a purpose-built, hardened hyperconverged operating system with a read-only overlay filesystem and minimal external attack surface. The platform does not use traditional OS package management; all security patches are delivered through vendor-managed updates applied via the built-in update system. The current version [X.Y.Z] was applied on [date]. Release notes documenting CVE remediations for each version are available at docs.verge.io/release-notes."

Troubleshooting

Common Issues

  • Problem: Scanner cannot identify the operating system

  • Solution: VergeOS is a custom OS and may not be fingerprinted by standard scanners. Note this in your compliance documentation as a hardened, purpose-built platform.

  • Problem: Credentialed scan requires SSH but it is disabled

  • Solution: See the Credentialed vs. Uncredentialed Scans section above. Enable SSH temporarily and with IP restrictions if required.

Additional Resources

Feedback

Need Help?

If you need further assistance or have any questions about this article, please don't hesitate to reach out to the VergeOS Support Team.

Secure Boot and Boot Integrity for Physical Nodes

Key Points

  • VergeOS does not use traditional UEFI Secure Boot for physical nodes
  • VergeOS implements its own boot integrity verification that prevents tampered images from booting
  • This approach provides practical tamper protection without the limitations of UEFI Secure Boot

Overview

VergeOS takes a different approach to boot security than traditional UEFI Secure Boot. While VergeOS physical nodes do not use BIOS-level Secure Boot, the system implements its own boot integrity mechanism that provides robust protection against tampering.

VergeOS Boot Integrity Protection

VergeOS has implemented its own methodology to ensure boot integrity. This mechanism verifies that the VergeOS image has not been modified or tampered with before allowing the system to boot.

How It Works

When a VergeOS node starts up, the system validates the integrity of the boot image. If the image has been tampered with or modified in any way, VergeOS will refuse to boot. This ensures that only authentic, unmodified VergeOS software runs on your infrastructure.

Comparison with Traditional UEFI Secure Boot

Aspect UEFI Secure Boot VergeOS Boot Integrity
Tamper protection Prevents boot of unsigned/modified OS Prevents boot of tampered VergeOS images
Alternative OS boot Blocks unsigned operating systems entirely Does not prevent booting a different OS
Implementation BIOS/firmware level, requires signed keys Software-level verification
Practical security Protects against unauthorized OS loading Protects against VergeOS image tampering

The key difference is timing and scope:

  • UEFI Secure Boot operates at the BIOS level and won't even attempt to boot an unsigned or unregistered operating system
  • VergeOS Boot Integrity allows the boot process to begin but will not complete boot if the VergeOS image has been tampered with

This means that while someone could theoretically install a completely different operating system on the hardware, they cannot modify the VergeOS image itself and have it boot successfully. Any tampering with VergeOS system files will be detected and prevent boot.

Why VergeOS Does Not Use UEFI Secure Boot

Traditional UEFI Secure Boot presents several challenges that make it impractical for VergeOS:

Certification Requirements

UEFI Secure Boot requires operating systems to be signed with keys that are registered in the system firmware. This process is controlled by a limited set of gatekeepers:

  • Microsoft maintains control over the primary Secure Boot key infrastructure
  • Only a small number of Linux distributions have registered Secure Boot keys (primarily Red Hat and Ubuntu)
  • Most Linux distributions that support Secure Boot actually bootstrap through Ubuntu's signed bootloader (shim) to load their own GRUB bootloader

Practical Limitations

For specialized operating systems like VergeOS, obtaining and maintaining Secure Boot certification would require:

  • Ongoing relationship with certificate authorities
  • Re-signing with each update
  • Dealing with potential key revocation scenarios

Security Implications

Practical Security

For most deployment scenarios, VergeOS boot integrity protection provides equivalent practical security to UEFI Secure Boot. Your VergeOS infrastructure is protected against image tampering, which is the primary concern for production environments.

What VergeOS Boot Integrity Protects Against

  • Modification of VergeOS system files
  • Injection of malicious code into the VergeOS image
  • Tampering with the boot process after VergeOS installation

What Requires Physical Security Controls

  • Installation of an entirely different operating system (requires physical access and storage reformation)
  • BIOS/firmware-level attacks (mitigate with physical security and firmware passwords)

Physical Security

As with any infrastructure, physical security of your nodes remains important. VergeOS boot integrity protects the software layer, while physical access controls protect against hardware-level attacks.

Disabling UEFI Secure Boot

Before installing VergeOS on physical nodes, you must disable UEFI Secure Boot in the system BIOS/UEFI settings. The specific steps vary by hardware manufacturer, but generally involve:

  1. Enter the BIOS/UEFI setup during system boot (typically F2, Del, or F10)
  2. Navigate to the Security or Boot section
  3. Locate the Secure Boot option and set it to Disabled
  4. Save changes and exit
  5. Proceed with the VergeOS installation

Pro Tip

Document your BIOS settings before making changes. Some enterprise servers may have additional security settings that interact with Secure Boot, such as TPM configuration or boot device restrictions.

Troubleshooting

Common Issues

  • Problem: Node fails to boot after VergeOS installation

  • Solution: Verify that UEFI Secure Boot is disabled in BIOS settings. Some systems may re-enable Secure Boot after firmware updates.

  • Problem: "Boot integrity check failed" error message

  • Solution: This indicates the VergeOS image has been modified. Re-download and reinstall VergeOS from an official source.

  • Problem: Cannot find Secure Boot option in BIOS

  • Solution: Check under Security, Boot, or Authentication menus. Some systems label it as "UEFI Security" or require administrator/setup password to access.

Additional Resources

Feedback

Need Help?

If you need further assistance or have any questions about this article, please don't hesitate to reach out to the VergeOS Support Team.

How to Add a TPM Device to a Virtual Machine

Overview

This article provides step-by-step instructions for adding a Trusted Platform Module (TPM) device to a virtual machine in VergeOS. TPM devices provide hardware-based security features including secure boot, encryption key management, and attestation capabilities.

Key Points

  • TPM devices enable hardware-based security features
  • Requires UEFI boot mode for full functionality
  • VM restart required after adding TPM device
  • Guest OS may require additional configuration

Prerequisites

Before adding a TPM device to your VM, ensure the following requirements are met:

  • UEFI Boot Mode: The VM should be configured to use UEFI boot for optimal TPM functionality
  • Supported Guest OS: Ensure your guest operating system supports TPM devices
  • VM Power State: The VM should be powered off before adding the TPM device
  • Proper Permissions: You must have modify permissions for the virtual machine

UEFI Boot Requirement

For Windows VMs requiring TPM (such as Windows 11), UEFI boot mode is mandatory. Legacy BIOS mode will not support TPM functionality.

Steps to Add TPM Device

1. Access VM Configuration

  1. Navigate to the VM Dashboard - Go to Virtual Machines > List - Double-click your target VM from the list

  2. Power off the VM if it's currently running - Click Power Off from the left menu if the VM is running - Wait for the VM to completely shut down

2. Enable UEFI Boot (if not already enabled)

  1. From the VM dashboard, click Edit in the left menu
  2. Locate the UEFI Boot option and enable it
  3. Click Submit to save the changes

UEFI Conversion

If converting an existing VM from Legacy BIOS to UEFI, create a snapshot before making changes to enable easy rollback if needed.

3. Add TPM Device

  1. From the VM dashboard, click Devices in the left menu
  2. Click New from the left menu

  3. Configure the TPM device settings: - Name: Enter a descriptive name (e.g., "TPM-2.0") or leave blank for auto-generation - Type: Select TPM from the dropdown - Description (optional): Add administrative notes about the device - Version: Select TPM version (typically TPM 2.0 for modern requirements)

  4. Click Submit to create the TPM device

4. Start the Virtual Machine

  1. From the VM dashboard, click Power On in the left menu
  2. Wait for the VM to boot completely
  3. Access the VM console to verify TPM functionality

Guest OS Configuration

Windows Configuration

For Windows guests (especially Windows 11):

  1. Verify TPM Detection - Open Device Manager - Look for "Security devices" section - Confirm TPM device is listed and functioning

  2. Enable TPM in Windows - Run tpm.msc from the Run dialog - Verify TPM status shows as "Ready for use" - Initialize TPM if prompted

  3. Configure BitLocker (if needed) - Go to Control Panel > System and Security > BitLocker Drive Encryption - Follow prompts to enable BitLocker with TPM

Linux Configuration

For Linux guests:

  1. Check TPM Detection 

    ls /dev/tpm*

  2. Install TPM Tools (if needed) 

    # Ubuntu/Debian
sudo apt-get install tpm2-tools

# RHEL/CentOS
sudo yum install tpm2-tools

  3. Verify TPM Functionality 

    tpm2_getcap properties-fixed

Troubleshooting

Common Issues

  1. TPM Not Detected in Guest OS - Solution: Verify UEFI boot is enabled and VM has been restarted - Check guest OS TPM driver support

  2. Windows 11 Installation Requirements - Solution: Ensure both UEFI boot and TPM 2.0 are enabled before installation - Use Windows 11 compatible installation media

  3. TPM Initialization Errors - Solution:

    1. Power off the VM completely
    2. Remove and re-add the TPM device
    3. Restart the VM and retry initialization

  4. BitLocker Configuration Issues - Solution: Ensure TPM is properly initialized before configuring BitLocker - Check Windows TPM management console (tpm.msc) for status

Performance Considerations

  • TPM devices have minimal performance impact on VM operations
  • No additional CPU or memory resources required
  • TPM operations are handled efficiently by the VergeOS hypervisor

Best Practices

  1. Backup Before Changes - Create a VM snapshot before adding TPM devices - Test TPM functionality in a development environment first

  2. Security Configuration - Enable Secure Boot alongside TPM for enhanced security - Configure appropriate TPM policies based on security requirements

  3. Documentation - Document TPM configuration for compliance and audit purposes - Maintain records of TPM-enabled VMs for security tracking

  4. Updates and Maintenance - Keep guest OS TPM drivers updated - Monitor TPM device status regularly - Include TPM configuration in VM documentation

Supported Features

With TPM enabled, your VM can support:

  • Secure Boot: Verify boot integrity and prevent unauthorized boot modifications
  • BitLocker Drive Encryption: Hardware-based encryption key management
  • Windows Hello: Biometric authentication (with additional hardware)
  • Device Attestation: Verify device integrity and compliance
  • Certificate Storage: Secure storage for digital certificates

Additional Resources

Document Information

  • Last Updated: 2025-07-02
  • VergeOS Version: 4.12.6+
  • Applies to: All VergeOS environments with TPM support