Far less attention goes to the management servers that sit quietly in the back of a data centre or control room, monitoring and configuring the hardware that keeps a facility running. They are usually Linux machines; they often hold credentials for every device on the network, and they are frequently built once and then left alone for years.

That makes them one of the most valuable footholds an attacker can find. Compromise the management server and you do not need to break into each device individually. You already have the keys.

A Real-World Example From Satellite Ground Stations

Satellite ground stations show the problem clearly. Between the antennas and the modems sits a layer of RF distribution hardware, including switch matrices that route any input signal to any output. Manufacturers such as ETL Systems build RF matrix systems ranging from compact 4×4 units up to 256×256, with multi-module configurations reaching 1,024 inputs and outputs, used in commercial satcoms, broadcast, defence and government facilities.

This hardware is built for resilience, with redundant power supplies and processors and hot-swappable cards. But it is managed over standard IP networks, typically from a central monitoring and control (M&C) platform running on Linux. If that platform is weak, every bit of hardware redundancy can be undone by a single stolen password. The same pattern applies to power distribution units, building management systems, industrial controllers and network appliances in almost any critical facility.

Start With a Minimal, Patched Base

A management server should run only what it needs. Start from a minimal install, remove compilers, desktop packages and unused services, and check what is listening with ss -tulpn. Every open port should have a reason to exist.

Patch on a schedule rather than when someone remembers. Use unattended-upgrades on Debian and Ubuntu or dnf-automatic on RHEL-family systems for security updates, and plan maintenance windows for kernel updates that need a reboot. Benchmark the build against a recognised baseline such as the CIS Benchmarks, and use OpenSCAP to scan for drift over time.

Lock Down SSH

SSH is usually the only way in, so it deserves the most attention. In /etc/ssh/sshd_config, set PermitRootLogin no and PasswordAuthentication no, and restrict access to a named group with AllowGroups. Use key-based authentication with hardware-backed keys where possible, and require multi-factor authentication for privileged accounts.

Do not expose SSH directly to wider networks. Engineers should connect through a VPN and a hardened bastion host, so there is one well-monitored path into the management environment. Tools such as fail2ban add a further layer against brute-force attempts.

Firewall and Segment Everything

Management interfaces belong on their own network segment, never on the office LAN and never reachable from the internet. On the server itself, use nftables with a default-drop policy for inbound traffic, allowing only SSH from the bastion host and only the management protocols needed to talk to devices on the management VLAN.

Apply the same thinking in the other direction. Restrict outbound connections so a compromised server cannot easily reach external command-and-control infrastructure or exfiltrate data.

Retire Clear-Text Management Protocols

Legacy infrastructure is often managed with Telnet, plain HTTP and SNMPv1 or v2c, all of which send credentials or community strings in clear text. Anyone on the segment can capture them. Modern equipment supports better options, and ETL’s matrix systems, for example, support HTTPS and SNMPv3 for monitoring and control.

Use them. With Net-SNMP, create SNMPv3 users with SHA authentication and AES privacy, and configure them as authPriv so traffic is both authenticated and encrypted. Disable v1 and v2c on every device that allows it. Replace self-signed certificates on web interfaces with certificates from an internal CA, and change every default credential before equipment goes into service.

Protect the Credentials

M&C platforms need credentials for the devices they manage, and those are too often stored in plain-text configuration files. Move them into a secrets manager such as HashiCorp Vault, restrict file permissions on anything that remains, and rotate credentials when staff leave or a device is replaced. Separate read-only monitoring accounts from those that can change configuration.

Enforce Mandatory Access Control

Keep SELinux or AppArmor in enforcing mode rather than switching it off when an application complains. Write or adjust policies for the M&C software so it can reach only the files, ports and processes it needs. If an attacker exploits the application, mandatory access control limits how far they can go.

Log, Audit and Alert

Configure auditd to watch configuration directories, credential stores and privileged commands, for example with rules such as -w /etc/ssh/sshd_config -p wa. Forward system logs, audit events and SNMP traps to a central SIEM over TLS using rsyslog or a similar agent, so evidence survives even if the server does not.

Then alert on what matters operationally as well as technically: logins outside maintenance windows, unexpected configuration changes on managed devices and switching or routing activity that does not match planned work.

Plan for Recovery

Finally, assume a management server will one day fail or be compromised. Keep its configuration in version control or an automation tool such as Ansible, back up application data and device configurations, and test restores regularly. A server that can be rebuilt cleanly in hours is far less dangerous than one nobody dares to touch.

Critical infrastructure is designed to keep running through hardware faults. With a minimal base, locked-down SSH, encrypted management protocols and proper logging, the Linux servers behind it can be just as resilient against attackers.

Read the full article →