Home Lab Front-End Data Store: Security and Network Isolation

Security in this platform follows a strict deny-by-default model across the entire stack. No service is reachable merely because it has been installed, enabled or assigned a network interface. Every exposed service must have a clear operational purpose and an explicitly defined path to the systems that need it.

This principle is particularly important for the front-end data store node, HG000009. The system participates in several distinct network roles, but that does not mean those networks should be able to communicate through it.

Core security principle: connectivity is granted for a specific purpose, between specific systems, over specific interfaces. Everything else remains unavailable.

Network interfaces do not imply network transit

A host connected to several network segments can easily become an unintended routing point. This can happen through an explicit configuration change, an operating-system default, an incorrectly applied automation task or a temporary troubleshooting adjustment that quietly becomes permanent.

To remove that ambiguity, IP forwarding is disabled on HG000009. The server can communicate through its own interfaces, but it cannot act as a router between them.

Management network
        |
        |  SSH administration only
        v
+-------------------------------+
| HG000009                      |
| Front-end data store          |
|                               |
| IP forwarding: DISABLED       |
| Default exposure: DENIED      |
+-------------------------------+
        ^
        |  Authenticated iSCSI only
        |
Back-end storage network

This turns network separation into a structural property of the system. Traffic cannot accidentally pass from the management network into the storage network simply because both are attached to the same host.

If communication must cross a security boundary, it has to use an intentionally designed interface or an authorised gateway elsewhere in the architecture.

Expose only the service each segment requires

Each network segment has a clearly defined function. Service ports are therefore released only on the interfaces and address ranges that require them.

A management interface should expose management services. A storage interface should carry storage traffic. Neither should silently inherit the other’s access.

NETWORK ROLE          PERMITTED PURPOSE
--------------------  -----------------------------------
Management segment    Restricted SSH administration
Storage segment       Authenticated point-to-point iSCSI
Other segments        No access unless explicitly required
Host routing          Disabled

This approach reduces the number of assumptions hidden inside the configuration. An administrator investigating the system does not have to infer whether an open port is intentional. The permitted communication paths correspond directly to documented architectural roles.

Treat private storage networks as privileged

Back-end storage connectivity is provided exclusively through iSCSI. Although the relevant traffic travels over a private point-to-point path, that network is not treated as automatically trustworthy.

Storage access is a privileged operation. A compromised or incorrectly connected system with unrestricted access to block storage could damage filesystems, expose data or create corruption that is difficult to diagnose.

For that reason, the iSCSI relationship uses authentication and password protection at both ends. Access depends on an explicitly configured relationship between initiator and target, rather than physical or logical presence on a private network alone.

Private does not mean trusted. Network isolation reduces exposure, while authentication establishes whether a system is actually authorised to use the service. Both controls are necessary because they address different failure modes.

Constrain administrative access

All remote administration is performed through SSH. Administrative access is restricted by source address, and host identity is validated explicitly.

For this environment, the names and addresses of administrative endpoints are pinned through a locally maintained /etc/hosts file. This avoids making administrative access dependent on dynamic or external name resolution.

The intention is not to claim that a hosts file is universally preferable to properly managed DNS. It is a deliberate choice for this small, controlled environment: the relevant endpoints are few, stable and under direct administration.

The result is an administrative path whose dependencies are easy to inspect:

Authorised administration host
        |
        | Source IP permitted
        | Host identity expected
        | SSH authentication required
        v
HG000009 management interface

Structural enforcement is stronger than convention

Many security failures do not begin with the absence of policies. They begin when a policy depends too heavily on people remembering what they must never change.

A convention might say that storage traffic should remain isolated. A structural control disables routing and prevents the host from carrying that traffic elsewhere.

A convention might say that only authorised systems should connect to storage. A structural control requires an authenticated iSCSI relationship.

A convention might say that administration should occur only from known systems. A structural control limits the sources from which SSH is accepted.

Good infrastructure security reduces the number of correct behaviours that depend solely on memory and discipline. Wherever practical, the architecture itself should prevent prohibited behaviour.

Operational benefits beyond prevention

Clear network roles do more than reduce the attack surface. They also simplify operations.

When an unexpected connection appears, there are fewer legitimate paths to investigate. When a service becomes unavailable, the intended dependency chain is easier to follow. During recovery, administrators can restore one controlled path at a time rather than reconnecting a broadly trusted network.

The design provides:

• no unintended traffic forwarding between segments;
• segmentation enforced by the host configuration;
• explicit and authenticated storage relationships;
• a restricted administrative entry point;
• trust boundaries that are visible and testable;
• simpler threat modelling and incident analysis;
• more predictable behaviour during failures and recovery.

A boundary should be visible in the design

The most important outcome is not the use of a particular firewall rule, protocol or configuration file. It is the removal of ambiguity.

Every interface has a purpose. Every reachable service has a reason to be reachable. Every privileged relationship is explicitly authorised. Networks connected to the same machine remain separate unless the architecture deliberately provides a route between them.

If traffic needs to cross a boundary, it must do so through a defined and deliberate interface. Trust should never emerge merely because two systems happen to be connected.

AI Assistance Disclosure

This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.

Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.