Difference between revisions of "OS Security Configuration Policy"

Latest revision as of 17:30, 9 May 2017

OS / Kickstart Policy

• Approval (by Head of Security Team) is required before creating any non-kickstart or non-company-approved standard Linux or Unix OS installation.
• Installation of company approved kickstart OS image must be used to create a standard Linux image.
  • New installs must all be 64bit CentOS 6 (or newer) unless there is a special 3rd party requirement that it has to be 32bit. 32bit systems will also need an approval.
  • Kickstart creates a minimal OS install, plus a few approved packages for troubleshooting purposes.
  • Our standard is to allocate all available/remaining space to /home, with company applications and support software run from /home (see step 6 in the Running Kickstart section under Kickstart for additional details), to isolate disk usage of additional process/applications from OS processes & logs.
  • Kickstart incorporates standardized partitioning/configuration/packages/security settings/etc.
  • Systems must use a central DNS/NTP/MAIL/Proxy for the Data Center they are in.
  • Systems must be attached to spacewalk and a central logging server.

User / Password Policy

• User and Root passwords must contain: 12 characters or greater, 1+ lowercase, 1+ uppercase, 1+ number, 1+ non-alphanumeric (neither letter or number, i.e. use punctuation or symbols).
  • User password hash for that user from /etc/shadow must be sent to Head of Security Team for approval.
  • New or changed root passwords must be sent to Head of Security Team for approval of proper password strength/policy (the actual password, not the password hash).
• Adding any user accounts or changing any user or app account information or password must be kept in sync with the master user database, and any changes must be submitted to the approval process. Systems not following this policy must be approved (by Head of Security Team).
• Master user database data will be synced across servers periodically and the local data/passwords/UIDs/GIDs changed and overwritten.
• Linux password encryption method must be set to SHA512, along with our minimal password parameter configuration policy (see Setting The Default Password Configuration section under User Management).
• Root logins must be disabled in ssh (PermitRootLogin no). However for automated processes/scripts, a locked-down ssh key must be used and PermitRootLogin must be set to 'without-password' (non-interactive login).
• Application and process accounts must not have a password, and must not be allowed to login directly. If a script or automated process needs access to the account, it must use a locked-down ssh key, or must be approved by Head of Security Team.
• Group or team logins are not permitted. Individuals must have their own accounts and only access the systems using that account (which can have group permissions or be allowed to sudo to an app or group account).

Sudo Policy

• Users must NOT be put into 'wheel' group.
• Passwordless root access is not permitted. The SYSADMINS section (at the bottom of the sudo configuration file) is for temporary granting of access, and should not be used to grant access for more than a few hours (in very rare cases, a few days).
• Individual or application accounts administering or working in a particular environment must perform their work without full root access (or equivalent), but should have all the commands they would need on a regular basis allowed in the sudoers file (new commands need approval/review by Head of Security Team).
• Sudo access for application accounts is granted to user accounts, and must not be granted to application or group accounts.
• Application accounts should have a pre-created startup config (systemd) or an init script (either one owned by root), and the app user should have proper sudo permissions for starting the app.

Note: Sudo will be integrated with LDAP, and once integrated, will require approval by Head of Security Team for any changes.

Security Policy

• Superuser / root / Administrator access / control limited to just a couple individuals (not generally available).
• MD5 Ciphers disabled.
• RC4 Ciphers disabled.
• SSLv2 & SSLv3 Ciphers disabled.
• Low quality Ciphers disabled.
• All Export Ciphers disabled.

SSH Policy

SSH Server configuration requirements (settings incorporated in company approved image from kickstart).

