CRS-LNX-01
Linux administration, systemd service sandboxing, and server hardening
Every web gateway, database engine, and model connector runs inside an operating system process governed by user identifiers, kernel capabilities, and socket bindings. Mastering defensive Linux administration gives an engineer direct visibility into listening ports, file permissions, and service boundaries before any application scanner is launched.
1. Kernel namespace confinement and network perimeter architecture
nftables blocks exposed internal sockets, while the systemd mount namespace locks operating system directories read-only around a single state folder.2. Inspecting sockets, capabilities, and service units without guesswork
Unintended network exposure frequently starts when a database, cache server, or debugging agent binds to all network interfaces on 0.0.0.0 instead of the loopback address 127.0.0.1. Running ss -tulpen reveals the exact listening address, transport protocol, owning user identifier, and process descriptor for every open port on the machine.
Remote administration over Secure Shell (SSH) requires disabling password logins and direct superuser sessions inside /etc/ssh/sshd_config so brute-force dictionary traffic fails at the transport handshake. Administrators verify syntax with sshd -t prior to reloading the daemon while keeping an active recovery terminal open.
Modern Linux distributions include built-in kernel namespace and system-call confinement inside systemd unit files without requiring external container runtimes. Directives such as NoNewPrivileges=yes, ProtectSystem=strict, ProtectHome=yes, and an empty CapabilityBoundingSet= strip root escalation paths even if a worker process suffers a parser bug.
| Command, Display Filter, or Primitive | Observed Technical Artifact | Operational Interpretation |
|---|---|---|
ss -tulpen | Active TCP and UDP listening sockets with process names and numeric user identifiers | Detects internal databases or test servers accidentally bound to public network interfaces |
sshd -T | grep -E 'permitroot|passwordauth' | Effective parsed Secure Shell daemon authentication settings | Confirms that password authentication and direct superuser logins are turned off |
systemd-analyze security app.service | Quantitative exposure score and missing unit sandboxing directives | Highlights writable filesystem paths, unrestricted capabilities, and missing syscall filters |
nft list ruleset | Active netfilter tables, chains, and default policy counters | Verifies that inbound traffic is dropped by default except on explicitly authorized ports |
find / -perm -4000 -type f 2>/dev/null | All binaries carrying the set-user-identifier (SUID) permission bit | Identifies privileged helper executables that could permit local privilege escalation |
3. Laboratory practicum and transition to automated verification
systemd, and enforcing default-drop packet rules.In an isolated virtual machine, the engineer creates a dedicated unprivileged account, applies the unit drop-in configuration shown below, and verifies with systemd-analyze security that filesystem mutation outside the state directory is rejected by the kernel.
# 1. Inspect listening sockets and verify zero unintended 0.0.0.0 bindings
sudo ss -tulpen
# 2. Harden /etc/systemd/system/api-worker.service.d/hardening.conf
[Service]
User=api-worker
Group=api-worker
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ReadWritePaths=/var/lib/api-worker
CapabilityBoundingSet=
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
# 3. Reload unit definitions and measure the updated exposure score
sudo systemctl daemon-reload && systemd-analyze security api-worker.serviceManual host hardening establishes the operating baseline, whereas multi-node releases require continuous checks against configuration drift. On the INDRA platform, static configuration verifier TOOL-COD-05 inspects container definitions and server blocks automatically, while classes INJ-CMD and CLD-K8S-06 verify runtime confinement.
4. Engineering reference notes for module CRS-LNX-01
Preventing administrator lockout when hardening OpenSSH configurations
Before restarting the sshd service, the administrator tests the configuration file with sudo sshd -t, keeps the current privileged terminal session open, and verifies key-based login in a second separate terminal window.
Difference between running a daemon under a non-root user and enabling ProtectSystem=strict
A standard unprivileged user can still read world-readable files across /etc, write to shared /tmp directories, and invoke unguarded setuid binaries, whereas ProtectSystem=strict with NoNewPrivileges=yes mounts the operating system tree read-only inside an isolated mount namespace.
Binding a web worker to port 443 without granting full superuser privileges
Instead of starting the application daemon as root, the unit file grants only the single ambient capability AmbientCapabilities=CAP_NET_BIND_SERVICE or delegates external transport termination to a reverse proxy talking to 127.0.0.1.
Choosing SystemCallErrorNumber=EPERM instead of immediate process termination in seccomp filters
Returning EPERM causes blocked system calls to fail cleanly with a standard permission error in application logs, allowing engineers to diagnose missing unit allowances during staging tests without silent crashes.
Enterprise pilot packages and air-gapped delivery
Perimeter posture, transport security & localization
Streebog-256 verification passport.Air-gapped interface verification (indra-core)
OpenAPI schemas and an isolated staging container as input, delivering a thirty-class paired decoy assessment with zero false positives, compiled mcp-sentinel contracts, and a full ledger passport.Autonomous agent runtime gate (MITR)
mcp.json manifests and tool schemas as input, delivering compiled satisfiability policies and pre-socket parameter enforcement.Request the offline kit or schedule a pilot
--no-index --find-links) and standalone verifier scripts are provided for isolated laboratory testing and enterprise pilot evaluations. Submit a work email below without page reload or write directly to af@isslab.ai.
Institutional developer and platform operator
OGRN 1267700083617, INN 9731161602, KPP 773101001, 18 Davydkovskaya Street, Suite VIII, Moscow, 121352). Under the Security 3.0 research and engineering program, the institute develops and operates the MITR runtime action gateway and the INDRA verification stand, publishes the monograph Proven Action, and maintains open Apache-2.0 software packages with zero outside subcontractors.