In Ubuntu Server and other systemd-based Linux distributions, systemd-journal-remote.service is an early-boot daemon responsible for actively receiving, parsing, and storing systemd journal logs transmitted over a network from other Linux machines. When enabled, it configures the local server to act as a centralized log aggregation endpoint, listening on a dedicated network socket (typically HTTPS on port 19532) for incoming journal entries. In modernised, highly segregated microservice architectures, ephemeral cloud instances, or standalone perimeter servers, allowing an endpoint to act as a log receiver creates a massive, unnecessary network attack surface. Exposing the local system’s logging infrastructure to network writes allows malicious actors to potentially perform log injection attacks, exhaust disk space (Denial of Service), or exploit parsing vulnerabilities in the daemon.
This guide explains how to completely disable the systemd-journal-remote service in Ubuntu Server, enforcing an absolute block on remote log reception and stripping the boot sequence down to its bare, secure essentials.
Stop and Mask the systemd-journal-remote Service
Because systemd-journal-remote is heavily integrated into the systemd network targets and can be dynamically invoked by socket activation (systemd-journal-remote.socket), a simple systemctl disable is fundamentally insufficient. The init system may still spin up the binary if network traffic hits the designated port. To guarantee the system is physically prevented from executing this remote logging listener, we must explicitly mask both the service and its associated socket.
- Log into your Ubuntu Server via SSH using an account with
sudoprivileges. - Stop the socket and service to clear any active network listeners in memory:
sudo systemctl stop systemd-journal-remote.socket systemd-journal-remote.service - Disable both units to remove their explicit dependencies from the standard boot targets:
sudo systemctl disable systemd-journal-remote.socket systemd-journal-remote.service - For absolute certainty, explicitly mask both units. This symlinks the unit files to
/dev/null, creating a hard cryptographic block against them being invoked dynamically during the startup sequence or by any network events:sudo systemctl mask systemd-journal-remote.socket systemd-journal-remote.service
Verify the Service Lockdown
By masking the socket and service, you guarantee that systemd will completely bypass the initialization of the remote journal receiver, optimizing the boot phase and securing the network perimeter.
To verify the lockdown is successful, attempt to start the socket manually:
sudo systemctl start systemd-journal-remote.socketSystemd will return a fatal error stating that the unit is masked (e.g., Failed to start systemd-journal-remote.socket: Unit systemd-journal-remote.socket is masked). Furthermore, running ss -tuln | grep 19532 will confirm that the server is no longer listening on the remote logging port, successfully neutralizing the daemon.