• Ssh client configuration must not be modified, unless it is required by a piece of software to function correctly (eg; oracle db software requires creating a local config file, specifically for the oracle user, for the software to function correctly in a multi-server RAC configuration).
• The standard ssh port must not be used (minimizes logging activity due to scanning/hacking attempts).
• Ssh protocol version 1, and related insecure protocol 1 settings must be disabled.
• Server keys must be increased to 1024 bits or higher (was 768).
• Direct root logins must be disabled (except from the console), configuration must be set to "PermitRootLogin no" except where locked-down root keys are utilized for a trusted host or an automated process, in which case the configuration must be set to "PermitRootLogin without-password".
• Ssh strict modes checking ("StrictModes yes") must be used, except on systems where a monitoring account or script processing account (like nrpe/applog) is accessing an application account (where an app home directory has g+r, which breaks strict mode).
• Authorized keys filename ("AuthorizedKeysFile .ssh/authorized_keys") must be set/enforced, to disallow use of an authorized_keys2 file, in order to reduce ambiguity and prevent the use of multiple authorized key files.
• Insecure host-based authentication mechanisms must be disabled ("RhostsRSAAuthentication no", "HostbasedAuthentication no", "IgnoreUserKnownHosts yes", "IgnoreRhosts yes").
• Passwordless accounts must not be allowed ("PermitEmptyPasswords no").
• GSS API authentication ("GSSAPIAuthentication no") must be disabled, to prevent login delays & issues.
• TCP keep alive's ("TCPKeepAlive yes") must be set, in order to avoid infinitely hanging sessions.
• Privilege separation must be enabled ("UsePrivilegeSeparation yes").
• Ssh must be configured such that sessions will timeout after a period of inactivity (currently issues with this setup).
• Keys must be locked down in order to allow only the single host they are used/generated from, so that if the keys are used outside of that host, they will not work and are therefore useless (note: some keys are locked down to specific commands/directories and do not even allow shell access).
• X11 over ssh is enabled, to allow various needed GUI utilities (and for Oracle installs).

Note: Sometimes the "allowed unauthenticated connections" parameter ("MaxStartups") is modified where needed to permit a larger number of rsync connections (primarily on data aggregation (backup/DTS/etc.) systems).

Software Policy

• Software installation must happen through Spacewalk, or Archiva for Java components. Only RPM packages can be installed on systems; tarballs are not allowed and must be converted to a RPM and installed via Spacewalk.
• Yum-priorities plugin for Non-Redhat systems and yum-protectbase plugin for RedHat and OracleLinux systems, must be installed and configured to ensure proper OS security updates are applied.
• All systems must be registered with Spacewalk. Spacewalk is used for all updates and for central management and reporting.
• OracleLinux 6.x must have UEK3 kernels disabled (6.x UEK3 is based on Enterprise 7.x) per Database Team requirements.
• Spacewalk required packages must be installed on CentOS. Note: RedHat now requires one additional package.
• Yum must be configured such that kernel and other packages are "updated", not "installed", to prevent multiple versions being installed simultaneously.
• Only approved repos with proper priority levels set may be utilized (out of kickstart), or, when using Spacewalk, Spacewalk must have proper priority levels set for all repos.
• JBoss must not be used, as it is not licensed to receive updates, and is vulnerable to known exploits. This also applies to internal systems since they may be exposed either directly, or indirectly via a proxy. Tomcat is approved as a JBoss replacement, as it receives security updates from the distro provider.
• Application deployments must not be run as root, but as an unprivileged app user. Deployments should include a separate one-time setup mode for any root-access required functionality (i.e., to install software from yum repos, verify users, etc. - but not add users, configuration, etc.), and regular deployments run as the app user.

Mail Policy

• Postfix is the mail standard for all our systems (Enterprise 5.x Linux or older systems using the old sendmail setup must be converted to use postfix).
• All data centers must have a pair of mail relay servers, which accepts mail from any company IP, through which all mail must flow.
• The mail server process running locally on a system will only accept mail from that system, and must not be listening to the network.
• All infrastructure alerts and all Linux systems (such as Nagios, hardware alerts, Dell iDrac, VMWare, storage systems, network devices, etc.) must be configured as coming from the example.net domain, must only be sent to example.net aliases (distribution lists), and not sent to any example.com addresses.

Apache Policy

• Unneeded/unused modules (in httpd.conf) must be disabled.
• Modules externally activated by default (ssl/php/perl/python/svn) must be disabled (httpd.conf is modified to use a conf.d-run directory instead of conf.d).
• Unused features (CGI/SSI/etc) must be disabled.
• Directory listing from / (recursive from / on filesystem, i.e. not confined to document_root) must be disabled.
• Server side TRACE/TRACK must be disabled, to minimize the attack surface of the apache authentication stack.
• Any URL requiring authentication must use https.
• Management/Status/Configuration pages such as; apache-info, apache-status, balancer-manager, jmx-console, web-console, etc. must be disallowed for any externally accessed URL's.
• Name & URL's must be masked so that only the IP info is shown for any externally accessed URL's (see "mask server name & URL's" in "Vhost Example" section under "Apache").
• A CentOS 7 Secure image must be used for web servers or proxy servers.
• The configuration file must utilize the following approved SSL settings:
  • SSLProtocol all -SSLv2 -SSLv3
  • Header always set Strict-Transport-Security "max-age=15768000;includeSubDomains"
  • Header onsuccess set Strict-Transport-Security "max-age=15768000;includeSubDomains"
  • SSLInsecureRenegotiation off
  • SSLHonorCipherOrder on
  • SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"