# Keep Your EasyDCIM Installation Secure
EasyDCIM security depends on the application, its host, Remote Agents, management networks, and administrator credentials. Use this checklist after installation and review it regularly.
# Keep Components Updated
Keep EasyDCIM, Remote Agents, easydcim-control, and the host operating system on supported and current versions. Updates may include security fixes and revoked support-key cleanup.
After an update, verify the installed components:
easydcim-control app status
easydcim-control agent status
Run the Agent command only on a host where a Remote Agent is installed. For update commands and post-update checks, see the Update Guide.
# Restrict Network Access
Use a firewall with a deny-by-default policy and allow only the traffic required by your environment.
- Expose HTTPS, normally TCP
443, only to users and integrations that require it. - Restrict host SSH to a VPN or specific administrator source addresses.
- Do not expose MariaDB, Redis, InfluxDB, the Docker socket, BMC/IPMI interfaces, or SNMP services to the public Internet.
- Restrict EasyDCIM and Remote Agent container SSH ports to trusted management networks.
- Allow Remote Agent provisioning and management ports only from the networks that use them.
- Keep BMC, switches, PDUs, and other management interfaces on a separate management network whenever possible.
Changing the SSH port can reduce unwanted scans, but it does not replace source IP restrictions, strong authentication, and firewall rules.
See Application Security for the port reference and Remote Agent Network Requirements for Agent-specific traffic.
# Protect Administrator Access
- Enable two-factor authentication for every administrator.
- Give each administrator an individual account and only the permissions they require.
- Disable accounts that are no longer used.
- Restrict backend and Admin API access to trusted IP addresses where possible.
- Prefer individual SSH keys over shared passwords or shared private keys.
- Review
/root/.ssh/authorized_keysregularly and remove unknown or unused entries. - Never send private SSH keys, passwords, API tokens, or environment files through tickets or email.
If password-based SSH access is not required, disable it after confirming that key-based administrative access works. Keep an existing administrative session open while testing SSH changes to avoid locking yourself out.
# Enable Support Access Only When Needed
Enable EasyDCIM Support Team Access only for an active support request and disable it immediately after the work is complete. Do not manually remove the source IP restriction from the support key or add additional source networks.
Verify the current state with:
easydcim-control app status
The expected state outside an active support session is:
Support Access: disabled
Keep easydcim-control updated so that revoked EasyDCIM support keys are removed. For access management and the current support-key fingerprint, see Support Team Access.
# Protect Credentials and Backups
Protect EasyDCIM environment files, API tokens, database passwords, Remote Agent credentials, and device credentials. Limit access to administrators who require them and rotate credentials after staff changes or suspected unauthorized access.
Back up the EasyDCIM App and Remote Agents separately. Keep at least one protected copy outside the EasyDCIM host and test that it can be restored. A backup stored only on the server does not protect against host failure or a root-level compromise.
See the Backup Guide for supported backup and restore commands.
# Monitor the Installation
Retain SSH, firewall, system, Docker, EasyDCIM, and Remote Agent logs for long enough to investigate delayed reports. Where possible, send security logs to another system so that a compromised host cannot modify the only copy.
Review unexpected:
- root SSH logins and changes to
authorized_keys, - firewall rule changes,
- systemd services and executable files,
- listening ports and outbound connections,
- administrator accounts and API tokens.
Useful first checks include:
easydcim-control app status
easydcim-control firewall audit
ufw status verbose
systemctl --failed
# If You Suspect a Compromise
Isolate the affected host and preserve its logs, disk snapshot, and suspicious files before removing anything. Disable support access and unknown SSH keys, then rotate every credential that may have been accessible from the host.
Also review connected Remote Agents and management networks for related activity. If an unauthorized party obtained root access, rebuilding the host from a trusted image is safer than relying only on removing the visible files.
# Quick Checklist
- EasyDCIM, Remote Agents,
easydcim-control, and the host are updated. - HTTPS is configured and unnecessary public ports are closed.
- SSH is restricted to trusted source addresses.
- Administrators use individual accounts and 2FA.
- Support Team Access is disabled when not in use.
- App and Agent backups are stored off-host and restore-tested.
- Security logs are retained and reviewed.