Welcome to the SIMP documentation!

This is the 4.2.0-0 release of SIMP compatible with the 6.7 release of CentOS and Red Hat Enterprise Linux (RHEL).

The System Integrity Management Platform (SIMP) is a framework designed around the concept that individuals and organizations should not need to repeat the work of automating the basic components of their operating system infrastructure.

Expanding upon this philosophy, SIMP also aims to take care of routine policy compliance to include NIST 800-53, FIPS 140-2, the DISA STIG, and the SCAP Security Guides.

By using the Puppet automation stack, SIMP is working toward the concept of a self-healing infrastructure that, when used with a consistent configuration management process, will allow users to have confidence that their systems not only start in compliance but remain in compliance over time.

Finally, SIMP has a goal of remaining flexible enough to properly maintain your operational infrastructure. To this end, where possible, the SIMP components are written to allow all security-related capabilities to be easily adjusted to meet the needs of individual applications.

Contents:

SIMP 4.2.0-2

Changelog

SIMP 4.2.0-2

Package: 4.2.0-2

This release is known to work with:

  • RHEL 6.7 x86_64
  • CentOS 6.7 x86_64

This is a backwards compatible release in the 4.X series of SIMP.

Manual Changes Requred for Legacy Upgrades

  • Bugs in the simplib::secure_mountpoints class (formerly common::secure_mountpoints)

Note

This only affects you if you did not have a separate partition for /tmp!

  • There were issues in the secure_mountpoints class that caused /tmp and /var/tmp to be mounted against the root filesystem. While the new code addresses this, it cannot determine if your system has been modified incorrectly in the past.
  • To fix the issue, you need to do the following: - Unmount /var/tmp (may take multiple unmounts) - Unmount /tmp (may take multiple unmounts) - Remove the ‘bind’ entries for /tmp and /var/tmp from /etc/fstab - Run puppet with the new code in place

Deprecations

  • The simp-sysctl module will be deprecated in the 4.3.0 release of SIMP. Current users should migrate to using the augeasproviders_sysctl module provided with SIMP going forward.

Significant Updates

NSCD Replaced with SSSD

After a long wait, all of the bugs that we discovered in SSSD have been fixed! Therefore, we have moved to using SSSD as our primary form of caching against our LDAP server. If you do not use LDAP, SSSD will not be installed by default.

This only applies to systems EL6.7 or EL7+, if you have updated SSSD on a system earlier than EL6.7, then you will need to set use_sssd to true in Hiera.

Note

In the future, support for NSCD will be removed as SSSD is the recommended system.

NIST 800-53 Compliance Mapping

This release adds the ability to map all class and define variables into policy components and validate that mapping at compile time. Our initial mapping is against the NIST 800-53r4 and is present in this release.

For more information, see pupmod_simp_compliance_markup for more information.

Puppet 4 Support

We have started explicit testing of our modules against Puppet 4. Puppet 3.8 is slated for EOL in December 2016 and we plan to move to the AIO installer in the next major release of SIMP.

The Foreman

Support for The Foreman was included into SIMP core. We needed to create our own simp-foreman module which prevents the destruction of an existing Puppet environment. This is not installed as part of SIMP core but can be added.

Move to Semantic Versioning 2.0.0

All of our components have officially moved to using Semantic Versioning 2.0.0. This allows us to keep our Puppet Modules and RPMs inline with each other as well as behaving as the rest of the Puppet ecosystem. This does mean that you will see version numbers rapidly advancing over time and this should not be a cause for alarm.

Upgrade Guidance

Fully detailed upgrade guidance can be found in the Upgrading SIMP portion of the User’s Guide.

Warning

You must have at least 2.2GB of free RAM on your system to upgrade to this release.

Note

Upgrading from releases older than 4.0 is not supported.

RPM Updates

Package Old Version New Version
clamav 0.98.7-1 0.99-3
clamav-data 0.98.7-1 0.99-3
clamav-data-empty 0.98.7-1 0.99-3
clamav-devel 0.98.7-1 0.99-3
clamav-filesystem 0.98.7-1 0.99-3
clamav-scanner 0.98.7-1 0.99-3
clamav-sysvinit 0.98.7-1 0.99-3
clamav-server 0.98.7-1 0.99-3
clamav-server-systemd 0.98.7-1 0.99-3
clamav-server-sysvinit 0.98.7-1 0.99-3
clamav-server-update 0.98.7-1 0.99-3
facter 2.4.1-1 2.4.6-1
globus-common 15.30-1 16.0-1
globus-gsi-proxy-core 7.7-2 7.9-1
globus-gsi-sysconfig 6.8-2 6.9-1
globus-gssapi-gsi 11.22-1 11.26-1
hiera 3.0.2-1 3.0.5-1
mcollective 2.2.3-1 2.8.4-1
mcollective-client 2.2.3-1 2.8.4-1
mcollective-filemgr-agent 1.0.2-1 1.1.0-1
mcollective-filemgr-client 1.0.2-1 1.1.0-1
mcollective-filemgr-common 1.0.2-1 1.1.0-1
mcollective-iptables-agent 3.0.1-1 3.0.2-1
mcollective-iptables-client 3.0.1-1 3.0.2-1
mcollective-iptables-common 3.0.1-1 3.0.2-1
mcollective-nrpe-agent 3.0.2-1 3.1.0-1
mcollective-nrpe-client 3.0.2-1 3.1.0-1
mcollective-nrpe-common 3.0.2-1 3.1.0-1
mcollective-sysctl-data 2.0.0-1 2.0.1-1
puppet 3.7.4-1 3.8.6-1
puppet-dashboard 1.2.23-1 N/A
puppet-server 3.8.1-1 N/A
puppetserver 1.1.1-1 1.1.3-1
razor-server 0.14.1-1 1.2.0-1
razor-torquebox 3.0.1-1 3.1.1.10-1
rubygem-rake N/A 0.9.6-25
voms 2.0.12-3 2.0.13-1

Fixed Bugs

pupmod-simp-activemq
  • Updated activemq to the latest release.
  • Removed the tanukiwrapper dependency.
pupmod-simp-apache
  • Fixed ordering issues that were discovered when testing the foreman module.
pupmod-simp-auditd
  • Fixed an issue where add_rules did not disable itself if $::auditd::enable_auditing was set to false.
pupmod-simp-freeradius
  • Moved all 2 and 3 paths to v2 and v3 paths respectively since the original paths were not Puppet 4 safe.
pupmod-simp-ganglia
  • Fixed several minor bugs found during Puppet 4 testing.
pupmod-simp-nfs
  • Ensure that the NFS exports template can handle ANY and all since these can be used in client_nets for use with iptables.
  • Added a temporary class nfs::lvm2 to ensure that the lvm2 package is updated to the latest version since the nfs-utils rpm requires it but has a broken dependency.
  • Fixed Puppet 4 support.
pupmod-simp-nscd
  • Replaced remaining lsb* variables.
  • Fixed a race condition between service nscd restart and service nscd reload
pupmod-simp-openldap
  • Fixed several ordering and variable issues discovered when testing for Puppet 4
  • Fixed numerous issues with nslcd
  • Now copy the system certificates to /etc/nslcd.d for instances that wish to use their own certificates.
pupmod-simp-pki
  • Removed the simip5.test.vm key which was leftover testing garbage.
pupmod-simp-pupmod
  • Fixed logic errors found when testing Puppet 4
  • Configuration changes now notify Service[‘puppetmaster’] instead of the more efficient Exec. This prevents a race condition where the service is restarted and the Exec fires before the service has fully restarted.
  • Fixed the puppetserver_* helper scripts that surfaced due to changes in the HTTP responses from the Puppet Server.
  • Ensure that the Service configuration directory can be changed.
pupmod-simp-rsyslog
  • Fixed issues found during Puppet 4 testing.
pupmod-simp-simp
  • Fixed numerous issues found when testing against Puppet 4.
  • Fixed the nfs_server default in the home_client class which had the potential to break automounting.
pupmod-simp-simplib
  • Confined all facts that break Puppet on Windows.
  • Removed simplib::os_bugfixes because...it never worked anyway.
  • Fixed the ipv6_enabled fact to not break if IPv6 is already disabled. - Thanks to Klaas Demter for this patch.
  • Fixed issues with the localusers function where it was having issues when used with Ruby >= 1.9
pupmod-simp-ssh
pupmod-simp-sssd
  • Ensure that the sssd client libraries are installed even if you’re not running the sssd daemon.
  • Removed the erroneous ldap_chpass_updates_last_change variable and re-normalized the module on the ldap_chpass_update_last_change variable.
pupmod-simp-stunnel
  • Fixed ordering issues in the module.
  • Removed the public and private PKI certificates from the chroot jail for better system security. This will not remove them on existing systems, it will simply not place them there on new installations.
simp-cli
  • Fixed a bug where pre-placed X.509 certificates would be removed when running simp config. Custom certificates can now be used out of the box.
simp-core
  • Connections to the remote YUM server were disabled by default on the initial Puppet server. This prevents issues with bootstrap ordering when not installing via ISO.
  • Fixed the unpack_dvd script to properly check for non-existent directories before unpacking the ISO images.
  • Fixed a bug where the Hiera use_ldap variable was not effective due to openldap::pam being included in the Hiera class list.
simp-doc
  • Spelling errors were corrected.
  • The PXE boot section was corrected.
  • Directory paths were fixed throughout the document.
  • The Security Conop tables were fixed.
DVD
  • Fixed a few typos in the auto.cfg file.

New Features

pupmod-onyxpoint-compliance
  • The first cut of the compliance mapper module. Will be replaced by a SIMP native version in the next release.
pupmod-simp-augeasproviders_grub
  • Imported the latest version of the upstream augeasproviders_grub module.
  • Added the ability to fully manage GRUB menu entries in both GRUB 2 and GRUB Legacy.
pupmod-simp-augeasproviders_sysctl
  • Added the ability to fail silently in the case that a running sysctl item cannot be manipulated. This is important in cases such as NFS where the appropriate module may not be loaded until it is actually used for the first time.
pupmod-simp-java_ks
  • Updated the module to the latest upstream version to support FIPS mode.
pupmod-simp-mcollective
pupmod-simp-openldap
  • Fixed the default.ldif template to modify the password setting defaults. This will not affect a running LDAP server.
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using external (non-SIMP) certificates.
pupmod-simp-pki
  • Allow the PKI content source to be modified so that you have a choice of where to pull your certificates. - Thanks to Carl Caum from Puppet Labs for this patch.
pupmod-simp-rsyslog
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using templates when sending to remote targets.
  • Ensure that all module artifacts are now packaged with the RPM.
pupmod-simp-simplib
  • Added a to_string() function.
  • Added a to_integer() function.
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-ssh
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-stunnel
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-sysctl
  • Migrate to using augeasproviders_sysctl for all sysctl activities.
  • This module will be deprecated in the next major release of SIMP.
simp-doc
  • The documentation on setting up redundant LDAP servers was updated.
  • A section on using The Foreman with SIMP was added.

Known Bugs

  • If you are running libvirtd, when svckill runs it will always attempt to kill dnsmasq unless you are deliberately trying to run the dnsmasq service. This does not actually kill the service but is, instead, an error of the startup script and causes no damage to your system.

SIMP Installation Guide

Contents:

Introduction

This guide will walk a user through the process of managing a SIMP system. This system includes, at a minimum, a SIMP server with properly configured networking information and a working Puppet server. Additionally, this document outlines the process of managing clients and users associated with the SIMP system.

Level of Knowledge

SIMP is designed for use by system administrators or users with a strong background using Linux operating systems. The core applications that make up SIMP and require prerequisite knowledge are:

SIMP does as much initial setup and configuration of these tools as possible. However, without at least some understanding, you will be unable to tailor a SIMP system to fit the desired environment. A general understanding of how to control and manipulate these tools from the command line interface (CLI) will be necessary, as SIMP does not come stock with a graphical user interface (GUI).

Knowledge of scripting and Ruby programming will also help to further customize a SIMP install but is not required for routine use.

SIMP Defined

The System Integrity Management Platform (SIMP) is a framework designed around the concept that individuals and organizations should not need to repeat the work of automating the basic components of their operating system infrastructure.

Expanding upon this philosophy, SIMP also aims to take care of routine policy compliance to include NIST 800-53, FIPS 140-2, the DISA STIG, and the SCAP Security Guides.

By using the Puppet automation stack, SIMP is working toward the concept of a self-healing infrastructure that, when used with a consistent configuration management process, will allow users to have confidence that their systems not only start in compliance but remain in compliance over time.

Finally, SIMP has a goal of remaining flexible enough to properly maintain your operational infrastructure. To this end, where possible, the SIMP components are written to allow all security-related capabilities to be easily adjusted to meet the needs of individual applications.

SIMP Server Installation

This chapter provides guidance on installing and configuring SIMP using the simp config utility.

System Requirements

SIMP scales well, but how much depends on a number of factors, including the number of nodes, the processor speed, the total memory, and the complexity of the manifests. The following minimal system requirements are recommended:

Using the SIMP Utility

The SIMP Utility does not assist users through the entire configuration process; however, it does make the initial configuration easier and more repeatable.

Important

Correct time across all systems is important to the proper functioning of SIMP and Puppet in general.

If a user has trouble connecting to the Puppet server and errors regarding certificate validation appear, check the Puppet server and client times to ensure they are synchronized.

Warning

Keep in mind as the installation process begins that Puppet does not work well with capital letters in host names. Therefore, they should not be used.

SIMP Default Passwords and Settings

Below is a table containing the default passwords found on a basic SIMP server.

Important

All default passwords should be changed during the initial configuration proceess.

Table: SIMP Default Passwords

Utility Password
Grub GrubPassword
Root User RootPassword
Simp User UserPassword

A table of settings that can be changed/defined during installation is located in Appendix B, List of Installation Variables. Review this if you are unfamiliar with SIMP.

Preparing the SIMP Server Environment

  1. Boot the system and ensure the SIMP ISO is selected.
  2. Press Enter* to run the standard SIMP install, or choose from the customized options list.
  3. When the installation is complete, the system will restart automatically.
  4. Log on as root and type the default password shown in Table 2.1.
  5. Type the default password again when prompted for the (current) UNIX password.
  6. Type a new password when prompted for the New Password. Retype the password when prompted.

Installing the SIMP Server

Warning

Keep in mind as the installation process begins that Puppet does not work well with capital letters in host names. Therefore, they should not be used.

  1. Log on as simp and run su - to gain root access.
  2. Type simp config
  1. Type simp config -a <Config File> to load a previously generated configuration instead of generating the configuration from the script. This is the option to run for systems that will be rebuilt often.
  2. For a list of additional commands, type simp help. Type simp help ***<Command>*** for more information on a specific command.
  3. A list of the variables that are set and more details are contained in List of Installation Variables.

Note

Once simp config has been run, a simp config file with all your settings is saved in /root/.simp/simp_conf.yaml

  1. Configure the system as prompted.
  2. Type simp bootstrap

Note

If progress bars are of equal length and the bootstrap finishes quickly, a problem has occurred. This is most likely due to an error in SIMP configuration. Refer to the previous step and make sure that all configuration options are correct.

  1. Type reboot

Performing Post-installation Setup on the SIMP Server

  1. Log on as root
  2. Run puppet for the first time. Errors will appear for DHCP. These can be safely ingored at this stage. Type: puppet agent -t
  3. Copy CentOS RHEL_MAJOR_MINOR_VERSION ISO(s) to the server and unpack using the unpack_dvd utility. This creates a new tree under /srv/www/yum/CentOS. Execute: unpack_dvd CentOS-RHEL_MAJOR_MINOR_VERSION- *####*-x86_64-Everything.iso
  4. Update your system using yum. The updates applied will be dependent on what ISO you initially used. Execute: yum clean all; yum makecache
  5. Run puppet. Ignore the same DHCP errors: puppet agent -t
  6. Type reboot

Client Management

This chapter provides guidance to install and configure SIMP clients based on the standard SIMP system installed using the SIMP DVD.

System Requirements

Before installing clients, the system should consist of the following minimum requirements:

  • Hardware/Virtual Machine (VM) : Capable of running RHEL 6 or 7 ; 64-bit compatible
  • RAM: 512 MB
  • HDD: 5 GB

Configuring the Puppet Master

Perform the following actions as root on the Puppet Master system prior to attempting to install a client.

Configure DNS

Most static files are pulled over rsync by Puppet in this implementation for network efficiency. Specific directories of interest are noted in this section.

It is possible to use an existing DNS setup; however, the following table lists the steps for a local setup.

  1. Navigate to /srv/rsync/bind_dns
  1. Modify the named files to correctly reflect the environment. At a minimum, the following files under /srv/rsync/bind_dns/default should be edited:
  • named/etc/named.conf
  • named/etc/zones/your.domain
  • named/var/named/forward/your.domain.db
  • named/var/named/reverse/0.0.10.db

Important

For the named/var/named/forward/your.domain.db and named/var/named/reverse/0.0.10.db files, add clients as needed. Make sure to rename both of these files to more appropriately match your system configuration.

  • At a minimum, review named/etc/named.conf and check/update the

    following:

    • Update the IP for allow-query and allow-recursion
    • Delete any unnecessary zone stanzas (i.e. forwarding) if not necessary
    • Substitute in the FQDN of your domain for all occurrences of your.domain
  1. Type puppet agent -t --tags named on the Puppet Master to apply the changes. Validate DNS and ensure the /etc/resolv.conf is updated appropriately
  2. If an error about the rndc.key appears when starting bind, copy the rndc.key to /etc then re-run the puppet command: cp -p /var/named/chroot/etc/rndc.key /etc/rndc.key

Configure DHCP

Perform the following actions as root on the Puppet Master system prior to attempting to install a client.

Open the /srv/rsync/dhcpd/dhcpd.conf file and edit it to suit the necessary environment.

Make sure the following is done in the dhcpd.conf :

  • The next-server setting in the pxeclients class block points to the IP Address of the TFTP server.
  • Create a Subnet block and edit the following:
    • Make sure the router and netmask are correct for your environment.
    • Enter the hardware ethernet and fixed-address for each client that will be kickstarted. SIMP environments should not allow clients to pick random IP Address in a subnet. The MAC address must be associated with and IP Address here. (You can add additional ones as needed.)
    • Enter the domain name for option domain-name
    • Enter the IP Address of the DNS server for option domain-name-servers

Save and close the file.

Run puppet agent -t on the Puppet Master to apply the changes.

Configure PXE Boot

Sample kickstart templates have been provided in the /var/www/ks directory on the SIMP server and on the SIMP DVD under /ks. Pre-boot images are locate in the DVD under /images/pxeboot. If you have an existing Preboot Execution Environment (PXE) setup you can use these to PXE a SIMP client. Follow your own sites procedures for this.

In this section we describe how to configure the Kickstart and TFTP servers to PXE boot a SIMP client. (The DHCP server setup, also required for PXE booting, is discussed in and earlier chapter.)

Note

This example sets up a PXE boot for a system that is the same OS as the SIMP Server. If you are setting up a PXE boot for a different OS then you must make sure that the OS packages are available for all systems you are trying to PXE boot through YUM. There are notes through out the instructions to help in setting multiple OS but they are not comprehensive. You should understand DHCP, KS, YUM and TFTP relationships for PXE booting before attempting this.

Setting Up Kickstart

This section describes how to configure the kickstart server.

  1. Locate the following files in the /var/www/ks directory:
    1. pupclient_x86_64.cfg
    2. diskdetect.sh
  2. Open each of the files and follow the instructions provided within them to replace the variables. You need to know the IP Addresses of the YUM, Kickstart, and TFTPserver. (They default to the simp server in simp config).
    1. pupclient_x86_64.cfg:

      1.) Note: #KSSERVER# should be replaced with Kickstart Server IP not Yum IP. (They are the same if you used the defaults.) 2.) In the URL line use the YUMSERVER ip not the Kickstart server IP. (Although on a default SIMP system the YUM and kicktart server are the same server so it is not a problem.) 3.) Use the commands in the top of the file in the comments section to generate the password hashes.

    2. diskdetect.sh: The diskdetect.sh script is responsible for detecting the first active disk and applying a disk configuration. Edit this file to meet any necessary requirements or use this file as a starting point for further work. It will work as is for most systems as long as your disk device names are in the list.

  3. Type chown root.apache /var/www/ks/* to ensure that all files are owned by root and in the apache group.

  4. Type chmod 640 /var/www/ks/* to change the permissions so the owner can read and write the file and the apache group can only read.

Note

The URLs and locations in the file are setup for a default SIMP install. That means the same OS and version as the SIMP server, all servers in one location (on the SIMP server) and in specific directories. If you have installed these servers in a different location then the defaults, you may need to edit URLs or directories.

Note

If you want to PXE boot more than this operating system, make a copy of these files, name them appropriately and update URLS and links inside and anything else you may need. (You must know what you are doing before attempting this.) If you are booting more than one OS you must also make sure your YUM server has the OS packages for the other OSs. By default the YUM server on SIMP has the packages only for the version of OS installed on the SIMP server.

Setting up TFTP

This section describes the process of setting up static files and manifests for TFTP.

Static Files

Verify the static files are in the correct location:

Type cd /srv/rsync/tftpboot and then type ls to check for the existence of the /srv/rsync/tftpboot/linux-install/OSTYPE-MAJORRELEASE_ARCH directory.

where OSTYPE and MAJORRELEASE under linux-install are the OS type and OS major version of the systems you will be PXE booting.

Under this directory your should find a directory named OSTYPE-MAJORRELEASE.MINORRELEASE-ARCH and a link to this directory named OSTYPE-MAJORRELEASE-ARCH.

Under OSTYPE-MAJORRELEASE.MINORRELEASE-ARCH your should find the files:

  • initrd.img
  • vmlinuz

If these are not there then you must create the directories as needed and copy the files from /var/www/yum/OSTYPE/MAJORRELEASE/ARCH/images/pxeboot or from the images directory on the SIMP DVD.

Important

The link is what is used in the TFTP configuration files.

Note

If you want to be able to PXE boot different OS, then add a directory for each on and obtain the pxeboot images and copy them under the linux-install directory. SIMP only provides images for the OS for the SIMP server.

Manifest

Create a site manifest for the TFTP server on the Puppet server.

  1. Create the file /etc/puppet/environment/simp/modules/site/manifests/tftpboot.pp. Use the source code example below.
    1. Replace KSSERVER with the IP address of Kickstart server (or the code to look up the IP Address using Hiera).
    2. Replace OSTYPE, MAJORRELEASE and ARCH with the correct value for the systems you will be PXE booting.
    3. MODEL NAME is usually of the form OSTYPE-MAJORRELEASE-ARCH for consistency.
class site::tftpboot {
  include 'tftpboot'

  tftpboot::linux_model { 'MODEL NAME':
    kernel => 'OSTYPE-MAJORRELEASE-ARCH/vmlinuz',
    initrd => 'OSTYPE-MAJORRELEASE-ARCH/initrd.img',
    ks     => "http://KSSERVER/ks/pupclient_x86_64.cfg",
    extra  => "ksdevice=bootif\nipappend 2"
  }

  tftpboot::assign_host { 'default': model => 'MODEL NAME' }
}
  1. Add the tftpboot site manifest on your puppet server node via Hiera.

Create the file (or edit if it exists): /etc/puppet/environments/simp/hieradata/hosts/<tftp.server.fqdn>.yaml. (By default the TFTP server is the same as your puppet server o in the deault case it will exist.) Add the following example code to that yaml file.

---
classes:
  - 'site::tftpboot'

3. After updating the above file, type puppet agent -t --tags tftpboot on the Puppet server.

Note

To PXE boot more OSs create, in the tftpboot.pp file, a tftpboot::linux_model block for each OS type using the extra directories and kickstart files created using the notes in previous sections. Point individual systems to them by adding assign_host lines with their MAC pointing to the appropriate model name.

Setting Up the Client

The following lists the steps to PXE boot the system and set up the client.

  1. Set up your client’s BIOS or virtual settings to boot off the network.
  2. Make sure the MAC address of the client is set up in DHCP (see Configure DHCP for more info.)
  3. Restart the system.
  4. Once the client installs, reboots, and begins to bootstrap, it will check in for the first time.
  5. Puppet will not autosign puppet certificates by default and waitforcert is enabled. The client will check in every 30 seconds for a signed cert. Log on to the puppet server and run puppet cert sign <puppet.client.fqdn>.

Upon successful deployment of a new client, it is highly recommended that LDAP administrative accounts be created.

Troubleshooting Issues

If the client has been kickstarted, but is not communicating with the Puppet server, try the following options:

  • Check the forward and reverse DNS entries on the client and server; both must be correct.
  • Check the time on the systems. More than an hour’s difference will cause serious issues with certificates.
  • Remove /var/lib/puppet/ssl on the client system; run puppet cert --clean ***<Client Host Name>*** on the Puppet server; and try again.

Troubleshoot Certificate Issues

If host certificates do not appear to be working and the banner is not getting rsync’d to the clients, ensure that all certificates verify against the installed CA certificates.

The table below lists the steps to determine which certificates are working and which are not.

  1. Navigate to /etc/puppet/environments/simp/keydist
  2. Run find . -name “****<Your.Domain>*.pub” -exec openssl verify -CApath cacerts {} \;

Important

The screen displays ./<Host Name>.<Your.Domain>/<Host Name>.<Your.Domain>.pub: OK If anything other than OK appears for each host, analyze the error and ensure that the CA certificates are correct.

If the TXT_DB error number 2 appears, revoke the certificate that is being regenerated. The table below lists the steps to revoke the certificate.

  1. Navigate to /etc/puppet/environments/simp/keydist;
  2. Run OPENSSL_CONF=default.cnf openssl ca -revoke ../../keydist/***<Host to Revoke>*/*<Host to Revoke>*.pub**

Apply Certificates

This section provides guidance on obtaining official certificates and generating a Fake CA.

Obtaining Official Certificates

All SIMP systems must have Public Key Infrastructure (PKI) keypairs generated for the server.

These keys reside in the /etc/puppet/keydist directory and are served to the clients over the Puppet protocol.

Note

These keypairs are not the keys that the Puppet server uses for its operation. Do not get the two confused.

The table below lists the steps to add any keys for the server that were received from a proper CA to /etc/puppet/keydist.

  1. Type mkdir /etc/puppet/keydist/***<Client System FQDN>***
  2. Type mv ***<Certificate Directory>***/***<FQDN>***.[pem|pub] /etc/puppet/keydist/***<FQDN>***
  3. Type chown -R root.puppet /etc/puppet/keydist
  4. Type chmod -R u=rwX,g=rX,o-rwx /etc/puppet/keydist

Table: Official Certificates Procedure

The table below lists the steps to create and populate the /etc/puppet/keydist/cacerts directory.

  1. Type cd /etc/puppet/environments/simp/modules/pki/files/keydist
  2. Type mkdir cacerts and copy the root CA public certificates into cacerts in Privacy Enhanced Mail (PEM) format (one per file).
  3. Type cd cacerts
  4. Type for file in *.pem; do ln -s $file `openssl x509 -in $file -hash -noout`.0; done

Generating Fake CAs

If server certificates have not or could not be obtained at the time of client installation, the SIMP team provides a way to create them for the system so that it will work until proper certificates are provided.

Note

This option should not be used for any operational system that can use proper enterprise PKI certificates.

The instructions below lists the steps to generate the Fake CAs.

  1. Type cd /etc/puppet/environments/simp/FakeCA
  2. Type vi togen
  3. Remove old entries from the file and add the Fully Qualified Domain Name (FQDN) of the systems (one per line) for which certificates will be created.

Note

To use alternate DNS names for the same system, separate the names with commas and without spaces. For example, .name,alt.name1,alt.name2.

  1. Type wc cacertkey

Note

Ensure that the cacertkey file is not empty. If it is, enter text into the file; then save and close the file.

  1. Type ./gencerts_nopass.sh auto

Note

To avoid using the default Fake CA values, remove the auto statement from the ./gencerts_nopass.sh command.

Table: Generating Fake CAs Procedure

Warning

If the clean.sh command is run after the certificates have been generated, the running system will break. To troubleshoot certificate problems, see the section at the end of this chapter.

If issues arise while generating keys, type cd /etc/puppet/Config/FakeCA to navigate to the /etc/puppet/Config/FakeCA directory, then type ./clean.sh to start over.

After running the clean.sh script, type ./gencerts_nopass.sh to run the script again using the previous procedure table.

Hiera Overview

SIMP now uses Hiera natively instead of Extdata. From Puppet Labs website: Hiera is a key/value lookup tool for configuration data, built to set node-specific data without repeating yourself. It is an attempt to make SIMP more configurable to you, the end user. It configures Puppet in two ways: automatic parameter lookup/hiera lookup functions, and assigning classes to nodes. The former allows you to generate reusable code and concentrates parameter assignment to one directory. The latter is a supplement to the failed inheritance model.

Setting Parameters

Automatic Lookup You can now safely declare any class on any node with ‘include’, even if the class is parametized. Before Hiera, this was not possible. Puppet will automatically retrieve class parameters from Hiera using keys. Add a key with a value pair to an appropriate yaml file, say default.yaml, as such:

Adding a Key/Value Pair to Hiera Examples

---
classfoo::parameter_bar: "Woo"
classfoo::parameter_baz: "Hoo"

You can then ‘include classfoo’ on any node, with parameter_bar and parameter_baz defaulting to Woo and Hoo, respectively.

Lookup Functions You are not required to set up your hierarchy for automatic variable lookup. Using three functionts, you can query Hiera for any key.

The first is hiera. This uses standard priority lookup and can retrieve values of any data type from Hiera. If no key is found, a default should be included. $myvar = hiera('parameter_bar', 'Woo')

The second is hiera_array. This uses an array merge lookup. It retrieves all array values for a given key througout the entire hierarchy and flattens them into a single array.

The third is hiera_hash. This uses a hash merge lookup. It retrieves all hash values for a given key throughout the entire hierarchy and merges them into a single hash.

Assigning Classes to Nodes

Assigning classes to nodes is done with the hiera_include function. Hiera does an array merge lookup on ‘tags’ to retrieve classes which should be included on a node. In SIMP, we place hiera_include('classes') in /etc/puppet/manifests/site.pp. Since site.pp is outside of any node definition and below all top scope variables, every node controlled by puppet will get every class tagged with ‘classes’ in its hierarchy. Additionally, simp_def.yaml in is the hierarchy of every node, so every node will receive those classes (by default).

Assigning Defined Types to Nodes

Defined types do not have the ability to receive parameters via Hiera in the traditional sense. To include a defined type on a node, one could use create_resources, but this is messy and discouraged. Instead, make a site class, /etc/puppet/modules/site/manifests/my_site.pp. For example, to include tftpboot linux_model and assign_host on your puppet server, puppet.your.domain:

Adding a Site Manifest Examples

# in /etc/puppet/modules/site/manifests/tftpboot.pp
# Set KSSERVER statically or use Hiera for lookup

class site::tftpboot {
  include 'tftpboot'

  tftpboot::linux_model { 'CentOS_RHEL_MAJOR_VERSION':
    kernel => 'centosRHEL_MAJOR_VERSION_x86_64/vmlinuz',
    initrd => 'centosRHEL_MAJOR_VERSION_x86_64/initrd.img',
    ks     => "http://KSSERVER/ks/pupclient_x86_64.cfg",
    extra  => 'ipappend 2'
  }

  tftpboot::assign_host { 'default': model => 'CentOS_RHEL_MAJOR_VERSION' }
}

Then, in /etc/puppet/hieradata/hosts/puppet.your.domain.yaml

Adding TFTP Site to Hiera Examples

---
classes:
  - 'site::tftpboot'

SIMP Hiera File Structure

  • /etc/puppet/hiera.yaml Hiera’s config file, used to control the hierarchy of your backends.
  • /etc/puppet/hieradata/ Default location of the yaml files which contain your node data
  • /etc/puppet/hieradata/simp_classes.yaml The list of default classes to include on any SIMP system.
  • /etc/puppet/hieradata/simp_def.yaml Contains the variables needed to configure a working SIMP system. Modified by simp-config.
  • /etc/puppet/hieradata/hosts/ By populating this directory with some.host.name.yaml file, you can assign parameters to host some.host.name
  • /etc/puppet/hieradata/domains/ Same principal as hosts, but domain names.
  • /etc/puppet/manifests/ Contains site.pp and all other node manifests. BE CAREFUL when modifying this directory, site.pp contains your globals. This directory can be used to supplement or even REPLACE Hiera, with nodes. Note that Hiera cannot regex hostnames to apply manifests, so a node manifest will have to be created here if you wish to have that ability.

SIMP 4.2.0-2

Changelog

SIMP 4.2.0-2

Package: 4.2.0-2

This release is known to work with:

  • RHEL 6.7 x86_64
  • CentOS 6.7 x86_64

This is a backwards compatible release in the 4.X series of SIMP.

Manual Changes Requred for Legacy Upgrades
  • Bugs in the simplib::secure_mountpoints class (formerly common::secure_mountpoints)

Note

This only affects you if you did not have a separate partition for /tmp!

  • There were issues in the secure_mountpoints class that caused /tmp and /var/tmp to be mounted against the root filesystem. While the new code addresses this, it cannot determine if your system has been modified incorrectly in the past.
  • To fix the issue, you need to do the following: - Unmount /var/tmp (may take multiple unmounts) - Unmount /tmp (may take multiple unmounts) - Remove the ‘bind’ entries for /tmp and /var/tmp from /etc/fstab - Run puppet with the new code in place
Deprecations
  • The simp-sysctl module will be deprecated in the 4.3.0 release of SIMP. Current users should migrate to using the augeasproviders_sysctl module provided with SIMP going forward.
Significant Updates
NSCD Replaced with SSSD

After a long wait, all of the bugs that we discovered in SSSD have been fixed! Therefore, we have moved to using SSSD as our primary form of caching against our LDAP server. If you do not use LDAP, SSSD will not be installed by default.

This only applies to systems EL6.7 or EL7+, if you have updated SSSD on a system earlier than EL6.7, then you will need to set use_sssd to true in Hiera.

Note

In the future, support for NSCD will be removed as SSSD is the recommended system.

NIST 800-53 Compliance Mapping

This release adds the ability to map all class and define variables into policy components and validate that mapping at compile time. Our initial mapping is against the NIST 800-53r4 and is present in this release.

For more information, see pupmod_simp_compliance_markup for more information.

Puppet 4 Support

We have started explicit testing of our modules against Puppet 4. Puppet 3.8 is slated for EOL in December 2016 and we plan to move to the AIO installer in the next major release of SIMP.

The Foreman

Support for The Foreman was included into SIMP core. We needed to create our own simp-foreman module which prevents the destruction of an existing Puppet environment. This is not installed as part of SIMP core but can be added.

Move to Semantic Versioning 2.0.0

All of our components have officially moved to using Semantic Versioning 2.0.0. This allows us to keep our Puppet Modules and RPMs inline with each other as well as behaving as the rest of the Puppet ecosystem. This does mean that you will see version numbers rapidly advancing over time and this should not be a cause for alarm.

Upgrade Guidance

Fully detailed upgrade guidance can be found in the Upgrading SIMP portion of the User’s Guide.

Warning

You must have at least 2.2GB of free RAM on your system to upgrade to this release.

Note

Upgrading from releases older than 4.0 is not supported.

RPM Updates
Package Old Version New Version
clamav 0.98.7-1 0.99-3
clamav-data 0.98.7-1 0.99-3
clamav-data-empty 0.98.7-1 0.99-3
clamav-devel 0.98.7-1 0.99-3
clamav-filesystem 0.98.7-1 0.99-3
clamav-scanner 0.98.7-1 0.99-3
clamav-sysvinit 0.98.7-1 0.99-3
clamav-server 0.98.7-1 0.99-3
clamav-server-systemd 0.98.7-1 0.99-3
clamav-server-sysvinit 0.98.7-1 0.99-3
clamav-server-update 0.98.7-1 0.99-3
facter 2.4.1-1 2.4.6-1
globus-common 15.30-1 16.0-1
globus-gsi-proxy-core 7.7-2 7.9-1
globus-gsi-sysconfig 6.8-2 6.9-1
globus-gssapi-gsi 11.22-1 11.26-1
hiera 3.0.2-1 3.0.5-1
mcollective 2.2.3-1 2.8.4-1
mcollective-client 2.2.3-1 2.8.4-1
mcollective-filemgr-agent 1.0.2-1 1.1.0-1
mcollective-filemgr-client 1.0.2-1 1.1.0-1
mcollective-filemgr-common 1.0.2-1 1.1.0-1
mcollective-iptables-agent 3.0.1-1 3.0.2-1
mcollective-iptables-client 3.0.1-1 3.0.2-1
mcollective-iptables-common 3.0.1-1 3.0.2-1
mcollective-nrpe-agent 3.0.2-1 3.1.0-1
mcollective-nrpe-client 3.0.2-1 3.1.0-1
mcollective-nrpe-common 3.0.2-1 3.1.0-1
mcollective-sysctl-data 2.0.0-1 2.0.1-1
puppet 3.7.4-1 3.8.6-1
puppet-dashboard 1.2.23-1 N/A
puppet-server 3.8.1-1 N/A
puppetserver 1.1.1-1 1.1.3-1
razor-server 0.14.1-1 1.2.0-1
razor-torquebox 3.0.1-1 3.1.1.10-1
rubygem-rake N/A 0.9.6-25
voms 2.0.12-3 2.0.13-1
Fixed Bugs
pupmod-simp-activemq
  • Updated activemq to the latest release.
  • Removed the tanukiwrapper dependency.
pupmod-simp-apache
  • Fixed ordering issues that were discovered when testing the foreman module.
pupmod-simp-auditd
  • Fixed an issue where add_rules did not disable itself if $::auditd::enable_auditing was set to false.
pupmod-simp-freeradius
  • Moved all 2 and 3 paths to v2 and v3 paths respectively since the original paths were not Puppet 4 safe.
pupmod-simp-ganglia
  • Fixed several minor bugs found during Puppet 4 testing.
pupmod-simp-nfs
  • Ensure that the NFS exports template can handle ANY and all since these can be used in client_nets for use with iptables.
  • Added a temporary class nfs::lvm2 to ensure that the lvm2 package is updated to the latest version since the nfs-utils rpm requires it but has a broken dependency.
  • Fixed Puppet 4 support.
pupmod-simp-nscd
  • Replaced remaining lsb* variables.
  • Fixed a race condition between service nscd restart and service nscd reload
pupmod-simp-openldap
  • Fixed several ordering and variable issues discovered when testing for Puppet 4
  • Fixed numerous issues with nslcd
  • Now copy the system certificates to /etc/nslcd.d for instances that wish to use their own certificates.
pupmod-simp-pki
  • Removed the simip5.test.vm key which was leftover testing garbage.
pupmod-simp-pupmod
  • Fixed logic errors found when testing Puppet 4
  • Configuration changes now notify Service[‘puppetmaster’] instead of the more efficient Exec. This prevents a race condition where the service is restarted and the Exec fires before the service has fully restarted.
  • Fixed the puppetserver_* helper scripts that surfaced due to changes in the HTTP responses from the Puppet Server.
  • Ensure that the Service configuration directory can be changed.
pupmod-simp-rsyslog
  • Fixed issues found during Puppet 4 testing.
pupmod-simp-simp
  • Fixed numerous issues found when testing against Puppet 4.
  • Fixed the nfs_server default in the home_client class which had the potential to break automounting.
pupmod-simp-simplib
  • Confined all facts that break Puppet on Windows.
  • Removed simplib::os_bugfixes because...it never worked anyway.
  • Fixed the ipv6_enabled fact to not break if IPv6 is already disabled. - Thanks to Klaas Demter for this patch.
  • Fixed issues with the localusers function where it was having issues when used with Ruby >= 1.9
pupmod-simp-ssh
pupmod-simp-sssd
  • Ensure that the sssd client libraries are installed even if you’re not running the sssd daemon.
  • Removed the erroneous ldap_chpass_updates_last_change variable and re-normalized the module on the ldap_chpass_update_last_change variable.
pupmod-simp-stunnel
  • Fixed ordering issues in the module.
  • Removed the public and private PKI certificates from the chroot jail for better system security. This will not remove them on existing systems, it will simply not place them there on new installations.
simp-cli
  • Fixed a bug where pre-placed X.509 certificates would be removed when running simp config. Custom certificates can now be used out of the box.
simp-core
  • Connections to the remote YUM server were disabled by default on the initial Puppet server. This prevents issues with bootstrap ordering when not installing via ISO.
  • Fixed the unpack_dvd script to properly check for non-existent directories before unpacking the ISO images.
  • Fixed a bug where the Hiera use_ldap variable was not effective due to openldap::pam being included in the Hiera class list.
simp-doc
  • Spelling errors were corrected.
  • The PXE boot section was corrected.
  • Directory paths were fixed throughout the document.
  • The Security Conop tables were fixed.
DVD
  • Fixed a few typos in the auto.cfg file.
New Features
pupmod-onyxpoint-compliance
  • The first cut of the compliance mapper module. Will be replaced by a SIMP native version in the next release.
pupmod-simp-augeasproviders_grub
  • Imported the latest version of the upstream augeasproviders_grub module.
  • Added the ability to fully manage GRUB menu entries in both GRUB 2 and GRUB Legacy.
pupmod-simp-augeasproviders_sysctl
  • Added the ability to fail silently in the case that a running sysctl item cannot be manipulated. This is important in cases such as NFS where the appropriate module may not be loaded until it is actually used for the first time.
pupmod-simp-java_ks
  • Updated the module to the latest upstream version to support FIPS mode.
pupmod-simp-mcollective
pupmod-simp-openldap
  • Fixed the default.ldif template to modify the password setting defaults. This will not affect a running LDAP server.
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using external (non-SIMP) certificates.
pupmod-simp-pki
  • Allow the PKI content source to be modified so that you have a choice of where to pull your certificates. - Thanks to Carl Caum from Puppet Labs for this patch.
pupmod-simp-rsyslog
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using templates when sending to remote targets.
  • Ensure that all module artifacts are now packaged with the RPM.
pupmod-simp-simplib
  • Added a to_string() function.
  • Added a to_integer() function.
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-ssh
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-stunnel
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-sysctl
  • Migrate to using augeasproviders_sysctl for all sysctl activities.
  • This module will be deprecated in the next major release of SIMP.
simp-doc
  • The documentation on setting up redundant LDAP servers was updated.
  • A section on using The Foreman with SIMP was added.
Known Bugs
  • If you are running libvirtd, when svckill runs it will always attempt to kill dnsmasq unless you are deliberately trying to run the dnsmasq service. This does not actually kill the service but is, instead, an error of the startup script and causes no damage to your system.

Glossary of Terms

Note

Many terms here have been reproduced from various locations across the Internet and are governed by the licenses surrounding the source material. Please see the reference links for specifics on usage and reproducability.

ACL
Access Control List
A list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation.
AIDE
Advanced Intrusion Detection Environment
An intrusion detection system for checking the integrity of files under Linux. AIDE can be used to help track file integrity by comparing a snapshot of the system’s files prior to and after a suspected incident. It is maintained by Rami Lehti and Pablo Virolainen.
Auditd
The userspace component to the Linux Auditing System. It is responsible for writing audit records to the disk. Viewing the logs is done with the ausearch or aureport utilities. Configuring the audit rules is done with the auditctl utility. During startup, the rules in /etc/audit/audit.rules are read by auditctl. The audit daemon itself has some configuration options that the admin may wish to customize. They are found in the auditd.conf file.
BIOS
Basic Input/Output System

A type of firmware used to perform hardware initialization during the booting process (power-on startup) on IBM PC compatible computers.

Source: Wikipedia: BIOS

CA
Certificate Authority
An entity that issues X.509 digital certificates.
CentOS
Community Enterprise Operating System
An Enterprise-grade Operating System that is mostly compatible with a prominent Linux distribution.
CLI
Command Line Interface

A means of interacting with a computer program where the user (or client) issues commands to the program in the form of successive lines of text (command lines).

CPU
Central Processing Unit

A central processing unit (CPU) is the electronic circuitry within a computer that carries out the instructions of a computer program by performing the basic arithmetic, logical, control and input/output (I/O) operations specified by the instructions

Source: Wikipedia: Central Processing Unit

DHCP
Dynamic Host Configuration Protocol
A network protocol that enables a server to automatically assign an IP address to a computer.
DNS
Domain Name System
A database system that translates a computer’s fully qualified domain name into an IP address and the reverse.
ENC
External Node Classifier

An arbitrary script or application which can tell Puppet which classes a node should have. It can replace or work in concert with the node definitions in the main site manifest (site.pp).

The Puppet Enterprise Console and The Foreman are two examples of External Node Classifiers.

Source: External Node Classifiers

FIPS
Federal Information Processing Standard

Federal Information Processing Standards (FIPS) Publications are standards issued by NIST after approval by the Secretary of Commerce pursuant to the Federal Information Security Management Act (FISMA)

The particular standard of note in SIMP is FIPS 140-2

Source: FIPS Publications

FQDN
Fully Qualified Domain Name
A domain name that specifies its exact location in the tree hierarchy of the DNS. It specifies all domain levels, including the top-level domain and the root zone. An FQDN is distinguished by its unambiguity; it can only be interpreted one way.
GUI
Graphical User Interface

A type of interface that allows users to interact with electronic devices through graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels or text navigation.

Source: Wikipedia: Graphical User Interface

HDD
Hard Disk Drive
A device for storing and retrieving digital information, primarily computer data.
Hiera

A key/value lookup tool for configuration data, built to make Puppet better and let you set node-specific data without repeating yourself.

Source: Hiera Overview

IP
IP Address
Internet Protocol Address

A numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication.

Source: Wikipedia: IP Address

IP6Tables
Internet Protocol 6 Tables
A user space application that provides an interface to the IPv6 firewall rules on modern Linux systems.
IPTables
Internet Protocol Tables
A user space application that provides an interface to the IPv4 firewall rules on modern Linux systems.
Kerberos
A computer network authentication protocol that works on the basis of “tickets” to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.
Key Distribution Center
Part of a cryptosystem intended to reduce the risks inherent in exchanging keys. KDCs often operate in systems within which some users may have permission to use certain services at some times and not at others.
LDAP
Lightweight Directory Access Protocol
A protocol for querying and modifying LDAP directory services including information such as names, addresses, email, phone numbers, and other information from an online directory.
MAC
MAC Address
Media Access Control
Media Access Control Address

A unique identifier assigned to network interfaces for communications on the physical network segment.

Source: <Wikipedia: MAC address

NAT
Network Address Translation
The process of modifying IP address information in IP packet headers while in transit across a traffic routing device.
NFS
Network File System
A distributed file system protocol that allows a user on a client computer to access files over a network in a manner similar to how local storage is accessed.
PAM
Pluggable Authentication Modules
A mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independent of the underlying authentication scheme.
PEM
Privacy Enhanced Mail
An early standard for securing electronic mail. This is the public-key of a specific certificate. This is also the format used for Certificate Authority certificates.
PERL
Practical Extraction and Report Language
A high-level, general-purpose, interpreted, dynamic programming language. PERL was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.
PKI
Public Key Infrastructure
A security architecture that has been introduced to provide an increased level of confidence for exchanging information over an increasingly insecure Internet. PKI enables users of a basically insecure public networks, such as the Internet, to securely authenticate to systems and exchange data. The exchange of data is done by using a combination of cryptographically bound public and private keys.
PSSH
Parallel Secure Shell
A tool that provides parallel versions of OpenSSH and other related tools.
Puppet
An Open Source configuration management tool written and maintained by Puppet Labs. Written as a Ruby DSL, Puppet provides a declarative language that allows system administrators to provide a consistently applied management infrastructure. Users describes system resource and resource state in the Puppet language. Puppet discovers system specific information via facter and compiles Puppet manifests into a system specific catalog containing resources and resource dependencies, which are applied to each client system.
PXE
Preboot Execution Environment
An environment to boot computers using a network interface independently of data storage devices (like hard disks) or installed operating systems.
RAM
Random Access Memory
A form of computer data storage. A random access device allows stored data to be accessed in nearly the same amount of time for any storage location, so data can be accessed quickly in any random order.
Red Hat
Red Hat®
Red Hat®, Inc.

A collection of many different software programs, developed by Red Hat®, Inc. and other members of the Open Source community. All software programs included in Red Hat Enterprise Linux® are GPG signed by Red Hat®, Inc. to indicate that they were supplied by Red Hat®, Inc.

See also RHEL.

RHEL
Red Hat Enterprise Linux
A commercial Linux operating system produced by Red Hat®, Inc. RHEL is designed to provide an Enterprise-ready Linux distribution suitable to multiple target applications.
RPM
RPM Package Manager
A package management system. The name RPM is associated with the .rpm file format, files in this format, software packaged in such files, and the package manager itself. RPM was developed primarily for GNU/Linux distributions; the file format is the baseline package format of the Linux Standard Base.
RSA
An algorithm for public-key cryptography that is based on the presumed difficulty of factoring large integers, the factoring problem. RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman, who first publicly described it in 1977.
Ruby
A dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro “Matz” Matsumoto. It was influenced primarily by Perl, Smalltalk, Eiffel, and Lisp. Ruby supports multiple programming paradigms, including functional, object oriented, imperative and reflective. It also has a dynamic type system and automatic memory management; it is therefore similar in varying respects to Smalltalk, Python, Perl, Lisp, Dylan, Pike, and CLU.
Service Account
An account that is not for use by a human user but which still requires login access to a host.
SFTP
SSH File Transfer Protocol
A network protocol that provides file access, file transfer, and file management functionalities over any reliable data stream. It was designed by the Internet Engineering Task Force (IETF) as an extension of the Secure Shell protocol (SSH) version 2.0 to provide secure file transfer capability, but is also intended to be usable with other protocols.
SIMP
System Integrity Management Platform
A security framework that sits on top of RHEL or CentOS.
SSH
Secure Shell
An application for secure data communication, remote shell services, or command execution between networked computers. SSH utilitizes a server/client model for point-to-point secure communication.
SSL
Secure Sockets Layer

The standard security technology for using PKI keys to provide a secure channel between two servers.

See also TLS.

Sudosh
An application that acts as an echo logger to enhance the auditing of privileged activities at the command line of the operating system. Utilities are available for playing back sudosh sessions in real time.
TFTP
Trivial File Transfer Protocol
A file transfer protocol generally used for automated transfer of configuration or boot files between machines in a local environment.
TLS
Transport Layer Security

A cryptographic protocol that provides network communications security. TLS and SSL encrypt the segments of network connections above the Transport Layer, using asymmetric cryptography for privacy and a keyed message authentication codes for message reliability.

See also SSL.

TTY
A Unix command that prints to standard output the name of the terminal connected to standard input. The name of the program comes from teletypewriter, abbreviated “TTY”.
VM
Virtual Machine
An isolated guest operating system installation running within a host operating system.
VNC
Virtual Network Computing
A graphical desktop sharing system that uses the remote framebuffer (RFB) protocol to control another computer remotely. It transmits the keyboard and mouse events from one computer to another, relaying the graphical screen updates back in the other direction, over a network.
WAN
Wide Area Network
A computer networking technology used to transmit ata over long distances, and between different Local Area Networks (LANs), Metropolitan Area Networks (MANs), and other localized computer networking architectures.
X.509

An ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

Source: Wikipedia: X.509

YUM
Yellowdog Updater, Modified

A software installation tool for Linux. It is a complete software management system that works with RPM files. YUM is designed to be used over a network or the Internet.

See also RPM.

Installation_Miscellaney

This sections provides a list of variables that are configurable during the install.

List of Installation Variables

Description Default Setting Puppet Variable Section
Enable FIPS-140-2 compliance enabled use_fips FIPS
Do you want to set up network interface - use DHCP or Static for NIC - Hostname of server - IP Address of server - Netmask - Default gateway static puppet.change.me none none none none - The device is confgured none none none SYSTEM
Your DNS server IP this install dns::servers DNS
The search domain for DNS. change.me dns::search DNS
Subnet used for clients managed by the puppet server subnet of IP this install client_nets PUPPET
NTP servers. none ntpd::servers NTP
IP addr of primary log server (rsyslog) none log_servers RSYSLOG
IP address of failover log server. none failover_log_server RSYSLOG
Yum server for simp modules. IP this install simp::yum::servers YUM
Turn on the audit deamon? true use_auditd SYSTEM
Turn on iptable deamon? true use_iptables SYSTEM
The default system run level 3 common::runlevel SYSTEM
Do you want to set SELINUX to enforcing? true selinux::ensure SYSTEM
Set a grub password on the puppet server? true set_grub_password GRUB
Make puppet server the master yum server? true is_master_yum_server YUM
The FQDN of the puppet server. puppet.change.me puppet::server PUPPET
Puppet servers IP address. current IP puppet::server::ip PUPPET
FQDN of Puppet Certificate Authority (CA) puppet server puppet::ca PUPPET
The port Puppet CA will listen on. 8141 puppet::ca_port PUPPET
The DNS name of puppet database server. puppet server puppetdb::master::config::puppetdb_server PUPPET
The port used by the puppet database server 8139 puppetdb::master::config::puppetdb_port PUPPET
Do you want to use LDAP? true use_ldap PUPPET
LDAP Server Base Distinquish Name (DN) generate from puppetsrv name ldap::basedn LDAP
The LDAP Bind Distiquished name. generate from LDAP base DN ldap::bind_dn LDAP
LDAP Bind password yes ldap::bind_hash LDAP
LDAP Sync Distiquished name. generate from LDAP base DN ldap::sync_dn LDAP
LDAP Sync password yes ldap::sync_pw LDAP
The LDAP root DN. generated from the ldap::basedn ldap::root_dn LDAP
LDAP root password This password is used for manually updating LDAP, you will want to set it your self. no ldap::root_hash LDAP
The URI for your LDAP server. ldap::// <puppetsrvFQDN> ldap::master LDAP
The directory that will hold files used to sync oprational directories /var/simp/rsync/ OSTYPE/MJRREL   RSYNC
The server that remote syncs 127.0.0.1 rsync::server RSYNC
Maximum rsync timeout in seconds 1 rsync::timeout RSYNC

Configuration

This briefly describes what is being configured in the different sections indicated in the table above.

You may make changes to the default settings in `` puppet config print environmentpath/simp/hieradata/simp_def.yaml` `` or one of the other yaml files in the hieradata directory.

These Hiera files can be used after initial set up to change settings. The Hiera Overview section gives an introduction of using Hiera in SIMP.

FIPS
  • Turning on and off FIPS mode sets kernel parameters and systems environment variables to ensure the system is FIPS 140-2 compliant.
  • FIPS is on by default. If you ever want to have your system to beFIPS compliant, you will want to ensure that the system is built with this enabled. It may easily be disabled once the system is built.
GRUB
  • Grub password in /etc/grub.conf
DNS
  • The /etc/resolv.conf
  • The DNS server capabilities are not configured by this.
SYSTEM
  • Basic network setup.
  • Startup files in /etc/init.d.
  • Configuration files under /etc/sysconfig.
  • Rsyslog settings.
PUPPET
  • Autosigning in */etc/puppet/autosign.conf
  • File Serving in */etc/puppet/fileserver.conf
  • Puppet server and Certificate Authority (CA) information in /etc/puppet/puppet.conf
  • Server certificates for the puppet host (Fake CA)
LDAP
  • If you select use_ldap and set this server as your LDAP server, OpenLDAP Puppet will enable the LDAP service on this server and all clients will be set to reference it for authentication.
  • If you select use_ldap and set another server as your LDAP server, then the clients (including this server) will use the specified server instead.
  • If you choose not to use LDAP the system is set up to use traditional local authentication only.
RSYNC
  • The puppet server is configured to rsync data directories for services like DNS, DHCP or TFTP.
YUM
  • Base YUM repositories for RPM updates.

Indices and tables

SIMP User Guide

Contents:

Introduction

This guide will walk a user through the process of managing a SIMP system. This system includes, at a minimum, a SIMP server with properly configured networking information and a working Puppet server. Additionally, this document outlines the process of managing clients and users associated with the SIMP system.

Level of Knowledge

SIMP is designed for use by system administrators or users with a strong background using Linux operating systems. The core applications that make up SIMP and require prerequisite knowledge are:

SIMP does as much initial setup and configuration of these tools as possible. However, without at least some understanding, you will be unable to tailor a SIMP system to fit the desired environment. A general understanding of how to control and manipulate these tools from the command line interface (CLI) will be necessary, as SIMP does not come stock with a graphical user interface (GUI).

Knowledge of scripting and Ruby programming will also help to further customize a SIMP install but is not required for routine use.

SIMP Defined

The System Integrity Management Platform (SIMP) is a framework designed around the concept that individuals and organizations should not need to repeat the work of automating the basic components of their operating system infrastructure.

Expanding upon this philosophy, SIMP also aims to take care of routine policy compliance to include NIST 800-53, FIPS 140-2, the DISA STIG, and the SCAP Security Guides.

By using the Puppet automation stack, SIMP is working toward the concept of a self-healing infrastructure that, when used with a consistent configuration management process, will allow users to have confidence that their systems not only start in compliance but remain in compliance over time.

Finally, SIMP has a goal of remaining flexible enough to properly maintain your operational infrastructure. To this end, where possible, the SIMP components are written to allow all security-related capabilities to be easily adjusted to meet the needs of individual applications.

User Management

This chapter explains how to manage users in the default SIMP environment.

Managing Users with Lightweight Directory Access Protocol (LDAP)

SIMP natively uses OpenLDAP for user and group management. Actionable copies of the LDAP Data Interchange Format (.ldif) files can be found on the system in the /usr/share/doc/simp-doc-<Version>/ldifs directory.

Users cannot have any extraneous spaces in .ldif files.

# Use `:set list` in vim to see hidden spaces at the end of lines.

# Use the following to strip out inappropriate characters

sed -i \
  's/\\(^[[:graph:]]\*:\\)[[:space:]]\*\\ ([[:graph:]]\*\\) \\[[:space:]]\*$/\\1\\2/' \
  file.ldif

Note

Use the [ and ] characters to scroll right when using ELinks.

Add Users

Users can be added with or without a password. Follow the instructions in the following sections.

Warning

This process should not be used to create users or groups for daemon processes unless the user has experience.

Adding Users With a Password

To add a user to the system, Secure Shell (SSH) to the LDAP server and use the slappasswd command to generate a password hash for a user.

Create a /root/ldifs directory and add the following information to the /root/ldifs/adduser.ldif file. Replace the information within < > with the installed system’s information.

Example ldif to add a user

dn: uid=<User UID>,ou=People,dc=your,dc=domain
uid: <User UID>
cn: <User UID>
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: ldapPublicKey
shadowMax: 90
shadowMin: 1
shadowWarning: 7
shadowLastChange: 10167
pwdReset: TRUE
sshPublicKey: <User SSH Public Key>
loginShell: /bin/bash
uidNumber: <User UID Number>
gidNumber: <User Primary GID>
homeDirectory: /home/<User UID>
userPassword: <Password Hash from slappasswd>

Type:

`ldapadd -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f /root/ldifs/adduser.ldif` .

Ensure that an administrative account is created as soon as the SIMP system has been properly configured. Administrative accounts should belong to the administratorsLDAP group (gidNumber 700). Members of this LDAP group can utilize sudo sudosh for privilege escalation.

Note

The pwdReset: TRUE command causes the user to change the assigned password at the next login. This command is useful to pre-generate the password first and change it at a later time.

This command appears to be broken in some versions of nss_ldap. Therefore, to avoid future issues set shadowLastChange to a value around 10000.

Adding Users Without a Password

Create a /root/ldifs directory and add the following information to the /root/ldifs/adduser.ldif file. Replace the information within < > with the installed system’s information.

Example ldif example to add a user

dn: uid=<User UID>,ou=People,dc=your,dc=domain
uid: <User UID>
cn: <User UID>
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: ldapPublicKey
sshPublicKey: <User SSH Public Key>
loginShell: /bin/bash
uidNumber: <User UID Number>
gidNumber: <User Primary GID>
homeDirectory: /home/<User UID>

Type:

ldapadd -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
 -f /root/ldifs/adduser.ldif
Remove Users

To remove a user, create a /root/ldifs/removeuser.ldif file. Add the information below to the file and replace the text within < > with the installed system’s information.

Example ldif to remove a user

dn: cn=<User UID>,ou=Group,dc=example,dc=domain
changeType: delete

dn: uid=<User UID>,ou=People,dc=example,dc=domain
changeType: delete

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f /root/ldifs/removeuser.ldif
Additional .ldif File Commands

Other useful commands for .ldif files can be found below. Before using these commands, ensure that the /root/ldifs directory has been created.

Changing a Password

To change a password, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to change password

dn: uid=<User UID>,ou=People,dc=your,dc=domain
changetype: modify
replace: userPassword
userPassword: <Hash from slappasswd>

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Adding a Group

To add a group, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to add a group

dn: cn=<Group Name>,ou=Group,dc=your,dc=domain
objectClass: posixGroup
objectClass: top
cn: <Group Name>
gidNumber: <GID>
description: "Some Descriptive Text"

Type:

ldapadd -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Removing a Group

To remove a group, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to remove a group

dn: cn=<Group Name>,ou=Group,dc=your,dc=domain
changetype: delete

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Adding Users to a Group

To add users to a group, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to add to a group

dn: cn=<Group Name>,ou=Group,dc=your,dc=domain
changetype: modify
add: memberUid
memberUid: <UID1>
memberUid: <UID2>
...
memberUid: <UIDX>

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Removing Users from a Group

To remove users from a group, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to remove a user from a group

dn: cn=<Group Name>,ou=Group,dc=your,dc=domain
changetype: modify
delete: memberUid
memberUid: <UID1>
memberUid: <UID2>
...
memberUid: <UIDX>

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Updating an SSH Public Key

To update an SSH public key, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to update SSH public key

dn: uid=<User UID>,ou=People,dc=your,dc=domain
changetype: modify
replace: sshPublicKey
sshPublicKey: <User OpenSSH Public Key>

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>
Forcing a Password Reset

To force a password reset, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to reset user’s shadowLastChange

dn: uid=<User UID>,ou=People,dc=your,dc=domain
changetype: modify
replace: pwdReset
pwdReset: TRUE
-
replace: shadowLastChange
shadowLastChange: 10000

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
-f <.ldif_file>

Note

The ldapmodify command is only effective when using the ppolicy overlay. In addition, the user’s shadowLastChange must be changed to a value prior to the expiration date to force a PAM reset.

Unlocking an LDAP Account

To unlock an LDAP account, add the following information to the /root/ldifs/<.ldif File> file. Replace the information below within < > with the installed system’s information.

Example ldif to Unlock LDAP Account

dn: uid=<User UID>,ou=People,dc=your,dc=domain
changetype: modify
delete: pwdAccountLockedTime

Type:

ldapmodify -Z -x -W -D "cn=LDAPAdmin,ou=People,dc=your,dc=domain" \
 -f <.ldif_file>

Note

The ldapmodify command is only effective when using the ppolicy overlay.

Troubleshooting Issues

If a user’s password is changed in LDAP or the user changes it shortly after its initial setup, the “Password too young to change” error may appear. In this situation, apply the pwdReset:TRUE command to the user’s account as described Add Users with a Password section.

Managing Local/Service Users

Though the SIMP team highly recommends using LDAP to centrally manage your users, you may occasionally need to set up a service account or specific local users on your systems.

This section walks you through doing this in a way that is compatible with SIMP.

The following examples assume that you are using the site module to set up your users. The examples may easily be extrapolated into defined types if you wish but are presented as classes for simplicity.

If you are not familiar with setting up SSH keys, you may want to follow the relevant GitHub documentation.

Service Account
class site::service_account {
  include 'ssh'

  $_svc_account_user           = 'svcuser'
  $_svc_account_group          = 'svcgroup'
  $_svc_account_id             = '1777',
  $_svc_account_homedir        = "/var/local/${_svc_account_user}"

  # Since this is a service account, automatically generate an SSH key for
  # the user and store it on the Puppet master for distribution.
  $_svc_account_ssh_private_key = ssh_keygen($_svc_account_user, '2048', true)
  $_svc_account_ssh_public_key = ssh_keygen($_svc_account_user, '2048')

  group { $_svc_account_group:
    gid       => $_svc_account_id,
    allowdupe => false,
  }

  user { $_svc_account_user:
    uid        => $_svc_account_id,
    allowdupe  => false,
    gid        => $_svc_account_group,
    home       => $_svc_account_homedir,
    managehome => true,
    shell      => '/bin/bash'
  }

  file { "${_svc_account_homedir}/.ssh":
    ensure => directory,
    owner  => $_svc_account_user,
    group  => $_svc_account_group,
    mode   => '0700'
  }

  ssh_authorized_key { $_svc_account_user:
    type    => 'ssh-rsa',
    key     => $_svc_account_ssh_public_key,
    target  => "${_svc_account_homedir}/.ssh/authorized_keys",
    require => [
      File["${_svc_account_homedir}/.ssh"],
      User[$_svc_account_user]
    ]
  }

  file { "${_svc_account_homedir}/.ssh/id_rsa":
    mode    => '0600',
    owner   => $_svc_account_user,
    group   => $_svc_account_group,
    content => $_svc_account_ssh_private_key
  }

  file { "/etc/ssh/local_keys/${_svc_account_user}":
    owner  => 'root',
    group  => $_svc_account_group,
    mode   => '0644',
    source => "puppet:///site/ssh_autokeys/${_svc_account_user}.pub"
  }

  sudo::user_specification { $_svc_account_user:
    user_list => ["(${_svc_account_group})"],
    host_list => [$::fqdn],
    runas     => 'root',
    cmnd      => ['/bin/cat /var/log/app.log'],
    passwd    => false
  }

  # Allow this service account from everywhere
  pam::access::manage { "Allow ${_svc_account_user}":
    users   => ${_svc_account_user},
    origins => ['ALL']
  }
}
Local User Account
class site::service_account {
  include 'ssh'

  $_local_account_user           = 'localuser'
  $_local_account_group          = 'localgroup'
  $_local_account_id             = '1778',

  # You'll probably want this in /home unless you're using NFS
  $_local_account_homedir        = "/home/${_local_account_user}"

  # You'll need to get this from the user as it is their public key.
  $_local_account_ssh_public_key = 'AAA...=='

  group { $_local_account_group:
    gid       => $_local_account_id,
    allowdupe => false,
  }

  user { $_local_account_user:
    uid        => $_local_account_id,
    allowdupe  => false,
    gid        => $_local_account_group,
    home       => $_local_account_homedir,
    managehome => true,
    shell      => '/bin/bash'
  }

  file { "/etc/ssh/local_keys/${_local_account_user}":
    owner  => 'root',
    group  => $_local_account_group,
    mode   => '0644',
    source => "puppet:///site/ssh_autokeys/${_local_account_user}.pub"
  }

  sudo::user_specification { $_local_account_user:
    user_list => ["(${_local_account_group})"],
    host_list => [$::fqdn],
    runas     => 'root',
    cmnd      => ['/bin/cat /var/log/app.log'],
    passwd    => false
  }

  # Allow this account from everywhere
  pam::access::manage { "Allow ${_local_account_user}":
    users   => ${_local_account_user},
    origins => ['ALL']
  }
}
Testing

The table below lists the steps to test that the configuration was applied correctly.

  1. Log on to a server that has the template code configuration applied.
  2. Type su - ***<USERNAME>***
  3. Type exec /usr/bin/ssh-agent /bin/bash to ensure that ssh-agent has a shell running.
  4. Type /usr/bin/ssh-add to attach the user’s certificates.
  5. Optional: Type /usr/bin/ssh-add -l to double check that the user’s certificates were added successfully.
  6. Type ssh ***<HOST>*** to SSH to a target machine that has the template code configuration applied.

If successful, the user should be authenticated and gain access to the target machine without entering a password.

If the user is prompted for a password, check to see if the permissions are set up properly and that the certificate keys are in the correct locations. In addition, check the /etc/security/access.conf file to ensure that it contains the user or user’s group in an allow statement. See access.conf(5) for details.

Client Management

This chapter provides guidance to install and configure SIMP clients based on the standard SIMP system installed using the SIMP DVD.

System Requirements

Before installing clients, the system should consist of the following minimum requirements:

  • Hardware/Virtual Machine (VM) : Capable of running RHEL 6 or 7 ; 64-bit compatible
  • RAM: 512 MB
  • HDD: 5 GB

Configuring the Puppet Master

Perform the following actions as root on the Puppet Master system prior to attempting to install a client.

Configure DNS

Most static files are pulled over rsync by Puppet in this implementation for network efficiency. Specific directories of interest are noted in this section.

It is possible to use an existing DNS setup; however, the following table lists the steps for a local setup.

  1. Navigate to /srv/rsync/bind_dns
  1. Modify the named files to correctly reflect the environment. At a minimum, the following files under /srv/rsync/bind_dns/default should be edited:
  • named/etc/named.conf
  • named/etc/zones/your.domain
  • named/var/named/forward/your.domain.db
  • named/var/named/reverse/0.0.10.db

Important

For the named/var/named/forward/your.domain.db and named/var/named/reverse/0.0.10.db files, add clients as needed. Make sure to rename both of these files to more appropriately match your system configuration.

  • At a minimum, review named/etc/named.conf and check/update the

    following:

    • Update the IP for allow-query and allow-recursion
    • Delete any unnecessary zone stanzas (i.e. forwarding) if not necessary
    • Substitute in the FQDN of your domain for all occurrences of your.domain
  1. Type puppet agent -t --tags named on the Puppet Master to apply the changes. Validate DNS and ensure the /etc/resolv.conf is updated appropriately
  2. If an error about the rndc.key appears when starting bind, copy the rndc.key to /etc then re-run the puppet command: cp -p /var/named/chroot/etc/rndc.key /etc/rndc.key

Configure DHCP

Perform the following actions as root on the Puppet Master system prior to attempting to install a client.

Open the /srv/rsync/dhcpd/dhcpd.conf file and edit it to suit the necessary environment.

Make sure the following is done in the dhcpd.conf :

  • The next-server setting in the pxeclients class block points to the IP Address of the TFTP server.
  • Create a Subnet block and edit the following:
    • Make sure the router and netmask are correct for your environment.
    • Enter the hardware ethernet and fixed-address for each client that will be kickstarted. SIMP environments should not allow clients to pick random IP Address in a subnet. The MAC address must be associated with and IP Address here. (You can add additional ones as needed.)
    • Enter the domain name for option domain-name
    • Enter the IP Address of the DNS server for option domain-name-servers

Save and close the file.

Run puppet agent -t on the Puppet Master to apply the changes.

Configure PXE Boot

Sample kickstart templates have been provided in the /var/www/ks directory on the SIMP server and on the SIMP DVD under /ks. Pre-boot images are locate in the DVD under /images/pxeboot. If you have an existing Preboot Execution Environment (PXE) setup you can use these to PXE a SIMP client. Follow your own sites procedures for this.

In this section we describe how to configure the Kickstart and TFTP servers to PXE boot a SIMP client. (The DHCP server setup, also required for PXE booting, is discussed in and earlier chapter.)

Note

This example sets up a PXE boot for a system that is the same OS as the SIMP Server. If you are setting up a PXE boot for a different OS then you must make sure that the OS packages are available for all systems you are trying to PXE boot through YUM. There are notes through out the instructions to help in setting multiple OS but they are not comprehensive. You should understand DHCP, KS, YUM and TFTP relationships for PXE booting before attempting this.

Setting Up Kickstart

This section describes how to configure the kickstart server.

  1. Locate the following files in the /var/www/ks directory:
    1. pupclient_x86_64.cfg
    2. diskdetect.sh
  2. Open each of the files and follow the instructions provided within them to replace the variables. You need to know the IP Addresses of the YUM, Kickstart, and TFTPserver. (They default to the simp server in simp config).
    1. pupclient_x86_64.cfg:

      1.) Note: #KSSERVER# should be replaced with Kickstart Server IP not Yum IP. (They are the same if you used the defaults.) 2.) In the URL line use the YUMSERVER ip not the Kickstart server IP. (Although on a default SIMP system the YUM and kicktart server are the same server so it is not a problem.) 3.) Use the commands in the top of the file in the comments section to generate the password hashes.

    2. diskdetect.sh: The diskdetect.sh script is responsible for detecting the first active disk and applying a disk configuration. Edit this file to meet any necessary requirements or use this file as a starting point for further work. It will work as is for most systems as long as your disk device names are in the list.

  3. Type chown root.apache /var/www/ks/* to ensure that all files are owned by root and in the apache group.

  4. Type chmod 640 /var/www/ks/* to change the permissions so the owner can read and write the file and the apache group can only read.

Note

The URLs and locations in the file are setup for a default SIMP install. That means the same OS and version as the SIMP server, all servers in one location (on the SIMP server) and in specific directories. If you have installed these servers in a different location then the defaults, you may need to edit URLs or directories.

Note

If you want to PXE boot more than this operating system, make a copy of these files, name them appropriately and update URLS and links inside and anything else you may need. (You must know what you are doing before attempting this.) If you are booting more than one OS you must also make sure your YUM server has the OS packages for the other OSs. By default the YUM server on SIMP has the packages only for the version of OS installed on the SIMP server.

Setting up TFTP

This section describes the process of setting up static files and manifests for TFTP.

Static Files

Verify the static files are in the correct location:

Type cd /srv/rsync/tftpboot and then type ls to check for the existence of the /srv/rsync/tftpboot/linux-install/OSTYPE-MAJORRELEASE_ARCH directory.

where OSTYPE and MAJORRELEASE under linux-install are the OS type and OS major version of the systems you will be PXE booting.

Under this directory your should find a directory named OSTYPE-MAJORRELEASE.MINORRELEASE-ARCH and a link to this directory named OSTYPE-MAJORRELEASE-ARCH.

Under OSTYPE-MAJORRELEASE.MINORRELEASE-ARCH your should find the files:

  • initrd.img
  • vmlinuz

If these are not there then you must create the directories as needed and copy the files from /var/www/yum/OSTYPE/MAJORRELEASE/ARCH/images/pxeboot or from the images directory on the SIMP DVD.

Important

The link is what is used in the TFTP configuration files.

Note

If you want to be able to PXE boot different OS, then add a directory for each on and obtain the pxeboot images and copy them under the linux-install directory. SIMP only provides images for the OS for the SIMP server.

Manifest

Create a site manifest for the TFTP server on the Puppet server.

  1. Create the file /etc/puppet/environment/simp/modules/site/manifests/tftpboot.pp. Use the source code example below.
    1. Replace KSSERVER with the IP address of Kickstart server (or the code to look up the IP Address using Hiera).
    2. Replace OSTYPE, MAJORRELEASE and ARCH with the correct value for the systems you will be PXE booting.
    3. MODEL NAME is usually of the form OSTYPE-MAJORRELEASE-ARCH for consistency.
class site::tftpboot {
  include 'tftpboot'

  tftpboot::linux_model { 'MODEL NAME':
    kernel => 'OSTYPE-MAJORRELEASE-ARCH/vmlinuz',
    initrd => 'OSTYPE-MAJORRELEASE-ARCH/initrd.img',
    ks     => "http://KSSERVER/ks/pupclient_x86_64.cfg",
    extra  => "ksdevice=bootif\nipappend 2"
  }

  tftpboot::assign_host { 'default': model => 'MODEL NAME' }
}
  1. Add the tftpboot site manifest on your puppet server node via Hiera.

Create the file (or edit if it exists): /etc/puppet/environments/simp/hieradata/hosts/<tftp.server.fqdn>.yaml. (By default the TFTP server is the same as your puppet server o in the deault case it will exist.) Add the following example code to that yaml file.

---
classes:
  - 'site::tftpboot'

3. After updating the above file, type puppet agent -t --tags tftpboot on the Puppet server.

Note

To PXE boot more OSs create, in the tftpboot.pp file, a tftpboot::linux_model block for each OS type using the extra directories and kickstart files created using the notes in previous sections. Point individual systems to them by adding assign_host lines with their MAC pointing to the appropriate model name.

Setting Up the Client

The following lists the steps to PXE boot the system and set up the client.

  1. Set up your client’s BIOS or virtual settings to boot off the network.
  2. Make sure the MAC address of the client is set up in DHCP (see Configure DHCP for more info.)
  3. Restart the system.
  4. Once the client installs, reboots, and begins to bootstrap, it will check in for the first time.
  5. Puppet will not autosign puppet certificates by default and waitforcert is enabled. The client will check in every 30 seconds for a signed cert. Log on to the puppet server and run puppet cert sign <puppet.client.fqdn>.

Upon successful deployment of a new client, it is highly recommended that LDAP administrative accounts be created.

Troubleshooting Issues

If the client has been kickstarted, but is not communicating with the Puppet server, try the following options:

  • Check the forward and reverse DNS entries on the client and server; both must be correct.
  • Check the time on the systems. More than an hour’s difference will cause serious issues with certificates.
  • Remove /var/lib/puppet/ssl on the client system; run puppet cert --clean ***<Client Host Name>*** on the Puppet server; and try again.

Troubleshoot Certificate Issues

If host certificates do not appear to be working and the banner is not getting rsync’d to the clients, ensure that all certificates verify against the installed CA certificates.

The table below lists the steps to determine which certificates are working and which are not.

  1. Navigate to /etc/puppet/environments/simp/keydist
  2. Run find . -name “****<Your.Domain>*.pub” -exec openssl verify -CApath cacerts {} \;

Important

The screen displays ./<Host Name>.<Your.Domain>/<Host Name>.<Your.Domain>.pub: OK If anything other than OK appears for each host, analyze the error and ensure that the CA certificates are correct.

If the TXT_DB error number 2 appears, revoke the certificate that is being regenerated. The table below lists the steps to revoke the certificate.

  1. Navigate to /etc/puppet/environments/simp/keydist;
  2. Run OPENSSL_CONF=default.cnf openssl ca -revoke ../../keydist/***<Host to Revoke>*/*<Host to Revoke>*.pub**

Apply Certificates

This section provides guidance on obtaining official certificates and generating a Fake CA.

Obtaining Official Certificates

All SIMP systems must have Public Key Infrastructure (PKI) keypairs generated for the server. These keys reside in the /etc/puppet/keydist directory and are served to the clients over the Puppet protocol.

Note

These keypairs are not the keys that the Puppet server uses for its operation. Do not get the two confused.

The table below lists the steps to add any keys for the server that were received from a proper CA to /etc/puppet/keydist.

  1. Type mkdir /etc/puppet/keydist/***<Client System FQDN>***
  2. Type mv ***<Certificate Directory>***/***<FQDN>***.[pem|pub] /etc/puppet/keydist/***<FQDN>***
  3. Type chown -R root.puppet /etc/puppet/keydist
  4. Type chmod -R u=rwX,g=rX,o-rwx /etc/puppet/keydist

Table: Official Certificates Procedure

The table below lists the steps to create and populate the /etc/puppet/keydist/cacerts directory.

  1. Type cd /etc/puppet/keydist
  2. Type mkdir cacerts and copy the root CA public certificates into cacerts in Privacy Enhanced Mail (PEM) format (one per file).
  3. Type cd cacerts
  4. Type for file in *.pem; do ln -s $file `openssl x509 -in $file -hash -noout`.0; done

Table: /etc/puppet/keydist/cacerts Directory Creation Procedure

Generating Fake CAs

If server certificates have not or could not be obtained at the time of client installation, the SIMP team provides a way to create them for the system so that it will work until proper certificates are provided.

Note

This option should not be used for any operational system that can use proper enterprise PKI certificates.

The table below lists the steps to generate the Fake CAs.

  1. Type cd /etc/puppet/Config/FakeCA
  2. Type vi togen
  3. Remove old entries from the file and add the Fully Qualified Domain Name (FQDN) of the systems (one per line) for which certificates will be created.

Note

To use alternate DNS names for the same system, separate the names with commas and without spaces. For example, .name,alt.name1,alt.name2.

  1. Type wc cacertkey

Note

Ensure that the cacertkey file is not empty. If it is, enter text into the file; then save and close the file.

  1. Type ./gencerts_nopass.sh auto

Note

To avoid using the default Fake CA values, remove the auto statement from the ./gencerts_nopass.sh command.

Table: Generating Fake CAs Procedure

Warning

If the clean.sh command is run after the certificates have been generated, the running system will break. To troubleshoot certificate problems, see the section at the end of this chapter.

If issues arise while generating keys, type cd /etc/puppet/Config/FakeCA to navigate to the /etc/puppet/Config/FakeCA directory, then type ./clean.sh to start over.

After running the clean.sh script, type ./gencerts_nopass.sh to run the script again using the previous procedure table.

Maximum Number of Nodes

The maximum number of clients reasonable per each system is dependent on many variables, including number of processors and size of memory. Although it is impossible to predict exactly how many clients a specific server may be able to handle, a simple algorithm can give the user an estimate.

Servers with different hardware have been tested at worst case scenario. This means that all of the server’s clients will run Puppet at the exact same time. The most important information collected during these runs was the compile time, which shows the increase in seconds that it takes for each node to compile when another node is added. After a certain number of nodes, nodes begin to drop to compile times lower than 30 seconds. These nodes are not actually completing their Puppet runs. This data can be seen in the following graph:

Number of Nodes vs. Compile Time

The queue size can be found by looking at the maximum number of clients running Puppet at once before any are dropped. According to the SIMP team’s data, a server with two cores has a queue size of four; a server with three cores has a queue size of six; however, a server with four cores has a queue size of six. Although it may appear that the queue size is plateauing as cores are increased, the SIMP team predicts that this is due to the limited memory. However, the team is confident that a system with four cores and 4GB of ram will indeed have a queue size of eight clients. From this, it can be concluded that, given enough memory, Queue_Size = 2*Cores.

Also using this data, the compile times for other systems can be predicted given the amount of processors, memory, and nodes. This is done using ordinary least squares in Octave.

In addition, the maximum number of clients can also be predicted with the use of the following equation:

Max_Num_Of_Total_Clients = (Run_Time_In_Sec / Comp_Time) * Queue_Size

Where Run_Time_In_Sec is the number of seconds per half an hour (1800), Queue_Size is the maximum number of clients in the worst case scenario (queue size), and Comp_Time is the average compile time of the clients when there are Max_Num_Worstcase clients.

_images/Graph_Max_Nodes_sized.png

SIMP Administration

This chapter provides basic guidance on how to administer a SIMP environment.

Warning

While working with the system, keep in mind that Puppet does not work well with capital letters in host names. Therefore, they should not be used.

Nightly Updates

All SIMP systems are configured, by default, to do a YUM update of the entire system on a nightly basis.

The configuration pulls updates from all repositories that the system is aware of. To change this behavior, refer to the Excluding Repositories FAQ section. This configuration is also helpful because it is easier to manage symlinks in YUM repositories than it is to manage individual package minutia for every single package on every system.

The general technique is to put packages that all systems will receive into the Updates repository provided with SIMP. Any packages that will only go to specific system sets will then be placed into adjunct repositories under /var/www/yum and the user will point specific systems at those repositories using the yumrepo Puppet type. Any common packages can be symlinked or hard linked between repositories for maximum space utilization.

Sudosh

By default, a SIMP system uses Sudosh to enable logging of sudo sessions to Rsyslog. To open a sudo session as root (or any other user), type su - as simp, or sudo sudosh as anyone else, instead of sudo su.

The logs are stored in /var/log/sudosh.log. Sessions can be replayed by typing sudosh-syslog-replay.

User Accounts

By default, users can add local users to a system or use LDAP to administer users.

It is recommended that LDAP is used for adding all regular users so that there is no conflict with multiple system updates and synchronization. For more information on managing LDAP users, refer to the User Management chapter.

It is also possible that there will be users that are local to the system. To have these users follow the normal password expiration conventions set on the system, use the native Puppet user and group types.

To have a user that does not expire, look at the /etc/puppet/localusers file to enable these users across the systems. The comments in the file provide instructions on generating entries for the desired systems. It is hoped that future versions of Puppet will support the modification of password expiration values via the native types and that the localusers file will be retired.

Certificate Management

This section describes the two different types of certificates used in a SIMP system and how to manage them. For information on initial certificate setup, refer to the Apply Certificates section of the Client Management chapter.

Server Certificates

Server certificates are the standard PKI certificates assigned either by an official CA or generated using the FakeCA utility offered by SIMP. They can be found in the /etc/pki/ directory of both the client and server systems. These certificates are set to expire annually. To change this, edit the following files with the number of days for the desired lifespan of the certificates:

Note

This assumes that the user has generated Certificates with the FakeCA provided by SIMP. If official certificates are being used, these settings must be changed within the official CA, not on the SIMP system.

  • /etc/puppet/Config/FakeCA/CA
  • /etc/puppet/Config/FakeCA/ca.cnf
  • /etc/puppet/Config/FakeCA/default\_altnames.cnf
  • /etc/puppet/Config/FakeCA/default.cnf
  • /etc/puppet/Config/FakeCA/user.cnf

In addition, any certificates that have already been created and signed will have a config file containing all of its details in /etc/puppet/Config/FakeCA/output/conf/.

Important

Editing any entries in the above mentioned config files will not affect the existing certificates. To make changes to an existing certificate it must be re-created and signed.

Below is an example of how to change the expiration time from one year (the default) to five years for any newly created certificate.

for file in $(grep -rl 365 /etc/puppet/Config/FakeCA/)
do
  sed -i 's/365/1825/' $file
done

Puppet Certificates

Puppet certificates are issued and maintained strictly within Puppet. They are different from the server certificates and should be managed with the puppet cert tool. For the complete documentation on the puppet cert tool, visit the Puppet Labs cert manual detailing its capabilities. On a SIMP system, these certificates are located in the /var/lib/puppet/ssl/ directory and are set to expire every five years.

Applications

This section describes how to add services to the servers. To perform this action, it is important to understand how to use IPtables and what the svckill.rb script does on the system.

IPTables

By default, the SIMP system locks down all incoming connections to the server save port 22. Port 22 is allowed from all external sources since it is expected that the user will want to be able to SSH into the systems from the outside at all times.

The default alteration for the IPtables start-up script is such that it will “fail safe”. This means that if the IPtables rules are incorrect, the system will not open up the IPtables rule set completely. Instead, the system will deny access to all ports except port 22 to allow for recovery via SSH.

There are many examples of how to use the IPtables module in the source code; the Apache module at /etc/puppet/modules/apache is a particularly good example. In addition, look at the definitions in the IPtables module to understand their purpose and choose the best option. Refer to the IPtables page of the Developers Guide for a good summary and example code (HTML version only).

svckill.rb

To ensure that the system does not run more services than are required, the svckill.rb script has been implemented to stop any service that is not properly defined in the Puppet catalogue.

To prevent services from stopping, refer to the instructions in the My Services Are Dying! FAQ section.

GUI

SIMP was designed as a minimized system, but it is likely that the user will want to have a GUI on some of the systems. Refer to the Infrastructure Setup section for information on setting up GUIs for the systems.

Backing up the Puppet Master

This section details all of the steps required for backing up the Puppet Master.

Note

SIMP, by default, provides two ways to back up data. They are BackupPC and Git. If there is a different preferred method, the user may install it and configure it first.

Warning

BackupPC may, or may not, work properly for you on RHEL7+ systems. The SIMP team is currently evaluating other options for an inbuilt backup system.

  1. Backup /var/lib/puppet/ssl
  2. Backup /etc/puppet
  3. Backup /srv/rsync and/or /var/simp/rsync
  4. Optional: Backup /var/www

Table: SIMP Upgrade Process

Managing Workstation Infrastructures

This chapter describes how to manage client workstations with a SIMP system including GUIs, repositories, virtualization, Network File System (NFS), printing, and Virtual Network Computing (VNC).

Infrastructure Setup

The following sections provide examples for setting up a SIMP workstation environment.

User Workstation Setup

Below is an example class, /etc/puppet/modules/site/manifests/workstation.pp, that could be used to set up a user workstation.

class site::workstation {
  include 'site::gui'
  include 'site::repos'
  include 'site::virt'
  include 'site::automount'
  include 'site::print::client'

  # Make sure everyone can log into all nodes.
  # If you want to change this, simply remove this line and add
  # individual entries to your nodes as appropriate
  pam::access::manage { "Allow Users":
    comment => 'Allow all users in the "users" group to access the system from anywhere.',
    users   => '(users)',
    origins => ['ALL']
  }

  # General Use Packages
  package { [
    'pidgin',
    'git',
    'control-center-extra',
    'gconf-editor',
    'evince',
    'libreoffice-writer',
    'libreoffice-xsltfilter',
    'libreoffice-calc',
    'libreoffice-impress',
    'libreoffice-emailmerge',
    'libreoffice-base',
    'libreoffice-math',
    'libreoffice-pdfimport',
    'bluefish',
    'gnome-media',
    'pulseaudio',
    'file-roller',
    'inkscape',
    'gedit-plugins',
    'planner'
  ]: ensure => 'latest'
  }
}

Graphical Desktop Setup

Below is an example manifest called /etc/puppet/modules/site/manifests/gui.pp for setting up a graphical desktop on a user workstation.

class site::gui {
  include 'xwindows::gdm'
  include 'windowmanager::gnome'
  include 'vnc::client'

   # Compiz Stuff
  package { [
    'fusion-icon',
    'emerald-themes',
    'compiz-fusion-extras',
    'compiz-fusion-extras-gnome',
    'vinagre'
  ]:
    ensure => 'latest'
  }
}

Workstation Repositories

Below is an example manifest called /etc/puppet/modules/site/manifests/repos.pp for setting up workstation repositories.

class site::repos {
  # Whatever local yumrepo statements you need for installing
  # your packages and keeping your systems up to date
}

Virtualization on User Workstations

Below is an example manifest called /etc/puppet/modules/site/manifests/virt.pp for allowing virtualization on a user workstation.

# We allow users to run VMs on their workstations.
# If you don't want this, just don't include this class.
# If this is installed, VM creation and management is still limited by PolicyKit

class site::virt {
  include 'libvirt::kvm'
  include 'libvirt::ksm'
  include 'network::redhat'

  network::redhat::add_eth { "em1":
    bridge => 'br0',
    hwaddr => $::macaddress_em1
  }

  network::redhat::add_eth { "br0":
    net_type => 'Bridge',
    hwaddr => $::macaddress_em1,
    require => Network::Redhat::Add_eth["em1"]
  }

  common::swappiness::conf { 'default':
    high_swappiness => '80',
    max_swappiness => '100'
  }

  # If 80% of memory is used, flush caches.
  exec { 'flush_cache_himem':

    command => '/bin/echo 1 > /proc/sys/vm/drop-caches',
    onlyif => inline_template("/bin/<%= memoryfree.split(/\s/)[0].
    to_f/memorysize.split(/\s/)[0].to_f < 0.2 ? true : false %>")
  }

  package { 'virt-manager': ensure => 'latest' }
}

Network File System

Below is an example manifest called /etc/puppet/modules/site/automount.pp for Network File System setup.

#If you are not using NFS, you do not need to include this.

class site::automount {
  include 'autofs'

  file { '/net':
    ensure => 'directory',
    mode   => '0755'
  }

#A global share
Autofs::map::master { ‘share’:
  mount_point => ‘/net’,
  map_name    => ‘/etc/autofs/share.map’
}
#Map the share
autofs::map::entry { ‘share’:
  options    => ‘-fstype=nfs4, port=2049.soft’,
location    => “${::nfs_server}:/share’.
Target     => ‘share’
}
}

Setting up a Printer Environment

Below are example manifests for setting up a printing environment.

Setting up a Print Client

Below is an example manifest called /etc/puppet/modules/site/manifests/print/client.pp for setting up a print client.

class site::print::client inherits site::print::server {
  polkit::local_authority { 'print_support':
    identity                 => ['unix_group:*'],
    action                   => 'org.opensuse.cupskhelper.mechanism.*',
    section_name       => 'Allow all print management permissions',
    result_any            => 'yes',
    result_interactive => 'yes',
    result_active         => 'yes'
  }

  package { 'cups-pdf': ensure => 'latest' }
  package { 'cups-pk-helper': ensure => 'latest' }
  package { 'system-config-printer': ensure => 'present' }
}
Setting up a Print Server

Below is an example manifest called /etc/puppet/modules/site/manifests/print/server.pp for setting up a print server.

class site::print::server {

  # Note, this is *not* set up for being a central print server.
  # You'll need to add the appropriate IPTables rules for that to work.
  package { 'cups': ensure => 'latest' }

  service { 'cups':
    enable     => 'true',
    ensure     => 'running',
    hasrestart => 'true',
    hasstatus  => 'true',
    require    => Package['cups']
  }
}

VNC

Virtual Network Computing (VNC) is a tool that is used to manage desktops and workstations remotely through the standard setup or a proxy.

VNC Standard Setup

Note

You must have the pupmod-vnc RPM installed to use VNC on your system!

To enable remote access via VNC on the system, include vnc::server in Hiera for the node.

The default VNC setup that comes with SIMP can only be used over SSH and includes three default settings:

Setting Type Setting Details
Standard

Port: 5901

Resolution: 1024x768@16
Low Resolution

Port: 5902

Resolution: 800x600@16
High Resolution

Port: 5903

Resolution: 1280x1024@16

Table: VNC Default Settings

To connect to any of these settings, SSH into the system running the VNC server and provide a tunnel to 127.0.0.1:<VNC Port>. Refer to the SSH client’s documentation for specific instructions.

To set up additional VNC port settings, refer to the code in `/etc/puppet/modules/vnc/manifests/server.pp <file:///etc/puppet/modules/vnc/manifests/server.pp>`__ for examples.

Important

Multiple users can log on to the same system at the same time with no adverse effects; however, none of these sessions are persistent.

To maintain a persistent VNC session, use the vncserver application on the remote host. Type man vncserver to reference the manual for additional details.

VNC Through a Proxy

The section describes the process to VNC through a proxy. This setup provides the user with a persistent VNC session.

Important

In order for this setup to work, the system must have a VNC server (vserver.your.domain), a VNC client (vclnt.your.domain), and a proxy (proxy.your.domain). A vuser account must also be set up as the account being used for the VNC. The vuser is a common user that has access to the server, client, and proxy.

Modify Puppet

If definitions for the machines involved in the VNC do not already exist in Hiera, create an /etc/puppet/hieradata/hosts/vserv.your.domain.yaml file. In the client hosts file, modify or create the entries shown in the examples below. These additional modules will allow vserv to act as a VNC server and vclnt to act as a client.

VNC Server node

# vserv.your.domain.yaml
classes:
  - 'windowmanager::gnome'
  - 'mozilla::firefox'
  - 'vnc::server'

VNC client node

# vclnt.your.domain.yaml
classes:
  - 'windowmanager::gnome'
  - 'mozilla::firefox'
  - 'vnc::client'
Run the Server

As vuser on vserv.your.domain, type vncserver.

The output should mirror the following:

New ‘vserv.your.domain:<Port Number> (vuser)’ desktop is vserv.your.domain:<Port Number>

Starting applications specified in /home/vuser/.vnc/xstartup Log file is /home/vuser/.vnc/vserv.your.domain:<Port Number>.log

Note

Remember the port number; it will be needed to set up an SSH tunnel.

Set up an SSH Tunnel

Set up a tunnel from the client (vclnt), through the proxy server (proxy), to the server (vserv). The table below lists the steps to set up the tunnel.

  1. On the workstation, type ssh -l vuser -L 590***<Port Number>*:localhost:590***<Port Number>***proxy.your.domain**

Note

This command takes the user to the proxy.

  1. On the proxy, type ssh -l vuser -L 590***<Port Number>*:localhost:590***<Port Number>***vserv.your.domain**

Note

This command takes the user to the VNC server.

Table: Set Up SSH Tunnel Procedure

Note

The port number in 590<Port Number> is the same port number as previously described. For example, if the <Port Number> was 6, then all references below to 590<Port Number> become 5906.

Set Up Clients

On vclnt.your.domain, type vncviewer localhost:590\ ***<Port Number>*** to open the Remote Desktop viewer.

Troubleshooting VNC Issues

If nothing appears in the terminal window, X may have crashed. To determine if this is the case, type ps -ef | grep XKeepsCrashing

If any matches result, stop the process associated with the command and try to restart vncviewer on vclnt.your.domain.

Upgrading SIMP

This chapter provides information on how to upgrade a running instance to the latest codebase.

Pre-Upgrade Recommendations

The following process should be followed before upgrade.

  1. Run puppet agent --disable to disable puppet.

Note

If you think you will need more than 4 hours to complete this task, also disable puppet in root’s crontab.

  1. You may wish to block all communications with agents while updating the server. This is not required but could spare you some headaches if something doesn’t work properly.

The simplest way to do this is to set the catalog retrieval capability to 127.0.0.1 in /etc/puppet/auth.conf as shown below.

path ~ ^/catalog/([^/]+)$
method find
# Uncomment this when complete and delete the other entries
#allow $1
allow 127.0.0.1

Using the syntax above, you can add fully qualified domain names, one at a time, to the ‘allow’ list and only those hosts will be able to retrieve their catalog from the running server. 127.0.0.1 serves as a placeholder so that no host can actually retrieve their catalog.

Migrating To Environments

SIMP 4.1 and 5.0 used the traditional, Rack-based, Puppet Master. Starting with 4.2 and 5.1, SIMP now uses the Clojure-based Puppet Server. Unfortunately, there are some conflicts with directly upgrading from the Puppet Master to the Puppet Server since some of the RPM package prerequisites conflict. This new Puppet Server can properly utilize Puppet Environments. To provide our users with this capability, and to facilitate more dynamic workflows in the future, the SIMP team has migrated all existing material to a native simp environment. To help facilitate your migration, the SIMP team has created two migration scripts that both upgrade your Puppet Server and migrate your existing data into the new simp environment.

Warning

You must have at least 2.2G of free memory to run the new Puppet Server.

Migration Script Features

The migration script will perform the following actions on your system:

  • Remove the puppet-server package from your system
  • Install the puppetserver package onto your system
  • Update all packages from your repositories
  • Create a backup folder at /etc/puppet/environments/pre_migration.simp
  • Create a Git repository in the backup folder under a timestamped directory
  • Commit all current materials from /etc/puppet into the backup Git repository
  • Checkout the backup Git repository under the timestamped directory as backup_data for ease of use
  • Migrate all existing data into the new simp environment under /etc/puppet/environments/simp

Note

All future upgrades will only affect the new simp environment. You may create new environments and/or modify the contents of /etc/puppet/modules without fear of the SIMP packages overwriting your work.

Migration Script Execution

  1. Copy the new SIMP ISO onto your system. For the purposes of these instructions, we will refer to this is SIMP_Update.iso. Please ensure that you are in the directory with the ISO prior to proceeding. Extract the new simp-utils package using the following command:
isoinfo -i SIMP_Update.iso -R -x `isoinfo -i SIMP_Update.iso -Rf | grep noarch/simp-utils` > simp-utils-update.rpm
  1. Install the new simp-utils RPM:
yum -y localupdate simp-utils*.rpm
  1. Unpack the DVD onto the system:
/usr/local/bin/unpack_dvd SIMP_Update.iso
  1. Run the migration script (this may take some time, do NOT hit CTRL-C!):
/usr/share/simp/upgrade_script/migrate_to_environments
  1. Run the puppet agent:
puppet agent -t
  1. Stop the new puppetserver service (it may not be running):
service puppetserver stop
  1. Remove any left over PID files:
rm /var/run/puppetserver/puppetserver
  1. Kill any running puppet master processes:
pkill -f 'puppet master'
  1. Wait for 10 seconds to let things finalize if necessary:
sleep 10
  1. Start the new Puppet Server:
service puppetserver start

Table: Executing the Migration Script

Your new Puppet Server should now be running and a run of puppet agent -t should complete as usual.

Converting from Extdata to Hiera

SIMP now uses Hiera natively instead of Extdata. Tools have been put into place by Puppet Labs and SIMP to make the conversion as easy as possible. Two scripts have been provided to automatically convert generic csv files and simp_def.csv to yaml. The first example shows how to convert an Extdata csv file called foo.csv into a Hiera yaml file called bar.yaml:

extdata2hiera -i foo.csv -o bar.yaml

The second example shows how to convert an Extdata csv simp_def file called simp_def.csv into a Hiera yaml file called simp_def.yaml.

simpdef2hiera --in simp_def.csv --out simp_def.yaml

Puppet will automatically retrieve class parameters from Hiera, using lookup keys like myclass::parameter_one. Puppet classes can optionally include parameters in their definition. This lets the class ask for data to be passed in at the time that it’s declared, and it can use that data as normal variables throughout its definition.

There are two main ways to reference Hiera data in puppet manifests. The first, and preferred way, is to use the automatic class variable lookup capability. For each class that you create, the variables will be automatically discovered in hiera should they exist. This is quite powerful in that you no longer need to provide class parameters in your manifests and can finally properly separate your data from your code.

Note

For more information on the lookup functions, see Link the puppet documentation on Hiera.

# Some class file in scope...
class foo (
  $param1 = 'default1'
  $param2 = 'default2'
) { .... }

# /etc/puppet/hieradata/default.yaml
---
foo::param1: 'custom1'

The second is similar to the old Extdata way, and looks like the following:

$var = hiera("some_hiera_variable", "default_value")

The following is from the Puppet Labs documentation, and explains the reason for switching to Hiera.

Automatic parameter lookup is good for writing reusable code because it is regular and predictable. Anyone downloading your module can look at the first line of each manifest and easily see which keys they need to set in their own Hiera data. If you use the Hiera functions in the body of a class instead, you will need to clearly document which keys the user needs to set.

Note

For more information on hiera and puppet in general, see http://docs.puppetlabs.com/hiera/1/complete_example.html.

Scope Functions

All scope functions must take arguments in array form. For example in /etc/puppet/modules/apache/templates/ssl.conf.erb:

<%=scope.function_bracketize(l) %>
becomes
<%=scope.function_bracketize([l]) %>

Commands

Deprecated commands mentioned in Puppet 2.7 upgrade are now completely removed.

Lock File

Puppet agent now uses the two lock files instead of one. These are the run-in-progress lockfile (agent_catalog_run_lockfile) and the disabled lockfile (agent_disabled_lockfile). The puppetagent_cron file (made by the pupmod module) must be edited to suit this change.

Logstash

This chapter gives instruction for getting a basic configuration of Logstash working in a SIMP environment.

Logstash

Logstash is an open source tool that provides a means for SIMP implementations to have logs and events collected, searched, and forwarded (filtered or unfiltered) to another host. SIMP comes with three separate but related modules. The modules are:

  • Logstash: Installs the RPMs and configuration needed for log inputs, filters, and outputs.
  • Kibana: Installs the RPMs and configuration needed for the Kibana 3 web interface.
  • Elasticsearch: Installs the RPMs and configuration needed for Elasticsearch.

Warning

The Logstash class is incompatible with the SIMP rsyslog::stock::server class! You cannot enable both of them on the same sever.

Logstash Architecture

The overall model for Logstash is very simple. It takes inputs from various sources, optionally applies filters, and outputs the results to a specified target. It’s likely that you can already forward logs to Logstash and output them in a useful format as part of your existing architecture.

Logstash filters can manipulate logs after ingest and before output. Examples of existing filters include fixing logs to split/combine lines, adding fields, normalizing time stamps, and adding GeoIP fields. Depending on the type of log manipulation that is desired, there is likely a filter and associated documentation that already exists.

Logstash SIMP Architecture

Applying the SIMP Logstash, Elasticsearch, and Kibana modules provides an implementation with a functioning log reduction and search capability. Unless scale dictates otherwise, these three modules can easily be applied to a single host.

The intent of providing Logstash in SIMP is to replace the default Rsyslog server with a capability that is easier to search and analyze over time. Once your Logstash server is set up, you simply need to direct your hosts to forward logs to your Logstash server. In a default SIMP configuration, this can be done by setting the $log_server variable in hiera.

Note

SIMP does NOT apply any filters to the logs by default.

It is up to each implementation to define and apply filters that meet their local requirements. While multiple output targets may be defined, SIMP only defines the Elasticsearch output by default. Please see the Elasticsearch Puppet module for details on how to define additional output targets.

SIMP Logstash Fow

Logstash, SIMP, and Security

The provided SIMP modules for Logstash, Elasticsearch, and Kibana have been built with connection security in mind. Overriding these settings could adversely affect the security of the logging infrastructure. The following list describes the security features in place with the default SIMP module settings:

Warning

The native (Java) Elasticsearch connections are not encrypted! This will be remedied in the future as sufficient methods are found.

  • User Name and Password Protection for Kibana: The Kibana web can be exposed to a defined list of hosts. If you are connecting to Kibana from anything other than the localhost, a user name and password is required for authentication. Both LDAP and local database users are supported.
  • Syslog over Stunnel: The default behavior in SIMP is to encrypt syslog traffic over Stunnel. This remains the case with Logstash. Unencrypted traffic is also supported for network devices.
  • Limiting Web Actions: The Kibana module restricts what HTTP commands a user can perform on the Elasticsearch data store. Full POST action must be given to the Logstash nodes and some nodes may require DELETE capabilities. Logstash hosts should be tightly controlled so that administrative users cannot modify data inside of Elasticsearch with carefully crafted commands. This is one reason that we use syslog on the local hosts.

Important

The Puppet modules for Logstash, Kibana, and Elasticsearch contain dozens of variables that may be manipulated. You should read each product’s documentation and ensure you understand any setting that is changed from the default SIMP values. Changes can affect both security and functionality of the system.

Logstash Setup

Logstash System Requirements

The storage requirements for Logstash and Elasticsearch vary depending on how long you plan on keeping logs. If you use the settings in ?, then your logs are not being filtered and are being sent to Elasticsearch. When using Elasticsearch, the logs are formatted for Elasticsearch and stored in /var/elasticsearch. You can also configure how many days of data you wish to keep in Elasticsearch (keep_days => ‘99’). Therefore, you should ensure you have enough space on /var to keep your defined number of days worth of logs.

As you grow your Elasticsearch cluster to handle increasing log loads, you will want to ensure that your keep_days is set to handle your entire cluster appropriately.

Note

You should have at least 4G of memory available on any Elasticsearch node.

Important

You should NOT install Logstash, Elasticsearch, nor Kibana on your Puppet master. There will likely be conflicts with Apache and resource limitations.

Using Kerberos 5 in SIMP

The Kerberos module helps an administrator obtain a working Key Distribution Center (KDC) setup and configure clients to use the KDC.

Important

Given the highly sensitive nature of Kerberos passwords and tokens, this module does not store or use any passwords related to the Kerberos KDC.

Remember the passwords chosen for the Kerberos KDC. Puppet does not have the ability to retrieve forgotten passwords.

As a result of the nature of Kerberos, an administrator must run /usr/sbin/kdb5_util create -s on the KDC to set the principal administrator password and initialize the database.

The following sections provide instruction on how to get started with Kerberos 5. For more detailed information, review the official Red Hat documentation.

Creating Principals

Once all of the systems using Kerberos are properly configured, either via the krb::stock classes or otherwise, the administrator must register principals with the KDC.

Create the Admin Principal

The first principal to be registered is an admin principal that manages the environment, since it is in the admin group. This principal must be created on the KDC system.

Before creating the admin principal, the user must first create an Access Control List (ACL). To accomplish this, add the following Puppet code to the site manifest for the KDC system. If a custom implementation of Kerberos is being used, changes may need to be made to the code.

Code for Creating an Admin Principal Kerberos

krb5_acl{ "${::domain}_admin":
  principal       => "*/admin@${::domain}",
  operation_mask  => '*'
}

The table below lists the steps to create an admin principal that is appropriate for common organizations. These steps should be accomplished after creating the ACL by using the code provided in the previous example.

  1. After using the code from the previous example, run puppet agent -t to allow the changes to take effect.
  2. To finish creating the principal, type /usr/bin/kadmin.local -r ***<Your.Domain>* -q “addprinc *<User Name>*/admin”

Note

By following this step, all features of the admin principal can be used remotely.

  1. To load the principal, type /usr/bin/kinit ***<User Name>*/admin**

Table: Creating the Admin Principal Procedure

Create the Host Principal(s)

Once the admin principal has been created, host principals for each host can be made. The table below lists the steps to complete this action.

  1. On the KDC, generate a principal for each host in the environment by typing /usr/sbin/kadmin.local -r ***<Your.Domain>* -q ‘addprinc -randkey host/*<FQDN>*‘

Note

To use much of the functionality of the host, the user must first ensure that each host has a keytab. SIMP uses the /etc/puppet/keydist directory for each host to distribute keytabs securely to the clients.

  1. To create a keytab file for each of the above hosts, type /usr/sbin/kadmin.local -r ***<Your.Domain>* -q ‘ktadd -k *<FQDN>*.keytab host/*<FQDN>*‘
  2. Propagate all keytabs to the Puppet server by moving all of the resulting keytab files securely to the /etc/puppet/keydist/<FQDN>/keytabs directory on the Puppet server, as appropriate for each file.
  3. Update the node declarations to include krb::keytab.

Note

Ensure that all keytab directories are readable by the group Puppet, but not globally.

Table: Creating Host Principals Procedure

Once the Puppet Agent runs on the clients, the keytabs are copied to the /etc/krb5_keytabs directory. The keytab matching the FQDN is set in place as the default keytab, /etc/krb5.keytab.

Troubleshooting Common Issues

How to troubleshoot common problems that occur when installing and using SIMP.

My Services Are Dying!

The following section describes how to mitigate issues relating to destructive reasoning and avoiding destruction of the SIMP system.

Destructive Reasoning with svckill.rb

Most security guides that have been published on the Internet strongly suggest disabling all services that are not necessary for system operation. However, to list every possible service that may be controlled by the chkconfig type on a given system in a manifest would not be useful and would bloat the memory space of the running Puppet process.

As an alternative solution, the SIMP Team implemented the svckill.rb script that runs with every Puppet run.

The svckill.rb script:

  • Collects a list of all services on the system. These are the same services that the user sees after typing chkconfig --list
  • Ignores certain critical services, including Puppet, IPtables, and the network.
  • Collects a list of all services that are defined in the manifests and modules.
  • Ensures that every service that is defined in the manifests and modules is excluded from the list of services to kill.
  • Kills and disables everything else.
Avoiding Destruction

If certain services should not be killed, declare them in the node manifest space.

Note

The key is to declare the services and not set them to any other option. By adding them to the manifest, the svckill.rb script will ignore them.

The example below demonstrates this action, assuming that the keepmealive service is added to the chkconfig.

preventing a service from being killed by svckill.rb

service { "keepmealive": }

Why Can’t I Login?!

If you’ve reached this page, you’re having issues logging into your system with a newly created account.

In almost all cases, this is because either your user has not been placed in a group allowed to access the system, your DNS is setup incorrectly, or your PKI certificates are invalid.

PAM Access Restrictions

By default, SIMP uses the pam_access.so PAM module to restrict access on each individual host. While this may not seem as flexible as some methods, it is the most failsafe method for ensuring that you don’t accidentally interrupt services due to network issues connecting to your LDAP server.

To allow a user to access a particular system, you need to use the pam::access::manage define as shown below.

pam::access::manage { 'Allow the security group into the system':
  users   => ['(security)'],
  origins => ['ALL'],
  comment => 'The core security team'
}

pam::access::manage { 'Allow bob into the system from the proxy only':
  users   => ['bob'],
  origins => ["proxy.${::domain}"],
  comment => 'Bob the proxied'
}
Troubleshooting DNS

If PAM is not the issue, you may be having DNS issues. This can evidence itself in two ways.

First, per the ‘Bob’ example above, you may be using an FQDN to identify a host on your network. If DNS is not properly configured, then there is no way for the host to understand that you should have access from this remote system.

Second, the default PKI settings in SIMP ensure that all connections are validated against the FQDN of the client system. In the case of an LDAP connection, a misconfiguration in DNS may result in an inability to authenticate against the LDAP service.

In the following sections, we will assume that we have a host named ‘system.my.domain’ with the IP address ‘1.2.3.4’.

Testing a Forward Lookup

The following should return the expected IP address for your system.

$ nslookup system.my.domain
Testing a Reverse Lookup

The following should return the expected hostname for your system. This hostname must be either the primary name in the PKI certificate or a valid alternate name.

$ nslookup 1.2.3.4
PKI Issues

If both PAM and DNS appear to be correct, you should next validate that your PKI certificates are both valid and functional.

See Checking Your SIMP PKI Communication for additional guidance.

Checking Your SIMP PKI Communication

SIMP comes with a fully functional Public Key Infrastructure in the guise of an aptly named Fake CA.

The Fake CA can be very useful for getting your environment running prior to obtaining proper certificates from an official CA.

Warning

The Fake CA is not hardware backed by default and should not be used for sensitive cryptographic operations unless there is no other alternative

Each Puppet environment contains its own Fake CA and, therefore, you must know which environment is serving the systems that are having issues prior to proceeding.

For this section, we will assume that it is the ‘simp’ environment located at the active environment path.

Note

Just as with Puppet certificates, the time on your system must be correct and your DNS must be fully functional. Check that these are correct before proceeding.

For the remainder of this section, we will assume that the FQDN of the system with issues is ‘system.my.domain’ and the LDAP server to which it is attempting to connect is ‘ldap.my.domain’.

Navigate to the environment keydist directory and validate the system certificates.

When validating certificates, you want to make sure that there are no errors regarding your certificate or CA. Ideally, the command will simply return the string ‘OK’.

$ cd `puppet config print environmentpath`/simp/keydist

# Validate the client system
$ openssl verify -CApath cacerts system.my.domain

# Validate the LDAP system
$ openssl verify -CApath cacerts ldap.my.domain

If there are any issues, you may need to follow the Fake CA README to generate new certificates for one or more of your hosts.

Puppet Certificate Issues

Puppet Client Certificate Issues

Most of the time, clients will have certificate issues due to the system clock not being properly set. Before taking any other measures, make sure that your system clock is correct on both the mmaster and the clients!

If you need to fix client certificate issues outside of time, first make sure that you don’t have a certificate already in place on your Puppet server.

$ puppet cert list --all

If you do have a certificate in place, and need to register a client with the same name, remove that client’s certificate from the system.

$ puppet cert clean <fqdn.of.the.client>

Warning

If you delete the Puppet server’s certificate, you will need to re-deploy Puppet certificates to all of your nodes!

Warning

NEVER RUN ``puppet cert clean –all``

Puppet Client Re-Registration

If, for some reason, you need to re-register your client with a new server, simply run the following on your client once the server is ready.

$ rm -rf `puppet config print ssldir`
$ puppet agent -t
Puppet Server Certificate Issues

Warning

This is destructive to your Puppet communications. This should only be used if you have no other options.

If the Puppet server has certificate issues, regenerate the server CAs. To do this, remove the contents of the ssl folder and regenerate those .pem files.

The following table lists the steps to regenerate the server CAs:

$ service puppetserver stop
$ rm -rf /var/lib/puppet/ssl
$ puppet cert list --all
$ puppet cert --generate ***<fqdn>***
$ service puppetserver start
$ puppet agent --test

SIMP FAQs

This chapter answers some of the frequently asked questions (FAQs) about SIMP.

Centralized Logging

SIMP provides a pre-built set of classes within the rsyslog module for enabling centralized logging within the infrastructure.

After completing these steps, run Puppet on the server and clients, or wait until after the next run to see logs start to flow.

Enable the Server

To enable the pre-built log server, add the following example code to the designated logging node.

Code to Enable the Server Logging Examples

classes :
  - 'simp::rsyslog::stock'
Enable the Clients

To have clients send data to the server, make the following changes to the /etc/puppet/hieradata/simp_def.yaml file.

Code to Enable the Client Logging Examples:

log_server="fqdn.of.your.log.server"

Changing Puppet Masters

It may be necessary to change the Puppet Master. To point a particular client to a new Puppet Master, follow the steps in the sections below.

On the Client

Enter the following changes into the /etc/puppet/puppet.conf file.

Code Changes on Client to Switch Puppet Masters

server = new.puppet.master.fqdn
ca_server = new.puppet.master.fqdn
ca_port = 8141

To remove all files and sub-directories in the /var/lib/puppet/ssl directory, type cd /var/lib/puppet/ssl. Then type rm -rf ./*.

Assuming the new Puppet Master has been set up to properly accept the client, type puppet agent --test to run a full Puppet run while pointing to the new server.

If all goes well, the client will now be synchronized with the new Puppet Master. If not, refer to the SIMP Server Installation section of the SIMP Install Guide and ensure that the new Puppet Master was set up properly.

On the Old Puppet Master

Remove or comment out all items for the client node in the /etc/puppet/hieradata/hosts space.

To run puppet agent in noop mode to ensure that there are no inadvertent errors, type puppet agent --test --noop.

Building a Bootable DVD from the SIMP tarball

SIMP is an overlay on top of RHEL, not a complete distribution. As such, the user must build a bootable DVD if provided with the SIMP source code or tar file.

To build a bootable SIMP DVD, if provided a RHEL DVD and the SIMP tar file, follow the steps in the sections below.

Build the DVD

The table below lists the steps to build a SIMP DVD, assuming that the user has copied the DVD to a location with enough space to house and unpack the ISO (around 10G).

Starting from the directory with the ISO, complete the steps outlined below. These steps are based on an example ISO of rhel-server-6.7-x86_64-dvd.iso.

  1. Type
for file in `isoinfo -Rf -i rhel-server-6.7-x86_64-dvd.iso | \
  tac`; do mkdir -p RHEL6.7-x86_64`dirname $file`; \
  isoinfo -R -x $file -i rhel-server-6.7-x86_64-dvd.iso > RHEL6.7-x86_64$file; done
  1. Type tar -C RHEL6.7-x86_64 -xzf ***<SIMP tarball>***
  2. Type
mkisofs -o SIMP-6.7-***<SIMP Version>-x86_64.iso \***
  -b isolinux/isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 \
  -boot-info-table -R -m TRANS.TBL -uid 0 -gid 0 RHEL6.7-x86_64

Table: Build a SIMP DVD Procedure

The fully bootable SIMP DVD is ready to install on a new system. Replace the RHEL version and architecture to fit the user’s needs. See the Changelog for compatible RHEL versions.

Use the Alternative Method

If the Ruby rake utility is installed, use the Rakefile provided in the Docs/examples directory of the tar file.

Excluding Repositories

By default, SIMP applies updates from all available repositories on a nightly basis. This ensures that bug fixes and security updates are applied to all systems without minute management in Puppet manifests. This section provides guidance on how to include or exclude specific repositories from nightly YUM updates.

Methodology

The common::yum_schedule::repos and common::yum_schedule::disable variables in the pupmod-common module control which repositories are enabled for nightly updating. Both variables must be specified in array format.

common::yum_schedule::repos is used to specify an array of repositories from which updates are provided; no other repositories will be used.

common::yum_schedule::disable is used to specify an array of repositories from which updates are not provided; all other repositories will be used.

IPtables NAT Rules

See the IPtables Module Reference for notes on using the basic IPtables Module.

Add NAT Rules

The user may be required to add Network Address Translation (NAT) rules to the IPtables ruleset. To achieve this using the IPtables module, SIMP 1.1.3 or later is required and the iptables::add_rules input statement should be used to affect the appropriate changes.

The example below shows an IPtable NAT rule.

Example of an IPtable NAT Rule

 iptables::add_rules { "nat_global":
    table => "nat",
    first => "true",
    absolute => "true",
    header => "false",
    content => "
    :PREROUTING ACCEPT [0:0]
    :POSTROUTING ACCEPT [0:0]
    :OUTPUT ACCEPT [0:0]
    "
  }

iptables::add_rules { "nat_test":
    table   => "nat",
    header  => "false",
    content => "
    -A PREROUTING --physdev-in
    eth1 -j DROP
    "
  }

Network-based Initial Server Build

This section provides guidance to install the initial SIMP server via an existing kickstart infrastructure.

Prepare the Kickstart

To kickstart the initial server, copy the netboot.cfg file into the kickstart location from ks/ at the root level of the extracted DVD.

Replace the KS_SERVER and KS_BASE variables in the netboot.cfg file to match the system settings.

Kickstart the System

Kickstart the system against the netboot.cfg file; this will build a functional SIMP server identical to the one that the user would have received from the DVD.

Post-Installation

This section describes the post installation procedures to use the server.

Setting up the new YUM repo

All of the SIMP systems must be able to reference two YUM locations after install. The first is the Local repo, which is spawned from the Local directory at the top of the DVD. This is expected to be referenced as http://yum_server/yum/SIMP/<Architecture> by the clients.

The second location is the Updates repo, which contains a repo with all of the base operating system RPMs. This is expected to be referenced as http://yum_server/yum/(RedHat|CentOS)/<Version>/<Architecture>/Updates by the clients.

The user is responsible for adjusting these locations in the pre-existing system; however, the table below lists the steps to adjust these locations on the newly built SIMP server.

Note

These steps assume that the SIMP DVD material is copied in its unpacked form to the /srv/SIMP directory and that the version unpacked is RHEL 5.8. Adjust the paths appropriately if the CentOS or 5.7 version is being used.

  1. Copy the entire SIMP DVD material to the SIMP server.
  2. Type cd /srv;
  3. Type mkdir -p www/yum/RedHat/5.8/x86_64;
  4. Type mv /srv/SIMP/SIMP www/yum;
  5. Type mv /srv/SIMP/ks www;
  6. Type cd www/yum/RedHat
  7. Type ln -s 5.8 6; and then cd 5.8/x86_64; to be able to move to newer versions more easily.
  8. Type mkdir Updates;
  9. Type cd Updates;
  10. Type find .. -type f -name “*.rpm” -exec ln -s {} \;
  11. Type createrepo -p .
  12. Type cd /var/www/yum/SIMP;
  13. Type updaterepos;
  14. Type chown -R root.apache /var/www;
  15. Type chmod -R u+rwX,g+rX,o-rwx /var/www;
  16. Enter the following commands into the command line to adjust the file.
cat << EOF >> /etc/yum.repos.d/filesystem.repo
[flocal-x86_64]
name=Local within the filesystem
baseurl=file:///var/www/yum/SIMP/x86_64
enabled=1
gpgcheck=0
EOF
  1. Enter the following commands into the command line to adjust the file.
cat << EOF >> /etc/yum.repos.d/filesystem.repo
[frhbase]
name=$ostype $rhversion base repo
baseurl=file:///var/www/yum/RedHat/6/x86_64/Server
enabled=1
gpgcheck=0
EOF

Follow the instructions in the Client Management for additional assistance.

Performing One-shot Operations

This section introduces the options provided for performing one-shot commands on all Puppet-managed systems without using Puppet. This is useful when the user needs to perform an action one time in every location, but does not want to enforce that action over time.

Use the PSSH Utility

Parallel Secure Shell (PSSH) has been included in SIMP for some time, but has not been installed by default.

The table below lists the steps to use PSSH.

Table: Use PSSH Procedure

Note

There is no manual page provided with PSSH; type pssh --help for further explanation.

Other SSH Options

Using the -f option forces TTY for SSH, which allows the user to run sudo commands via PSSH.

Using the -OStrictHostKeyChecking=no option connects the user to the target servers via SSH even if there is an issue with ~/.ssh/known_hosts.

Puppet Server Behind a NAT

This section provides guidance for when the Puppet server is behind a NAT but is managing hosts outside the NAT.

To resolve this issue, open the /etc/puppet/manifests/vars.pp file and rename the puppet_servers variable to puppet_server_hosts_mod. Then, create a new $puppet_servers variable and point it to template('site/nat_ip_switch.erb').

The entries in vars.pp should look like the following example.

Example Sample Entries in vars.pp

$puppet_server_hosts_mod = "puppet.$dns_domain|1.2.3.4 puppet2.$dns_domain|2.3.4.5"
$puppet_servers = template('site/nat_ip_switch.erb')

Create a /etc/puppet/modules/site/templates/nat_ip_switch.erb file with the content shown in the next example. Change the appropriate portions of the content to meet the needs of the user environment.

Important

Ensure that the .erb file is owned by root.puppet and mode 640.

Source Create the nat_ip_switch.erb

<%
# Edit this variable to provide the IP address mappings.
# The left-hand side should contain the internal addresses.
# The right-hand side should contain the external addresses.
t_ipmap = {
    "1.2.3.4" => "10.10.10.10",
    "2.3.4.5" => '10.2.3.4'
}

# Edit this regex to match the hosts.
# This is done with a Regexp; the user can use whichever is preferred.
# Pure IP matching would be faster using the IPAddr class.
t_inside_nets = Regexp.new("^5\.*")

t_pupsrvs = puppet_server_hosts_mod.split(/\s|,|;/)

# Change the ipaddress variable to the host that the regexp above is matching.
if not t_inside_nets.match(ipaddress) then
  t_pupsrvs.each_index do |t_i|
    t_vals = t_pupsrvs[t_i].split(/\|/)
    if t_ipmap.include?(t_vals.last) then
      t_vals[-1] = t_ipmap[t_vals.last]
      t_pupsrvs[t_i] = t_vals.join('|')
    end
  end

  t_pupsrvs = t_pupsrvs.join(' ')
end
-%>
<%= t_pupsrvs -%>

Run puppet agent -t on the client to receive the appropriately mapped NAT address of the Puppet server.

If the user cannot connect to the NAT’d Puppet server, change the values in the /etc/hosts directory to the correct values and try running puppet agent -t again.

Redundant LDAP

This section describes how to set up redundant OpenLDAP servers in SIMP.

The version of OpenLDAP in RHEL5 only supports syncrepl. Multi-master replication has been added in a more recent version of OpenLDAP but is not currently supported in SIMP. Syncrepl is optimal for Wide Area Network (WAN) situations and is the SIMP default.

Set up the Master

If the standard puppet_servers.pp file in SIMP is being used, the user has a working master server. If not, the following example demonstrates how to use the SIMP openldap module to create a server using the puppet_servers.pp file .

Source Code for Using an OpenLDAP Server openldap

# These are some common variables.
# See /etc/puppet/manifests/vars.pp for the stock version.

$ldap_master = 'ldap://ldapmaster.your.domain'

class ldap_common {
  include 'openldap::slapd_pki'

  openldap::slapd::conf { 'default':
    suffix => 'dc=your,dc=domain',
    rootdn => 'dn=LDAPAdmin,ou=People,dc=your,dc=domain',
    rootpw => '{SSHA}$klskf$asoghaagasgasgaggawawg',
    tlsCertificateFile => "/etc/pki/public/${fqdn}.pub",
    tlsCertificateKeyFile => "/etc/pki/private/${fqdn}.pem",
    client_nets => [ '1.2.3.4/16' ]
  }
}

class ldap_master inherits ldap_common {
  include 'openldap::slapo::syncprov'

  openldap::slapo::syncprov::conf { "default": }
}

node ldapmaster {
  include 'ldap_master'
}
Set up the Replicated Servers

Once the master is ready, LDAP slave nodes must be configured to replicate data from the master. The example below shows an the code that should be added to the slave node in Puppet. The actual order of which gets done first is irrelevant; the replicated servers will attempt to contact the master until they are successful.

Source Code to Configure an LDAP Slave Node replication

class ldap_repl inherits ldap_common {
  include 'openldap::slapd::syncrepl'

  openldap::slapd::syncrepl::conf { "111":
    provider => $ldap_master,
    syncrepl_retry => '60 10 600 +',
    searchbase => 'dc=your,dc=domain',
    starttls => 'critical',
    bindmethod => 'simple',
    binddn => 'cn=LDAPSync,ou=People,dc=your,dc=domain',
    credentials => '<plain text password>',
    updateref => $ldap_master
  }
}

node ldaprepl1 {
  include "ldap_repl"
}

node ldaprepl2 {
  include "ldap_repl"
}
Promote a Slave Node

Slave nodes can be promoted to act as the LDAP master node. To do this, change the node classifications of the relevant hosts. The following example shows the promotion of the ldaprepl1 server to the master server.

Source Promoting a Slave Node LDAP

# Change the common ldap server variable to promote the slave node.

$ldap_master = 'ldap://ldaprepl1.your.domain'

node ldapmaster {
  # include 'ldap_master'
}

node ldaprepl1 {
  # include 'ldap_repl'
  include 'ldap_master'
}

After the next Puppet run on all hosts, ldaprepl1 will be promoted to the master and all slave nodes will point to it.

Troubleshooting

If the system is not replicating, it is possible that another user has updated the $ldap_sync_passwd and $ldap_sync_hash entries in the /etc/puppet/manifests/vars.pp file without also updating the value in LDAP itself; this is the most common issue reported by users.

Currently, SIMP cannot self-modify the LDAP database directly; therefore, the LDAP Administrator needs to perform this action. Refer to the User Management chapter for more information on manipulating entries in OpenLDAP.

The example below shows the changes necessary to update the $ldap_sync information in LDAP.

Update $ldap_sync Information in LDAP Examples

dn: cn=LDAPSync,ou=People,dc=your,dc=domain
changetype: modify
replace: userPassword
userPassword: <Hash from $ldap_sync_hash>
Master Node Demotion

In the event that multiple master nodes have been set up, it may be necessary to demote one or more of them to slave instances. To do this, add the replication code shown in the previous section titled Set up the Replicated Servers to the manifest of the master node being demoted.

Once this is complete, manually remove the active database from the LDAP server being demoted and then run Puppet. The SIMP team is working to enable SIMP to handle this transition automatically in the future.

SFTP Restricted Account

This section describes the method for restricting an account to SSH File Transfer Protocol (SFTP) access only.

Add a User

Create a user account based on the following example.

user { "foo":
  uid => <UID>,
  gid => <GID>,
  shell => <Path to SFTP Server>
}

On a SIMP system, shell would be: "/usr/libexec/openssh/sftp-server"

Modify /etc/shells

To modify /etc/shells to include the shell information provided in the previous user account example, add common::shells in Hiera, and add /usr/libexec/openssh/sftp-server to the list.

SSH Authorized Keys Setup

This section provides guidance on managing SSH keys within the SIMP environment.

LDAP Enabled

When enabled, ssh keys are both stored and retrieved directly from LDAP.

See Also: Managing Users with LDAP

Without LDAP

If not using LDAP, or in addition to LDAP, SSH authorized keys can be placed in /etc/ssh/local_keys/<USERNAME>. This location can be changed by setting the ::ssh::server::conf::authorizedkeysfile parameter in Hiera or your ENC.

See Also: Managing Local/Service Users

SIMP RPMs

This provides a comprehensive list of all SIMP RPMs and related metadata. Most importantly, it provides a list of which modules are installed by default and which are simply available in the repository.

Name Version Default
pupmod-acpid 0.0.1-1 true
pupmod-aide 4.1.0-7 true
pupmod-apache 4.1.0-16 true
pupmod-auditd 5.0.0-0 false
pupmod-auditd 4.1.0-13 false
pupmod-augeasproviders 2.1.3-0 true
pupmod-augeasproviders_apache 2.0.1-0 false
pupmod-augeasproviders_base 2.0.1-0 true
pupmod-augeasproviders_core 2.0.1-0 true
pupmod-augeasproviders_grub 2.0.1-0 true
pupmod-augeasproviders_mounttab 2.0.1-0 false
pupmod-augeasproviders_nagios 2.0.1-0 false
pupmod-augeasproviders_pam 2.0.1-0 false
pupmod-augeasproviders_postgresql 2.0.1-0 false
pupmod-augeasproviders_puppet 2.0.1-0 false
pupmod-augeasproviders_shellvar 2.0.1-0 false
pupmod-augeasproviders_ssh 2.5.0-0 true
pupmod-augeasproviders_sysctl 2.0.1-0 false
pupmod-autofs 4.1.0-6 false
pupmod-backuppc 4.1.0-5 false
pupmod-cgroups 1.0.0-7 false
pupmod-clamav 4.1.0-6 true
pupmod-concat 4.0.0-3 true
pupmod-dhcp 4.1.0-4 true
pupmod-freeradius 4.2.0-4 false
pupmod-ganglia 4.1.0-6 false
pupmod-gfs2 4.1.0-2 false
pupmod-iptables 4.1.0-13 true
pupmod-jenkins 4.1.0-6 false
pupmod-krb5 4.1.0-3 false
pupmod-libvirt 4.1.0-15 false
pupmod-logrotate 4.1.0-2 true
pupmod-mcafee 4.1.0-2 false
pupmod-mozilla 4.1.0-1 false
pupmod-multipathd 4.1.0-2 false
pupmod-named 4.2.0-6 true
pupmod-network 4.1.0-4 true
pupmod-nfs 4.1.0-12 false
pupmod-nscd 5.0.0-4 true
pupmod-ntpd 4.1.0-8 true
pupmod-oddjob 1.0.0-1 false
pupmod-onyxpoint-gpasswd 1.0.0-1 true
pupmod-openldap 4.1.1-3 true
pupmod-openscap 4.2.0-2 false
pupmod-pam 4.1.0-12 true
pupmod-pam 4.1.0-11 true
pupmod-pki 4.1.0-4 true
pupmod-polkit 4.1.0-1 false
pupmod-postfix 4.1.0-4 true
pupmod-pupmod 6.0.0-19 true
pupmod-puppetlabs-apache 1.0.1-2 false
pupmod-puppetlabs-inifile 1.2.0-1 true
pupmod-puppetlabs-java 1.2.0-0 false
pupmod-puppetlabs-java_ks 1.2.0-1 false
pupmod-puppetlabs-mysql 2.2.3-1 false
pupmod-richardc-datacat 0.6.1-0 false
pupmod-rsync 4.2.0-2 true
pupmod-rsyslog 5.0.0-0 true
pupmod-saz-memcached 4.0.0-2 false
pupmod-selinux 1.0.0-4 true
pupmod-simp 1.1.0-4 true
pupmod-simp 1.1.0-3 true
pupmod-simp-activemq 2.0.0-0 false
pupmod-simp-elasticsearch 2.0.0-3 false
pupmod-simp-kibana 3.0.1-3 false
pupmod-simp-logstash 1.0.0-6 false
pupmod-simp-mcollective 2.0.0-0 false
pupmod-simplib 1.0.0-0 true
pupmod-site 2.0.0-3 true
pupmod-snmpd 4.1.0-3 false
pupmod-ssh 4.1.0-10 true
pupmod-ssh-augeas-lenses 4.1.0-10 true
pupmod-sssd 4.1.0-6 false
pupmod-stunnel 4.2.0-9 true
pupmod-sudo 4.1.0-2 true
pupmod-sudosh 4.1.0-3 true
pupmod-svckill 1.0.0-4 true
pupmod-sysctl 4.1.0-5 true
pupmod-tcpwrappers 3.0.0-2 true
pupmod-tftpboot 4.1.0-7 true
pupmod-tpm 0.0.1-8 true
pupmod-upstart 4.1.0-3 true
pupmod-vnc 4.1.0-3 false
pupmod-vsftpd 5.0.0-0 false
pupmod-windowmanager 4.1.0-2 false
pupmod-xinetd 2.1.0-3 false
pupmod-xwindows 4.1.0-3 false
puppetlabs-postgresql 4.1.0-1.SIMP true
puppetlabs-puppetdb 5.0.0-0 true
puppetlabs-stdlib 4.9.0-0.SIMP false
rubygem-simp-cli 1.0.8-0.el6 true
rubygem-simp-cli-doc 1.0.8-0.el6 true
simp 4.2.0-RC1 false
simp-bootstrap 4.2.0-2 true
simp-doc 4.2.0-RC1.1446214631 true
simp-doc 4.2.0-RC1 true
simp-gpgkeys 2.0.0-2.el6 true
simp-gpgkeys 2.0.0-3.el6 true
simp-rsync 4.2.0-1.el6 true
simp-rsync-clamav 4.2.0-1.el6 true
simp-utils 4.1.0-12 true

SIMP 4.2.0-2

Changelog

SIMP 4.2.0-2

Package: 4.2.0-2

This release is known to work with:

  • RHEL 6.7 x86_64
  • CentOS 6.7 x86_64

This is a backwards compatible release in the 4.X series of SIMP.

Manual Changes Requred for Legacy Upgrades
  • Bugs in the simplib::secure_mountpoints class (formerly common::secure_mountpoints)

Note

This only affects you if you did not have a separate partition for /tmp!

  • There were issues in the secure_mountpoints class that caused /tmp and /var/tmp to be mounted against the root filesystem. While the new code addresses this, it cannot determine if your system has been modified incorrectly in the past.
  • To fix the issue, you need to do the following: - Unmount /var/tmp (may take multiple unmounts) - Unmount /tmp (may take multiple unmounts) - Remove the ‘bind’ entries for /tmp and /var/tmp from /etc/fstab - Run puppet with the new code in place
Deprecations
  • The simp-sysctl module will be deprecated in the 4.3.0 release of SIMP. Current users should migrate to using the augeasproviders_sysctl module provided with SIMP going forward.
Significant Updates
NSCD Replaced with SSSD

After a long wait, all of the bugs that we discovered in SSSD have been fixed! Therefore, we have moved to using SSSD as our primary form of caching against our LDAP server. If you do not use LDAP, SSSD will not be installed by default.

This only applies to systems EL6.7 or EL7+, if you have updated SSSD on a system earlier than EL6.7, then you will need to set use_sssd to true in Hiera.

Note

In the future, support for NSCD will be removed as SSSD is the recommended system.

NIST 800-53 Compliance Mapping

This release adds the ability to map all class and define variables into policy components and validate that mapping at compile time. Our initial mapping is against the NIST 800-53r4 and is present in this release.

For more information, see pupmod_simp_compliance_markup for more information.

Puppet 4 Support

We have started explicit testing of our modules against Puppet 4. Puppet 3.8 is slated for EOL in December 2016 and we plan to move to the AIO installer in the next major release of SIMP.

The Foreman

Support for The Foreman was included into SIMP core. We needed to create our own simp-foreman module which prevents the destruction of an existing Puppet environment. This is not installed as part of SIMP core but can be added.

Move to Semantic Versioning 2.0.0

All of our components have officially moved to using Semantic Versioning 2.0.0. This allows us to keep our Puppet Modules and RPMs inline with each other as well as behaving as the rest of the Puppet ecosystem. This does mean that you will see version numbers rapidly advancing over time and this should not be a cause for alarm.

Upgrade Guidance

Fully detailed upgrade guidance can be found in the Upgrading SIMP portion of the User’s Guide.

Warning

You must have at least 2.2GB of free RAM on your system to upgrade to this release.

Note

Upgrading from releases older than 4.0 is not supported.

RPM Updates
Package Old Version New Version
clamav 0.98.7-1 0.99-3
clamav-data 0.98.7-1 0.99-3
clamav-data-empty 0.98.7-1 0.99-3
clamav-devel 0.98.7-1 0.99-3
clamav-filesystem 0.98.7-1 0.99-3
clamav-scanner 0.98.7-1 0.99-3
clamav-sysvinit 0.98.7-1 0.99-3
clamav-server 0.98.7-1 0.99-3
clamav-server-systemd 0.98.7-1 0.99-3
clamav-server-sysvinit 0.98.7-1 0.99-3
clamav-server-update 0.98.7-1 0.99-3
facter 2.4.1-1 2.4.6-1
globus-common 15.30-1 16.0-1
globus-gsi-proxy-core 7.7-2 7.9-1
globus-gsi-sysconfig 6.8-2 6.9-1
globus-gssapi-gsi 11.22-1 11.26-1
hiera 3.0.2-1 3.0.5-1
mcollective 2.2.3-1 2.8.4-1
mcollective-client 2.2.3-1 2.8.4-1
mcollective-filemgr-agent 1.0.2-1 1.1.0-1
mcollective-filemgr-client 1.0.2-1 1.1.0-1
mcollective-filemgr-common 1.0.2-1 1.1.0-1
mcollective-iptables-agent 3.0.1-1 3.0.2-1
mcollective-iptables-client 3.0.1-1 3.0.2-1
mcollective-iptables-common 3.0.1-1 3.0.2-1
mcollective-nrpe-agent 3.0.2-1 3.1.0-1
mcollective-nrpe-client 3.0.2-1 3.1.0-1
mcollective-nrpe-common 3.0.2-1 3.1.0-1
mcollective-sysctl-data 2.0.0-1 2.0.1-1
puppet 3.7.4-1 3.8.6-1
puppet-dashboard 1.2.23-1 N/A
puppet-server 3.8.1-1 N/A
puppetserver 1.1.1-1 1.1.3-1
razor-server 0.14.1-1 1.2.0-1
razor-torquebox 3.0.1-1 3.1.1.10-1
rubygem-rake N/A 0.9.6-25
voms 2.0.12-3 2.0.13-1
Fixed Bugs
pupmod-simp-activemq
  • Updated activemq to the latest release.
  • Removed the tanukiwrapper dependency.
pupmod-simp-apache
  • Fixed ordering issues that were discovered when testing the foreman module.
pupmod-simp-auditd
  • Fixed an issue where add_rules did not disable itself if $::auditd::enable_auditing was set to false.
pupmod-simp-freeradius
  • Moved all 2 and 3 paths to v2 and v3 paths respectively since the original paths were not Puppet 4 safe.
pupmod-simp-ganglia
  • Fixed several minor bugs found during Puppet 4 testing.
pupmod-simp-nfs
  • Ensure that the NFS exports template can handle ANY and all since these can be used in client_nets for use with iptables.
  • Added a temporary class nfs::lvm2 to ensure that the lvm2 package is updated to the latest version since the nfs-utils rpm requires it but has a broken dependency.
  • Fixed Puppet 4 support.
pupmod-simp-nscd
  • Replaced remaining lsb* variables.
  • Fixed a race condition between service nscd restart and service nscd reload
pupmod-simp-openldap
  • Fixed several ordering and variable issues discovered when testing for Puppet 4
  • Fixed numerous issues with nslcd
  • Now copy the system certificates to /etc/nslcd.d for instances that wish to use their own certificates.
pupmod-simp-pki
  • Removed the simip5.test.vm key which was leftover testing garbage.
pupmod-simp-pupmod
  • Fixed logic errors found when testing Puppet 4
  • Configuration changes now notify Service[‘puppetmaster’] instead of the more efficient Exec. This prevents a race condition where the service is restarted and the Exec fires before the service has fully restarted.
  • Fixed the puppetserver_* helper scripts that surfaced due to changes in the HTTP responses from the Puppet Server.
  • Ensure that the Service configuration directory can be changed.
pupmod-simp-rsyslog
  • Fixed issues found during Puppet 4 testing.
pupmod-simp-simp
  • Fixed numerous issues found when testing against Puppet 4.
  • Fixed the nfs_server default in the home_client class which had the potential to break automounting.
pupmod-simp-simplib
  • Confined all facts that break Puppet on Windows.
  • Removed simplib::os_bugfixes because...it never worked anyway.
  • Fixed the ipv6_enabled fact to not break if IPv6 is already disabled. - Thanks to Klaas Demter for this patch.
  • Fixed issues with the localusers function where it was having issues when used with Ruby >= 1.9
pupmod-simp-ssh
pupmod-simp-sssd
  • Ensure that the sssd client libraries are installed even if you’re not running the sssd daemon.
  • Removed the erroneous ldap_chpass_updates_last_change variable and re-normalized the module on the ldap_chpass_update_last_change variable.
pupmod-simp-stunnel
  • Fixed ordering issues in the module.
  • Removed the public and private PKI certificates from the chroot jail for better system security. This will not remove them on existing systems, it will simply not place them there on new installations.
simp-cli
  • Fixed a bug where pre-placed X.509 certificates would be removed when running simp config. Custom certificates can now be used out of the box.
simp-core
  • Connections to the remote YUM server were disabled by default on the initial Puppet server. This prevents issues with bootstrap ordering when not installing via ISO.
  • Fixed the unpack_dvd script to properly check for non-existent directories before unpacking the ISO images.
  • Fixed a bug where the Hiera use_ldap variable was not effective due to openldap::pam being included in the Hiera class list.
simp-doc
  • Spelling errors were corrected.
  • The PXE boot section was corrected.
  • Directory paths were fixed throughout the document.
  • The Security Conop tables were fixed.
DVD
  • Fixed a few typos in the auto.cfg file.
New Features
pupmod-onyxpoint-compliance
  • The first cut of the compliance mapper module. Will be replaced by a SIMP native version in the next release.
pupmod-simp-augeasproviders_grub
  • Imported the latest version of the upstream augeasproviders_grub module.
  • Added the ability to fully manage GRUB menu entries in both GRUB 2 and GRUB Legacy.
pupmod-simp-augeasproviders_sysctl
  • Added the ability to fail silently in the case that a running sysctl item cannot be manipulated. This is important in cases such as NFS where the appropriate module may not be loaded until it is actually used for the first time.
pupmod-simp-java_ks
  • Updated the module to the latest upstream version to support FIPS mode.
pupmod-simp-mcollective
pupmod-simp-openldap
  • Fixed the default.ldif template to modify the password setting defaults. This will not affect a running LDAP server.
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using external (non-SIMP) certificates.
pupmod-simp-pki
  • Allow the PKI content source to be modified so that you have a choice of where to pull your certificates. - Thanks to Carl Caum from Puppet Labs for this patch.
pupmod-simp-rsyslog
  • Ensure that use_simp_pki is now treated as a global catalyst.
  • Added support for using templates when sending to remote targets.
  • Ensure that all module artifacts are now packaged with the RPM.
pupmod-simp-simplib
  • Added a to_string() function.
  • Added a to_integer() function.
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-ssh
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-stunnel
  • Ensure that use_simp_pki is now treated as a global catalyst.
pupmod-simp-sysctl
  • Migrate to using augeasproviders_sysctl for all sysctl activities.
  • This module will be deprecated in the next major release of SIMP.
simp-doc
  • The documentation on setting up redundant LDAP servers was updated.
  • A section on using The Foreman with SIMP was added.
Known Bugs
  • If you are running libvirtd, when svckill runs it will always attempt to kill dnsmasq unless you are deliberately trying to run the dnsmasq service. This does not actually kill the service but is, instead, an error of the startup script and causes no damage to your system.

Glossary of Terms

Note

Many terms here have been reproduced from various locations across the Internet and are governed by the licenses surrounding the source material. Please see the reference links for specifics on usage and reproducability.

ACL
Access Control List
A list of permissions attached to an object. An ACL specifies which users or system processes are granted access to objects, as well as what operations are allowed on given objects. Each entry in a typical ACL specifies a subject and an operation.
AIDE
Advanced Intrusion Detection Environment
An intrusion detection system for checking the integrity of files under Linux. AIDE can be used to help track file integrity by comparing a snapshot of the system’s files prior to and after a suspected incident. It is maintained by Rami Lehti and Pablo Virolainen.
Auditd
The userspace component to the Linux Auditing System. It is responsible for writing audit records to the disk. Viewing the logs is done with the ausearch or aureport utilities. Configuring the audit rules is done with the auditctl utility. During startup, the rules in /etc/audit/audit.rules are read by auditctl. The audit daemon itself has some configuration options that the admin may wish to customize. They are found in the auditd.conf file.
BIOS
Basic Input/Output System

A type of firmware used to perform hardware initialization during the booting process (power-on startup) on IBM PC compatible computers.

Source: Wikipedia: BIOS

CA
Certificate Authority
An entity that issues X.509 digital certificates.
CentOS
Community Enterprise Operating System
An Enterprise-grade Operating System that is mostly compatible with a prominent Linux distribution.
CLI
Command Line Interface

A means of interacting with a computer program where the user (or client) issues commands to the program in the form of successive lines of text (command lines).

CPU
Central Processing Unit

A central processing unit (CPU) is the electronic circuitry within a computer that carries out the instructions of a computer program by performing the basic arithmetic, logical, control and input/output (I/O) operations specified by the instructions

Source: Wikipedia: Central Processing Unit

DHCP
Dynamic Host Configuration Protocol
A network protocol that enables a server to automatically assign an IP address to a computer.
DNS
Domain Name System
A database system that translates a computer’s fully qualified domain name into an IP address and the reverse.
ENC
External Node Classifier

An arbitrary script or application which can tell Puppet which classes a node should have. It can replace or work in concert with the node definitions in the main site manifest (site.pp).

The Puppet Enterprise Console and The Foreman are two examples of External Node Classifiers.

Source: External Node Classifiers

FIPS
Federal Information Processing Standard

Federal Information Processing Standards (FIPS) Publications are standards issued by NIST after approval by the Secretary of Commerce pursuant to the Federal Information Security Management Act (FISMA)

The particular standard of note in SIMP is FIPS 140-2

Source: FIPS Publications

FQDN
Fully Qualified Domain Name
A domain name that specifies its exact location in the tree hierarchy of the DNS. It specifies all domain levels, including the top-level domain and the root zone. An FQDN is distinguished by its unambiguity; it can only be interpreted one way.
GUI
Graphical User Interface

A type of interface that allows users to interact with electronic devices through graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels or text navigation.

Source: Wikipedia: Graphical User Interface

HDD
Hard Disk Drive
A device for storing and retrieving digital information, primarily computer data.
Hiera

A key/value lookup tool for configuration data, built to make Puppet better and let you set node-specific data without repeating yourself.

Source: Hiera Overview

IP
IP Address
Internet Protocol Address

A numerical label assigned to each device (e.g., computer, printer) participating in a computer network that uses the Internet Protocol for communication.

Source: Wikipedia: IP Address

IP6Tables
Internet Protocol 6 Tables
A user space application that provides an interface to the IPv6 firewall rules on modern Linux systems.
IPTables
Internet Protocol Tables
A user space application that provides an interface to the IPv4 firewall rules on modern Linux systems.
Kerberos
A computer network authentication protocol that works on the basis of “tickets” to allow nodes communicating over a non-secure network to prove their identity to one another in a secure manner.
Key Distribution Center
Part of a cryptosystem intended to reduce the risks inherent in exchanging keys. KDCs often operate in systems within which some users may have permission to use certain services at some times and not at others.
LDAP
Lightweight Directory Access Protocol
A protocol for querying and modifying LDAP directory services including information such as names, addresses, email, phone numbers, and other information from an online directory.
MAC
MAC Address
Media Access Control
Media Access Control Address

A unique identifier assigned to network interfaces for communications on the physical network segment.

Source: <Wikipedia: MAC address

NAT
Network Address Translation
The process of modifying IP address information in IP packet headers while in transit across a traffic routing device.
NFS
Network File System
A distributed file system protocol that allows a user on a client computer to access files over a network in a manner similar to how local storage is accessed.
PAM
Pluggable Authentication Modules
A mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API). It allows programs that rely on authentication to be written independent of the underlying authentication scheme.
PEM
Privacy Enhanced Mail
An early standard for securing electronic mail. This is the public-key of a specific certificate. This is also the format used for Certificate Authority certificates.
PERL
Practical Extraction and Report Language
A high-level, general-purpose, interpreted, dynamic programming language. PERL was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.
PKI
Public Key Infrastructure
A security architecture that has been introduced to provide an increased level of confidence for exchanging information over an increasingly insecure Internet. PKI enables users of a basically insecure public networks, such as the Internet, to securely authenticate to systems and exchange data. The exchange of data is done by using a combination of cryptographically bound public and private keys.
PSSH
Parallel Secure Shell
A tool that provides parallel versions of OpenSSH and other related tools.
Puppet
An Open Source configuration management tool written and maintained by Puppet Labs. Written as a Ruby DSL, Puppet provides a declarative language that allows system administrators to provide a consistently applied management infrastructure. Users describes system resource and resource state in the Puppet language. Puppet discovers system specific information via facter and compiles Puppet manifests into a system specific catalog containing resources and resource dependencies, which are applied to each client system.
PXE
Preboot Execution Environment
An environment to boot computers using a network interface independently of data storage devices (like hard disks) or installed operating systems.
RAM
Random Access Memory
A form of computer data storage. A random access device allows stored data to be accessed in nearly the same amount of time for any storage location, so data can be accessed quickly in any random order.
Red Hat
Red Hat®
Red Hat®, Inc.

A collection of many different software programs, developed by Red Hat®, Inc. and other members of the Open Source community. All software programs included in Red Hat Enterprise Linux® are GPG signed by Red Hat®, Inc. to indicate that they were supplied by Red Hat®, Inc.

See also RHEL.

RHEL
Red Hat Enterprise Linux
A commercial Linux operating system produced by Red Hat®, Inc. RHEL is designed to provide an Enterprise-ready Linux distribution suitable to multiple target applications.
RPM
RPM Package Manager
A package management system. The name RPM is associated with the .rpm file format, files in this format, software packaged in such files, and the package manager itself. RPM was developed primarily for GNU/Linux distributions; the file format is the baseline package format of the Linux Standard Base.
RSA
An algorithm for public-key cryptography that is based on the presumed difficulty of factoring large integers, the factoring problem. RSA stands for Ron Rivest, Adi Shamir and Leonard Adleman, who first publicly described it in 1977.
Ruby
A dynamic, reflective, general-purpose object-oriented programming language that combines syntax inspired by Perl with Smalltalk-like features. Ruby originated in Japan during the mid-1990s and was first developed and designed by Yukihiro “Matz” Matsumoto. It was influenced primarily by Perl, Smalltalk, Eiffel, and Lisp. Ruby supports multiple programming paradigms, including functional, object oriented, imperative and reflective. It also has a dynamic type system and automatic memory management; it is therefore similar in varying respects to Smalltalk, Python, Perl, Lisp, Dylan, Pike, and CLU.
Service Account
An account that is not for use by a human user but which still requires login access to a host.
SFTP
SSH File Transfer Protocol
A network protocol that provides file access, file transfer, and file management functionalities over any reliable data stream. It was designed by the Internet Engineering Task Force (IETF) as an extension of the Secure Shell protocol (SSH) version 2.0 to provide secure file transfer capability, but is also intended to be usable with other protocols.
SIMP
System Integrity Management Platform
A security framework that sits on top of RHEL or CentOS.
SSH
Secure Shell
An application for secure data communication, remote shell services, or command execution between networked computers. SSH utilitizes a server/client model for point-to-point secure communication.
SSL
Secure Sockets Layer

The standard security technology for using PKI keys to provide a secure channel between two servers.

See also TLS.

Sudosh
An application that acts as an echo logger to enhance the auditing of privileged activities at the command line of the operating system. Utilities are available for playing back sudosh sessions in real time.
TFTP
Trivial File Transfer Protocol
A file transfer protocol generally used for automated transfer of configuration or boot files between machines in a local environment.
TLS
Transport Layer Security

A cryptographic protocol that provides network communications security. TLS and SSL encrypt the segments of network connections above the Transport Layer, using asymmetric cryptography for privacy and a keyed message authentication codes for message reliability.

See also SSL.

TTY
A Unix command that prints to standard output the name of the terminal connected to standard input. The name of the program comes from teletypewriter, abbreviated “TTY”.
VM
Virtual Machine
An isolated guest operating system installation running within a host operating system.
VNC
Virtual Network Computing
A graphical desktop sharing system that uses the remote framebuffer (RFB) protocol to control another computer remotely. It transmits the keyboard and mouse events from one computer to another, relaying the graphical screen updates back in the other direction, over a network.
WAN
Wide Area Network
A computer networking technology used to transmit ata over long distances, and between different Local Area Networks (LANs), Metropolitan Area Networks (MANs), and other localized computer networking architectures.
X.509

An ITU-T standard for a public key infrastructure (PKI) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm.

Source: Wikipedia: X.509

YUM
Yellowdog Updater, Modified

A software installation tool for Linux. It is a complete software management system that works with RPM files. YUM is designed to be used over a network or the Internet.

See also RPM.

Indices and tables

SIMP Security Concepts

This is the 4.2.0-0 release of SIMP compatible with the 6.7 release of CentOS and Red Hat Enterprise Linux (RHEL).

This document provides a foundational Security Concept of Operations for the SIMP framework.

Contents:

Introduction

This manual describes the security concepts of the SIMP system. The system was originally designed to meet a specific set of technical security controls using industry best practices and has been modified recently to meet as many of the security controls provided by the National Institute of Standards and Technology’s (NIST) special publication 800-53 as possible.

This manual outlines three categories of security:

  • Technical Architecture: discusses the technical approaches to securing the system
  • Operational Security: discusses the security of SIMP in an operational setting
  • Information System Management: discusses how SIMP helps achieve security in terms of system management

A brief discussion of how the SIMP system helps achieve categories of controls is provided; additional technical details regarding each control can be found in the SIMP Security Controls Traceability Matrix (SCTM).

When possible, the security control identifier will be found at the end of a concept to provide the reader with a reference to the specific control that is being discussed. The identifier is written as [AB-X(Y)], where A is the control family, X is the control section, and Y is the control enhancement.

Technical Security

This chapter contains SIMP security concepts that are related to the technical security controls described in NIST 800-53.

Identification and Authentication

This section addresses the identification and authentication of users and devices.

User Identification and Authentication

Identification and authentication of system and service users can occur at the system level or globally in the SIMP architecture. While local accounts and groups can be created manually, the SIMP team suggests adding users via the /etc/puppet/localusers file or by using the native Puppet user and group types. System users can authenticate their access using Secure Shell (SSH) keys or passwords. For more centralized control, identify and authenticate users by using the Lightweight Directory Access Protocol (LDAP). [IA-2]

The SIMP team recommends using LDAP as the primary source for user management and provides a functional default OpenLDAP configuration for this purpose. LDAP and Pluggable Authentication Modules (PAM) work together closely and, with the default SIMP configuration, the PAM settings are enforced on top of the LDAP settings for two layers of control. Due to this partnership, items such as account lockouts may need to be reset on both the local system and the LDAP server. If the suggested settings in the SIMP-provided default Lightweight Directory Interchange Formats (LDIF) are not used, implementations must ensure that security is maintained through manual procedures. Use of group accounts for users is strongly discouraged. System services may need to have accounts, but all of these should be managed by Puppet using the user and group native types. [IA-2(5)].

Device Identification and Authentication

Devices are identified by a Media Access Control (MAC) address prior to receiving an IP address via the Dynamic Host Configuration Protocol (DHCP). In the default SIMP architecture, IP addresses are fixed mappings to their associated MAC address (i.e., not assigned dynamically). There is no authentication for the binding of MAC addresses to IP addresses due to the nature of the DHCP protocol.

Device authentication occurs through the mapping of the MAC to the IP through the internally controlled DHCP and the mapping of the IP to the host name through the internally controlled Domain Name System (DNS) service for each individual Puppet client. After kickstart, each client system generates an internal cryptographic identifier and communicates that information with the Puppet server to be approved by an administrator at a later time. All further communication between the Puppet server and the clients over the Puppet protocol is encrypted subsequently and authenticated with this identifier. Automatic approval can be set up in tightly controlled environments; however, this option is not suggested for open environments. [IA-3, IA-3(3)]

Identifier Management

Managing user identifiers (also known as user names) involves administrative procedures that are unique for each implementation. Disabling unused local accounts is the only control that SIMP can enforce technologically. In this case, if an account has an expired password that has not been changed 35 days after expiration, the account will be disabled. If a user does not have a password (e.g., he or she only authenticates with SSH keys), then there is no inherent technological mechanism for enforcement due to the nature of the software. [IA-4(e)]

Authenticator Management

Authenticators for users are passwords and/or SSH keys; the management of each is implementation specific. SSH keys do not expire; therefore, implementations must provide a procedure for removing invalid keys. Removing public keys from LDAP is one practical solution.

When using passwords, local and LDAP passwords provided for users should be set to change at first log on. This is the default in the SIMP-provided LDIFs. Once a user attempts to change a password, the settings in PAM and LDAP enforce complexity requirements. By default, SIMP requires 14-character passwords with at least one character from three of the four designated categories (i.e., upper case letters, lower case letters, numbers, or special characters), and no more than three consecutive characters from each category. [IA-5, IA-5(1), IA-5(4)] Password ageing and history is enforced through a combination of PAM and LDAP. By default, the previous 24 passwords cannot be reused. [IA-5(1)(e)]

There are a number of default passwords in SIMP that are required for installation. Each implementation requires the user to change the default passwords and protect the new passwords. In addition, there are embedded passwords within the SIMP system that are used due to a lack of software-supported alternatives.

Access Control

This section describes the various levels of access control, including account management, access enforcement, information flow enforcement, separation of duties, least privilege, session controls, permitted actions without identification and authentication, security attributes, and remote access.

Account Management

Account management procedures should be created and maintained for each implementation of SIMP. The procedures should include the information listed in NIST 800-53 control AC-2. SIMP has the mechanisms in place to enforce most account management policies. The mechanisms for account management have several default settings including:

  • Central account management using OpenLDAP. [AC-2(1)]
  • Password expiration. Local accounts expire 35 days after password expiration. [AC-2(3)]LDAP accounts do not expire automatically due to inactivity; implementations should audit LDAP accounts regularly.
  • Auditing of administrative actions to capture local account creation and modifications to LDAP accounts is done via the /var/log/slapd_audit.log file for ldap accounts and /var/log/audit.log for local accounts. [AC-2(4)]
  • Shell session timeouts after 15 minutes of inactivity. [AC-2(5)] This can be circumvented by running a command that opens an endless pipe such as /bin/cat. However, this command cannot be enforced more heavily due to the high likelihood of breaking system applications. If the optional gnome module is used, the GNOME screen saver will lock the screen after 15 minutes of inactivity.
  • Assignment of users into groups locally or centrally via LDAP. [AC-2(7)] By default, SIMP will have an administrators groups that has the ability to run sudosh. Implementations should further define administrators or user groups and limit them with the Puppet sudo class.

Access Enforcement

SIMP uses the implementation of Discretionary Access Control (DAC) that is native to Linux. Specific file permissions have been assigned based on published security guidance for Red Hat, CentOS, and UNIX.

Default permissions on files created by users are enforced with user file access mask settings (using the umask command) that allow only the owner to read and write to the file. Implementations may further extend the access control in UNIX by restricting access to application files or using the file Access Control List (ACL) commands getfacl and setacl. Users of SIMP should not change file permissions on operating system files as it may decrease the overall security of the system. If a group needs access to a particular file or directory, use the setfacl command to allow the necessary access without lessening the permissions on the system. [AC-3]

Information Flow Enforcement

IPtables on each SIMP system is controlled by the IPtables Puppet module. When developing a new module, the IPtables rules needed for an application should be included with the module by calling the appropriate methods from the IPtables module. The end result should be a running IPtables rule set that includes the default SIMP rules and any rules needed for applications. The default communications allowed are included in Default Server Ports and Default Client Ports. [AC-4]

Default Server Ports
Application Direction Protocol Transport Ports Comment
Puppet Localhost HTTP TCP 8140 The port upon which the Puppet master listens for client connections via Apache
Puppet CA In HTTPS TCP 8141 This is used to ensure that Apache can verify all certificates from external systems properly prior to allowing access to Puppet.
Apache/YUM In HTTP TCP 80 This is used for YUM and is unencrypted, since YUM will not work otherwise.
DHCPD In DHCP/BOOTP TCP/UDP 546, 547 DHCP pooling is disabled by default and should only be used if the implementation requires the use of this protocol.
TFTP In TFTP TCP/UDP 69 This is used for kickstart. It could also be used to update network devices. TFTP does not support encryption.
rsyslog Out syslog TCP/UDP 6514 This is encrypted when communicating with a SIMP syslog server (not installed by default).
named In/Out DNS TCP/UDP 53 Inbound connections happen to the locally managed hosts. Outbound connections happen to other domains per the normal operations of DNS.
NTPD Out NTP TCP/UDP 123 Only connects to an external time source by default.
SSHD In SSH TCP 22 SSH is always allowed from any source IP by default.
stunnel In TLS TCP 8730 Stunnel is a protected connection for rsyncing configuration files to Puppet clients.
rsync Localhost RSYNC TCP 873 This accepts connections to the localhost and forwards through Stunnel.
LDAP In LDAP TCP 389 Connections are protected by bi-directional, authenticated encryption.
LDAPS In LDAPS TCP 636 Used for LDAP over SSL.
Default Client Ports
Application Direction Protocol Transport Ports Comment
Puppet Out HTTPS TCP 8140 Communications to the Puppet server.
rsyslog Out syslog TCP/UDP 6514 This is encrypted when communicating with a SIMP syslog server.
DNS Client Out DNS TCP/UDP 53 Normal name resolution.
NTPD Out NTP TCP/UDP 123 Only connects to an external time source by default.
SSHD In SSH TCP 22 SSH is allowed from any source IP by default.
LDAP Out LDAP TCP 389 Connections are protected by bi-directional authenticated encryption.

Separation of Duties

SIMP enforces separation of duties using account groups. Groups are created with each implementation to separate roles or duties properly. The SIMP team recommends that this management be done using posixGroups in LDAP for full operating System support. [AC-5]

Least Privilege

SIMP does not allow root to directly SSH into a system. The root user must be at a console (or at a virtual instance of the physical console) to log on. Otherwise, users must log on as themselves and perform privileged commands using sudo or sudosh. [AC-6]

NIST 800-53 least privilege security controls give people access to objects only as needed. SIMP provides only the needed software, services, and ports to allow the system to be functional and scalable. The system then relies on a given implementation to perform proper account management and user role assignments. [AC-6]

Session Controls

SIMP provides a number of security features for sessions. These features include:

  • Accounts are locked after five invalid log on attempts over a 15-minute period. The account is then locked for 15 minutes. No administrator action is required to unlock an account. [AC-7]
  • System banners are presented to a user both before and after logging on. The default banner should be customized for each implementation. [AC-8]
  • After a successful log on, the date, time, and source of the last log on is presented to the user. The number of failed log on attempts since the last log on is also provided. [AC-9 and AC-9(1)]
  • A limit of 10 concurrent SSH sessions are allowed per user. This can be further limited if an implementation decides it is set too high. Given the way SSH is used in operational settings, this default value is reasonable. [AC-10]
  • Session lock only applies if the windowmanager::gnome module is used. Sessions lock automatically after 15 minutes of inactivity. Users must authenticate their access with valid credentials to reestablish a session. [AC-11]

Permitted Actions without Identification and Authentication

SIMP has a number of applications that do not require both identification and authentication. These services are listed below along with an explanation of why these aspects are not required. Implementations should include any additional services that do require identification and/or authentication. [AC-14]

Service/Application Rationale
TFTP TFTP is a simple file transfer application that, in the SIMP environment, does not allow for writing to the files being accessed. This application is primarily used to support the Preboot Execution Environment (PXE) booting of hosts and the updating of network devices. There is no option to authenticate systems at this level by protocol design. TFTP is limited to a user’s local subnet using IPtables and is enforced additionally with TCPWrappers.
DHCP By default, system IP addresses are not pooled, but are rather statically assigned to a client, which is identified by the MAC address. DHCP is limited to the local subnet.
Apache/YUM RPMs are stored in a directory for systems to use for both kickstart and package updating. Sensitive information should never be stored here. Apache/YUM is limited to the local subnet.
DNS The DNS protocol does not require identification nor authentication. DNS is limited to the local subnet.

Table: Actions Without Identification and Authentication

Security Attributes

SELinux is now available in SIMP. SELinux is an implementation of mandatory access control. It can be set to enforcing mode during the SIMP configuration or turned on at a later time. All of the SIMP packaged modules have been designed to work with SELinux set to enforcing. [AC-16]

Remote Access

Remote access in SIMP is performed over SSH, specifically using the OpenSSH software. OpenSSH provides both confidentiality and integrity of remote access sessions. The SSH IPtables rules allow connections from any host. SSH relies on other Linux mechanisms to provide identification and authentication of a user. As discussed in the auditing section, user actions are audited with the audit daemon and sudosh. [AC-17]

Systems and Communications Protection

The following sections provide information regarding application partitioning, shared resources, and various levels of protection for systems and communications.

User and Administration Application Separation (Application Partitioning)

SIMP can be used in a variety of ways. The most common is a platform for hosting other services or applications. In that case, there are only administrative users present. Users with accounts will be considered as a type of privileged user.

SIMP can also be used as a platform for workstations or general users performing non-administrative activities. In both cases, general users with accounts on an individual host are allowed access to the host using the pam::access module, so long as they have an account on the target host. No user may perform or have access to administrative functions unless given sudo or sudosh privileges via Puppet.

Shared Resources

There are several layers of access control that prevent the unauthorized sharing of resources in SIMP. Account access, operating system DAC settings, and the use of PKI collectively prevent resources from being shared in ways that were not intended. [SC-4]

Denial of Service Protection

SIMP has limited ability to prevent or limit the effects of Denial of Service (DoS) attacks. The primary measures in place are to drop improperly formatted packets using IPtables and Kernel configurations such as syncookies. [SC-5]

Boundary Protection

SIMP does not provide boundary protection. [SC-7]

Transmission Security

SIMP traffic is protected with protocols that provide confidentiality and integrity of data while in transit. The tables in Information Flow Enforcement describe the protocols used to encrypt traffic and explain the protocols that cannot be protected at the transmission layer. SSH, SSL, and TLS all provide data transmission integrity and confidentiality. The software that controls them on Red Hat and CentOS are OpenSSH and OpenSSL. The SIMP team takes industry guidance into consideration when configuring these services. For example, the list the cryptographic ciphers available is limited to the highest ciphers that SIMP needs. All others are removed. [SC-8, SC-9, SC-23, SC-7]

Single User Mode

SIMP systems have a password requirement for single user mode. In the event maintenance needs to be performed at a system console, users must be in possession of the root password before they can be authenticated. Grub passwords are also set to prevent unauthorized modifications to boot parameters. [SC-24]

PKI and Cryptography

SIMP has two native certificate authorities. The first is known as Fake CA. A local certificate authority is used to create properly formed server certificates if an implementation does not have other means of obtaining them. Many SIMP services require certificates; therefore, SIMP provides this tool for testing or for situations where other certificates are not available. The second certificate authority, Puppet CA, is built into Puppet. Puppet creates, distributes, and manages certificates that are specifically for Puppet. More information on the Puppet CA can be found in the Puppet Labs security documentation. [SC-17, SC-13]

Warning

Fake CA certificates should not be used in an operational setting.

Mobile Code

SIMP does not use mobile code; however, there are not any particular tools that will prevent its use. [SC-18]

Protection of Information at Rest

There are no additional protections for information at rest beyond operating system capabilities in SIMP. There are also no measures in place to encrypt or sign data before transmission. Each implementation should determine how to further protect information at rest. [SC-28]

Audit and Accountability

This section discusses the content, storage, and protection of auditable events.

Auditable Events

Auditd and rsyslog provide the foundation for SIMP auditing. Auditd performs the majority of the security-related events; however, other Linux logs also have security information in them, which are captured using rsyslog.

The default auditable events for SIMP were developed based on several industry best practices including those from the SCAP Security Guide and several government configuration guides. The suggested rules by those guides were fine-tuned so the audit daemon would not fill logs with useless records or reduce performance. These guides should be referenced for a detailed explanation of why rules are applied. Additional justification can be found in the comments of the SIMP audit rules found in the appendix of this guide. [AU-2]

The SIMP development team reviews every release of the major security guides for updated auditable events suggestions. Each of those suggestions is reviewed and applied if deemed applicable. [AU-2(3)] Privileged commands are audited as part of the SIMP auditing configuration. This is accomplished by monitoring sudo commands with auditd. Keystrokes for administrators that use sudosh are also logged. Each session can be replayed using sudosh-replay. [AU-2(4)]

Content of Audit Records

Audit records capture the following information [AU-3]:

  • Date and Time
  • UID and GID of the user performing the action
  • Command
  • Event ID
  • Key
  • Node Hostname/IP Address
  • Login Session ID
  • Executable

Audit Storage

Audit logs are stored locally on a separate partition in the /var/log directory. The size of this partition is configurable. Other default audit storage configurations include:

  • A syslog log is written when the audit partition has 75MB free. (This can be changed to e-mail, if e-mail infrastructure is in place.) [AU-5(a), AU-5(1)]
  • The log file rotates once it reaches 30MB.

Audit Reduction and Response

SIMP provides a means to capture the proper information for audit records and stores them centrally. Each implementation must decide and document how it reduces, analyzes, and responds to audit events. [AU-5]

Auditd, like all services in SIMP, is controlled by Puppet. Stopping the service without disabling Puppet means the service will always be started automatically during a Puppet run. The files that control the audit configuration will also revert to their original state if changed manually on a client node. In the event auditd fails, the system will continue to operate. Several security guides have suggested that the system should shut down if auditd fails for any reason. However, SIMP will not shut down, but will provide an alert via syslog when this happens. [AU-5(1)]

SIMP also comes with an optional module for the Elasticsearch/Logstash/Kibana (ELK) stack. These three open source tools can be combined to parse, index, and visualize logs. There are also SIMP provided dashboards for the Kibana web interface. Implementations can build their own dashboards to meet local security or functional needs for log reduction and management. [AU-6]

Protection of Audit Information

The primary means of protecting the audit logs is through the use of file permissions. Audit records are stored in the /var/log directory and can only be accessed by root. Audit logs are rotated off daily if the implementation has not developed a way of offloading the logs to another location where they can be backed up. Lastly, if the rsyslog::stock::log_server module is implemented, logs are transmitted to the log server over a TLS protected link.

Time Synchronization

Each SIMP client (including the Puppet Master) has NTPD enabled by default. Part of the installation directs the clients to a time server. If no servers are available, the SIMP clients can use the Puppet Master as the central time source. Audit logs receive their time stamp from the local server’s system clock; therefore, the SIMP client must be connected to a central time source for time stamps in audit logs to be accurate.

Operational Security

This chapter contains SIMP security concepts that are related to the operational security controls in NIST 800-53.

Configuration Management

This section describes the management of various configurations within SIMP.

Baseline Configurations

SIMP baselines include configuration settings and Puppet modules. Currently, baselines are maintained for both Red Hat/CentOS 6.x, and Red Hat/CentOS 7.x. Each configuration item that is managed by a Puppet module has an RPM installed on the Puppet Master in the form of pupmod-name-x.x.x-x. This process allows for one main SIMP baseline to be maintained and modules to be upgraded easily. An overall SIMP RPM is also installed on the Puppet Master, which denotes the version number of SIMP that is installed. [CM-2, CM-2(2), CM-2(3), CM-6]

SIMP installs a minimal set of RPMs, which can be found in ?. RPMs, services, and IPtables rules all use a deny-all, but allow-by-exception module. Additional RPMs must be installed by each implementation. Services must be declared explicitly or they will be disabled by Puppet; IPtables rules must allow a service explicitly. [CM-2(5)]

Managing Configuration Changes

Configuration change approvals are managed by each implementation; SIMP only provides the mechanisms to apply changes on clients. A combination of Puppet, rsync, and YUM is used to apply those changes across all (or selected) Puppet clients. All changes made are audited with auditd or are logged to other files via syslog. [CM-3(a), CM-3(3)]

UNIX systems are made up of hundreds of configuration files that can contain dozens of settings. SIMP does not make an attempt to manage all of the settings in every file. Instead, critical operating system files or files that need to be controlled centrally are managed. Implementations can manage additional files if they are deemed necessary. [CM-6]

Security Verification and Flaw Remediation

SIMP cannot detect flaws automatically; each implementation is responsible for tracking flaws. However, SIMP provides a way for flaws to be fixed across all clients. One or all of the following can help automate flaw remediation [CM-6, SI-2, SI-2(1), SI-2(4)]:

  • Puppet: Apply a configuration change to files that are managed by Puppet.
  • rsync: Use this mechanism to deliver a file to a client. This can be used with or without Puppet to synchronize files.
  • YUM: Update packages nightly with YUM. Placing an updated package in YUM and running a YUM update manually, or allowing time for the cron job to run, will ensure packages on all clients are updated. Otherwise, a cron job will perform a daily update of packages with YUM.
  • PSSH: Allow commands to run across a set of nodes with the PSSH utility. Through the use of keys, this becomes a powerful way to run a one-time operation against a large number of nodes.

The extent of security verification that is performed currently is based on changes to files that Puppet or the Advanced Intrusion Detection Environment (AIDE) provides. There are also Security Content Automation Protocol (SCAP) profiles available from the SCAP-Security-Guide project that check security configuration settings. [SI-6]

Malicious Code Protection

For most environments, SIMP will use ClamAV to protect against malicious code. Rsync is used to push out new definitions, which should be updated by the local administrator regularly. SIMP also comes with a mcafee::uvscan module that manages an installation of uvscan, if it is preferred. The module can configure .dat file updates to occur over rsync.

Both the ClamAV and McAfee modules provide a method to run a scan via cron on a customer scheduled basis. [SI-3] SIMP also comes with the chkrootkit tool to check for rootkits. The tool runs as a cron job and places its output into syslog. [SI-3]

Software and Information Integrity

Unauthorized changes to a local client can be detected by Puppet or AIDE (for any file managed by Puppet). In the event that a managed file is changed locally, Puppet will revert the file back to its original state. It is important to note that this is a function of Puppet and is intended to be more of a configuration management feature rather than a security feature. If a Puppet client has been compromised, the Puppet Master may not have the ability to retake control over that client. However, the Puppet Master can configure all other nodes to deny traffic from the compromised node if they are configured by the administrator to do so. There are additional configuration files that are checked by AIDE, which is triggered by a cron job. AIDE logs any detected file changes in syslog. Each implementation may add additional files that are managed by Puppet or watched by AIDE. The AIDE baseline database is updated periodically to handle the installation and updating of system RPMs and reduce false positives. [SI-7, SI-7(1), SI-7(2), SI-7(3)]

Remote Maintenance

Remote maintenance can be performed on SIMP using SSH. Local maintenance can be performed at the console or via serial port (if available). SSH sessions are tracked and logged using the security features built into SIMP. Console access requires someone to have access to the physical (or virtual) console along with the root password. Auditing of those actions also occurs in accordance with the configured audit policy. It is up to the implementation to decide how to distribute authentication information for remote maintenance. [MA-4, MA-4(1), MA-6]

Incident Response

While Puppet is not intended to be a security product primarily, its features help provide security functionality such as dynamic reconfigurations and wide-scale consistent mitigation application. If an implementation chooses, they can leverage Puppet’s ability to reconfigure systems as part of incident response. [IR]

Contingency Planning

SIMP does not provide any direct support for contingency planning. Some of the mechanisms provided by SIMP might be used to support an implementation’s contingency plan.

System Backup

SIMP comes with a module called backuppc. This module provides a base configuration of the BackupPC software and allows Puppet servers and clients to perform backups.

Information System Management

This chapter contains SIMP security concepts that are related to the management security controls in NIST 800-53.

Risk Assessment

This section describes the process of identifying risks within a system.

SIMP Self Risk Assessment

Risk can be found in any system. The SIMP team is constantly evaluating the system and the settings to minimize inherit risk. Most risks can be mitigated by processes and procedures at the implementation level. The following table describes the known areas in SIMP. [RA-1]

Risk Possible Mitigations
Disabling Puppet: This can cause the clients to be out of sync with the Puppet Master. SIMP attempts to force a break on any locks and restart Puppet on all clients after a time of 4*runinterval (30 minutes by default). Implementations should ensure that further steps have not been taken to disable Puppet and should monitor their logs. Administrators can use the puppetlast command on the Puppet Master to detect servers that have not checked in within a reasonable time period.
Out of Date Patches: SIMP can be built with the RPMs from CentOS or Red Hat. Those RPMs should be assumed out of date at the time a system is initially installed (if using the SIMP DVD). Implementations should obtain the latest RPMs and apply them in a reasonable manner. All SIMP systems will, by default, attempt to update all packages using YUM nightly. Therefore, having an updated repository will ensure that the systems are updated on a regular basis.
Poor Account Management: SIMP security access control is based on users being created and managed over time. Giving shell access to unnecessary users allows them the opportunity to escalate privileges. Use the default LDIFs and local user modules to ensure that account settings remain restrictive. Ensure the system has policies and procedures in place to manage accounts. Finally, ensure that users are in appropriate groups with limited privileges.

Table: SIMP Risk

Vulnerability Scanning

The SIMP development and security team performs regular vulnerability scanning of the product using commercial and open source tools. Results and mitigations for findings from those tools can be provided upon request. [CA-2, RA-5]

Security Assessment and Authorization

Assessment and authorization varies by implementation. Implementations are encouraged to use documentation artifacts provided by the SIMP team to assist with assessment and authorization. [CA-2]

Security Concepts Appendices

Default Files Watched by AIDE

/boot   NORMAL
/bin    NORMAL
/sbin   NORMAL
/lib    NORMAL
/opt    NORMAL
/usr    NORMAL
/root   NORMAL
!/usr/src
!/usr/tmp
/etc    PERMS
!/etc/mtab
!/etc/.*~
/etc/exports  NORMAL
/etc/fstab    NORMAL
/etc/passwd   NORMAL
/etc/group    NORMAL
/etc/gshadow  NORMAL
/etc/shadow   NORMAL
/etc/security/opasswd   NORMAL
/etc/hosts.allow   NORMAL
/etc/hosts.deny    NORMAL
/etc/sudoers NORMAL
/etc/skel NORMAL
/etc/logrotate.d NORMAL
/etc/resolv.conf DATAONLY
/etc/nscd.conf NORMAL
/etc/securetty NORMAL
/etc/profile NORMAL
/etc/bashrc NORMAL
/etc/bash_completion.d/ NORMAL
/etc/login.defs NORMAL
/etc/zprofile NORMAL
/etc/zshrc NORMAL
/etc/zlogin NORMAL
/etc/zlogout NORMAL
/etc/profile.d/ NORMAL
/etc/X11/ NORMAL
/etc/yum.conf NORMAL
/etc/yumex.conf NORMAL
/etc/yumex.profiles.conf NORMAL
/etc/yum/ NORMAL
/etc/yum.repos.d/ NORMAL
/var/log   LOG
!/var/log/sa
!/var/log/aide/aide.log
!/var/log/aide/aide.report
/etc/audit/ LSPP
/etc/libaudit.conf LSPP
/usr/sbin/stunnel LSPP
/var/spool/at LSPP
/etc/at.allow LSPP
/etc/at.deny LSPP
/etc/cron.allow LSPP
/etc/cron.deny LSPP
/etc/cron.d/ LSPP
/etc/cron.daily/ LSPP
/etc/cron.hourly/ LSPP
/etc/cron.monthly/ LSPP
/etc/cron.weekly/ LSPP
/etc/crontab LSPP
/var/spool/cron/root LSPP
/etc/login.defs LSPP
/etc/securetty LSPP
/var/log/faillog LSPP
/var/log/lastlog LSPP
/etc/hosts LSPP
/etc/sysconfig LSPP
/etc/inittab LSPP
/etc/grub LSPP
/etc/rc.d LSPP
/etc/ld.so.conf LSPP
/etc/localtime LSPP
/etc/sysctl.conf LSPP
/etc/modprobe.d/00_simp_blacklist.conf LSPP
/etc/pam.d LSPP
/etc/security LSPP
/etc/aliases LSPP
/etc/postfix LSPP
/etc/ssh/sshd_config LSPP
/etc/ssh/ssh_config LSPP
/etc/stunnel LSPP
/etc/vsftpd.ftpusers LSPP
/etc/vsftpd LSPP
/etc/issue LSPP
/etc/issue.net LSPP
/etc/cups LSPP
!/var/log/and-httpd

Audit Rules

## For audit 1.6.5 and higher
##

# Ignore errors
# This may sound counterintuitive, but we'd rather skip bad rules and load the
# rest than miss half the file.  Warnings are still logged in the daemon
# restart output.
-i

## Remove any existing rules
-D

## Continue loading rules on failure.
# Particularly with the automatically generated nature of these rules in
# Puppet, it is possible that one or more may fail to load. We want to continue
# in that case so that we audit as much as possible.
-c

## Increase buffer size to handle the increased number of messages.
## Feel free to increase this if the machine panic's
# Default: 8192
-b 16394

## Set failure mode to panic
# Default: 2
-f 2

## Rate limit messages
# Default: 0
# If you set this to non-zero, you almost definitely want to set -f to 1 above.
-r 0

## Get rid of all anonymous and daemon junk.  It clogs up the logs and doesn't
# do anyone # any good.
-a exit,never -F auid!=4294967295

# Ignore system services. In most guides this is tagged onto every rule but
# that just makes for more processing time.
-a exit,never -F auid!=0 -F auid<500

## unsuccessful file operations
# CCE-26712-0
# CCE-26651-0
-a always,exit -F arch=b64 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -S openat -S open -S close -S rename -S truncate -S ftruncate -S rmdir -S unlink -S unlinkat -F exit=-EACCES -k access
-a always,exit -F arch=b64 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -S openat -S open -S close -S rename -S truncate -S ftruncate -S rmdir -S unlink -S unlinkat -F exit=-EPERM -k access
-a always,exit -F arch=b32 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -S openat -S open -S close -S rename -S truncate -S ftruncate -S rmdir -S unlink -S unlinkat -F exit=-EACCES -k access
-a always,exit -F arch=b32 -S creat -S mkdir -S mknod -S link -S symlink -S mkdirat -S mknodat -S linkat -S symlinkat -S openat -S open -S close -S rename -S truncate -S ftruncate -S rmdir -S unlink -S unlinkat -F exit=-EPERM -k access

-a always,exit -F perm=a -F exit=-EACCES -k access
-a always,exit -F perm=a -F exit=-EPERM -k access

# Permissions auditing
# CCE-26280-8
# CCE-27173-4
# CCE-27174-2
# CCE-27175-9
# CCE-27177-5
# CCE-27178-3
# CCE-27179-1
# CCE-27180-9
# CCE-27181-7
# CCE-27182-5
# CCE-27183-3
# CCE-27184-1
# CCE-27185-8
-a always,exit -F arch=b64 -S chown -S fchmod -S fchmodat -S fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -k perm_mod
-a always,exit -F arch=b32 -S chown -S fchmod -S fchmodat -S fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -k perm_mod

# Audit useful items that someone does when su'ing to root.
# Had to add an entry at the top for getting rid of anonymous records.  They
# are only moderately useful and contain *way* too much noise since this covers
# things like cron as well.

-a always,exit -F arch=b64 -F auid!=0 -F uid=0 -S capset -S mknod -S pivot_root -S quotactl -S setsid -S settimeofday -S setuid -S swapoff -S swapon -k su-root-activity
-a always,exit -F arch=b32 -F auid!=0 -F uid=0 -S capset -S mknod -S pivot_root -S quotactl -S setsid -S settimeofday -S setuid -S swapoff -S swapon -k su-root-activity

# Audit the execution of suid and sgid binaries.
# CCE-26457-2
-a always,exit -F arch=b64 -F euid=0 -F uid!=0 -S execve -k suid-root-exec
-a always,exit -F arch=b32 -F euid=0 -F uid!=0 -S execve -k suid-root-exec

## Audit the loading and unloading of kernel modules.
# CCE-26611-4
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules
-a always,exit -F arch=b32 -S init_module -S delete_module -k modules

## Things that could affect time
# CCE-27172-6
# CCE-27203-9
# CCE-27169-2
# CCE-27170-0
-a exit,always -F arch=b32 -S adjtimex -S stime -S clock_settime -S settimeofday -k audit_time_rules
-a exit,always -F arch=b64 -S adjtimex -S clock_settime -S settimeofday -k audit_time_rules

# CCE-27172-6
-w /etc/localtime -p wa -k audit_time_rules

## Things that could affect system locale
# CCE-26648-6
-a always,exit -F arch=b32 -S sethostname -S setdomainname -k audit_network_modifications
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k audit_network_modifications
-w /etc/issue -p wa -k audit_network_modifications
-w /etc/issue.net -p wa -k audit_network_modifications
-w /etc/hosts -p wa -k audit_network_modifications
-w /etc/sysconfig/network -p wa -k audit_network_modifications

# Mount options.
# CCE-26573-6
-a always,exit -F arch=b32 -S mount -S umount -S umount2 -k mount
-a always,exit -F arch=b64 -S mount -S umount2 -k mount

# audit umask changes.
# This is uselessly noisy.
# -a exit,always -S umask -k umask

# CCE-26664-3
-w /etc/group -p wa -k audit_account_changes
-w /etc/group- -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/passwd- -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/shadow- -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

# CCE-26657-7
-w /etc/selinux/ -p wa -k MAC-policy

# CCE-26691-6
-w /var/log/faillog -p wa -k logins
-w /var/log/lastlog -p wa -k logins

# CCE-26610-6
-w /var/run/utmp -p wa -k session
-w /var/run/btmp -p wa -k session
-w /var/run/wtmp -p wa -k session

# CCE-26662-7
-w /etc/sudoers -p wa -k CFG_sys

# Generally good things to audit.
-w /var/spool/at -p wa -k CFG_sys
-w /etc/at.deny -p wa -k CFG_sys
-w /etc/cron.deny -p wa -k CFG_cron
-w /etc/cron.d -p wa -k CFG_cron
-w /etc/cron.daily -p wa -k CFG_cron
-w /etc/cron.hourly -p wa -k CFG_cron
-w /etc/cron.monthly -p wa -k CFG_cron
-w /etc/cron.weekly -p wa -k CFG_cron
-w /etc/crontab -p wa -k CFG_cron
-w /etc/anacrontab -p wa -k CFG_cron
-w /etc/login.defs -p wa -k CFG_sys
-w /etc/securetty -p wa -k CFG_sys
-w /etc/shells -p wa -k CFG_shell
-w /etc/profile -p wa -k CFG_shell
-w /etc/bashrc -p wa -k CFG_shell
-w /etc/csh.cshrc -p wa -k CFG_shell
-w /etc/csh.login -p wa -k CFG_shell
-w /etc/sysconfig -p wa -k CFG_sys
-w /etc/inittab -p wa -k CFG_sys
-w /etc/rc.d/init.d -p wa -k CFG_sys
-w /etc/rc.local -p wa -k CFG_sys
-w /etc/rc.sysinit -p wa -k CFG_sys
-w /etc/xinetd.d -p wa -k CFG_sys
-w /etc/ld.so.conf -p wa -k CFG_sys
-w /etc/ld.so.conf.d -p wa -k CFG_sys
-w /etc/sysctl.conf -p wa -k CFG_sys
-w /etc/modprobe.d/00_simp_blacklist.conf -p wa -k CFG_sys
-w /etc/modprobe.conf.d -p wa -k CFG_sys
-w /etc/pam.d -p wa -k CFG_pam
-w /etc/pam_smb.conf -p wa -k CFG_pam
-w /etc/aliases -p wa -k CFG_sys
-w /etc/ssh/sshd_config -p wa -k CFG_sys
-w /etc/issue -p wa -k CFG_sys
-w /etc/issue.net -p wa -k CFG_sys
-w /etc/snmp/snmpd.conf -p wa -k CFG_sys
-w /etc/resolv.conf -p wa -k CFG_sys
-w /etc/nsswitch.conf -p wa -k CFG_sys
-w /etc/host.conf -p wa -k CFG_sys
-w /etc/krb5.conf -p wa -k CFG_sys
-w /etc/initlog.conf -p wa -k CFG_sys
-w /etc/default -p wa -k CFG_sys
-w /lib/firmware/microcode.dat -p wa -k CFG_sys
-w /etc/fstab -p wa -k CFG_sys
-w /etc/hosts.allow -p wa -k CFG_sys
-w /etc/hosts.deny -p wa -k CFG_sys
-w /etc/exports -p wa -k CFG_sys
-w /etc/yum.conf -p wa -k yum-config
-w /etc/yum.repos.d -p wa -k yum-config
-a exit,always -F arch=b32 -S ptrace -k paranoid
-a exit,always -F arch=b64 -S ptrace -k paranoid
-a always,exit -F arch=b32 -S personality -k paranoid
-a always,exit -F arch=b64 -S personality -k paranoid
-w /etc/aide.conf -p wa -k CFG_aide
-w /etc/aide.conf.d/default.aide -p wa -k CFG_aide
-w /etc/rc.d/init.d/auditd -p wa -k auditd
-w /var/log/audit.log -p wa -k audit-logs
-w /etc/pam_ldap.conf -p a -k CFG_etc_ldap
-w /etc/ntp.conf -p wa -k CFG_ntp
-w /etc/ntp/keys -p wa -k CFG_ntp
-w /etc/ntp/ntpservers -p wa -k CFG_ntp
-w /etc/pki/private -p wa -k PKI
-w /etc/pki/public -p wa -k PKI
-w /etc/pki/cacerts -p wa -k PKI
-w /etc/pki/private/ws69.kw.awesome.sauce.pem -p wa -k PKI
-w /etc/pki/public/ws69.kw.awesome.sauce.pub -p wa -k PKI
-w /var/log/audit.log.1 -p rwa -k audit-logs
-w /var/log/audit.log.2 -p rwa -k audit-logs
-w /var/log/audit.log.3 -p rwa -k audit-logs

-w /etc/security/access.conf -p wa -k CFG_security
-w /etc/security/console.perms -p wa -k CFG_security
-w /etc/security/chroot.conf -p wa -k CFG_security
-w /etc/security/limits.conf -p wa -k CFG_security
-w /etc/security/group.conf -p wa -k CFG_security
-w /etc/security/time.conf -p wa -k CFG_security
-w /etc/security/pam_env.conf -p wa -k CFG_security
-w /etc/grub.conf -p wa -k CFG_grub
-w /etc/xinted.conf -p wa -k CFG_xinted
-w /etc/services -p wa -k CFG_services
-w /etc/default/nss -p wa -k CFG_defaults
-w /etc/xinetd.d/chargen -p wa -k CFG_xinted.d
-w /etc/xinetd.d/chargen-udp -p wa -k CFG_xinted.d
-w /etc/xinetd.d/cups-lpd -p wa -k CFG_xinted.d
-w /etc/xinetd.d/daytime -p wa -k CFG_xinted.d
-w /etc/xinetd.d/daytime-udp -p wa -k CFG_xinted.d
-w /etc/xinetd.d/echo -p wa -k CFG_xinted.d
-w /etc/xinetd.d/echo-udp -p wa -k CFG_xinted.d
-w /etc/xinetd.d/rsync -p wa -k CFG_xinted.d
-w /etc/xinetd.d/time -p wa -k CFG_xinted.d
-w /etc/xinetd.d/time-udp -p wa -k CFG_xinted.d
-w /usr/share/gdm/defaults.conf -p wa -k CFG_sys
-w /etc/init/ -p wa -k CFG_upstart
# CCE-26612-2 deliberiately ignored so that audit rules may be manipulated by
# Puppet.

Default Kickstart Files

Default Puppet Master Kickstart file (contains default RPMs)

#
# Use the following Ruby code to generate your password hashes:
#   ruby -r 'digest/sha2' -e 'puts "password".crypt("$6$" + rand(36**8).to_s(36))'
#
# Use the following command to generate your grub password hash:
#   grub2-mkpasswd-pbkdf2
#
# Replace the following strings in this file
# #BOOTPASS# - Your hashed bootloader password
# #ROOTPASS# - Your hashed root password
# #KSSERVER# - The IP address of your YUM server
# #YUMSERVER# - The IP address of your YUM server
# #LINUXDIST# - The LINUX Distribution you are kickstarting
#        - Current CASE SENSITIVE options: RedHat CentOS

authconfig --enableshadow --passalgo=sha512
bootloader --location=mbr --append="console=ttyS1,57600 console=tty1" --iscrypted --password=#BOOTPASS#
rootpw --iscrypted #ROOTPASS#
zerombr
firewall --enabled --ssh
firstboot --disable
logging --level=info
network --bootproto=dhcp
reboot
selinux --permissive
timezone --utc GMT

install
skipx

%include /tmp/repo-include

text
keyboard us
lang en_US
url --url http://#KSSERVER#/yum/#LINUXDIST#/7/x86_64

%include /tmp/part-include

%packages --nobase
-sendmail
-sysklogd
acl
aide
anacron
audit
bzip2
coolkey
crontabs
cryptsetup-luks
dhclient
git
gnupg
iptables
iptables-ipv6
irqbalance
krb5-workstation
libaio
libutempter
logrotate
logwatch
lsof
lsscsi
mdadm
microcode_ctl
mutt
net-snmp
net-tools
netlabel_tools
ntp
openssh-clients
openssh-server
pam_krb5
pam_pkcs11
pciutils
psacct
quota
redhat-lsb
rpm
rsync
rsyslog
smartmontools
sssd
stunnel
subversion
sudo
sysstat
tcp_wrappers
tmpwatch
unzip
usbutils
vim-enhanced
vlock
wget
which
zip
# Puppet stuff
rsync
facter
puppet

# In case of broken repo, these should be installed.
hdparm
kbd
libhugetlbfs
policycoreutils
prelink
rootfiles
selinux-policy-targeted
setserial
sysfsutils
udftools

# Don't install these
-rhn-check
-rhn-setup
-rhnsd
-subscription-manager
-yum-rhn-plugin
%end

%pre
ksserver="#KSSERVER#"
wget -O /tmp/diskdetect.sh http://$ksserver/ks/diskdetect.sh;
chmod 750 /tmp/diskdetect.sh;
/tmp/diskdetect.sh;
wget -O /tmp/repodetect.sh http://$ksserver/ks/repodetect.sh;
chmod 750 /tmp/repodetect.sh;
/tmp/repodetect.sh '7' $ksserver;
%end

%post
ostype="#LINUXDIST#"
if [ $ostype == "CentOS" ]; then
    sed -i '/enabled=/d' /etc/yum.repos.d/CentOS-Base.repo;
      sed -i '/\[.*\]/ a\
      enabled=0' /etc/yum.repos.d/CentOS-Base.repo;
      fi
      ksserver="#KSSERVER#"

# Notify users that bootstrap will run on firstboot
echo "Welcome to SIMP!  If this is firstboot, SIMP bootstrap is scheduled to run.
If this host is not autosigned by Puppet, sign your Puppet certs to begin bootstrap.
Otherwise, it should already be running! Tail /root/puppet.bootstrap.log for details.
Wait for completion and reboot.

To remove this message, delete /root/.bootstrap_msg" > /root/.bootstrap_msg
sed -i "2i if [ -f /root/.bootstrap_msg ]\nthen\n  cat /root/.bootstrap_msg\nfi" /root/.bashrc
source /root/.bashrc

# Enable the firstboot bootstrapping script.
wget --no-check-certificate -O /etc/init.d/runpuppet http://$ksserver/ks/runpuppet;
chmod 700 /etc/rc.d/init.d/runpuppet;
chkconfig --add runpuppet;
chkconfig --level 35 runpuppet on;
%end

SIMP RPMs

Red Hat Enterprise Linux
Name Source
BackupPC-3.2.1-10.SIMP.4.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/BackupPC-3.2.1-10.SIMP.4.el6.x86_64.rpm
activemq-5.9.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/activemq-5.9.1-2.el6.noarch.rpm
activemq-info-provider-5.9.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/activemq-info-provider-5.9.1-2.el6.noarch.rpm
bitmap-console-fonts-0.3-15.el6.noarch.rpm Red Hat Optional Repository
bitmap-fangsongti-fonts-0.3-15.el6.noarch.rpm Red Hat Optional Repository
bitmap-fonts-compat-0.3-15.el6.noarch.rpm Red Hat Optional Repository
bitmap-miscfixed-fonts-0.3-15.el6.noarch.rpm Red Hat Optional Repository
chkrootkit-0.49-9.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/chkrootkit-0.49-9.el6.x86_64.rpm
clamav-0.98.7-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamav-0.98.7-1.el6.x86_64.rpm
clamav-db-0.98.7-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamav-db-0.98.7-1.el6.x86_64.rpm
clamav-devel-0.98.7-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamav-devel-0.98.7-1.el6.x86_64.rpm
clamav-milter-0.98.7-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamav-milter-0.98.7-1.el6.x86_64.rpm
clamav-unofficial-sigs-3.7.1-7.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamav-unofficial-sigs-3.7.1-7.el6.noarch.rpm
clamd-0.98.7-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamd-0.98.7-1.el6.x86_64.rpm
clamsmtp-1.10-6.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/clamsmtp-1.10-6.el6.x86_64.rpm
dejavu-lgc-sans-fonts-2.33-1.el6.noarch.rpm Red Hat Base Repository
dejavu-lgc-serif-fonts-2.33-1.el6.noarch.rpm Red Hat Base Repository
dracut-004-388.el6.noarch.rpm Red Hat Base Repository
dracut-fips-004-388.el6.noarch.rpm Red Hat Base Repository
dracut-fips-aesni-004-388.el6.noarch.rpm Red Hat Optional Repository
dracut-kernel-004-388.el6.noarch.rpm Red Hat Base Repository
elasticsearch-1.3.2.noarch.rpm https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.3.2.noarch.rpm
elasticsearch-curator-1.1.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/elasticsearch-curator-1.1.1-0.el6.noarch.rpm
es2unix-1.6.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/es2unix-1.6.1-0.el6.noarch.rpm
facter-2.4.1-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/products/x86_64/facter-2.4.1-1.el6.x86_64.rpm
fping-2.4b2-10.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/fping-2.4b2-10.el6.x86_64.rpm
freeradius-ldap-2.2.6-4.el6.x86_64.rpm Red Hat Base Repository
freeradius-utils-2.2.6-4.el6.x86_64.rpm Red Hat Base Repository
ganglia-3.7.1-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ganglia-3.7.1-2.el6.x86_64.rpm
ganglia-devel-3.7.1-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ganglia-devel-3.7.1-2.el6.x86_64.rpm
ganglia-gmetad-3.7.1-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ganglia-gmetad-3.7.1-2.el6.x86_64.rpm
ganglia-gmond-3.7.1-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ganglia-gmond-3.7.1-2.el6.x86_64.rpm
ganglia-gmond-python-3.7.1-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ganglia-gmond-python-3.7.1-2.el6.x86_64.rpm
glibc-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-common-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-devel-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-devel-2.12-1.166.el6_7.1.i686.rpm Red Hat Updates Repository
glibc-headers-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-static-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-static-2.12-1.166.el6_7.1.i686.rpm Red Hat Updates Repository
glibc-utils-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
glibc-2.12-1.166.el6_7.1.i686.rpm Red Hat Update Repository
globus-callout-3.13-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-callout-3.13-2.el6.x86_64.rpm
globus-common-15.30-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-common-15.30-1.el6.x86_64.rpm
globus-gsi-callback-5.8-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-callback-5.8-1.el6.x86_64.rpm
globus-gsi-cert-utils-9.11-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-cert-utils-9.11-1.el6.x86_64.rpm
globus-gsi-credential-7.9-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-credential-7.9-1.el6.x86_64.rpm
globus-gsi-openssl-error-3.5-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-openssl-error-3.5-2.el6.x86_64.rpm
globus-gsi-proxy-core-7.7-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-proxy-core-7.7-2.el6.x86_64.rpm
globus-gsi-proxy-ssl-5.7-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-proxy-ssl-5.7-2.el6.x86_64.rpm
globus-gsi-sysconfig-6.8-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-gsi-sysconfig-6.8-2.el6.x86_64.rpm
globus-gss-assist-10.15-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gss-assist-10.15-1.el6.x86_64.rpm
globus-gssapi-gsi-11.20-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gssapi-gsi-11.20-1.el6.x86_64.rpm
globus-openssl-module-4.6-2.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/globus-openssl-module-4.6-2.el6.x86_64.rpm
gpxe-bootimgs-0.9.7-6.14.el6.noarch.rpm Red Hat Base Repository
gpxe-roms-qemu-0.9.7-6.14.el6.noarch.rpm Red Hat Base Repository
gweb-2.1.8-1.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/gweb-2.1.8-1.noarch.rpm
hmaccalc-0.9.12-2.el6.x86_64.rpm Red Hat Base Repository
incron-0.5.9-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/incron-0.5.9-1.el6.x86_64.rpm
java-1.7.0-openjdk-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm Red Hat Updates Repository
java-1.7.0-openjdk-demo-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm Red Hat Updates Repository
java-1.7.0-openjdk-devel-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm Red Hat Updates Repository
java-1.7.0-openjdk-src-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm Red Hat Updates Repository
kernel-2.6.32-573.3.1.el6.x86_64.rpm Red Hat Updates Repository
kernel-abi-whitelists-2.6.32-573.3.1.el6.noarch.rpm Red Hat Updates Repository
kernel-debug-2.6.32-573.3.1.el6.x86_64.rpm Red Hat Updates Repository
kernel-debug-devel-2.6.32-573.3.1.el6.x86_64.rpm Red Hat Updates Repository
kernel-devel-2.6.32-573.3.1.el6.x86_64.rpm Red Hat Updates Repository
kernel-doc-2.6.32-573.3.1.el6.noarch.rpm Red Hat Updates Repository
kernel-firmware-2.6.32-573.3.1.el6.noarch.rpm Red Hat Updates Repository
kernel-headers-2.6.32-573.3.1.el6.x86_64.rpm Red Hat Updates Repository
kibana-3.1.0.SIMP-0.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/kibana-3.1.0.SIMP-0.noarch.rpm
lcgdm-libs-1.8.10-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/lcgdm-libs-1.8.10-1.el6.x86_64.rpm
leiningen-2.0.0-0.2preview10.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/leiningen-2.0.0-0.2preview10.el6.noarch.rpm
lfc-libs-1.8.10-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/lfc-libs-1.8.10-1.el6.x86_64.rpm
lfc-python-1.8.10-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/lfc-python-1.8.10-1.el6.x86_64.rpm
libarchive-devel-2.8.3-4.el6_2.x86_64.rpm Red Hat Optional Repository
libconfuse-2.7-4.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/libconfuse-2.7-4.el6.x86_64.rpm
libconfuse-devel-2.7-4.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/libconfuse-devel-2.7-4.el6.x86_64.rpm
libev-4.03-3.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/libev-4.03-3.el6.x86_64.rpm
libselinux-ruby-2.0.94-5.8.el6.x86_64.rpm Red Hat Base Repository
libyaml-0.1.4-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/libyaml-0.1.4-2.el6.x86_64.rpm
libyaml-devel-0.1.4-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/libyaml-devel-0.1.4-2.el6.x86_64.rpm
logstash-1.4.2-1_2c0f5a1.noarch.rpm https://download.elasticsearch.org/logstash/logstash/packages/centos/logstash-1.4.2-1_2c0f5a1.noarch.rpm
logstash-contrib-1.4.2-1_efd53ef.noarch.rpm https://download.elastic.co/logstash/logstash/packages/centos/logstash-contrib-1.4.2-1_efd53ef.noarch.rpm
mcollective-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-client-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-client-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-common-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-common-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-filemgr-agent-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-agent-1.0.1-1.noarch.rpm
mcollective-filemgr-client-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-client-1.0.1-1.noarch.rpm
mcollective-filemgr-common-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-common-1.0.1-1.noarch.rpm
mcollective-iptables-agent-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-agent-3.0.1-1.noarch.rpm
mcollective-iptables-client-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-client-3.0.1-1.noarch.rpm
mcollective-iptables-common-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-common-3.0.1-1.noarch.rpm
mcollective-logstash-audit-2.0.0-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-logstash-audit-2.0.0-1.noarch.rpm
mcollective-nrpe-agent-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-agent-3.0.2-1.noarch.rpm
mcollective-nrpe-client-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-client-3.0.2-1.noarch.rpm
mcollective-nrpe-common-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-common-3.0.2-1.noarch.rpm
mcollective-package-agent-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-agent-4.3.0-1.el6.noarch.rpm
mcollective-package-client-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-client-4.3.0-1.el6.noarch.rpm
mcollective-package-common-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-common-4.3.0-1.el6.noarch.rpm
mcollective-puppet-agent-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-agent-1.7.2-1.el6.noarch.rpm
mcollective-puppet-client-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-client-1.7.2-1.el6.noarch.rpm
mcollective-puppet-common-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-common-1.7.2-1.el6.noarch.rpm
mcollective-service-agent-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-agent-3.1.2-1.noarch.rpm
mcollective-service-client-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-client-3.1.2-1.noarch.rpm
mcollective-service-common-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-common-3.1.2-1.noarch.rpm
mcollective-sysctl-data-2.0.0-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-sysctl-data-2.0.0-1.noarch.rpm
mrepo-0.8.7-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/mrepo-0.8.7-2.el6.noarch.rpm
mysql-connector-python-1.1.6-1.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/mysql-connector-python-1.1.6-1.el6.noarch.rpm
nscd-2.12-1.166.el6_7.1.x86_64.rpm Red Hat Updates Repository
nspr-4.10.8-1.el6_6.x86_64.rpm Red Hat Base Repository
nss-3.19.1-3.el6_6.x86_64.rpm Red Hat Updates Repository
nss-softokn-3.14.3-22.el6_6.x86_64.rpm Red Hat Base Repository
nss-softokn-freebl-3.14.3-22.el6_6.x86_64.rpm Red Hat Base Repository
nss-sysinit-3.19.1-3.el6_6.x86_64.rpm Red Hat Updates Repository
nss-tools-3.19.1-3.el6_6.x86_64.rpm Red Hat Updates Repository
nss-util-3.19.1-1.el6_6.x86_64.rpm Red Hat Updates Repository
openssl-1.0.1e-42.el6.x86_64.rpm Red Hat Base Repository
openssl-devel-1.0.1e-42.el6.x86_64.rpm Red Hat Base Repository
pdsh-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-2.28-0.x86_64.rpm
pdsh-mod-dshgroup-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-dshgroup-2.28-0.x86_64.rpm
pdsh-mod-machines-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-machines-2.28-0.x86_64.rpm
pdsh-mod-netgroup-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-netgroup-2.28-0.x86_64.rpm
pdsh-rcmd-exec-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-rcmd-exec-2.28-0.x86_64.rpm
pdsh-rcmd-ssh-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-rcmd-ssh-2.28-0.x86_64.rpm
perl-Archive-Zip-1.30-2.el6.noarch.rpm Red Hat Base Repository
perl-Crypt-DES-2.05-9.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Crypt-DES-2.05-9.el6.x86_64.rpm
perl-DateTime-Format-DateParse-0.05-4.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-DateTime-Format-DateParse-0.05-4.el6.noarch.rpm
perl-DateTime-Format-Mail-0.3001-6.el6.noarch.rpm Red Hat Base Repository
perl-DateTime-Format-W3CDTF-0.04-8.el6.noarch.rpm Red Hat Base Repository
perl-File-RsyncP-0.72-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-File-RsyncP-0.72-1.el6.x86_64.rpm
perl-Math-Calc-Units-1.07-6.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Math-Calc-Units-1.07-6.el6.noarch.rpm
perl-Net-FTP-AutoReconnect-0.3-3.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Net-FTP-AutoReconnect-0.3-3.el6.noarch.rpm
perl-Net-FTP-RetrHandle-0.2-3.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Net-FTP-RetrHandle-0.2-3.el6.noarch.rpm
perl-Net-SNMP-5.2.0-4.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Net-SNMP-5.2.0-4.el6.noarch.rpm
perl-Sort-Versions-1.5-12.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/perl-Sort-Versions-1.5-12.el6.noarch.rpm
perl-Time-modules-2006.0814-5.el6.noarch.rpm Red Hat Base Repository
perl-XML-RSS-1.45-2.el6.noarch.rpm Red Hat Base Repository
pssh-2.3.1-5.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/pssh-2.3.1-5.el6.noarch.rpm
puppet-3.7.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-3.7.4-1.el6.noarch.rpm
puppet-dashboard-1.2.23-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-dashboard-1.2.23-1.el6.noarch.rpm
puppet-server-3.7.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-server-3.7.4-1.el6.noarch.rpm
puppetdb-2.3.8-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetdb-2.3.8-1.el6.noarch.rpm
puppetdb-terminus-2.3.8-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetdb-terminus-2.3.8-1.el6.noarch.rpm
puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.el6.noarch.rpm
puppetserver-1.1.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetserver-1.1.1-1.el6.noarch.rpm
python-argparse-1.2.1-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-argparse-1.2.1-2.el6.noarch.rpm
python-backports-1.0-3.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-backports-1.0-3.el6.x86_64.rpm
python-backports-ssl_match_hostname-3.4.0.2-4.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-backports-ssl_match_hostname-3.4.0.2-4.el6.noarch.rpm
python-elasticsearch-1.2.0-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/python-elasticsearch-1.2.0-0.el6.noarch.rpm
python-importlib-1.0.2-1.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-importlib-1.0.2-1.el6.noarch.rpm
python-ordereddict-1.1-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-ordereddict-1.1-2.el6.noarch.rpm
python-pyes-0.20.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/python-pyes-0.20.1-0.el6.noarch.rpm
python-pyro-4.14-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-pyro-4.14-2.el6.noarch.rpm
python-redis-2.0.0-1.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-redis-2.0.0-1.el6.noarch.rpm
python-six-1.9.0-2.el6.noarch.rpm Red Hat Base Repository
python-unittest2-0.5.1-3.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-unittest2-0.5.1-3.el6.noarch.rpm
python-urllib3-1.5-7.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/python-urllib3-1.5-7.el6.noarch.rpm
qstat-2.11-9.20080912svn311.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/qstat-2.11-9.20080912svn311.el6.x86_64.rpm
radiusclient-ng-0.5.6-5.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/radiusclient-ng-0.5.6-5.el6.x86_64.rpm
razor-server-0.14.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/razor-server-0.14.1-1.el6.noarch.rpm
razor-torquebox-3.0.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/razor-torquebox-3.0.1-1.el6.noarch.rpm
rlwrap-0.37-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rlwrap-0.37-3.el6.x86_64.rpm
rrdtool-1.4.4-0.20.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/rrdtool-1.4.4-0.20.el6.x86_64.rpm
ruby-augeas-0.4.1-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-augeas-0.4.1-3.el6.x86_64.rpm
ruby-json-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-json-1.5.5-3.el6.x86_64.rpm
ruby-ldap-0.9.7-10.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ruby-ldap-0.9.7-10.el6.x86_64.rpm
ruby-mysql-2.8.2-1.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/ruby-mysql-2.8.2-1.el6.x86_64.rpm
ruby-rgen-0.6.5-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-rgen-0.6.5-2.el6.noarch.rpm
ruby-shadow-2.2.0-2.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-shadow-2.2.0-2.el6.x86_64.rpm
rubygem-activerecord-2.3.16-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-activerecord-2.3.16-1.el6.noarch.rpm
rubygem-activesupport-2.3.16-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-activesupport-2.3.16-1.el6.noarch.rpm
rubygem-deep_merge-1.0.0-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-deep_merge-1.0.0-2.el6.noarch.rpm
rubygem-fastthread-1.0.7-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-fastthread-1.0.7-1.el6.x86_64.rpm
rubygem-ffi-1.4.0-2.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-ffi-1.4.0-2.el6.x86_64.rpm
rubygem-highline-1.6.11-1.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/rubygem-highline-1.6.11-1.noarch.rpm
rubygem-hpricot-0.8.6-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-hpricot-0.8.6-1.el6.x86_64.rpm
rubygem-json-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-json-1.5.5-3.el6.x86_64.rpm
rubygem-json-doc-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-json-doc-1.5.5-3.el6.x86_64.rpm
rubygem-mustache-0.99.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-mustache-0.99.4-1.el6.noarch.rpm
rubygem-net-ldap-0.2.2-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ldap-0.2.2-4.el6.noarch.rpm
rubygem-net-ldap-doc-0.2.2-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ldap-doc-0.2.2-4.el6.noarch.rpm
rubygem-net-ping-1.6.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ping-1.6.2-1.el6.noarch.rpm
rubygem-net-ping-doc-1.5.3-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ping-doc-1.5.3-4.el6.noarch.rpm
rubygem-puppet-lint-1.1.0-1.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/rubygem-puppet-lint-1.1.0-1.el6.noarch.rpm
rubygem-rack-1.0.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-rack-1.0.1-2.el6.noarch.rpm
rubygem-rake-0.8.7-2.1.el6.noarch.rpm http://mirror.netdepot.com/centos/6.7/os/x86_64/Packages/rubygem-rake-0.8.7-2.1.el6.noarch.rpm
rubygem-rake-compiler-0.9.3-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/rubygem-rake-compiler-0.9.3-2.el6.noarch.rpm
rubygem-rake-compiler-doc-0.9.3-2.el6.noarch.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/rubygem-rake-compiler-doc-0.9.3-2.el6.noarch.rpm
rubygem-rdiscount-1.6.8-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-rdiscount-1.6.8-1.el6.x86_64.rpm
rubygem-ronn-0.7.3-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-ronn-0.7.3-1.el6.noarch.rpm
rubygem-stomp-1.3.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-stomp-1.3.2-1.el6.noarch.rpm
rubygem-stomp-doc-1.3.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-stomp-doc-1.3.2-1.el6.noarch.rpm
scap-security-guide-0.1.21-3.el6.noarch.rpm Red Hat Base Repository
sendmail-milter-8.14.4-9.el6.x86_64.rpm http://mirror.netdepot.com/centos/6.7/os/x86_64/Packages/sendmail-milter-8.14.4-9.el6.x86_64.rpm
hiera-3.0.2-1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/hiera-3.0.2-1.el6.noarch.rpm
simp-lastbind-2.4.23-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/simp-lastbind-2.4.23-0.x86_64.rpm
simp-ppolicy-check-password-2.4.39-0.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/simp-ppolicy-check-password-2.4.39-0.el6.x86_64.rpm
sudosh2-1.0.2-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/sudosh2-1.0.2-2.el6.x86_64.rpm
syslinux-tftpboot-4.04-3.el6.noarch.rpm Red Hat Base Repository
tanukiwrapper-3.5.9-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/tanukiwrapper-3.5.9-1.el6.x86_64.rpm
trousers-0.3.13-2.el6.x86_64.rpm Red Hat Base Repository
voms-2.0.12-3.el6.x86_64.rpm http://mirror.symnds.com/distributions/fedora-epel/6/x86_64/voms-2.0.12-3.el6.x86_64.rpm
Community ENTerprise Operating System
Name Source
BackupPC-3.2.1-10.SIMP.4.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/BackupPC-3.2.1-10.SIMP.4.el6.x86_64.rpm
activemq-5.9.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/activemq-5.9.1-2.el6.noarch.rpm
activemq-info-provider-5.9.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/activemq-info-provider-5.9.1-2.el6.noarch.rpm
bitmap-console-fonts-0.3-15.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/bitmap-console-fonts-0.3-15.el6.noarch.rpm
bitmap-fangsongti-fonts-0.3-15.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/bitmap-fangsongti-fonts-0.3-15.el6.noarch.rpm
bitmap-fonts-compat-0.3-15.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/bitmap-fonts-compat-0.3-15.el6.noarch.rpm
bitmap-miscfixed-fonts-0.3-15.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/bitmap-miscfixed-fonts-0.3-15.el6.noarch.rpm
chkrootkit-0.49-9.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/chkrootkit-0.49-9.el6.x86_64.rpm
clamav-0.98.7-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamav-0.98.7-1.el6.x86_64.rpm
clamav-db-0.98.7-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamav-db-0.98.7-1.el6.x86_64.rpm
clamav-devel-0.98.7-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamav-devel-0.98.7-1.el6.x86_64.rpm
clamav-milter-0.98.7-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamav-milter-0.98.7-1.el6.x86_64.rpm
clamav-unofficial-sigs-3.7.1-7.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamav-unofficial-sigs-3.7.1-7.el6.noarch.rpm
clamd-0.98.7-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamd-0.98.7-1.el6.x86_64.rpm
clamsmtp-1.10-6.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/clamsmtp-1.10-6.el6.x86_64.rpm
dejavu-lgc-sans-fonts-2.33-1.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/dejavu-lgc-sans-fonts-2.33-1.el6.noarch.rpm
dejavu-lgc-serif-fonts-2.33-1.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/dejavu-lgc-serif-fonts-2.33-1.el6.noarch.rpm
dracut-004-388.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/dracut-004-388.el6.noarch.rpm
dracut-fips-004-388.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/dracut-fips-004-388.el6.noarch.rpm
dracut-kernel-004-388.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/dracut-kernel-004-388.el6.noarch.rpm
elasticsearch-1.3.2.noarch.rpm https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-1.3.2.noarch.rpm
elasticsearch-curator-1.1.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/elasticsearch-curator-1.1.1-0.el6.noarch.rpm
es2unix-1.6.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/es2unix-1.6.1-0.el6.noarch.rpm
facter-2.4.1-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/products/x86_64/facter-2.4.1-1.el6.x86_64.rpm
fping-2.4b2-10.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/fping-2.4b2-10.el6.x86_64.rpm
freeradius-ldap-2.2.6-4.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/freeradius-ldap-2.2.6-4.el6.x86_64.rpm
freeradius-utils-2.2.6-4.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/freeradius-utils-2.2.6-4.el6.x86_64.rpm
ganglia-3.7.1-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ganglia-3.7.1-2.el6.x86_64.rpm
ganglia-devel-3.7.1-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ganglia-devel-3.7.1-2.el6.x86_64.rpm
ganglia-gmetad-3.7.1-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ganglia-gmetad-3.7.1-2.el6.x86_64.rpm
ganglia-gmond-3.7.1-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ganglia-gmond-3.7.1-2.el6.x86_64.rpm
ganglia-gmond-python-3.7.1-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ganglia-gmond-python-3.7.1-2.el6.x86_64.rpm
glibc-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-2.12-1.166.el6_7.1.x86_64.rpm
glibc-common-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-common-2.12-1.166.el6_7.1.x86_64.rpm
glibc-devel-2.12-1.166.el6_7.1.x86_64.rpm http://centos.mirror.nac.net/6.7/updates/x86_64/Packages/glibc-devel-2.12-1.166.el6_7.1.x86_64.rpm
glibc-devel-2.12-1.166.el6_7.1.i686.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-devel-2.12-1.166.el6_7.1.i686.rpm
glibc-headers-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-headers-2.12-1.166.el6_7.1.x86_64.rpm
glibc-static-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-static-2.12-1.166.el6_7.1.x86_64.rpm
glibc-static-2.12-1.166.el6_7.1.i686.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-static-2.12-1.166.el6_7.1.i686.rpm
glibc-utils-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-utils-2.12-1.166.el6_7.1.x86_64.rpm
glibc-2.12-1.166.el6_7.1.i686.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/glibc-2.12-1.166.el6_7.1.i686.rpm
globus-callout-3.13-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-callout-3.13-2.el6.x86_64.rpm
globus-common-15.30-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-common-15.30-1.el6.x86_64.rpm
globus-gsi-callback-5.8-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-callback-5.8-1.el6.x86_64.rpm
globus-gsi-cert-utils-9.11-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-cert-utils-9.11-1.el6.x86_64.rpm
globus-gsi-credential-7.9-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-credential-7.9-1.el6.x86_64.rpm
globus-gsi-openssl-error-3.5-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-openssl-error-3.5-2.el6.x86_64.rpm
globus-gsi-proxy-core-7.7-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-proxy-core-7.7-2.el6.x86_64.rpm
globus-gsi-proxy-ssl-5.7-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-proxy-ssl-5.7-2.el6.x86_64.rpm
globus-gsi-sysconfig-6.8-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gsi-sysconfig-6.8-2.el6.x86_64.rpm
globus-gss-assist-10.15-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gss-assist-10.15-1.el6.x86_64.rpm
globus-gssapi-gsi-11.22-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-gssapi-gsi-11.22-1.el6.x86_64.rpm
globus-openssl-module-4.6-2.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/globus-openssl-module-4.6-2.el6.x86_64.rpm
gpxe-bootimgs-0.9.7-6.14.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/gpxe-bootimgs-0.9.7-6.14.el6.noarch.rpm
gpxe-roms-qemu-0.9.7-6.14.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/gpxe-roms-qemu-0.9.7-6.14.el6.noarch.rpm
gweb-2.1.8-1.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/gweb-2.1.8-1.noarch.rpm
haveged-1.9.1-2.el6.x86_64.rpm http://lug.mtu.edu/epel/6/x86_64/haveged-1.9.1-2.el6.x86_64.rpm
hiera-3.0.2-1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X/hiera-3.0.2-1.el6.noarch.rpm
hmaccalc-0.9.12-2.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/hmaccalc-0.9.12-2.el6.x86_64.rpm
incron-0.5.9-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/incron-0.5.9-1.el6.x86_64.rpm
java-1.7.0-openjdk-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/java-1.7.0-openjdk-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm
java-1.7.0-openjdk-demo-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/java-1.7.0-openjdk-demo-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm
java-1.7.0-openjdk-devel-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/java-1.7.0-openjdk-devel-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm
java-1.7.0-openjdk-src-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/java-1.7.0-openjdk-src-1.7.0.85-2.6.1.3.el6_7.x86_64.rpm
kernel-2.6.32-573.3.1.el6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-2.6.32-573.3.1.el6.x86_64.rpm
kernel-abi-whitelists-2.6.32-573.3.1.el6.noarch.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-abi-whitelists-2.6.32-573.3.1.el6.noarch.rpm
kernel-debug-2.6.32-573.3.1.el6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-debug-2.6.32-573.3.1.el6.x86_64.rpm
kernel-debug-devel-2.6.32-573.3.1.el6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-debug-devel-2.6.32-573.3.1.el6.x86_64.rpm
kernel-devel-2.6.32-573.3.1.el6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-devel-2.6.32-573.3.1.el6.x86_64.rpm
kernel-doc-2.6.32-573.3.1.el6.noarch.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-doc-2.6.32-573.3.1.el6.noarch.rpm
kernel-firmware-2.6.32-573.3.1.el6.noarch.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-firmware-2.6.32-573.3.1.el6.noarch.rpm
kernel-headers-2.6.32-573.3.1.el6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/kernel-headers-2.6.32-573.3.1.el6.x86_64.rpm
kibana-3.1.0.SIMP-0.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/kibana-3.1.0.SIMP-0.noarch.rpm
lcgdm-libs-1.8.10-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/lcgdm-libs-1.8.10-1.el6.x86_64.rpm
leiningen-2.0.0-0.2preview10.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/leiningen-2.0.0-0.2preview10.el6.noarch.rpm
lfc-libs-1.8.10-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/lfc-libs-1.8.10-1.el6.x86_64.rpm
lfc-python-1.8.10-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/lfc-python-1.8.10-1.el6.x86_64.rpm
libarchive-devel-2.8.3-4.el6_2.x86_64.rpm http://mirror.netdepot.com/centos/6.7/os/x86_64/Packages/libarchive-devel-2.8.3-4.el6_2.x86_64.rpm
libconfuse-2.7-4.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/libconfuse-2.7-4.el6.x86_64.rpm
libconfuse-devel-2.7-4.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/libconfuse-devel-2.7-4.el6.x86_64.rpm
libev-4.03-3.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/libev-4.03-3.el6.x86_64.rpm
libselinux-ruby-2.0.94-5.8.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/libselinux-ruby-2.0.94-5.8.el6.x86_64.rpm
libyaml-0.1.4-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/libyaml-0.1.4-2.el6.x86_64.rpm
libyaml-devel-0.1.4-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/libyaml-devel-0.1.4-2.el6.x86_64.rpm
logstash-1.4.2-1_2c0f5a1.noarch.rpm https://download.elasticsearch.org/logstash/logstash/packages/centos/logstash-1.4.2-1_2c0f5a1.noarch.rpm
logstash-contrib-1.4.2-1_efd53ef.noarch.rpm https://download.elastic.co/logstash/logstash/packages/centos/logstash-contrib-1.4.2-1_efd53ef.noarch.rpm
mcollective-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-client-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-client-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-common-2.2.3-1.SIMP.1.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/mcollective-common-2.2.3-1.SIMP.1.el6.noarch.rpm
mcollective-filemgr-agent-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-agent-1.0.1-1.noarch.rpm
mcollective-filemgr-client-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-client-1.0.1-1.noarch.rpm
mcollective-filemgr-common-1.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-filemgr-common-1.0.1-1.noarch.rpm
mcollective-iptables-agent-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-agent-3.0.1-1.noarch.rpm
mcollective-iptables-client-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-client-3.0.1-1.noarch.rpm
mcollective-iptables-common-3.0.1-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-iptables-common-3.0.1-1.noarch.rpm
mcollective-logstash-audit-2.0.0-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-logstash-audit-2.0.0-1.noarch.rpm
mcollective-nrpe-agent-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-agent-3.0.2-1.noarch.rpm
mcollective-nrpe-client-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-client-3.0.2-1.noarch.rpm
mcollective-nrpe-common-3.0.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-nrpe-common-3.0.2-1.noarch.rpm
mcollective-package-agent-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-agent-4.3.0-1.el6.noarch.rpm
mcollective-package-client-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-client-4.3.0-1.el6.noarch.rpm
mcollective-package-common-4.3.0-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-package-common-4.3.0-1.el6.noarch.rpm
mcollective-puppet-agent-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-agent-1.7.2-1.el6.noarch.rpm
mcollective-puppet-client-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-client-1.7.2-1.el6.noarch.rpm
mcollective-puppet-common-1.7.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-puppet-common-1.7.2-1.el6.noarch.rpm
mcollective-service-agent-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-agent-3.1.2-1.noarch.rpm
mcollective-service-client-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-client-3.1.2-1.noarch.rpm
mcollective-service-common-3.1.2-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-service-common-3.1.2-1.noarch.rpm
mcollective-sysctl-data-2.0.0-1.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/mcollective-sysctl-data-2.0.0-1.noarch.rpm
mrepo-0.8.7-2.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/mrepo-0.8.7-2.el6.noarch.rpm
mysql-connector-python-1.1.6-1.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/mysql-connector-python-1.1.6-1.el6.noarch.rpm
nscd-2.12-1.166.el6_7.1.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/nscd-2.12-1.166.el6_7.1.x86_64.rpm
nspr-4.10.8-1.el6_6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/nspr-4.10.8-1.el6_6.x86_64.rpm
nss-3.19.1-3.el6_6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/nss-3.19.1-3.el6_6.x86_64.rpm
nss-softokn-3.14.3-22.el6_6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/nss-softokn-3.14.3-22.el6_6.x86_64.rpm
nss-softokn-freebl-3.14.3-22.el6_6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/nss-softokn-freebl-3.14.3-22.el6_6.x86_64.rpm
nss-sysinit-3.19.1-3.el6_6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/nss-sysinit-3.19.1-3.el6_6.x86_64.rpm
nss-tools-3.19.1-3.el6_6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/nss-tools-3.19.1-3.el6_6.x86_64.rpm
nss-util-3.19.1-1.el6_6.x86_64.rpm http://mirror.cs.vt.edu/pub/CentOS/6.7/updates/x86_64/Packages/nss-util-3.19.1-1.el6_6.x86_64.rpm
openssl-1.0.1e-42.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/openssl-1.0.1e-42.el6.x86_64.rpm
openssl-devel-1.0.1e-42.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/openssl-devel-1.0.1e-42.el6.x86_64.rpm
pdsh-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-2.28-0.x86_64.rpm
pdsh-mod-dshgroup-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-dshgroup-2.28-0.x86_64.rpm
pdsh-mod-machines-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-machines-2.28-0.x86_64.rpm
pdsh-mod-netgroup-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-mod-netgroup-2.28-0.x86_64.rpm
pdsh-rcmd-exec-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-rcmd-exec-2.28-0.x86_64.rpm
pdsh-rcmd-ssh-2.28-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/pdsh-rcmd-ssh-2.28-0.x86_64.rpm
perl-Archive-Zip-1.30-2.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/perl-Archive-Zip-1.30-2.el6.noarch.rpm
perl-Crypt-DES-2.05-9.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Crypt-DES-2.05-9.el6.x86_64.rpm
perl-DateTime-Format-DateParse-0.05-4.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-DateTime-Format-DateParse-0.05-4.el6.noarch.rpm
perl-DateTime-Format-Mail-0.3001-6.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/perl-DateTime-Format-Mail-0.3001-6.el6.noarch.rpm
perl-DateTime-Format-W3CDTF-0.04-8.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/perl-DateTime-Format-W3CDTF-0.04-8.el6.noarch.rpm
perl-File-RsyncP-0.72-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-File-RsyncP-0.72-1.el6.x86_64.rpm
perl-Math-Calc-Units-1.07-6.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Math-Calc-Units-1.07-6.el6.noarch.rpm
perl-Net-FTP-AutoReconnect-0.3-3.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Net-FTP-AutoReconnect-0.3-3.el6.noarch.rpm
perl-Net-FTP-RetrHandle-0.2-3.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Net-FTP-RetrHandle-0.2-3.el6.noarch.rpm
perl-Net-SNMP-5.2.0-4.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Net-SNMP-5.2.0-4.el6.noarch.rpm
perl-Sort-Versions-1.5-12.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/perl-Sort-Versions-1.5-12.el6.noarch.rpm
perl-Time-modules-2006.0814-5.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/perl-Time-modules-2006.0814-5.el6.noarch.rpm
perl-XML-RSS-1.45-2.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/perl-XML-RSS-1.45-2.el6.noarch.rpm
pssh-2.3.1-5.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/pssh-2.3.1-5.el6.noarch.rpm
puppet-3.7.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-3.7.4-1.el6.noarch.rpm
puppet-dashboard-1.2.23-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-dashboard-1.2.23-1.el6.noarch.rpm
puppet-server-3.7.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppet-server-3.7.4-1.el6.noarch.rpm
puppetdb-2.3.8-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetdb-2.3.8-1.el6.noarch.rpm
puppetdb-terminus-2.3.8-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetdb-terminus-2.3.8-1.el6.noarch.rpm
puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/puppetlabs-stdlib-4.5.1-2.20150121git7a91f20.el6.noarch.rpm
puppetserver-1.1.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/puppetserver-1.1.1-1.el6.noarch.rpm
python-argparse-1.2.1-2.1.el6.noarch.rpm http://mirror.5ninesolutions.com/centos/6.7/os/x86_64/Packages/python-argparse-1.2.1-2.1.el6.noarch.rpm
python-backports-1.0-3.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-backports-1.0-3.el6.x86_64.rpm
python-backports-ssl_match_hostname-3.4.0.2-2.el6.noarch.rpm http://mirror.5ninesolutions.com/centos/6.7/os/x86_64/Packages/python-backports-ssl_match_hostname-3.4.0.2-2.el6.noarch.rpm
python-elasticsearch-1.2.0-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/python-elasticsearch-1.2.0-0.el6.noarch.rpm
python-importlib-1.0.2-1.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-importlib-1.0.2-1.el6.noarch.rpm
python-ordereddict-1.1-2.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-ordereddict-1.1-2.el6.noarch.rpm
python-pyes-0.20.1-0.el6.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/python-pyes-0.20.1-0.el6.noarch.rpm
python-pyro-4.14-2.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-pyro-4.14-2.el6.noarch.rpm
python-redis-2.0.0-1.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-redis-2.0.0-1.el6.noarch.rpm
python-six-1.9.0-2.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/python-six-1.9.0-2.el6.noarch.rpm
python-unittest2-0.5.1-3.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/python-unittest2-0.5.1-3.el6.noarch.rpm
python-urllib3-1.10.2-1.el6.noarch.rpm http://mirrors.tripadvisor.com/centos/6.7/os/x86_64/Packages/python-urllib3-1.10.2-1.el6.noarch.rpm
qstat-2.11-9.20080912svn311.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/qstat-2.11-9.20080912svn311.el6.x86_64.rpm
radiusclient-ng-0.5.6-5.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/radiusclient-ng-0.5.6-5.el6.x86_64.rpm
razor-server-0.14.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/razor-server-0.14.1-1.el6.noarch.rpm
razor-torquebox-3.0.1-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/products/x86_64/razor-torquebox-3.0.1-1.el6.noarch.rpm
rlwrap-0.37-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rlwrap-0.37-3.el6.x86_64.rpm
rrdtool-1.4.4-0.20.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/rrdtool-1.4.4-0.20.el6.x86_64.rpm
ruby-augeas-0.4.1-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-augeas-0.4.1-3.el6.x86_64.rpm
ruby-json-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-json-1.5.5-3.el6.x86_64.rpm
ruby-ldap-0.9.7-10.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ruby-ldap-0.9.7-10.el6.x86_64.rpm
ruby-mysql-2.8.2-1.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/ruby-mysql-2.8.2-1.el6.x86_64.rpm
ruby-rgen-0.6.5-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-rgen-0.6.5-2.el6.noarch.rpm
ruby-shadow-2.2.0-2.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/ruby-shadow-2.2.0-2.el6.x86_64.rpm
rubygem-activerecord-2.3.16-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-activerecord-2.3.16-1.el6.noarch.rpm
rubygem-activesupport-2.3.16-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-activesupport-2.3.16-1.el6.noarch.rpm
rubygem-deep_merge-1.0.0-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-deep_merge-1.0.0-2.el6.noarch.rpm
rubygem-fastthread-1.0.7-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-fastthread-1.0.7-1.el6.x86_64.rpm
rubygem-ffi-1.4.0-2.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-ffi-1.4.0-2.el6.x86_64.rpm
rubygem-highline-1.6.11-1.noarch.rpm https://dl.bintray.com/simp/4.2.X-Ext/rubygem-highline-1.6.11-1.noarch.rpm
rubygem-hpricot-0.8.6-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-hpricot-0.8.6-1.el6.x86_64.rpm
rubygem-json-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-json-1.5.5-3.el6.x86_64.rpm
rubygem-json-doc-1.5.5-3.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-json-doc-1.5.5-3.el6.x86_64.rpm
rubygem-mustache-0.99.4-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-mustache-0.99.4-1.el6.noarch.rpm
rubygem-net-ldap-0.2.2-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ldap-0.2.2-4.el6.noarch.rpm
rubygem-net-ldap-doc-0.2.2-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ldap-doc-0.2.2-4.el6.noarch.rpm
rubygem-net-ping-1.6.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ping-1.6.2-1.el6.noarch.rpm
rubygem-net-ping-doc-1.5.3-4.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-net-ping-doc-1.5.3-4.el6.noarch.rpm
rubygem-puppet-lint-1.1.0-1.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/rubygem-puppet-lint-1.1.0-1.el6.noarch.rpm
rubygem-rack-1.0.1-2.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-rack-1.0.1-2.el6.noarch.rpm
rubygem-rake-0.8.7-2.1.el6.noarch.rpm http://mirror.netdepot.com/centos/6.7/os/x86_64/Packages/rubygem-rake-0.8.7-2.1.el6.noarch.rpm
rubygem-rake-compiler-0.9.3-2.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/rubygem-rake-compiler-0.9.3-2.el6.noarch.rpm
rubygem-rake-compiler-doc-0.9.3-2.el6.noarch.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/rubygem-rake-compiler-doc-0.9.3-2.el6.noarch.rpm
rubygem-rdiscount-1.6.8-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-rdiscount-1.6.8-1.el6.x86_64.rpm
rubygem-ronn-0.7.3-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-ronn-0.7.3-1.el6.noarch.rpm
rubygem-stomp-1.3.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-stomp-1.3.2-1.el6.noarch.rpm
rubygem-stomp-doc-1.3.2-1.el6.noarch.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/rubygem-stomp-doc-1.3.2-1.el6.noarch.rpm
scap-security-guide-0.1.21-3.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/scap-security-guide-0.1.21-3.el6.noarch.rpm
sendmail-milter-8.14.4-9.el6.x86_64.rpm http://mirror.netdepot.com/centos/6.7/os/x86_64/Packages/sendmail-milter-8.14.4-9.el6.x86_64.rpm
simp-lastbind-2.4.23-0.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/simp-lastbind-2.4.23-0.x86_64.rpm
simp-ppolicy-check-password-2.4.39-0.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/simp-ppolicy-check-password-2.4.39-0.el6.x86_64.rpm
sudosh2-1.0.2-2.el6.x86_64.rpm https://dl.bintray.com/simp/4.2.X-Ext/sudosh2-1.0.2-2.el6.x86_64.rpm
syslinux-tftpboot-4.04-3.el6.noarch.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/syslinux-tftpboot-4.04-3.el6.noarch.rpm
tanukiwrapper-3.5.9-1.el6.x86_64.rpm http://yum.puppetlabs.com/el/6/dependencies/x86_64/tanukiwrapper-3.5.9-1.el6.x86_64.rpm
trousers-0.3.13-2.el6.x86_64.rpm http://mirror.ash.fastserv.com/pub/linux/centos/6.7/os/x86_64/Packages/trousers-0.3.13-2.el6.x86_64.rpm
voms-2.0.12-3.el6.x86_64.rpm http://mirror.cogentco.com/pub/linux/epel/6/x86_64/voms-2.0.12-3.el6.x86_64.rpm

SIMP SCTM

This SCTM was developed based on the National Institute of Standards and Technology (NIST) Specical Publication 800-53 (Revision 3) controls that SIMP currently meets. Empty contents means SIMP does not meet that control. Implementations are free to take these tables and use them as a starting point for any accreditation activities that follow NIST 800-53.

SIMP SCTM Technical Controls
Control ID Control Name Control Family SIMP Implementation Method
AC-1 Access Control Policy and Procedures Access Control  
AC-2(1) Account Management (Control Enhancement) Access Control LDAP is used to centrally manage accounts. Local accounts can optionally be added and managed by puppet.
AC-2(2) Account Management (Control Enhancement) Access Control  
AC-2(3) Account Management (Control Enhancement) Access Control Inactive local accounts expire 35 days after password expiration. LDAP accounts can be set to expire in LDAP and using PAM. There is no automated method (included with SIMP) to check inactive LDAP accounts. Implementations should address inactive LDAP accounts with automated or administrative measures.
AC-2(4) Account Management (Control Enhancement) Access Control Local account creation is audited with auditd. (as are all of root’s actions). Sudosh logs all commands for someone running sudosh. This will not work if the SIMP implementation uses specific sudo rules. Instead, sudo actions are logged using auditd. Ldap modifications are logged in the ldap logs.
AC-2(5) Account Management (Control Enhancement) Access Control Shell accounts are logged out after 15 minutes of inactivity
AC-2(6) Account Management (Control Enhancement) Access Control  
AC-2(7) Account Management (Control Enhancement) Access Control SIMP has a default administrators group (700) that users can be assigned to. Additional roles and groups are up to the implementations. Role changes are logged in the LDAP logs.
AC-3 Access Enforcement Access Control  
AC-3(2) Access Enforcement (Control Enhancement) Access Control  
AC-3(3) Access Enforcement (Control Enhancement) Access Control DAC has been built into Unix for a long time and is expected to work. Implementations may want to check that user assignments to groups properly enforce DAC they way they expect. New as of SIMP 5.0 is the use of MAC. All stock SIMP modules work with MAC enabled. It’s up to each implementation to ensure their applications and modules are made to work with MAC enabled.
AC-3(4) Access Enforcement (Control Enhancement) Access Control DAC has been built into Unix for a long time and is expected to work. Implements may want to check that user assignments to groups properly enforce DAC they way they expect.
AC-3(5) Access Enforcement (Control Enhancement) Access Control SIMP implements file permissions per the SCAP-Security-Guide (SSG) RHEL7 guidance. There are some exceptions of file permissions being more or less restrictive than the guide. Mitigations and responses to those variances will be published once final RHEL7 SCAP content is available.
AC-3(6) Access Enforcement (Control Enhancement) Access Control  
AC-4(1) Information Flow Enforcement (Control Enhancement) Access Control IPTables enforces flow control to the puppet master and clients. The default rules allow the services needed for kick start and puppet (and SSH of course). IPTables is managed by puppet so that any user modifications to /etc/sysconfig/iptables is rewritten with the rules from the manifest. The rules can and should be tailored per implementation.
AC-4(2) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(3) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(4) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(5) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(6) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(7) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(8) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(9) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(10) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(11) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(12) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(13) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(14) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(15) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(16) Information Flow Enforcement (Control Enhancement) Access Control  
AC-4(17) Information Flow Enforcement (Control Enhancement) Access Control  
AC-5 Separation of Duties Access Control  
AC-6 Least Privilege Access Control SIMP was built using a minimalist approach. Only the services, applications (RPMs and their dependencies), and network rules that are needed are implemented. Adding additional services, users, or software are done using built in RedHat/CentOS features or puppet. For example, services cannot be manually added without first registering them with puppet.
AC-6(1) Least Privilege (Control Enhancement) Access Control File permissions and administrative functions are denied to users who are not administrators using Unix DAC. Roles can be defined by a implementation. Typically it’s done using ldap groups and sudosh. Suoders rules can be set for roles that need a limited set of commands/functions.
AC-6(2) Least Privilege (Control Enhancement) Access Control Direct remote root login is not allowed on SIMP. Users must assume their role first (defined in LDAP or locally). There is a local simp user on the puppet master that has a password assigned. That allows for emergency maintenance via SSH. Single user mode is password protected, but will allow direct access before escalation. Protection of the single user mode and simp user’s password is up to the implementation. Privilege escalation is performed using sudosh or sudo. Most implementations will use sudosh for global admins and sudo for roles that need minimal admin ability. Lastly, serial port access is does allow direct root login (/etc/securetty). Implementations may further restrict this at the risk.
AC-6(3) Least Privilege (Control Enhancement) Access Control  
AC-6(4) Least Privilege (Control Enhancement) Access Control  
AC-6(5) Least Privilege (Control Enhancement) Access Control  
AC-6(6) Least Privilege (Control Enhancement) Access Control  
AC-7 Unsuccessful Login Attempts Access Control SIMP locks accounts after 5 invalid attempts over 15 minutes span. It then keeps the account locked for 15 minutes. After that, the account is unlocked automatically.
AC-7(1) Unsuccessful Login Attempts (Control Enhancement) Access Control An account is never locked to a point an admin must unlock it. It will continue to be unlocked after 15 minutes. This should meet most modern policies. It can be further restricted if required by local policies.
AC-7(2) Unsuccessful Login Attempts (Control Enhancement) Access Control  
AC-8 System Use Notification Access Control SIMP displays a default banner prior to login. Implementations must customize that banner for their use.
AC-9 Previous Logon (Access) Notification Access Control SIMP uses the pam_lastlog.so module to display last login information.
AC-9(1) Previous Logon (Access) Notification (Control Enhancement) Access Control SIMP uses the pam_lastlog.so module to display last login information.
AC-9(2) Previous Logon (Access) Notification (Control Enhancement) Access Control SIMP uses the pam_lastlog.so module to display last login information, including the number of failed login attempts since the last logon.
AC-9(3) Previous Logon (Access) Notification (Control Enhancement) Access Control  
AC-10 Concurrent Session Control Access Control The default value for concurrent sessions in SIMP is 10 (/etc/security/limits.conf). Given the variety of system usage to include automated processes, it could impact functionality if this value were set lower. It can be tailored to a lower value if the implementation determines that number will not impact functionality.
AC-11 Session Lock Access Control Terminal sessions do not enforce a session lock so this control is technically not implemented. However, it’s mitigated by forcing inactive sessions to log out. If the gnome module is applied, SIMP locks a gnome session after 5 minutes.
AC-14 Permitted Actions without Identification or Authentication Access Control SIMP provides several services that do not require authentication. Most require some form of identification. These are documented in the SIMP Security Concepts and is kept current for that version. Individual modules are not yet documented.
AC-14(1) Permitted Actions without Identification or Authentication (Control Enhancement) Access Control Justifications to those services that do not require Identification and Authentication can be found in the SIMP Security Concepts document.
AC-16 Security Attributes Access Control New in SIMP 5.0 is the usage of MAC via SELinux. This is optional for each implementation and can be turned off at any time. All of the stock SIMP modules work with SELinux enabled and have the least restrictive MAC policies enforced. These policies assign each object a SELinux user, role, type, and level. These characteristics are used to define a context for each object.
AC-16(1) Security Attributes (Control Enhancement) Access Control  
AC-16(2) Security Attributes (Control Enhancement) Access Control  
AC-16(3) Security Attributes (Control Enhancement) Access Control  
AC-16(4) Security Attributes (Control Enhancement) Access Control SeLinux user, role, type, and level are the security attributes that are associated with each object with SELinux enabled in SIMP.
AC-16(5) Security Attributes (Control Enhancement) Access Control  
AC-17 Remote Access   By default, external connections are not allowed with the exception of SSH. This is documented in the SIMP user manual. Implementations have the ability to override this with the understanding that puppet controls Iptables.
AC-17(1) Remote Access (Control Enhancement) Access Control The extent of monitoring remote connections is done by auditd and syslog. The contents of the remote session is not logged. The keystrokes of users with sudosh shells are all logged.
AC-17(2) Remote Access (Control Enhancement) Access Control Remote access is limited to SSH. SSH (openssh on centos/rhel) provides both confidentiality and integrity of the remote session.
AC-17(3) Remote Access (Control Enhancement) Access Control  
AC-17(4) Remote Access (Control Enhancement) Access Control This control is enforced via other access control mechanisms already covered in 800-53. Namely, AC-6. By default, SSH in SIMP will allow anyone to connect. Once identification and authentication is performed, access control to privileged commands is enforced as usual.
AC-17(5) Remote Access (Control Enhancement) Access Control Auditd provides logging of failed access attempts. It’s up to the implementation to perform a level of inspection of these unauthorized events. Auditd does this by default. Other checks will ensure auditd is running and registered with puppet.
AC-17(6) Remote Access (Control Enhancement) Access Control  
AC-17(7) Remote Access (Control Enhancement) Access Control  
AC-17(8) Remote Access (Control Enhancement) Access Control This control is only met by defining all connections that SIMP allows internally and externally. For now, since this is a remote access control, it should suffice to continue to note that the only remote access protocol allowed by default is SSH.
AC-18 Wireless Access Access Control  
AC-18(1) Wireless Access (Control Enhancement) Access Control  
AC-18(2) Wireless Access (Control Enhancement) Access Control  
AC-18(3) Wireless Access (Control Enhancement) Access Control  
AC-18(4) Wireless Access (Control Enhancement) Access Control  
AC-18(5) Wireless Access (Control Enhancement) Access Control  
AC-19 Access Control for Mobile Devices Access Control  
AC-19(1) Access Control for Mobile Devices (Control Enhancement) Access Control  
AC-19(2) Access Control for Mobile Devices (Control Enhancement) Access Control  
AC-19(3) Access Control for Mobile Devices (Control Enhancement) Access Control  
AC-19(4) Access Control for Mobile Devices (Control Enhancement) Access Control  
AC-20 Use of External Information Systems Access Control  
AC-20(1) Use of External Information Systems (Control Enhancement) Access Control  
AC-20(2) Use of External Information Systems (Control Enhancement) Access Control  
AC-21 User-Based Collaboration and Information Sharing Access Control  
AC-21(1) User-Based Collaboration and Information Sharing (Control Enhancement) Access Control  
AC-22 Publicly Accessible Content Access Control  
AU-1 Audit and Accountability Policy and Procedures Audit and Accountability  
AU-2 Auditable Events Audit and Accountability
  1. SIMP audit rules were built by using idustry best practices gathered over the years. The heaviest reliance has been on the SCAP-Security Guide (SSG). SIMP aims for a balance between performance and operational needs so the settings are rarely an exact match from these guides. The list of events that audited are by auditd can be found in appendix of the Security Concepts document. b. Implementation Specific c. Rational is for audit setting is provided in SSG. d. Threat information is specific to the implementation. Auditd and syslog facility can always be fine tuned for each implementation.
AU-2(3) Auditable Events (Control Enhancement) Audit and Accountability SIMP is constantly reviewing the audit rules for accuracy, relevance, and performance. Rules are added and in some cases removed as information becomes available.
AU-2(4) Auditable Events (Control Enhancement) Audit and Accountability Privileged user commands are logged using sudosh and auditd (sudo actions). By default, users in the administrators group can run sudosh. All of the key strokes (except things that are not echoed back to the screen like passwords) are logged to /var/log/sudosh.log and can be sent to syslog. If an implementation sets up specific sudo actions for other groups or users, those actions are logged with auditd.
AU-3 Content of Audit Records Audit and Accountability The linux audit daemon contains event type, date/time, host, and outcome of events by default.
AU-3(1) Content of Audit Records (Control Enhancement) Audit and Accountability There are a number of events that are captured beyond the auditd. The SIMP syslog module captures additional log events from apache, ldap, puppet, messages.log, and secure.log.
AU-3(2) Content of Audit Records (Control Enhancement) Audit and Accountability By default, the SIMP syslog module logs locally. There is an option to send the syslog events to a central location. Instructions for implementing a syslog server are provided in the User Guide. Lastly, a combination of elasticsearch, logstash, and kibana (ELK) can be applied to filter, index, and search logs. Puppet modules are provided for the ELK stack
AU-4 Audit Storage Capacity Audit and Accountability The audit partition is configured as a separation partition from the system files, reducing the likelihood of audit interfering with system operations. Implementaions can change this but it’s highly discouraged.
AU-5 Response to Audit Processing Failures Audit and Accountability
  1. Implementation Specific. b. The audit.conf file configures the system to log to syslog when disk space becomes low. If the disk becomes full, the audit daemon will be suspended, but the system will remain active. This is contrary to some industry guidance to put the system into single user mode when disk space becomes an issue. Implementations may wish to change the default behaviour at the risk of stopping the system from functioning.
AU-5(1) Response to Audit Processing Failures (Control Enhancement) Audit and Accountability SIMP provides a warning (to syslog) when the disk has 75MB free. Each log file can be up to 30MB.
AU-5(2) Response to Audit Processing Failures (Control Enhancement) Audit and Accountability  
AU-5(3) Response to Audit Processing Failures (Control Enhancement) Audit and Accountability  
AU-5(4) Response to Audit Processing Failures (Control Enhancement) Audit and Accountability SIMP will not shut down a system by default. Implementation can configure this option at the own risk in the auditd.conf file.
AU-6 Audit Review, Analysis, and Reporting Audit and Accountability  
AU-6(1) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability  
AU-6(3) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability The ELK modules provide implementations with one means to centralize, review, and recognize trends in SIMP logs.
AU-6(4) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability The ELK modules provide implementations with one means to centralize, review, and recognize trends in SIMP logs.
AU-6(5) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability The ELK modules provide implementations with one means to centralize, review, and recognize trends in SIMP logs. The logs sent to syslog can be customized to include logs from any application. They would then be in a central place for viewing and aggregation by users of the Kibana interface.
AU-6(6) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability  
AU-6(7) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability  
AU-6(9) Audit Review, Analysis, and Reporting (Control Enhancement) Audit and Accountability  
AU-7 Audit Reduction and Report Generation Audit and Accountability  
AU-7(1) Audit Reduction and Report Generation (Control Enhancement) Audit and Accountability While not true audit reduction, RedHat does allow someone with access to audit logs to perform filters using the journald. If audit logs are forwarded to a syslog server, it’s not difficult for an admin to security officer to run batch filters against all of the audit records. As of SIMP 4.0.5, an optional Logstash, Kibana, and Elasticsearch modules can be applied. If applied, they provide centralized and indexed logs. An implementation can then perform searches against the logs or provide alerts to other parts of their infrastructure.
AU-8 Time Stamps Audit and Accountability Auditd uses the system clock to time stamp audit events.
AU-8(1) Time Stamps (Control Enhancement) Audit and Accountability Time is an essential component of puppet. Therefore, NTPD is used to synchronize puppet clients with the puppet server. That default configuration can be changed to synchronize puppet each server/client with another time source.
AU-9 Protection of Audit Information Audit and Accountability File system permissions and SELinux protect the content of /var/log/audit and /etc/audit/*
AU-9(1) Protection of Audit Information (Control Enhancement) Audit and Accountability  
AU-9(2) Protection of Audit Information (Control Enhancement) Audit and Accountability  
AU-9(3) Protection of Audit Information (Control Enhancement) Audit and Accountability  
AU-9(4) Protection of Audit Information (Control Enhancement) Audit and Accountability  
AU-10 Non-repudiation Audit and Accountability  
AU-10(1) Non-repudiation (Control Enhancement) Audit and Accountability  
AU-10(2) Non-repudiation (Control Enhancement) Audit and Accountability  
AU-10(3) Non-repudiation (Control Enhancement) Audit and Accountability  
AU-10(4) Non-repudiation (Control Enhancement) Audit and Accountability  
AU-10(5) Non-repudiation (Control Enhancement) Audit and Accountability  
AU-12(1) Audit Generation (Control Enhancement) Audit and Accountability  
AU-11 Audit Record Retention Audit and Accountability  
AU-12 Audit Generation Audit and Accountability
  1. Auditd provides the audit generation capability and is running on all SIMP systems by default.b. The audit.rules files configures events that are audited. c. The audit.rules applies the list of audit rules defined in SIMP Security Concepts document.
AU-12(1) Audit Generation (Control Enhancement) Audit and Accountability Auditd stamps audit records with the system time. The system time is obtained from a central time source and synchronized between SIMP systems.
AU-12(2) Audit Generation (Control Enhancement) Audit and Accountability Auditd provides logging in standard formats. Additionally, logs that are sent through syslog adhere to that standard.
AU-13 Monitoring For Information Disclosure Audit and Accountability  
AU-14 Session Audit Audit and Accountability  
AU-14(1) Session Audit (Control Enhancement) Audit and Accountability Sessions that use the sudo shell have all keystrokes recorded. Those sessions can be viewed in text format or replayed to the screen
IA-1 Identification and Authentication Policy and Procedures Identification and Authentication  
IA-2(1) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(2) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(3) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(4) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(5) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(6) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(7) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication  
IA-2(8) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication The authentication mechanisms used within SIMP are all resistant to replay attacks by default. Known vulnerabilities can occur in the protocols. As they are known, vendors release patches, which must them be applied by the implementation. Privileged accounts use the same protocols as unprivileged accounts.
IA-2(9) User Identification and Authentication (Organizational Users) (Control Enhancement) Identification and Authentication The authentication mechanisms used within SIMP are all resistant to replay attacks by default. Known vulnerabilities can occur in the protocols. As they are known, vendors release patches, which must them be applied by the implementation.
IA-3 Device Identification and Authentication Identification and Authentication Identification of each puppet client occurs before an IP address can be assigned. This is controlled using DHCP (each client must have an address bound by MAC address). Devices identification and authentication with puppet occurs using SSL certificates. The clients must each have a SSL certificate installed to establish a valid session with the puppet master.
IA-3(1) Device Identification and Authentication (Control Enhancement) Identification and Authentication  
IA-3(2) Device Identification and Authentication (Control Enhancement) Identification and Authentication  
IA-3(3) Device Identification and Authentication (Control Enhancement) Identification and Authentication DHCP is used to statically define the IP addresses of each puppet client.
IA-4 Identifier Management Identification and Authentication Local accounts expire 35 days after their passwords expire. There is no mechanism implemented to detect inactive LDAP accounts. Implementations might wish to mitigate this by regularly reviewing and removing unneeded accounts.
IA-4(1) Identifier Management (Control Enhancement) Identification and Authentication  
IA-4(2) Identifier Management (Control Enhancement) Identification and Authentication  
IA-4(3) Identifier Management (Control Enhancement) Identification and Authentication  
IA-4(4) Identifier Management (Control Enhancement) Identification and Authentication  
IA-4(5) Identifier Management (Control Enhancement) Identification and Authentication  
IA-5 Authenticator Management Identification and Authentication
  1. Authenticator strength is enforced using pam_crack_lib.so. This works for user defined passwords on local and LDAP accounts. E. It’s up to the implementation to change the values for the various passwords. F. Password history is set to 24 by default in SIMP and enforced with pam.G. For local accounts, password aging is set to 180 days. It’s set to the same in LDAP, but enforced at the time of account creation using ldifs. LDAP subsequently uses PAM to enforce the aging. Key based passwordless logins do not enforce aging. Upon generation, server and puppet certificates can also be set to expire.H. Authenticators for local and LDAP account are protected using operating system access controls. The server certificates are also protected using operating system controls.
IA-5(1) Authenticator Management (Control Enhancement) Identification and Authentication
  1. Authenticator strength is enforced using pam_crack_lib.so. This works for user defined passwords on local and LDAP accounts. Administrators can bypass PAM and set weak passwords in LDAP. Under normal circumstances, users would be forced to change their password at login, at which point pam enforced complexity. b. Not enforced c. Hashed passwords are built into linux (/etc/shadow and /etc/pam.d/system-auth pam_unix.so). LDAP password changed by users are done through pam before getting placed in LDAP. Manual LDAP password are created using the slapasswd command.d. Password minimum and maximum lifetimes are enforced through /etc/login.defs and ldap. e. By default, the previous 24 passwords can not be reused.
IA-5(2) Authenticator Management (Control Enhancement) Identification and Authentication Puppet comes with a self contained public key infrastructure. Though just used for puppet, it operates as a full PKI. So the certificate path is validated.SSL certificates that are used for SSL and TLS also have certificate path validation built into the protocol.Note: SSH Keys are not considered PKI.
IA-5(3) Authenticator Management (Control Enhancement) Identification and Authentication  
IA-5(4) Authenticator Management (Control Enhancement) Identification and Authentication Pam cracklib enforces password complexity rules on Redhat and CentOS. Additional tools to check authenticator strength can be used in operational settings.
IA-5(5) Authenticator Management (Control Enhancement) Identification and Authentication The simp-config utility gives each implementation an opportunity to change default passwords at build time. It’s up to the implementation to change the values for the various passwords.
IA-5(6) Authenticator Management (Control Enhancement) Identification and Authentication Authenticators are protected with operating system access control and file permissions.
IA-5(7) Authenticator Management (Control Enhancement) Identification and Authentication Plaintext passwords are only used when application support no other means of providing a password.
IA-5(8) Authenticator Management (Control Enhancement) Identification and Authentication  
IA-6 Authenticator Feedback Identification and Authentication Plaintext passwords are not echoed back to the screen.
IA-7 Cryptographic Module Authentication Identification and Authentication Redhat 7 and the several modules are being evaluated for FIPS 140 compliance. Implementations should check the FIPS site for updates on this evaluation. The SIMP team will also continue to evaluate the status and any relevant settings that need to be applied as a result of this evaluation.
IA-8 Identification and Authentication (Non-Organizational Users) Identification and Authentication  
SC-1 System and Communications Protection Policy and Procedures System and Communications Protection  
SC-2 Application Partitioning System and Communications Protection The spirit of this control is providing logical separation so that users are not able to access administrative functions. There is no notion of partitioning within SIMP. There are access control enforcement that can be proven through tests on those controls. If this control is allocated to SIMP alone, it’s unlikely it can be met. Since SIMP is the infrastructure that applications would use, showing that application users cannot access the SIMP environment is a better way to prove this control is met.
SC-2(1) Application Partitioning (Control Enhancement) System and Communications Protection The spirit of this control is providing logical separation so that users are not able to access administrative functions. There is no notion of partitioning within SIMP. There are access control enforcement that can be proven through tests on those controls. If this control is allocated to SIMP alone, it’s unlikely it can be met. Since SIMP is the infrastructure that applications would use, showing that application users cannot access the SIMP environment is a better way to prove this control is met.
SC-3 Security Function Isolation System and Communications Protection The spirit of this control is providing logical separation so that users are not able to access administrative functions. There is no notion of partitioning within SIMP. There are access control enforcement that can be proven through tests on those controls. If this control is allocated to SIMP alone, it’s unlikely it can be met. Since SIMP is the infrastructure that applications would use, showing that application users cannot access the SIMP environment is a better way to prove this control is met.
SC-3(1) Security Function Isolation (Control Enhancement) System and Communications Protection  
SC-3(2) Security Function Isolation (Control Enhancement) System and Communications Protection  
SC-3(3) Security Function Isolation (Control Enhancement) System and Communications Protection  
SC-3(4) Security Function Isolation (Control Enhancement) System and Communications Protection  
SC-3(5) Security Function Isolation (Control Enhancement) System and Communications Protection  
SC-4 Information In Shared Resources System and Communications Protection While difficult for the SIMP team to prove, object reuse has been part of previous versions of RedHat common criteria testing. That testing focusing on Files system objects, IPC objects and Memory objects. Any issues discovered within the platform that cause object reuse issues are likely to be address in security patches provided by the vendor.
SC-4(1) Information In Shared Resources (Control Enhancement) System and Communications Protection  
SC-5 Denial of Service Protection System and Communications Protection  
SC-5(1) Denial of Service Protection (Control Enhancement) System and Communications Protection  
SC-5(2) Denial of Service Protection (Control Enhancement) System and Communications Protection  
SC-6 Resource Priority System and Communications Protection  
SC-7 Boundary Protection System and Communications Protection Most of this control deals with a separate boundary interface (FW etc.). There is a part of this control that deals with controlling network access at key internal boundary points. Since SIMP implements IPTables on all hosts (by default), each node might be considered an internal boundary. Note – internal boundaries are more likely implemented via vlans or internal layer 3 devices.
SC-7(1) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(2) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(3) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(4) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(5) Boundary Protection (Control Enhancement) System and Communications Protection Iptables, as configured by default, blocks all incoming traffic except for what is explicitly allowed.
SC-7(6) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(7) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(8) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(9) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(10) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(11) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(12) Boundary Protection (Control Enhancement) System and Communications Protection IPTables is the host based firewall implementation on RedHat/CentOS.
SC-7(13) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(14) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(15) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(16) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(17) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-7(18) Boundary Protection (Control Enhancement) System and Communications Protection  
SC-8 Transmission Integrity System and Communications Protection With the exception of the services needed for kickstart, most communications within SIMP are protected by SSH or SSL. Implementations can add additional services or modules that do not use SSH or SSL. The SIMP Security Concepts document details the default allowed protocols and the mechanisms in place to protect them. It’s also worth noting that the SIMP team has taken ever measure possible to remove encryption ciphers available to operating system applications. In the event this breaks an application, implementations might have to add those ciphers back.
SC-8(1) Transmission Integrity (Control Enhancement) System and Communications Protection With the exception of the services needed for kickstart, most communications within SIMP are protected by SSH or SSL. Implementations can add additional services or modules that do not use SSH or SSL. The SIMP Security Concepts document details the default allowed protocols and the mechanisms in place to protect them. It’s also worth noting that the SIMP team has taken ever measure possible to remove encryption ciphers available to operating system applications. In the event this breaks an application, implementations might have to add those ciphers back.
SC-8(2) Transmission Integrity (Control Enhancement) System and Communications Protection  
SC-9 Transmission Confidentiality System and Communications Protection With the exception of the services needed for kickstart, most communications within SIMP are protected by SSH or SSL. Implementations can add additional services or modules that do not use SSH or SSL. The SIMP Security Concepts document details the default allowed protocols and the mechanisms in place to protect them. It’s also worth noting that the SIMP team has taken ever measure possible to remove encryption ciphers available to operating system applications. In the event this breaks an application, implementations might have to add those ciphers back.
SC-9(1) Transmission Confidentiality (Control Enhancement) System and Communications Protection With the exception of the services needed for kickstart, most communications within SIMP are protected by SSH or SSL. Implementations can add additional services or modules that do not use SSH or SSL. The SIMP Security Concepts document details the default allowed protocols and the mechanisms in place to protect them. It’s also worth noting that the SIMP team has taken ever measure possible to remove encryption ciphers available to operating system applications. In the event this breaks an application, implementations might have to add those ciphers back.
SC-9(2) Transmission Confidentiality (Control Enhancement) System and Communications Protection  
SC-10 Network Disconnect System and Communications Protection  
SC-11 Trusted Path System and Communications Protection  
SC-12 Cryptographic Key Establishment and Management System and Communications Protection In an operational setting, SIMP does not establish keys. It does come with the ability to create server keys using a custom application know as “FakeCA”. SSH keys can also be established using standard Unix command line tools. In an operational settings, both sets of keys should be obtained from valid key infrastructures. There is also a CA that puppet uses to generate and manage keys for puppet only.
SC-12(1) Cryptographic Key Establishment and Management (Control Enhancement) System and Communications Protection  
SC-12(2) Cryptographic Key Establishment and Management (Control Enhancement) System and Communications Protection  
SC-12(3) Cryptographic Key Establishment and Management (Control Enhancement) System and Communications Protection  
SC-12(4) Cryptographic Key Establishment and Management (Control Enhancement) System and Communications Protection  
SC-12(5) Cryptographic Key Establishment and Management (Control Enhancement) System and Communications Protection  
SC-13 Use of Cryptography   The forms of cryptography used are applied through SSH, SSL, and TLS. RedHat FIPs mode enabling is on the near term horizon for SIMP. Once enabled, it will be documented here and should allow implemtations to further explain how this control is being met. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS). The Security Concepts docucment provides additional details on default services/protocols that are used.
SC-13(1) Use of Cryptography (Control Enhancement)   The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-13(2) Use of Cryptography (Control Enhancement)   The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-13(3) Use of Cryptography (Control Enhancement)    
SC-13(4) Use of Cryptography (Control Enhancement)    
SC-14 Public Access Protections System and Communications Protection  
SC-15 Collaborative Computing Devices System and Communications Protection  
SC-15(1) Collaborative Computing Devices (Control Enhancement) System and Communications Protection  
SC-15(2) Collaborative Computing Devices (Control Enhancement) System and Communications Protection  
SC-15(3) Collaborative Computing Devices (Control Enhancement) System and Communications Protection  
SC-16 Transmission of Security Attributes System and Communications Protection  
SC-16(1) Transmission of Security Attributes (Control Enhancement) System and Communications Protection  
SC-17 Public Key Infrastructure Certificates System and Communications Protection In an operational setting, SIMP does not establish keys. It does come with the ability to create server keys using a custom application know as “FakeCA”. SSH keys can also be established using standard unix command line tools. In an operational settings, both sets of keys should be obtained from valid key infrastructures.There is also a CA that puppet uses to generate and manage keys for puppet only.
SC-18 Mobile Code System and Communications Protection  
SC-18(1) Mobile Code (Control Enhancement) System and Communications Protection  
SC-18(2) Mobile Code (Control Enhancement) System and Communications Protection  
SC-18(3) Mobile Code (Control Enhancement) System and Communications Protection  
SC-18(4) Mobile Code (Control Enhancement) System and Communications Protection  
SC-19 Voice Over Internet Protocol System and Communications Protection  
SC-20 Secure Name /Address Resolution Service (Authoritative Source) System and Communications Protection  
SC-20(1) Secure Name /Address Resolution Service (Authoritative Source) (Control Enhancement) System and Communications Protection  
SC-21 Secure Name /Address Resolution Service (Recursive or Caching Resolver) System and Communications Protection  
SC-21(1) Secure Name /Address Resolution Service (Recursive or Caching Resolver) (Control Enhancement) System and Communications Protection  
SC-22 Architecture and Provisioning for Name/Address Resolution Service System and Communications Protection  
SC-23 Session Authenticity System and Communications Protection The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-23(1) Session Authenticity (Control Enhancement) System and Communications Protection The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-23(2) Session Authenticity (Control Enhancement) System and Communications Protection  
SC-23(3) Session Authenticity (Control Enhancement) System and Communications Protection The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-23(4) Session Authenticity (Control Enhancement) System and Communications Protection  
SC-24 Fail in Known State System and Communications Protection The forms of cryptography used are applied through SSH, SSL, and TLS. There are several unencrypted protocols used on the puppet server (Apache/YUM, DHCPD, TFTP, and DNS) that are documented in the Security Concepts document.
SC-25 Thin Nodes System and Communications Protection  
SC-26 Honeypots System and Communications Protection  
SC-26(1) Honeypots (Control Enhancement) System and Communications Protection  
SC-27 Operating System-Independent Applications System and Communications Protection  
SC-28 Protection of Information at Rest System and Communications Protection Confidentiality of data at rest is achieved using the operating system access control. Integrity is only checked for critical operating system files. Implementations have the ability to extend the integrity checking of AIDE to include additional files that are not frequently changed.
SC-28 Protection of Information at Rest (Control Enhancement) System and Communications Protection  
SC-29 Heterogeneity System and Communications Protection  
SC-30 Virtualization Techniques System and Communications Protection  
SC-30(1) Virtualization Techniques (Control Enhancement) System and Communications Protection  
SC-30(2) Virtualization Techniques (Control Enhancement) System and Communications Protection  
SC-31 Covert Channel Analysis System and Communications Protection  
SC-31(1) Covert Channel Analysis (Control Enhancement) System and Communications Protection  
SC-32 Information System Partitioning System and Communications Protection  
SC-33 Transmission Preparation Integrity System and Communications Protection  
SC-34 Non-modifiable Executable Programs System and Communications Protection  
SC-34(1) Non-modifiable Executable Programs (Control Enhancement) System and Communications Protection  
SC-34(2) Non-modifiable Executable Programs (Control Enhancement) System and Communications Protection  

Table: SIMP SCTM

SIMP SCTM Operational Controls
Control ID Control Name Control Family SIMP Implementation Method
AT-1 Security Awareness and Training Policy and Procedures Awareness and Training  
AT-2(1) Security Awareness (Control Enhancement) Awareness and Training  
AT-3 Security Training Awareness and Training  
AT-3(1) Security Training (Control Enhancement) Awareness and Training  
AT-3(2) Security Training (Control Enhancement) Awareness and Training  
AT-4 Security Training Records Awareness and Training  
AT-5 Contacts with Security Groups and Associations Awareness and Training  
CM-1 Configuration Management Policy and Procedures Configuration Management  
CM-2 Baseline Configuration Configuration Management SIMP has strictly enforced version control during development. The baseline files for SIMP are kept and maintained in a git repository. Files are packaged and a series of auto tests are performed on each release. Once released, there is a version number associated for distribution. Additionally, custom puppet modules are in the form of RPMs and have version numbers associated with them. All documentation is also built with source code.
CM-2(1) Baseline Configuration (Control Enhancement) Configuration Management  
CM-2(2) Baseline Configuration (Control Enhancement) Configuration Management SIMP has strictly enforced version control during development. The baseline files for SIMP are kept and maintained in a git repository. Files are packaged and a series of auto tests are performed on the release. Once released, there is a version number associated for distribution. All documentation is also built with source code.
CM-2(3) Baseline Configuration (Control Enhancement) Configuration Management All old versions of SIMP remain in the code repository.
CM-2(4) Baseline Configuration (Control Enhancement) Configuration Management  
CM-2(5) Baseline Configuration (Control Enhancement) Configuration Management
  1. SIMP provides a minimal list of packages and services installed. The minimal list of packages can be found in kickstart files and the appendix of this document. Additional packages are installed by each implementation or as SIMP modules are applied. b. It’s not feasible to technically deny additional applications from being installed. There is nothing in SIMP that can stop and RPM from being applied. Applications that require network access to service activation must be registered with puppet.
CM-2(6) Baseline Configuration (Control Enhancement) Configuration Management As a project, SIMP is developmental only. The environments where it is tested is up to the implementation. Development testing is performed on SIMP in environments that have a code base frozen.
CM-3 Configuration Change Control Configuration Management  
CM-3(1) Configuration Change Control (Control Enhancement) Configuration Management  
CM-3(2) Configuration Change Control (Control Enhancement) Configuration Management  
CM-3(3) Configuration Change Control (Control Enhancement) Configuration Management Configuration changes in SIMP are automated using a combination of puppet, yum, and rsync. While not all files on an operating system are managed by those mechanisms, many are. Changes to critical files that are managed by puppet, revert back to their original state. These mechanisms were not meant to defeat an attack by a malicious insider.
CM-3(4) Configuration Change Control (Control Enhancement) Configuration Management  
CM-4 Security Impact Analysis Configuration Management All features or bugs in SIMP are vetted through the development process by being placed on the product backlog and discussed with the entire team. There is a security representative on the SIMP team that is part of that vetting process.
CM-4(1) Security Impact Analysis (Control Enhancement) Configuration Management  
CM-4(2) Security Impact Analysis (Control Enhancement) Configuration Management  
CM-5 Access Restrictions for Change Configuration Management SIMP can only meet the enforcement part of this control. The remainder must be met by the environment that SIMP is implemented in. Changes to a SIMP based systems are enforced with built in Unix/LDAP groups. Only someone with sudo or sudosh access (usually an admin group) can apply changes to the environment
CM-5(1) Access Restrictions for Change (Control Enhancement) Configuration Management SIMP can only meet the enforcement part of this control. The remainder must be met by the environment that SIMP is implemented in. Changes to a SIMP based systems are enforced with built in Unix/LDAP groups. Only someone with sudo or sudosh access (usually an admin group) can apply changes to the environment
CM-5(2) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(3) Access Restrictions for Change (Control Enhancement) Configuration Management Redhat and Centos packages are signed with gpg keys. Those keys are vendor specific. Package installation occurs only when those gpgkeys are validate using the installed gpg public keys for the operating system. SIMP specific RPMS that were developed are signed using keys generate by the development team.
CM-5(4) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(5) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(6) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(7) Access Restrictions for Change (Control Enhancement) Configuration Management Most of the critical files that are managed by puppet cannot be permanently changed on a puppet client without disabling puppet and rsync. If they are changed, puppet will revert them back to their original state.
CM-6 Configuration Settings Configuration Management Part “d” of this control is met my SIMP. The others are not. SIMP uses puppet to monitor changes to configuration settings. If changes to puppet controlled settings are manually made, they revert back to their original state.
CM-6(1) Configuration Settings (Control Enhancement) Configuration Management The puppet master is the central point of management for a SIMP system. While not required, the puppet master usually hosts a kickstart server so that clients are built the same every time.
CM-6(2) Configuration Settings (Control Enhancement) Configuration Management Puppet is not intended to be a security mechanism to prevent unauthorized changes to files. For files that are managed by puppet that changed, they will revert back to their original state. This control is really about protecting from unauthorized changes so access control to the puppet master should suffice to meet it. Changes to files are audited using auditd. Puppet changes are also audited. It’s up to the implementation to perform altering on those changes.
CM-6(3) Configuration Settings (Control Enhancement) Configuration Management This control is not fully met by SIMP. It’s important to point out that SIMP does provide logging of events to syslog. It’s currently up to the implementation to alert on those events.
CM-7 Least Functionality Configuration Management There isn’t an explicit list of services that SIMP denies. Instead, it was built to provide only the essential functionality. Additional services get added only as needed.
CM-7(1) Least Functionality (Control Enhancement) Configuration Management  
CM-7(2) Least Functionality (Control Enhancement) Configuration Management Applications can be installed, but new services will not run unless first registered with puppet. Additionally, puppet modules must be modified to ensure that IPtables opens up the necessary services. Minimally, for a service to remain active, it must be registered with puppet or the svckill.rb script will stop them.To be clear, there is nothing in SIMP that prevents the installation of RPMs (from the command line or YUM).
CM-7(3) Least Functionality (Control Enhancement) Configuration Management The registration process for ports, protocols, and services are handled via puppet.
CM-8 Information System Component Inventory Configuration Management  
CM-8(1) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(2) Information System Component Inventory (Control Enhancement) Configuration Management To the extent possible, puppet tracks clients that are within it’s control. It’s not meant to be a true inventory mechanism.
CM-8(3) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(4) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(5) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(6) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-9 Configuration Management Plan Configuration Management  
CM-9(1) Configuration Management Plan (Control Enhancement) Configuration Management  
CP-1 Contingency Planning Policy and Procedures Contingency Planning  
CP-2 Contingency Plan Contingency Planning  
CP-2(1) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(2) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(3) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(4) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(5) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(6) Contingency Plan (Control Enhancement) Contingency Planning  
CP-3 Contingency Training Contingency Planning  
CP-3(1) Contingency Training (Control Enhancement) Contingency Planning  
CP-3(2) Contingency Training (Control Enhancement) Contingency Planning  
CP-4 Contingency Plan Testing and Exercises Contingency Planning  
CP-4(1) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-4(2) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-4(3) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-6 Alternate Storage Site Contingency Planning  
CP-6(1) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-6(2) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-6(3) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-7 Alternate Processing Site Contingency Planning  
CP-7(1) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(2) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(3) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(4) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(5) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-8 Telecommunications Services Contingency Planning  
CP-8(1) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(2) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(3) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(4) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-9 Information System Backup Contingency Planning The BackupPC module is not currently available in SIMP 5.0.
CP-9(1) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(2) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(3) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(5) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(6) Information System Backup (Control Enhancement) Contingency Planning  
CP-10 Information System Recovery and Reconstitution Contingency Planning The BackupPC module is not currently available in SIMP 5.0.
CP-10(1) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(2) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(3) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(4) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(5) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(6) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
IR-1 Incident Response Policy and Procedures Incident Response  
IR-2 Incident Response Training Incident Response  
IR-2(1) Incident Response Training (Control Enhancement) Incident Response  
IR-2(2) Incident Response Training (Control Enhancement) Incident Response  
IR-3 Incident Response Testing and Exercises Incident Response  
IR-3(1) Incident Response Testing and Exercises (Control Enhancement) Incident Response  
IR-4 Incident Handling Incident Response  
IR-4(1) Incident Handling (Control Enhancement) Incident Response  
IR-4(2) Incident Handling (Control Enhancement) Incident Response If an implementation chooses, they can leverage puppet’s ability to reconfigure systems as part of incident response. While puppet is not intended to be a security product, its features can help provide security functionality such as dynamic reconfigurations.
IR-4(3) Incident Handling (Control Enhancement) Incident Response  
IR-4(4) Incident Handling (Control Enhancement) Incident Response  
IR-4(5) Incident Handling (Control Enhancement) Incident Response  
IR-5 Incident Monitoring Incident Response  
IR-5(1) Incident Monitoring (Control Enhancement) Incident Response  
IR-6 Incident Reporting Incident Response  
IR-6(1) Incident Reporting (Control Enhancement) Incident Response  
IR-6(2) Incident Reporting (Control Enhancement) Incident Response  
IR-7 Incident Response Assistance Incident Response  
IR-7(1) Incident Response Assistance (Control Enhancement) Incident Response  
IR-8 Incident Response Plan Incident Response  
MA-1 System Maintenance Policy and Procedures Maintenance  
MA-2 Controlled Maintenance Maintenance  
MA-2(1) Controlled Maintenance (Control Enhancement) Maintenance  
MA-2(2) Controlled Maintenance (Control Enhancement) Maintenance  
MA-3 Maintenance Tools Maintenance  
MA-3(1) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(2) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(3) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(4) Maintenance Tools (Control Enhancement) Maintenance  
MA-4 Non-Local Maintenance Maintenance Remote maintenance can be performed on SIMP using SSH or direct console access. SSH sessions are tracked and logged using the security features built into SIMP. Console access requires someone to have access to the physical (or virtual) console along with the root password. Auditing of those actions also occurs in accordance with the configured audit policy. It’s up to the implementation to decide how to distribute authentication information for remote maintenance.
MA-4(1) Non-Local Maintenance (Control Enhancement) Maintenance Remote maintenance can be performed on SIMP using SSH or direct console access. SSH sessions are tracked and logged using the security features built into SIMP. Console access requires someone to have access to the physical (or virtual) console along with the root password. Audting of those actions also occurs in accordance with the configured audit policy. It’s up to the implementation to decide how to distribute authentication information for remote maintenance
MA-4(2) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(3) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(4) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(5) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(6) Non-Local Maintenance (Control Enhancement) Maintenance Remote maintenance is performed using SSH. SSH inherently provides confidentiality and integrity of data while in transit.
MA-4(7) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-5 Maintenance Personnel Maintenance  
MA-5(1) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(2) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(3) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(4) Maintenance Personnel (Control Enhancement) Maintenance  
MA-6 Timely Maintenance Maintenance  
MP-1 Media Protection Policy and Procedures Media Protection  
MP-2 Media Access Media Protection  
MP-2(1) Media Access (Control Enhancement) Media Protection  
MP-2(2) Media Access (Control Enhancement) Media Protection  
MP-4 Media Storage Media Protection  
MP-5 Media Transport Media Protection  
MP-5(1) Media Transport (Control Enhancement) Media Protection  
MP-5(2) Media Transport (Control Enhancement) Media Protection  
MP-5(3) Media Transport (Control Enhancement) Media Protection  
MP-5(4) Media Transport (Control Enhancement) Media Protection  
MP-6 Media Sanitization Media Protection  
MP-6(1) Media Sanitization (Control Enhancement) Media Protection  
MP-6(2) Media Sanitization (Control Enhancement) Media Protection  
MP-6(3) Media Sanitization (Control Enhancement) Media Protection  
MP-6(4) Media Sanitization (Control Enhancement) Media Protection  
MP-6(5) Media Sanitization (Control Enhancement) Media Protection  
MP-6(6) Media Sanitization (Control Enhancement) Media Protection  
PE-1 Physical and Environmental Protection Policy and Procedures Physical and Environmental Protection  
PE-2 Physical Access Authorizations Physical and Environmental Protection  
PE-2(1) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-2(2) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-2(3) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-3 Physical Access Control Physical and Environmental Protection  
PE-3(1) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(2) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(3) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(4) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(5) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(6) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-4 Access Control for Transmission Medium Physical and Environmental Protection  
PE-5 Access Control for Output Devices Physical and Environmental Protection  
PE-6 Monitoring Physical Access Physical and Environmental Protection  
PE-6(1) Monitoring Physical Access (Control Enhancement) Physical and Environmental Protection  
PE-6(2) Monitoring Physical Access (Control Enhancement) Physical and Environmental Protection  
PE-7 Visitor Control Physical and Environmental Protection  
PE-7(1) Visitor Control (Control Enhancement) Physical and Environmental Protection  
PE-7(2) Visitor Control (Control Enhancement) Physical and Environmental Protection  
PE-8 Access Records Physical and Environmental Protection  
PE-8(1) Access Records (Control Enhancement) Physical and Environmental Protection  
PE-8(2) Access Records (Control Enhancement) Physical and Environmental Protection  
PE-9 Power Equipment and Power Cabling Physical and Environmental Protection  
PE-9(1) Power Equipment and Power Cabling (Control Enhancement) Physical and Environmental Protection  
PE-9(2) Power Equipment and Power Cabling (Control Enhancement) Physical and Environmental Protection  
PE-10 Emergency Shutoff Physical and Environmental Protection  
PE-10(1) Emergency Shutoff (Control Enhancement) Physical and Environmental Protection  
PE-11 Emergence Power Physical and Environmental Protection  
PE-11(1) Emergence Power (Control Enhancement) Physical and Environmental Protection  
PE-11(2) Emergence Power (Control Enhancement) Physical and Environmental Protection  
PE-12 Emergency Lighting Physical and Environmental Protection  
PE-12(1) Emergency Lighting (Control Enhancement) Physical and Environmental Protection  
PE-13 Fire Protection Physical and Environmental Protection  
PE-13(1) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(2) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(3) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(4) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-14 Temperature and Humidity Controls Physical and Environmental Protection  
PE-14(1) Temperature and Humidity Controls (Control Enhancement) Physical and Environmental Protection  
PE-14(2) Temperature and Humidity Controls (Control Enhancement) Physical and Environmental Protection  
PE-15 Water Damage Protection Physical and Environmental Protection  
PE-15(1) Water Damage Protection (Control Enhancement) Physical and Environmental Protection  
PE-16 Delivery and Removal Physical and Environmental Protection  
PE-17 Alternate Work Site Physical and Environmental Protection  
PE-18 Location of Information System Components Physical and Environmental Protection  
PE-18(1) Location of Information System Components (Control Enhancement) Physical and Environmental Protection  
PE-19 Information Leakage Physical and Environmental Protection  
SI-1 System and Information Integrity Policy and Procedures System and Information Integrity  
SI-2(1) Flaw Remediation (Control Enhancement) System and Information Integrity Patches that are part of the software base for SIMP are tested within the development environment. There is automated testing that is constantly being extended to test more features. There are times that patches to the base operating system (Centos or RedHat) are needed to resolve issues in SIMP. Those are also tested at build time, but require additional testing by implementations as patches are released from vendors. It’s also important to note that SIMP is packaged and delivered decoupled with the operating system source files. It’s up to the implementation to test vendor specific patches that are not part of the SIMP code base. Flaws are tracked using the software project management tool Redmine.
SI-2(2) Flaw Remediation (Control Enhancement) System and Information Integrity  
SI-2(3) Flaw Remediation (Control Enhancement) System and Information Integrity  
SI-2(4) Flaw Remediation (Control Enhancement) System and Information Integrity SIMP uses the yellowdog update manager (YUM) to deliver software patches to clients. Each installation usually has at least one YUM repository. There is also a cronjob running that runs once per day. It’s the responsibility of the implementation to get patches to the yum server. Once they are there, the cron job will perform a yum update and the patches will be applied.
SI-3 Malicious Code Protection System and Information Integrity SIMP has modules available for mcafee and ClamAV. The ClamAV. Implementations need need to provide their own version of the mcafee software for the module to work. That module comes with the ability to sync dat updates to clients via rsync. The modulde does NOT specify how often and what files systems should be scanned. SIMP also implements the open source tool chkrootkit that comes installed by default.
SI-3(1) Malicious Code Protection (Control Enhancement) System and Information Integrity The provided anti-virus modules are installed via puppet modules. Those modules include the ability to sycn data file updates via rsync. Therefore, all management of malicious code detection is done centrally.
SI-3(2) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(3) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(4) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(5) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(6) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-4 Information System Monitoring Tools and Techniques System and Information Integrity  
SI-4(1) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(2) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(3) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(4) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(5) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(6) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(7) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(8) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(9) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(10) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(11) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(12) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(13) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(14) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(15) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(16) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(17) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-5 System Alerts, Advisories, and Directives System and Information Integrity The only part of the control (a) that is met by SIMP, is the tracking of security alerts for products that are part of the code base. The development team subscribes to message boards for the main products (puppet) that are part of the packaging. RedHat/Centos advisories are also tracked out of necessity but since ALL the OS files are not part of SIMP delivery, patches are not our direct responsibility.
SI-5(1) System Alerts, Advisories, and Directives (Control Enhancement) System and Information Integrity  
SI-6 Security Functionality Verification System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide (the checks for RHEL 7 are not yet complete/finalized). Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(1) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(2) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(3) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-7 Software and Information Integrity System and Information Integrity SIMP comes with AIDE installed. Puppet also serves the purpose of checking the integrity of files. During each client run, a change in file integrity means the file needs to be restored to it’s original state.
SI-7(1) Software and Information Integrity (Control Enhancement) System and Information Integrity AIDE baselines are not performed beyond initial install unless otherwise configured. Implementations can re-baseline the database.
SI-7(2) Software and Information Integrity (Control Enhancement) System and Information Integrity  
SI-7(3) Software and Information Integrity (Control Enhancement) System and Information Integrity AIDE is managed by puppet and is therefore centrally managed.
SI-7(4) Software and Information Integrity (Control Enhancement) System and Information Integrity  
SI-8 Spam Protection System and Information Integrity  
SI-8(1) Spam Protection (Control Enhancement) System and Information Integrity  
SI-8(2) Spam Protection (Control Enhancement) System and Information Integrity  
SI-9 Information Input Restrictions System and Information Integrity  
SI-10 Information Input Validation System and Information Integrity  
SI-11 Error Handling System and Information Integrity  
SI-13 Predictable Failure Prevention System and Information Integrity  
SI-13(1) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(2) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(3) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(4) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  

Table: SIMP SCTM

SIMP SCTM Management Controls
Control ID Control Name Control Family SIMP Implementation Method
AT-1 Security Awareness and Training Policy and Procedures Awareness and Training  
AT-2(1) Security Awareness (Control Enhancement) Awareness and Training  
AT-3 Security Training Awareness and Training  
AT-3(1) Security Training (Control Enhancement) Awareness and Training  
AT-3(2) Security Training (Control Enhancement) Awareness and Training  
AT-4 Security Training Records Awareness and Training  
AT-5 Contacts with Security Groups and Associations Awareness and Training  
CM-1 Configuration Management Policy and Procedures Configuration Management  
CM-2 Baseline Configuration Configuration Management SIMP has strictly enforced version control during development. The baseline files for SIMP are kept and maintained in a git repository. Files are packaged and a series of auto tests are performed on each release. Once released, there is a version number associated for distribution. Additionally, custom puppet modules are in the form of RPMs and have version numbers associated with them. All documentation is also built with source code.
CM-2(1) Baseline Configuration (Control Enhancement) Configuration Management  
CM-2(2) Baseline Configuration (Control Enhancement) Configuration Management SIMP has strictly enforced version control during development. The baseline files for SIMP are kept and maintained in a git repository. Files are packaged and a series of auto tests are performed on the release. Once released, there is a version number associated for distribution. All documentation is also built with source code.
CM-2(3) Baseline Configuration (Control Enhancement) Configuration Management All old versions of SIMP remain in the code repository.
CM-2(4) Baseline Configuration (Control Enhancement) Configuration Management  
CM-2(5) Baseline Configuration (Control Enhancement) Configuration Management
  1. SIMP provides a minimal list of packages and services installed. The minimal list of packages can be found in kickstart files and the appendix of this document. Additional packages are installed by each implementation or as SIMP modules are applied. b. It’s not feasible to technically deny additional applications from being installed. There is nothing in SIMP that can stop and RPM from being applied. Applications that require network access to service activation must be registered with puppet.
CM-2(6) Baseline Configuration (Control Enhancement) Configuration Management As a project, SIMP is developmental only. The environments where it is tested is up to the implementation. Development testing is performed on SIMP in environments that have a code base frozen.
CM-3 Configuration Change Control Configuration Management  
CM-3(1) Configuration Change Control (Control Enhancement) Configuration Management  
CM-3(2) Configuration Change Control (Control Enhancement) Configuration Management  
CM-3(3) Configuration Change Control (Control Enhancement) Configuration Management Configuration changes in SIMP are automated using a combination of puppet, yum, and rsync. While not all files on an operating system are managed by those mechanisms, many are. Changes to critical files that are managed by puppet, revert back to their original state. These mechanisms were not meant to defeat an attack by a malicious insider.
CM-3(4) Configuration Change Control (Control Enhancement) Configuration Management  
CM-4 Security Impact Analysis Configuration Management All features or bugs in SIMP are vetted through the development process by being placed on the product backlog and discussed with the entire team. There is a security representative on the SIMP team that is part of that vetting process.
CM-4(1) Security Impact Analysis (Control Enhancement) Configuration Management  
CM-4(2) Security Impact Analysis (Control Enhancement) Configuration Management  
CM-5 Access Restrictions for Change Configuration Management SIMP can only meet the enforcement part of this control. The remainder must be met by the environment that SIMP is implemented in. Changes to a SIMP based systems are enforced with built in Unix/LDAP groups. Only someone with sudo or sudosh access (usually an admin group) can apply changes to the environment
CM-5(1) Access Restrictions for Change (Control Enhancement) Configuration Management SIMP can only meet the enforcement part of this control. The remainder must be met by the environment that SIMP is implemented in. Changes to a SIMP based systems are enforced with built in Unix/LDAP groups. Only someone with sudo or sudosh access (usually an admin group) can apply changes to the environment
CM-5(2) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(3) Access Restrictions for Change (Control Enhancement) Configuration Management Redhat and Centos packages are signed with gpg keys. Those keys are vendor specific. Package installation occurs only when those gpgkeys are validate using the installed gpg public keys for the operating system. SIMP specific RPMS that were developed are signed using keys generate by the development team.
CM-5(4) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(5) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(6) Access Restrictions for Change (Control Enhancement) Configuration Management  
CM-5(7) Access Restrictions for Change (Control Enhancement) Configuration Management Most of the critical files that are managed by puppet cannot be permanently changed on a puppet client without disabling puppet and rsync. If they are changed, puppet will revert them back to their original state.
CM-6 Configuration Settings Configuration Management Part “d” of this control is met my SIMP. The others are not. SIMP uses puppet to monitor changes to configuration settings. If changes to puppet controlled settings are manually made, they revert back to their original state.
CM-6(1) Configuration Settings (Control Enhancement) Configuration Management The puppet master is the central point of management for a SIMP system. While not required, the puppet master usually hosts a kickstart server so that clients are built the same every time.
CM-6(2) Configuration Settings (Control Enhancement) Configuration Management Puppet is not intended to be a security mechanism to prevent unauthorized changes to files. For files that are managed by puppet that changed, they will revert back to their original state. This control is really about protecting from unauthorized changes so access control to the puppet master should suffice to meet it. Changes to files are audited using auditd. Puppet changes are also audited. It’s up to the implementation to perform altering on those changes.
CM-6(3) Configuration Settings (Control Enhancement) Configuration Management This control is not fully met by SIMP. It’s important to point out that SIMP does provide logging of events to syslog. It’s currently up to the implementation to alert on those events.
CM-7 Least Functionality Configuration Management There isn’t an explicit list of services that SIMP denies. Instead, it was built to provide only the essential functionality. Additional services get added only as needed.
CM-7(1) Least Functionality (Control Enhancement) Configuration Management  
CM-7(2) Least Functionality (Control Enhancement) Configuration Management Applications can be installed, but new services will not run unless first registered with puppet. Additionally, puppet modules must be modified to ensure that IPtables opens up the necessary services. Minimally, for a service to remain active, it must be registered with puppet or the svckill.rb script will stop them.To be clear, there is nothing in SIMP that prevents the installation of RPMs (from the command line or YUM).
CM-7(3) Least Functionality (Control Enhancement) Configuration Management The registration process for ports, protocols, and services are handled via puppet.
CM-8 Information System Component Inventory Configuration Management  
CM-8(1) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(2) Information System Component Inventory (Control Enhancement) Configuration Management To the extent possible, puppet tracks clients that are within it’s control. It’s not meant to be a true inventory mechanism.
CM-8(3) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(4) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(5) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-8(6) Information System Component Inventory (Control Enhancement) Configuration Management  
CM-9 Configuration Management Plan Configuration Management  
CM-9(1) Configuration Management Plan (Control Enhancement) Configuration Management  
CP-1 Contingency Planning Policy and Procedures Contingency Planning  
CP-2 Contingency Plan Contingency Planning  
CP-2(1) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(2) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(3) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(4) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(5) Contingency Plan (Control Enhancement) Contingency Planning  
CP-2(6) Contingency Plan (Control Enhancement) Contingency Planning  
CP-3 Contingency Training Contingency Planning  
CP-3(1) Contingency Training (Control Enhancement) Contingency Planning  
CP-3(2) Contingency Training (Control Enhancement) Contingency Planning  
CP-4 Contingency Plan Testing and Exercises Contingency Planning  
CP-4(1) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-4(2) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-4(3) Contingency Plan Testing and Exercises (Control Enhancement) Contingency Planning  
CP-6 Alternate Storage Site Contingency Planning  
CP-6(1) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-6(2) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-6(3) Alternate Storage Site (Control Enhancement) Contingency Planning  
CP-7 Alternate Processing Site Contingency Planning  
CP-7(1) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(2) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(3) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(4) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-7(5) Alternate Processing Site (Control Enhancement) Contingency Planning  
CP-8 Telecommunications Services Contingency Planning  
CP-8(1) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(2) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(3) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-8(4) Telecommunications Services (Control Enhancement) Contingency Planning  
CP-9 Information System Backup Contingency Planning The BackupPC module is not currently available in SIMP 5.0.
CP-9(1) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(2) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(3) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(5) Information System Backup (Control Enhancement) Contingency Planning  
CP-9(6) Information System Backup (Control Enhancement) Contingency Planning  
CP-10 Information System Recovery and Reconstitution Contingency Planning The BackupPC module is not currently available in SIMP 5.0.
CP-10(1) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(2) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(3) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(4) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(5) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
CP-10(6) Information System Recovery and Reconstitution (Control Enhancement) Contingency Planning  
IR-1 Incident Response Policy and Procedures Incident Response  
IR-2 Incident Response Training Incident Response  
IR-2(1) Incident Response Training (Control Enhancement) Incident Response  
IR-2(2) Incident Response Training (Control Enhancement) Incident Response  
IR-3 Incident Response Testing and Exercises Incident Response  
IR-3(1) Incident Response Testing and Exercises (Control Enhancement) Incident Response  
IR-4 Incident Handling Incident Response  
IR-4(1) Incident Handling (Control Enhancement) Incident Response  
IR-4(2) Incident Handling (Control Enhancement) Incident Response If an implementation chooses, they can leverage puppet’s ability to reconfigure systems as part of incident response. While puppet is not intended to be a security product, its features can help provide security functionality such as dynamic reconfigurations.
IR-4(3) Incident Handling (Control Enhancement) Incident Response  
IR-4(4) Incident Handling (Control Enhancement) Incident Response  
IR-4(5) Incident Handling (Control Enhancement) Incident Response  
IR-5 Incident Monitoring Incident Response  
IR-5(1) Incident Monitoring (Control Enhancement) Incident Response  
IR-6 Incident Reporting Incident Response  
IR-6(1) Incident Reporting (Control Enhancement) Incident Response  
IR-6(2) Incident Reporting (Control Enhancement) Incident Response  
IR-7 Incident Response Assistance Incident Response  
IR-7(1) Incident Response Assistance (Control Enhancement) Incident Response  
IR-8 Incident Response Plan Incident Response  
MA-1 System Maintenance Policy and Procedures Maintenance  
MA-2 Controlled Maintenance Maintenance  
MA-2(1) Controlled Maintenance (Control Enhancement) Maintenance  
MA-2(2) Controlled Maintenance (Control Enhancement) Maintenance  
MA-3 Maintenance Tools Maintenance  
MA-3(1) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(2) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(3) Maintenance Tools (Control Enhancement) Maintenance  
MA-3(4) Maintenance Tools (Control Enhancement) Maintenance  
MA-4 Non-Local Maintenance Maintenance Remote maintenance can be performed on SIMP using SSH or direct console access. SSH sessions are tracked and logged using the security features built into SIMP. Console access requires someone to have access to the physical (or virtual) console along with the root password. Auditing of those actions also occurs in accordance with the configured audit policy. It’s up to the implementation to decide how to distribute authentication information for remote maintenance.
MA-4(1) Non-Local Maintenance (Control Enhancement) Maintenance Remote maintenance can be performed on SIMP using SSH or direct console access. SSH sessions are tracked and logged using the security features built into SIMP. Console access requires someone to have access to the physical (or virtual) console along with the root password. Audting of those actions also occurs in accordance with the configured audit policy. It’s up to the implementation to decide how to distribute authentication information for remote maintenance
MA-4(2) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(3) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(4) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(5) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-4(6) Non-Local Maintenance (Control Enhancement) Maintenance Remote maintenance is performed using SSH. SSH inherently provides confidentiality and integrity of data while in transit.
MA-4(7) Non-Local Maintenance (Control Enhancement) Maintenance  
MA-5 Maintenance Personnel Maintenance  
MA-5(1) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(2) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(3) Maintenance Personnel (Control Enhancement) Maintenance  
MA-5(4) Maintenance Personnel (Control Enhancement) Maintenance  
MA-6 Timely Maintenance Maintenance  
MP-1 Media Protection Policy and Procedures Media Protection  
MP-2 Media Access Media Protection  
MP-2(1) Media Access (Control Enhancement) Media Protection  
MP-2(2) Media Access (Control Enhancement) Media Protection  
MP-4 Media Storage Media Protection  
MP-5 Media Transport Media Protection  
MP-5(1) Media Transport (Control Enhancement) Media Protection  
MP-5(2) Media Transport (Control Enhancement) Media Protection  
MP-5(3) Media Transport (Control Enhancement) Media Protection  
MP-5(4) Media Transport (Control Enhancement) Media Protection  
MP-6 Media Sanitization Media Protection  
MP-6(1) Media Sanitization (Control Enhancement) Media Protection  
MP-6(2) Media Sanitization (Control Enhancement) Media Protection  
MP-6(3) Media Sanitization (Control Enhancement) Media Protection  
MP-6(4) Media Sanitization (Control Enhancement) Media Protection  
MP-6(5) Media Sanitization (Control Enhancement) Media Protection  
MP-6(6) Media Sanitization (Control Enhancement) Media Protection  
PE-1 Physical and Environmental Protection Policy and Procedures Physical and Environmental Protection  
PE-2 Physical Access Authorizations Physical and Environmental Protection  
PE-2(1) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-2(2) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-2(3) Physical Access Authorizations (Control Enhancement) Physical and Environmental Protection  
PE-3 Physical Access Control Physical and Environmental Protection  
PE-3(1) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(2) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(3) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(4) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(5) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-3(6) Physical Access Control (Control Enhancement) Physical and Environmental Protection  
PE-4 Access Control for Transmission Medium Physical and Environmental Protection  
PE-5 Access Control for Output Devices Physical and Environmental Protection  
PE-6 Monitoring Physical Access Physical and Environmental Protection  
PE-6(1) Monitoring Physical Access (Control Enhancement) Physical and Environmental Protection  
PE-6(2) Monitoring Physical Access (Control Enhancement) Physical and Environmental Protection  
PE-7 Visitor Control Physical and Environmental Protection  
PE-7(1) Visitor Control (Control Enhancement) Physical and Environmental Protection  
PE-7(2) Visitor Control (Control Enhancement) Physical and Environmental Protection  
PE-8 Access Records Physical and Environmental Protection  
PE-8(1) Access Records (Control Enhancement) Physical and Environmental Protection  
PE-8(2) Access Records (Control Enhancement) Physical and Environmental Protection  
PE-9 Power Equipment and Power Cabling Physical and Environmental Protection  
PE-9(1) Power Equipment and Power Cabling (Control Enhancement) Physical and Environmental Protection  
PE-9(2) Power Equipment and Power Cabling (Control Enhancement) Physical and Environmental Protection  
PE-10 Emergency Shutoff Physical and Environmental Protection  
PE-10(1) Emergency Shutoff (Control Enhancement) Physical and Environmental Protection  
PE-11 Emergence Power Physical and Environmental Protection  
PE-11(1) Emergence Power (Control Enhancement) Physical and Environmental Protection  
PE-11(2) Emergence Power (Control Enhancement) Physical and Environmental Protection  
PE-12 Emergency Lighting Physical and Environmental Protection  
PE-12(1) Emergency Lighting (Control Enhancement) Physical and Environmental Protection  
PE-13 Fire Protection Physical and Environmental Protection  
PE-13(1) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(2) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(3) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-13(4) Fire Protection (Control Enhancement) Physical and Environmental Protection  
PE-14 Temperature and Humidity Controls Physical and Environmental Protection  
PE-14(1) Temperature and Humidity Controls (Control Enhancement) Physical and Environmental Protection  
PE-14(2) Temperature and Humidity Controls (Control Enhancement) Physical and Environmental Protection  
PE-15 Water Damage Protection Physical and Environmental Protection  
PE-15(1) Water Damage Protection (Control Enhancement) Physical and Environmental Protection  
PE-16 Delivery and Removal Physical and Environmental Protection  
PE-17 Alternate Work Site Physical and Environmental Protection  
PE-18 Location of Information System Components Physical and Environmental Protection  
PE-18(1) Location of Information System Components (Control Enhancement) Physical and Environmental Protection  
PE-19 Information Leakage Physical and Environmental Protection  
SI-1 System and Information Integrity Policy and Procedures System and Information Integrity  
SI-2(1) Flaw Remediation (Control Enhancement) System and Information Integrity Patches that are part of the software base for SIMP are tested within the development environment. There is automated testing that is constantly being extended to test more features. There are times that patches to the base operating system (Centos or RedHat) are needed to resolve issues in SIMP. Those are also tested at build time, but require additional testing by implementations as patches are released from vendors. It’s also important to note that SIMP is packaged and delivered decoupled with the operating system source files. It’s up to the implementation to test vendor specific patches that are not part of the SIMP code base. Flaws are tracked using the software project management tool Redmine.
SI-2(2) Flaw Remediation (Control Enhancement) System and Information Integrity  
SI-2(3) Flaw Remediation (Control Enhancement) System and Information Integrity  
SI-2(4) Flaw Remediation (Control Enhancement) System and Information Integrity SIMP uses the yellowdog update manager (YUM) to deliver software patches to clients. Each installation usually has at least one YUM repository. There is also a cronjob running that runs once per day. It’s the responsibility of the implementation to get patches to the yum server. Once they are there, the cron job will perform a yum update and the patches will be applied.
SI-3 Malicious Code Protection System and Information Integrity SIMP has modules available for mcafee and ClamAV. The ClamAV. Implementations need need to provide their own version of the mcafee software for the module to work. That module comes with the ability to sync dat updates to clients via rsync. The modulde does NOT specify how often and what files systems should be scanned. SIMP also implements the open source tool chkrootkit that comes installed by default.
SI-3(1) Malicious Code Protection (Control Enhancement) System and Information Integrity The provided anti-virus modules are installed via puppet modules. Those modules include the ability to sycn data file updates via rsync. Therefore, all management of malicious code detection is done centrally.
SI-3(2) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(3) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(4) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(5) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-3(6) Malicious Code Protection (Control Enhancement) System and Information Integrity  
SI-4 Information System Monitoring Tools and Techniques System and Information Integrity  
SI-4(1) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(2) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(3) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(4) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(5) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(6) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(7) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(8) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(9) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(10) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(11) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(12) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(13) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(14) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(15) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(16) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-4(17) Information System Monitoring Tools and Techniques (Control Enhancement) System and Information Integrity  
SI-5 System Alerts, Advisories, and Directives System and Information Integrity The only part of the control (a) that is met by SIMP, is the tracking of security alerts for products that are part of the code base. The development team subscribes to message boards for the main products (puppet) that are part of the packaging. RedHat/Centos advisories are also tracked out of necessity but since ALL the OS files are not part of SIMP delivery, patches are not our direct responsibility.
SI-5(1) System Alerts, Advisories, and Directives (Control Enhancement) System and Information Integrity  
SI-6 Security Functionality Verification System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide (the checks for RHEL 7 are not yet complete/finalized). Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(1) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(2) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-6(3) Security Functionality Verification (Control Enhancement) System and Information Integrity SIMP comes with an optional module to install and perform regular runs of the SCAP-Security-Guide. Doing so will report (for a user defined frequency) OVAL results of security settings of a host against SSG recommendations.
SI-7 Software and Information Integrity System and Information Integrity SIMP comes with AIDE installed. Puppet also serves the purpose of checking the integrity of files. During each client run, a change in file integrity means the file needs to be restored to it’s original state.
SI-7(1) Software and Information Integrity (Control Enhancement) System and Information Integrity AIDE baselines are not performed beyond initial install unless otherwise configured. Implementations can re-baseline the database.
SI-7(2) Software and Information Integrity (Control Enhancement) System and Information Integrity  
SI-7(3) Software and Information Integrity (Control Enhancement) System and Information Integrity AIDE is managed by puppet and is therefore centrally managed.
SI-7(4) Software and Information Integrity (Control Enhancement) System and Information Integrity  
SI-8 Spam Protection System and Information Integrity  
SI-8(1) Spam Protection (Control Enhancement) System and Information Integrity  
SI-8(2) Spam Protection (Control Enhancement) System and Information Integrity  
SI-9 Information Input Restrictions System and Information Integrity  
SI-10 Information Input Validation System and Information Integrity  
SI-11 Error Handling System and Information Integrity  
SI-13 Predictable Failure Prevention System and Information Integrity  
SI-13(1) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(2) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(3) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
SI-13(4) Predictable Failure Prevention (Control Enhancement) System and Information Integrity  
Control ID Control Name Control Family SIMP Implementation Method
Control ID Control Name Control Family SIMP Implementation Method
CA-1 Security Assessment and Authorization Policies Security Assessment and Authorization  
CA-2 Security Assessments Security Assessment and Authorization  
CA-2(1) Security Assessments (Control Enhancement) Security Assessment and Authorization  
CA-2(2) Security Assessments (Control Enhancement) Security Assessment and Authorization  
CA-3 Information System Connections Security Assessment and Authorization  
CA-3(1) Information System Connections (Control Enhancement) Security Assessment and Authorization  
CA-3(2) Information System Connections (Control Enhancement) Security Assessment and Authorization  
CA-5 Plan of Action and Milestones Security Assessment and Authorization  
CA-5(1) Plan of Action and Milestones (Control Enhancement) Security Assessment and Authorization  
CA-6 Security Authorization Security Assessment and Authorization  
CA-7 Continuous Monitoring Security Assessment and Authorization  
CA-7(1) Continuous Monitoring (Control Enhancement) Security Assessment and Authorization  
CA-7(2) Continuous Monitoring (Control Enhancement) Security Assessment and Authorization  
Pl-1 Security Planning Policy and Procedures Planning The SIMP installation manual provides instructions for the installation of the product in a manner that is compliant with a multitude of security controls.
PL-2 System Security Plan Planning Security Plans are provided for specific implementations. The SIMP team will continue to develop security documentation that can be used as s resource for implementation specific System Security Plans.
PL-2(1) System Security Plan (Control Enhancement) Planning TODO: Develop SIMP specific SSP.
PL-2(2) System Security Plan (Control Enhancement) Planning  
PL-4 Rules of Behavior Planning  
PL-4(1) Rules of Behavior (Control Enhancement) Planning  
PL-5 Privacy Impact Assessment Planning  
PL-6 Security-Related Activity Planning Planning  
PS-1 Personnel Security Policy and Procedures Planning  
PS-2 Position Categorization Planning  
PS-3(2) Personnel Screening (Control Enhancement) Planning  
RA-1 Risk Assessment Policy and Procedures Risk Assessment  
RA-2 Security Categorization Risk Assessment  
RA-3 Risk Assessment Risk Assessment  
RA-5 Vulnerability Scanning Risk Assessment The SIMP team performs a variety of security testing as part of the development process. Compliance and configuration checking is done using SSG. SIMP makes every effort to address problems discovered by these tools. Some configuration settings will not align with tools since the product was meant to be used for operational settings where some security features cause a loss in functionality. Implementations have the option of further hardening their system further at the risk of losing some functionality.
RA-5(1) Vulnerability Scanning (Control Enhancement) Risk Assessment SCAP-Security-Guide is the two primary tool used to check for suspected configuration errors. Puppet also continues to protect clients against unwanted changes.
RA-5(2) Vulnerability Scanning (Control Enhancement) Risk Assessment SCAP-Security-Guide is the two primary tool used to check for suspected configuration errors. Puppet also continues to protect clients against unwanted changes.
RA-5(3) Vulnerability Scanning (Control Enhancement) Risk Assessment Regular vulnerability scanning is performed during development of SIMP.
RA-5(4) Vulnerability Scanning (Control Enhancement) Risk Assessment Part of the vulnerability scanning process determines what information can be determined by a malicious outside user.
RA-5(5) Vulnerability Scanning (Control Enhancement) Risk Assessment The compliance tools require that privileged accounts be used to perform testing.
RA-5(6) Vulnerability Scanning (Control Enhancement) Risk Assessment  
RA-5(7) Vulnerability Scanning (Control Enhancement) Risk Assessment Only part of this requirement is met. SIMP can detect when any software is installed via auditd and syslog. Services that are not registered with puppet will not operate without user intervention. Those changes are also audited. SIMP does not provide the ability to alert on those actions, however, Logstash filters or Elasticsearch queries can be applied if needed.
RA-5(8) Vulnerability Scanning (Control Enhancement) Risk Assessment  
RA-5(9) Vulnerability Scanning (Control Enhancement) Risk Assessment  
SA-1 System and Services Acquisition Policy and Procedures System and Service Acquisition  
SA-2 Allocation of Resources System and Service Acquisition  
SA-3 Life Cycle Support System and Service Acquisition  
SA-4 Acquisitions System and Service Acquisition  
SA-4(1) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(2) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(3) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(4) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(5) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(6) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-4(7) Acquisitions (Control Enhancement) System and Service Acquisition  
SA-5 Information System Documentation System and Service Acquisition  
SA-5(1) Information System Documentation (Control Enhancement) System and Service Acquisition  
SA-5(2) Information System Documentation (Control Enhancement) System and Service Acquisition  
SA-5(3) Information System Documentation (Control Enhancement) System and Service Acquisition  
SA-5(4) Information System Documentation (Control Enhancement) System and Service Acquisition  
SA-5(5) Information System Documentation (Control Enhancement) System and Service Acquisition  
SA-6 Software Usage Restrictions System and Service Acquisition  
SA-6 (1) Software Usage Restrictions System and Service Acquisition  
SA-7 User Installed Software System and Service Acquisition  
SA-8 Security Engineering Principles System and Service Acquisition  
SA-9 External Information System Services System and Service Acquisition  
SA-9(1) External Information System Services (Control Enhancement) System and Service Acquisition  
SA-10 Developer Configuration Management System and Service Acquisition  
SA-10(1) Developer Configuration Management (Control Enhancement) System and Service Acquisition  
SA-10(2) Developer Configuration Management (Control Enhancement) System and Service Acquisition  
SA-11 Developer Security Testing System and Service Acquisition  
SA-11(1) Developer Security Testing (Control Enhancement) System and Service Acquisition  
SA-11(2) Developer Security Testing (Control Enhancement) System and Service Acquisition  
SA-11(3) Developer Security Testing (Control Enhancement) System and Service Acquisition  
SA-12 Supply Chain Protection System and Service Acquisition  
SA-12(1) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(2) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(3) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(4) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(5) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(6) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-12(7) Supply Chain Protection (Control Enhancement) System and Service Acquisition  
SA-13 Trustworthiness System and Service Acquisition  
SA-14 Critical Information System Components System and Service Acquisition  
SA-14(1) Critical Information System Components (Control Enhancement) System and Service Acquisition  

Table: Management Controls

Indices and tables

License

Contact

If you have questions please contact the SIMP team. simp@simp-project.org

Help

If you are looking for assistance please email the SIMP mailing lists. simp@simp-project.org

Indices and tables