Operating high-traffic internet-facing web applications requires treating host-level security as a primary architectural pillar rather than an afterthought. Far too many production servers run web applications, telemetry scrapers, and database daemons with excessive Linux root privileges, permissive filesystem permissions, and unhardened kernel network stacks. If an attacker identifies an unpatched vulnerability in an application dependency, running with root privileges grants immediate total control over the server. Establishing true host defense demands zero-root least privilege execution, systemd namespace sandboxing, and aggressive kernel sysctl hardening.
At multiDomainCMS, we host production services natively on Ubuntu/Debian Linux without relying on heavy virtualization or Docker container abstraction layers. While Docker provides isolated container images, running native user-space services delivers superior I/O throughput, raw hardware telemetry visibility, and lower memory overhead. However, native hosting requires deliberate, rigorous Linux systemd sandboxing to ensure each application process is locked inside a virtual fortress with zero access to sensitive system paths.
The Systemd Sandboxing Fortress: Defense in Depth
Modern Linux distributions powered by systemd incorporate advanced kernel namespace and seccomp filtering capabilities directly into unit configuration files. By declaring sandboxing directives inside /etc/systemd/system/multidomaincms.service, we restrict process capabilities without modifying a single line of Node.js application code:
| Security Directive | Kernel Mechanism | Attack Vector Neutralized |
|---|---|---|
| ProtectSystem=strict | VFS mount namespace; mounts root filesystems as read-only. | Malicious binary injection, overwriting system configuration files in /etc. |
| NoNewPrivileges=true | prctl(PR_SET_NO_NEW_PRIVS) system call. | Privilege escalation via SUID binaries (e.g., sudo, su, pkexec exploits). |
| PrivateTmp=true | Filesystem mount namespace creating per-service /tmp directory. | Symlink race conditions, inspecting temp files created by other services. |
| CapabilityBoundingSet= | POSIX 1003.1e capabilities mask; drops all 41 root capabilities. | Raw socket sniffing, mounting filesystems, rebooting host, modifying firewall. |
Kernel Hardening: Essential sysctl.conf Network Parameters
The default Linux kernel network configuration is balanced for general-purpose desktop and local network environments. Exposing an unhardened server directly to public internet traffic leaves TCP networking vulnerable to SYN flood DDoS attacks, IP spoofing, and connection exhaustion.
Our production hosts enforce hardened TCP/IP kernel settings inside /etc/sysctl.d/99-security-hardening.conf:
# 1. Mitigate TCP SYN Flood Attacks net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_synack_retries = 2 # 2. Block IP Spoofing and Source Routing net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.default.accept_source_route = 0 # 3. Ignore ICMP Broadcast Echoes (Prevent Smurf Attacks) net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_responses = 1 # 4. Disable ICMP Redirect Acceptance (Prevent Man-In-The-Middle Routing) net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 # 5. Virtual Memory Security & Core Dump Restrictions fs.protected_hardlinks = 1 fs.protected_symlinks = 1 fs.protected_fifos = 2 fs.protected_regular = 2 fs.suid_dumpable = 0
SSH Hardening & Uncomplicated Firewall (UFW) Configuration
Remote administrative access is restricted to encrypted, key-authenticated SSH sessions. Passwords, root login, and legacy ciphers are disabled completely in /etc/ssh/sshd_config:
PermitRootLogin no: Eliminates brute-force attacks against the root superuser account. All administration must be conducted via a dedicated sudo user.PasswordAuthentication no: Requires authentic Ed25519 or 4096-bit RSA SSH keys. Passwords are never accepted over the wire.KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512: Restricts key exchange to modern quantum-resistant and forward-secret algorithms.MaxAuthTries 3: Drops connections immediately after three failed authentication attempts, severely crippling automated dictionary scanners.
Firewall Policy: Default Deny Ingress
The host firewall operates under a strict Default Deny Ingress policy. Only explicitly required ports are opened:
- Port 80/TCP (HTTP) & Port 443/TCP (HTTPS): Ingress permitted to Nginx edge gateway.
- Port 22/TCP (SSH): Ingress restricted to authorized administrative VPN or bastion subnets.
- Internal Ports (3000 Node, 27017 MongoDB, 9090 Prometheus, 3100 Loki): Bound exclusively to
127.0.0.1localhost loopback interface. External ingress from public network interfaces is blocked at the packet filter level, guaranteeing that telemetry and database services can never be accessed directly from the internet.
Automated Compliance Auditing and Kernel Integrity Monitoring
Hardening is not a one-time configuration; it requires continuous verification against configuration drift and unauthorized runtime modifications. In production bare-metal environments, we implement automated compliance checks that execute periodically:
- Systemd Sandboxing Score Verification: Systemd includes an automated security analyzer,
systemd-analyze security [service_name], which evaluates over 60 sandboxing directives and assigns an exposure score from 0.0 (safest) to 10.0 (exposed). Production Node.js, Prometheus, and MongoDB services are tuned to score below 2.5 ("OK/LOW RISK"). - AIDE (Advanced Intrusion Detection Environment): Daily cryptographic integrity hashes are computed for critical binaries (
/bin,/sbin,/usr/bin) and system configurations (/etc/systemd,/etc/nginx). Any unauthorized file modification immediately triggers an alert to our native userspace telemetry watchdog. - Restricted AppArmor Profiles: In addition to systemd sandboxing, supplementary AppArmor profiles enforce mandatory access control (MAC) policies, preventing worker processes from traversing parent directories outside
/var/www/and/opt/even if file system permissions are misconfigured.
| Security Layer | Hardening Mechanism | Threat Mitigated |
|---|---|---|
| Process Sandboxing | ProtectSystem=strict & PrivateTmp=true |
Filesystem tampering & temp-race vulnerabilities |
| Kernel Syscall Filtering | SystemCallFilter=@system-service |
Zero-day kernel privilege escalations |
| Network Perimeter | Loopback binding & Default Deny Ingress | Unauthorized direct access to internal databases/telemetry |
| Capability Restrictions | CapabilityBoundingSet= (empty) |
Root execution & setuid binary exploitation |
Frequently Asked Linux Hardening Questions
Why not just run everything in Docker containers for security?
Running Docker does not automatically guarantee security; poorly configured containers running as root inside the container can break out via kernel vulnerabilities. Furthermore, Docker introduces network bridge virtualization latency, filesystem overlay driver overhead, and complicates native host telemetry monitoring. Systemd sandboxing provides comparable or superior security isolation at the native Linux kernel level with zero performance penalty.
What is the risk of allowing MemoryDenyWriteExecute in systemd with Node.js?
MemoryDenyWriteExecute=true instructs the kernel to prevent creating memory mappings that are both writable and executable (W^X violation). While this blocks buffer overflow shellcode exploits, V8's JIT compilers (Maglev and Turbofan) require writing machine code to memory and executing it. In some environments, this directive must be adjusted or tested carefully to ensure V8 JIT compilation remains functional without falling back to slow interpreter mode.
How does TCP SYN cookies protect our web servers during a DDoS attack?
During a SYN flood attack, attackers send thousands of SYN packets with forged IP addresses, never completing the 3-way handshake. Normally, the server allocates state memory in the SYN backlog table for every connection, quickly causing kernel memory exhaustion. With net.ipv4.tcp_syncookies = 1, the server does not allocate memory; it encodes connection parameters into the sequence number of the SYN-ACK packet. State is only allocated when the legitimate client responds with a valid ACK packet.