Server hardening
Last updated: June 11, 2026
- Server hardening
- 1. Infrastructure-level quarantine
- 2. Severing OS-level logging services
- 3. Application-level daemon silencing
- 4. Enforcing RAM-only logging and disabling swap
- 5. Eliminating memory dumps and history
- 6. Disabling telemetry, bootloaders, and bloatware
- 7. Severing remote access
- 8. Network layer defense
- 9. Instance termination and cryptographic erasure
Server hardening
Our zero-knowledge architecture is not just a policy; it's enforced at the operating system level. Every proxy server is provisioned from a hardened machine image that strips the server of its ability to log data, capture memory dumps, or accept remote access. To ensure ongoing protection against emerging vulnerabilities, we regularly rebuild this image to incorporate the latest upstream security patches. Below is the exact sequence used to enforce our No-logs policy.
1. Infrastructure-level quarantine
Before we harden the internal operating system, we isolate the instance from the cloud provider's default infrastructure tooling. Cloud providers deploy automated management and security tools. If left active, these tools can bypass our OS-level restrictions and create persistent forensic artifacts.
We enforce the following rules at the infrastructure level:
- No snapshots: We do not create snapshots or use automated snapshot schedules (like AWS DLM or GCP Snapshot Schedules). Because proxy servers are designed as ephemeral, stateless routers, there's no persistent data to back up.
- No agentless scanning: We refuse to enable cloud-native threat detection and agentless scanning (including GCP Security Command Center VMTD, Amazon GuardDuty, and AWS Inspector). We guarantee that a ghost copy of your encrypted volume is never momentarily spun up, and your active memory is never probed from the hypervisor layer.
2. Severing OS-level logging services
We systematically terminate, disable, and permanently mask core services to prevent the generation of syslog, auth, and kernel logs.
Disabling rsyslog
We stop the traditional rsyslog service and mask it to prevent any background processes from waking it up.
systemctl disable --now rsyslog.service syslog.socket systemctl mask rsyslog.service syslog.socket
Disabling systemd-journald We stop the core logging service that collects data from all parts of the system, alongside all of its trigger sockets.
systemctl disable --now systemd-journald.service systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket systemctl mask systemd-journald.service systemd-journald.socket systemd-journald-dev-log.socket systemd-journald-audit.socket
Disabling the audit daemon
systemctl disable --now auditd systemctl mask auditd.service
Suppressing cloud-init boot telemetry
Cloud providers use cloud-init to configure instances on their first boot. By default, this process writes deployment metadata (which can include the initial deployment scripts, environmental variables, and configuration flags) directly to the disk. We overwrite the default configuration to ensure all runtime initialization data is thrown into a black hole rather than written to /var/log/.
tee /etc/cloud/cloud.cfg.d/05_logging.cfg <<EOF log_cfg: | [logger_root] level=CRITICAL handlers=nullHandler [handler_nullHandler] class=NullHandler args=() EOF
3. Application-level daemon silencing
Even with the operating system entirely stripped of its logging capabilities, we go a step further to ensure the proxy software itself is completely blind to the traffic it routes.
We forcefully override the proxy daemon's service manager configuration to run it in absolute silent mode. We instruct the runtime environment to disable all internal application logging and pipe all standard output and standard error streams directly into a black hole (/dev/null). The application is physically incapable of printing connection states, IP bindings, or errors.
mkdir -p /etc/systemd/system/evadity-proxy.service.d tee /etc/systemd/system/evadity-proxy.service.d/override.conf <<EOF [Service] StandardOutput=null StandardError=null Environment="LOG_LEVEL=off" EOF systemctl daemon-reload
4. Enforcing RAM-only logging and disabling swap
We disable swap memory and convert the primary logging directory into a volatile RAM disk (tmpfs). If an unmanaged background service attempts to create a rogue log, it writes to volatile memory, never touching the persistent disk, and vanishes completely when the proxy server is terminated.
Mounting /var/log to RAM
mkdir -p /var/log find /var/log -type f -delete if ! grep -qE '^\s*tmpfs\s+/var/log\s+tmpfs' /etc/fstab; then echo 'tmpfs /var/log tmpfs rw,nosuid,nodev,noexec,mode=0755,size=64m 0 0' | tee -a /etc/fstab fi systemctl daemon-reload mount -a
Disabling swap
swapoff -a sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
5. Eliminating memory dumps and history
We instruct the kernel to reject core dumps and aggressively wipe any residual system history generated during the initial boot sequence.
Preventing kernel core dumps By default, if a process crashes, the Linux kernel may write a core dump to the disk (a literal copy of the active RAM at the time of the crash). We explicitly override this at the kernel level to guarantee that unencrypted memory states and cryptographic keys are never written to the drive, even in the event of a catastrophic software failure.
echo "kernel.core_pattern=|/bin/false" | tee -a /etc/sysctl.d/99-disable-coredumps.conf sysctl -p /etc/sysctl.d/99-disable-coredumps.conf
Deleting existing crash reports and memory dumps
rm -rf /var/lib/systemd/coredump/* rm -rf /var/crash/*
Wiping command history and rotation utilities We neutralize the log rotation utility from the operating system and aggressively delete any residual command history generated during the initial provisioning sequence.
systemctl disable --now logrotate.timer logrotate.service systemctl mask logrotate.timer logrotate.service find /root /home -maxdepth 4 -name '.*history' -type f -delete find /var/log -type f -delete
6. Disabling telemetry, bootloaders, and bloatware
We strip the proxy server of unnecessary daemons, update checkers, and crash reporters that could leak system metadata to external servers.
Disabling firmware checkers and dynamic banners We stop and permanently mask native firmware update checkers, dynamic login banners that fetch remote content, and OS-specific telemetry timers.
Disabling native crash reporters We stop and mask native OS crash reporting daemons, forcefully rewriting their configuration files to permanently disable background crash reporting.
Removing remote management agents and telemetry We completely rip out the cloud providers' native management daemons alongside the operating system's built-in tracking packages. This blinds the GCP and AWS control planes, removes native package telemetry, and disables unnecessary storage daemons, ensuring no external entity can read internal memory states, active process lists, or system configurations.
systemctl disable --now amazon-ssm-agent.service systemctl mask amazon-ssm-agent.service systemctl disable --now google-cloud-ops-agent.service google-osconfig-agent.service systemctl mask google-cloud-ops-agent.service google-osconfig-agent.service systemctl disable --now multipathd.service multipathd.socket systemctl mask multipathd.socket multipathd.service
Enforcing absolute immutability To prevent background processes from unexpectedly writing update logs to disk, restarting daemons, or altering our tested security perimeter, we freeze the operating system state. We forcefully disable the native automated upgrade utilities and place a permanent hold on all background package managers. The proxy server operates as a completely static, immutable appliance.
7. Severing remote access
Once the proxy server is configured and the hardening sequence is complete, we permanently sever access to the machine. The SSH daemon is stopped and disabled at the service level, and the underlying SSH server packages are completely purged from the operating system. We cannot log in to your proxy server, even if we wanted to.
systemctl disable --now ssh.service systemctl mask ssh.service
8. Network layer defense
We enforce network-level isolation by crippling unused networking stacks, dropping topology probes, flushing internal routing caches, and deploying a default-drop firewall.
Disabling the IPv6 stack To prevent IPv6 routing leaks, shadow interfaces, or SLAAC (Stateless Address Autoconfiguration) bypasses, we completely disable the IPv6 stack at the kernel level. This ensures the proxy server operates exclusively over the IPv4 namespace.
echo "net.ipv6.conf.all.disable_ipv6 = 1" | tee -a /etc/sysctl.d/99-disable-ipv6.conf echo "net.ipv6.conf.default.disable_ipv6 = 1" | tee -a /etc/sysctl.d/99-disable-ipv6.conf sysctl -p /etc/sysctl.d/99-disable-ipv6.conf
Network stealth and topology masking We instruct the kernel to silently drop network discovery probes and routing manipulation attempts. By aggressively ignoring ICMP redirects and source-routed packets, the proxy server prevents attackers from mapping the network topology or altering established routing paths. We also disable ICMP echo replies, rendering the server effectively invisible to automated internet scanners.
tee /etc/sysctl.d/99-network-stealth.conf <<EOF net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.all.accept_source_route = 0 net.ipv4.icmp_echo_ignore_all = 1 EOF sysctl -p /etc/sysctl.d/99-network-stealth.conf
Disabling local DNS caching
We disable the local systemd-resolved cache to ensure no temporary records of DNS queries are held in the proxy server's active memory. Every query is routed directly without leaving a persistent or volatile footprint.
mkdir -p /etc/systemd/resolved.conf.d tee /etc/systemd/resolved.conf.d/nocache.conf <<EOF [Resolve] Cache=no EOF systemctl restart systemd-resolved
Default-drop firewall (nftables)
The nftables firewall acts as a strict gatekeeper. We apply a default drop policy, ensuring the proxy server silently blocks and discards all inbound network connections except for your encrypted traffic.
policy drop;: Default rule for all incoming traffic.tcp dport ${PROXY_PORT} accept&udp dport ${PROXY_PORT} accept: Explicit exceptions allowing inbound TCP and UDP traffic exclusively on the port dynamically assigned to your connection.ct state established,related accept: Connection tracking allows the proxy server to safely receive incoming replies for outbound traffic that you initiated (e.g., receiving webpage data back after fetching a secure website).
9. Instance termination and cryptographic erasure
The termination of a proxy server triggers a process known as cryptographic erasure (crypto-shredding).
All storage volumes attached to our cloud instances are encrypted at rest. When a proxy server is terminated, the unique data encryption key associated with the volume is permanently deleted.
Without this key, the encrypted data residing on the drive is permanently rendered into high-entropy cryptographic static. Even in the highly improbable event of immediate physical hardware seizure, a forensic team would recover nothing but irretrievable noise.
Simultaneously, the compute and network layers are dismantled. The hypervisor reclaims and zeroes out the active memory, and the ephemeral IP address is detached and discarded back into the provider's regional pool. Every functional component of the proxy server environment ceases to exist.