General guidelines

General guidelines for server deployment and management include:

• Use configuration management for deploying and managing servers and services (ansible, puppet,...).
• 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.
• 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.
• 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.

Login and Access Recommendations

SSH Access Control

Two-Factor Authentication (2FA) 

• Open-source solutions like Privacy Idea can be used, but setup may vary depending on your environment. Commercial solutions such as Yubico are also available. 
• You can also combine different methods for multi factor authentication, such as: 
  • OpenID Connect (OIDC) + SSH Key 
  • Kerberos Ticket + SSH Key 
  • SSH Key + Certificate 
• If 2FA is not feasible, enforce the combination of both password and SSH keys. Update /etc/ssh/sshd_config as follows: 

                   AuthenticationMethods "publickey,password"  

• To prevent users without SSH keys from being locked out, gradually implement this policy by targeting specific groups: 

                  Match Group GROUPNAME  
                              AuthenticationMethods publickey,password  

Best Practices for SSH Access

• Disable SSH access for the root user to enhance security. 
• Lock accounts after multiple failed login attempts (e.g., configure the PAM system-auth module). 
• Blacklist IPs after repeated failed attempts using tools like fail2ban. Example: block IPs after 5 failed attempts within 30 seconds for 1 hour. 
• Restrict SSH access to specific IP ranges. 
• Configure an idle timeout to disconnect inactive sessions automatically. Add the following to /etc/ssh/sshd_config: 
          ClientAliveInterval 300  
          ClientAliveCountMax 0 
• Limit the number of simultaneous SSH connection attempts to prevent DoS attacks. Configure the following in /etc/ssh/sshd_config: 
          MaxStartups 10:30:60 
• Some administrators prefer to change the default SSH port to reduce automated attacks, although this is a minor security measure.  

Private Key Management

• Users should password-protect their private keys (e.g., SSH, X.509) and avoid storing them unencrypted. 
• Prohibit storing private keys on publicly accessible servers, such as login nodes or shared user interfaces.  

Account Management

Administrative Accounts

• Use system user accounts with sudo privileges for administrative tasks instead of logging in as root. 
• Avoid using LDAP accounts for emergency (breaking-glass) access to reduce reliance on external services. 
• Enforce administrative access using Kerberos tickets combined with SSH keys for added security.  

• User credentials are nominative and should not be shared.

• User credentials should never be transferred over an insecure channel.

• Regularly review and remove unused accounts to reduce the attack surface.  

Password Length and Complexity 

• User passwords should be at least 12 characters long and include a mix of upper and lowercase letters, numbers, and special characters. 
• Admin passwords should be 16–64 characters long, avoiding common words, usernames, or dictionary words.  

Password Auditing

• Use tools to enforce password complexity and periodically check for weak or reused passwords.  

Monitoring and Brute Force Protection

Failed Login Detection 

• Regularly audit authentication logs to identify suspicious login patterns or brute force attempts. Refer to the logging recommendations for additional guidance.  

Automated Protections

• Deploy tools like fail2ban to monitor failed logins and block offending IPs. 
• Configure thresholds to lock accounts or block IPs after repeated failed login attempts (e.g., 5 failed attempts within 30 seconds).  

References

• EOSC Security Operational Baseline 2022
• EOSC Security Operational Baseline: IT Security best practices
• ENISA guidelines
• NSA Cybersecurity Advisories and Guidance