Skip to content

Security Baseline

This document outlines the baseline security principles of the HomeOps Server Foundation. The goal is to define a clear, minimal, and auditable security posture for the platform foundation phase.

This baseline focuses on principles and intent rather than detailed configurations or enforcement mechanisms.

Table of Contents

  1. Security Scope
  2. Identity and Access Model
  3. Secure Remote Access (SSH)
  4. Network Security Principles
  5. Firewall Philosophy
  6. Logging and Visibility
  7. Related Architecture Decisions
  8. Documentation Boundary
  9. Hardening Log
  10. Administrative Access Hardening (Phase 1)
  11. Attack Surface Reduction (Phase 1)

Security Scope

The security baseline at this stage applies to:

  • The Proxmox VE host
  • Management access paths
  • Identity and access model
  • Network exposure principles

Detailed configuration steps and hardening measures are documented in internal project documentation.

↑ Back to top

Identity and Access Model

  • The Proxmox host is administered through authenticated management access.
  • Privileged access is limited to designated administrative users.
  • Role separation is preferred over shared credentials.
  • Interactive access is intended for administration only, not for application runtime.

The user and permission model is defined to support traceability and controlled access, even in a single-admin environment.

↑ Back to top

Secure Remote Access (SSH)

  • Remote administrative access is performed over SSH.
  • SSH is treated as a management interface, not a general-purpose access method.
  • Password-based access is avoided in favor of key-based authentication where possible.
  • SSH exposure is limited to trusted networks.

Detailed SSH configuration and hardening steps are maintained in internal documentation.

↑ Back to top

Network Security Principles

  • The Proxmox host exposes only required management services.
  • No application services are directly exposed from the host.
  • Network segmentation is planned but not yet implemented in Phase 1.
  • IPv6 is intentionally not enabled during the initial foundation phase.

The network design prioritizes predictability and minimal exposure over flexibility at this stage.

↑ Back to top

Firewall Philosophy

  • No host-level firewall rules are actively enforced during the initial foundation phase.
  • Firewall policies will be introduced incrementally once service roles are defined.
  • Network-level controls (e.g. upstream router) provide the primary perimeter at this stage.

Firewall rules and enforcement details will be introduced in later phases and documented separately.

↑ Back to top

Logging and Visibility

  • System logs are retained locally on the host.
  • Administrative actions are intended to be traceable.
  • No centralized logging is deployed during Phase 1.

Logging and observability will be expanded as hosted services are introduced.

↑ Back to top

The security posture described in this document is based on the following architecture decisions:

↑ Back to top

Documentation Boundary

This document intentionally avoids:

  • IP addressing details
  • Firewall rule definitions
  • Authentication secrets
  • Host-level hardening commands

Such details are maintained exclusively in internal project documentation to support secure operation and rebuildability.

↑ Back to top

Hardening Log

Administrative Access Hardening (Phase 1)

During the foundation phase, administrative access to the Proxmox VE host was hardened to establish a secure and traceable baseline.

The following measures were implemented:

SSH Hardening

  • Dedicated named administrative user created
  • Host-specific Ed25519 SSH key deployed
  • Password-based authentication disabled
  • Keyboard-interactive authentication disabled
  • Direct root login over SSH disabled
  • SSH access restricted to key-based authentication only

Result: - Brute-force and password-based attacks eliminated - All remote administrative actions attributable to a named identity

User Model Alignment (Linux and Proxmox)

Administrative access was unified across:

  • SSH access (Linux user)
  • sudo privilege escalation
  • Proxmox Web UI access (@pam realm)

Root account policy:

  • Root retained for break-glass use only
  • No direct SSH login permitted
  • Daily operations performed via named administrative user

Result: - Clear separation between operational and emergency access - Improved auditability and traceability

Sudo and Audit Baseline

  • sudo privileges explicitly assigned via group membership
  • Passwordless sudo not enabled
  • All escalation events logged via systemd-journald
  • Default PAM configuration retained
  • No external identity providers introduced in Phase 1

Result: - Privilege escalation remains explicit and logged - Authentication stack remains predictable and simple

↑ Back to top

Attack Surface Reduction (Phase 1)

  • Unused network services removed
  • Local mail transport removed
  • Security patching automated (Debian security repositories only)
  • Non-security and Proxmox upgrades require manual administrative approval

↑ Back to top