This input can be taken into account when setting up, reviewing or recovering an information system, but is not meant to be exhaustive, additional security measures to address the specific risks of every information systems are required.

General guidelines

General guidelines for server deployment and management include:

  • Use configuration management for deploying and managing servers and services (ansible, puppet,...).
  • It is poor practice if multiple admins share the same root account and/or use the same password on multiple servers - provide unique accounts to admins, and use session recording.
  • User credentials are nominative and should not be shared.
  • User credentials should never be transferred over an insecure channel.
  • Disable SSH password login to the servers, prefer using SSH keys. If possible use MFA for SSH login.
  • Enable auditing. 
  • Disable unneeded kernel modules (blacklist them) and remove unneeded software packages that are installed by a default installation.
  • Use central remote logging (in case of a compromise, logs on the local machine could be deleted, with remote logs it is easier to understand how and why the incident happened). It will also allow you to search across them with more ease.
  • Lock accounts after multiple failed attempts (like using PAM system-auth).
  • Blacklist IPs after multiple failed logins (like using fail2ban).
  • Provide account provisioning and de-provisioning policies, and use an identity governance system (IAM = central service for account creation/deletion): the user accounts are created, modified and terminated on a single service which ensures consistency. By configuring user accounts for each service locally, it will require a lot of work to keep the validity of users (are they still employed, entitled to use the services?) in sync with their access to the servers.
  • Ensure that private keys (SSH, X.509,...) are not stored unencrypted (ie. they should be password protected). Ideally, no private keys should be stored on publicly accessible servers (such as user interfaces or login nodes).

  • Configure termination for inactive sessions.
  • Check systems for long-running sessions (e.g. more than 8 hours).
  • Use the least privilege approach, only allow users and services to access a service, that really needs it.
  • Use network segments to detach critical services from the others.
  • Enable monitoring on all servers, it will be easier to detect anomalies.
  • Monitor patch status using services like Pakiti
  • For the firewall, apply deny all rules by default and only open ports that are needed.
  • Subscribe to and follow security notifications for the software you rely on.
  • Ensure that all remote server management interfaces (e.g. BMC subsystems) are not exposed externally, access should be restricted to administrative users with ACLs in place. Disable default built-in administrative accounts that might be provided by default by the vendor. A unique administrative account configuration for your management systems is usually a good practice.

References

  • No labels