Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Verify the CA API Gateway is installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher. If the CA API Gateway is not installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher, this is a finding.
Configure the CA API Gateway to be installed on Red Hat Enterprise Linux (RHEL) Version 6.7 or higher.
Review the CA API Gateway configuration to determine if RADIUS + LDAPS or LDAPS is employed to centrally manage authentication settings. - SSH to SSG as a member of ssgconfig. - Select: 1) Configure system settings, 6) Export configuration. - Export configuration to "file". - Go back to main menu, select 3) Use a privileged shell (root). - Navigate to /home/ssgconfig, open "file". - Check "authenticationType". If "authenticationType" is not RADIUS_WITH_LDAP or RADIUS_WITH_LDAPS, this is a finding.
Configure the CA API Gateway to employ RADIUS + LDAPS or LDAPS to centrally manage authentication settings. Prerequisites: - RADIUS server (for the RADIUS+LDAPS configuration) - LDAPS server with posixAccount objects for user logins - LDAPS server CA certificate available via HTTP at a specific URL - LDAP account for the SSG to bind and lookup info - posixUser object within LDAP contain object (OU) - All SSG LDAP posixAccount objects are filtered either by a fixed gidNumber or by membership in an LDAP group containing a sequence of memberUid attributes, one for each user. Configure SSG to use LDAPS. - SSH to SSG as a member of ssgconfig - Select: 1) Configure system settings, 4) Configure authentication method. - Select: 2) ldap. - Walk through configuration steps, providing requisite information ensuring: - Select LDAPS (secure) "y". - Select the appropriate TLS port (636 is the default). - Disable anonymous bind. - Specify the URL containing the PEM of the CA certificate to download. - Specify that the SSG LDAP client "demand" the server's certificate. - Set the user filter to use either a specific gidNumber or a group DN. - Set the posixAccount attribute to use as login name (uid). Confirmation configuration should be approximately: Authentication Type: LDAP_ONLY Label | Value --------------------------------------------------------------------------------------------- Secure | true ActiveDirectory | false Server | smldap.l7tech.com BaseDn | dc=l7tech,dc=com Port | 636 AnonymousBind | false BindDn | cn=Manager,dc=l7tech,dc=com BindPassword | <Hidden> Object for finding the password for users | ou=posixAccounts Object class name of users in the LDAP | posixAccount Server CaCert File | /etc/openldap/cacerts/ldapcacert Certificate Action | DEMAND GroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com PAM login attribute | uid Finally, apply configuration and restart the SSG. Configure SSG to use RADIUS+LDAPS. - SSH to SSG as ssgconfig. - Select: 1) Configure system settings, 4) Configure authentication method. - Select: 4) ldap_radius. - Walk through configuration steps, providing requisite information ensuring: - Enter the RADIUS server's address and secret. - Complete the LDAP questions as for the LDAPS only case (above). Confirmation configuration should be approximately: Authentication Type: RADIUS_WITH_LDAP Label | Value ------------------------------- Server | freerad217.l7tech.com Secret | <Hidden> Timeout | 3 Label | Value --------------------------------------------------------------------------------------------- Secure | true ActiveDirectory | false Server | smldap.l7tech.com BaseDn | dc=l7tech,dc=com Port | 636 AnonymousBind | false BindDn | cn=Manager,dc=l7tech,dc=com BindPassword | <Hidden> Object for finding the password for users | ou=posixAccounts Object class name of users in the LDAP | posixAccount Server CaCert Url | http://localhost:8080/cert Certificate Action | DEMAND GroupDn | cn=ssgconfig_ldap,ou=posixGroups,dc=l7tech,dc=com PAM login attribute | uid
Verify the "/etc/audit/auditd.conf" file contains the lines: disk_full_action = HALT disk_error_action = HALT If "/etc/audit/auditd.conf" does not contain these lines, this is a finding.
Configure the "auditd" configuration file "/etc/audit/auditd.conf" by adding these lines: disk_full_action = HALT disk_error_action = HALT
Verify the CA API Gateway forwards all log audit log messages to the central log server. Within the "/etc/rsyslog.conf" file, confirm a rule in the format "*.* @@loghost.log.com" is in the ruleset section. If the CA API Gateway "/etc/rsyslog.conf" file does not have a rule in the format "*.* @@loghost.log.com" in the ruleset section, this is a finding.
Configure the CA API Gateway to forward all audit log messages to the central log server. - Log in to CA API Gateway as root. - Open "/etc/rsyslog.conf" for editing. - Add a rule "*.* @@loghost.log.com" to the ruleset section of the "rsyslogd.conf" file.
Verify login as "root" (at the console) and "ssgconfig" have non-default passwords. The default password for "root" is "7layer" and the default password for "ssgconfig" is "7layer". If root or ssgconfig use default passwords, this is a finding.
Use the "passwd" command to set non-default passwords.
Verify the "root" (or its equivalent, renamed account) is listed in the password configuration files. If the "root" account is not listed in the password configuration files, this is a finding.
Configure the "root" account as the local account of last resort. Disable the "ssgconfig" account by destroying its password and making the login shell "/sbin/nologin".
Verify the CA API Gateway configuration files for passwords (/etc/login.defs, /etc/pam.d/password, /etc/pam.d/password-auth-ac, /etc/pam.d/system-auth, and /etc/pam.d/system-auth-ac) each have this line: PASS_MIN_LEN 15. If the CA API Gateway configuration files for passwords (/etc/login.defs, /etc/pam.d/password, /etc/pam.d/password-auth-ac, /etc/pam.d/system-auth, and /etc/pam.d/system-auth-ac) do not have the line requiring minimum 15-character password length, this is a finding.
In order to change the default setting: - Log in to Gateway via SSH. - Open /etc/login.defs. - Change the value for PASS_MIN_LENGTH to desired value. Then: - Change the PASS_MIN_LENGTH field to desired value in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac -- /etc/pam.d/system-auth -- /etc/pam.d/system-auth-ac Note: Must be a value of "15" or greater.
Verify the password attribute "difok" field is set to "8" in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac If the password attribute "difok" field is not set to "8" in these files, this is a finding.
Set the password attribute "difok" field is set to "8" in the following files: -- /etc/pam.d/password-auth -- /etc/pam.d/password-auth-ac
Verify expiry of account with command: chage -l "USERNAME" and look at the "Account expires" line for expiry date. If the expiry date is more than "72" hours after emergency account creation, this is a finding.
For existing accounts, set expiry time of an account using command: chage -E "YYYY-MM-DD" "USERNAME For new accounts, create using command: useradd -e <expiry_date> USERNAME where the expiry date in YYYY-MM-DD format is when you wish the account to expire.
Verify "/usr/local/bin/failtest" script exists and is executable. Verify crontab runs "/usr/local/bin/failtest" every minute by checking cron's logfile "/var/log/cron". If "/usr/local/bin/failtest" does not exist or it is not executable, this is a finding.
Install and configure (setup SNMP trap dest/authentication) alerter script in /usr/local/bin/failtest. Configure cron to run "/usr/local/bin/failtest" every minute as indicated by /etc/crontab entry
Verify "/usr/local/bin/alerter" script exists and is executable. Verify crontab runs "/usr/local/bin/alerter" every minute by checking cron's logfile /var/log/cron. If the "/usr/local/bin/alerter" script does not exist, this is a finding. If the "/usr/local/bin/alerter" script does not run every minute as a cron job, this is a finding. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }
Install and configure (setup SNMP trap dest/authentication) alerter script in /usr/local/bin/alerter. Run "/usr/local/bin/alerter -w" to write initial config to filesystem. Configure cron to run "/usr/local/bin/alerter -c" every minute. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash This script implements watching for changes in a system that may indicate unauthorized changes have been made to the system. It is designed to be run as "alerter -w" to capture the current configuration and then to be run out of cron on a regular basis as "alerter -c", which then compares the current configuration to the previously captured configuration. If the configuration has changed, an SNMP TRAP is sent using the "SNMPBASECMD" variable as the base "snmptrap" command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses "/var/run/alerter" as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }
Verify the CA API Gateway is configured to use LDAP or RADIUS+LDAP for all administrative accounts by using the "ssgconfig" account and using menu: 1) Configure system settings >> 4) Configure authentication method. Select the appropriate ldap/ldap+radius configuration and then verify its settings by continuing the menu process until it completes. If LDAP or RADIUS+LDAP is not configured for all administrative accounts, this is a finding.
Configure the Gateway to use LDAP or RADIUS+LDAP for all administrative accounts by using the "ssgconfig" account and using menu: 1) Configure system settings >> 4) Configure authentication method. Select the appropriate ldap/ldap+radius configuration and then set the appropriate settings for your environment by following the menu process until it completes.
Verify the Gateway (using "ssgconfig") is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.
Configure the Gateway using "ssgconfig" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.
Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.
Configure the Gateway using "ssgconfig" to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.
Verify the Gateway (using ssgconfig) is configured to use multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and verify the list of ntp servers is correct. If the CA API Gateway is not configured to use multiple ntp sources, this is a finding.
Configure the Gateway using ssgconfig to set multiple ntp sources using menu: 1) Configure system settings >> 1) Configure networking and system time settings. Walk through the query process until being queried for time servers and insert a comma-separated list of ntp time servers.
Verify "/usr/local/bin/alerter" script exists and is executable. Verify crontab runs "/usr/local/bin/alerter" every minute by checking cron's logfile /var/log/cron. If the "/usr/local/bin/alerter" script does not exist, this is a finding. If the "/usr/local/bin/alerter" script does not run every minute as a cron job, this is a finding. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }
Install and configure (setup SNMP trap dest/authentication) alerter script in "/usr/local/bin/alerter". Run "/usr/local/bin/alerter -w" to write initial config to filesystem. Configure cron to run "/usr/local/bin/alerter -c" every minute. An example follows. The SNMP destination host and username/password are configured by editing the shell variables near the beginning of the script. SNMPUSER should be set to the username recognized by the SNMP Management Station. SNMPENGINEID should be set to the SNMPv3 EngineID the Management Station uses for this application. SNMPHOST should be set to the hostname of the SNMP Management Station. This authentication configuration is placed in "/etc/snmp/snmp.conf": ----------------------------------- defSecurityLevel authPriv defAuthType SHA defPrivType AES defAuthPassphrase {password123} defPrivPassphrase {password123} ----------------------------------- This snmp alerter script is placed in "/usr/local/bin/alerter script": -------- #!/bin/bash # # This script implements watching for changes in a system that may indicate unauthorized # changes have been made to the system # # It is designed to be run as "alerter -w" to capture the current configuration and # then to be run out of cron on a regular basis as "alerter -c" which then compares the # current configuration to the previously captured configuration. If the configuration # has changed an SNMP TRAP is sent using the SNMPBASECMD variable as the base snmptrap command. # SNMPBASECMD will have to be configured appropriately depending on the exact SNMPv3 security # implemented on the SNMP Management Server. # # The script uses /var/run/alerter as a base directory to capture filesystem timestamps and # the installed RPM software list. SNMPUSER=myuser SNMPENGINEID=0x0102030405 SNMPHOST=rsbfreebsd.ca.com SNMPENTNUM="1.3.6.1.4.1.17304" SNMPNOTIF=".7.3.128" SNMPBASECMD="snmptrap -v 3 -n \"\" -u ${SNMPUSER} -e ${SNMPENGINEID} ${SNMPHOST} 0 ${SNMPENTNUM}.7.3.128.0 ${SNMPENTNUM}.7.3.129.0 s" ALERTER_ROOT=/var/run/alerter ACCOUNTFILES=("/etc/passwd" "/etc/shadow" "/etc/group") TSFILE=timestamps RPMFILE=rpmlist function usage { echo "$0 [-w | -c]" echo " -w - Write data" echo " -c - Compare current to data" echo " (at least one must be selected)" echo } function writeTsSummary { for file in ${ACCOUNTFILES[*]} do ts=$(stat -c '%Y' $file) echo $file $ts >> $ALERTER_ROOT/$TSFILE done } function writeRpmSummary { rpm -qa >> $ALERTER_ROOT/$RPMFILE } function writeSummaries { if [ ! -d $ALERTER_ROOT ] then mkdir $ALERTER_ROOT fi rm -f $ALERTER_ROOT/$TSFILE $ALERTER_ROOT/$RPMFILE writeTsSummary writeRpmSummary }
Verify "server" lines in the "/etc/ntp.conf" file are all marked with "autokey". Perform the command "ntpq -p" to show peer functioning. If the "server" lines in the "/etc/ntp.conf" file are not marked with "autokey", this is a finding. If the command "ntpq -p" does not show peers functioning, this is a finding.
Configure Gateway to use public key (autokey in NTP terminology) authentication. See: http://support.ntp.org/bin/view/Support/ConfiguringAutokey
Verify the "snmptrap" shell command used to emit SNMP TRAPS to the Network Management Station is using Version 3 with User Authentication for each potential trap source identified in this document. "snmptrap -v 3 -a SHA -A mypassword -x AES -X mypassword -l authPriv -u traptest -e 0x8000000001020304 localhost REQUIRED_TRAP_OID" If SNMP Version 3 is not being used, this is a finding.
Change the "snmptrap" command at each source to use encryption/authentication (Version 3) IE: "snmptrap -v 3 -a SHA -A mypassword -x AES -X mypassword -l authPriv -u traptest -e 0x8000000001020304 localhost REQUIRED_TRAP_OID"
Using the "ssgconfig" menu subsystem, confirm RADIUS has been configured via 1) Configure system settings >> 4) Configure authentication method item 3 or 4. Confirm password is set to "Enter the RADIUS shared secret [<Hidden>]". If RADIUS is not correctly configured, this is a finding.
Using the ssgconfig menu subsystem, confirm RADIUS has been configured via 1) Configure system settings >> 4) Configure authentication method item 3 or 4. Configure radius/ladap_radius as required.
Using the "ssgconfig" menu subsystem, confirm LDAP (Secure) has been configured via 1) Configure system settings >> 4) Configure authentication method item 2 or 4. Confirm the answer to the question "Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:" is "y". Ensure the answer to question "Specify the URL where the PEM formatted CA certificate can be located [ldaps://smldap.l7tech.com:636]:" is a trusted source of the certificate. If the LDAP is not correctly configured, this is a finding.
Using the "ssgconfig" menu subsystem, set LDAP (Secure) by 1) Configure system settings >> 4) Configure authentication method item 2 or 4. Set the answer to the question "Do you want to specify the URL to a PEM containing the certificate (y/n) [y]:" to "y". Set the answer to the question "Specify the URL where the PEM formatted CA certificate can be located [ldaps://smldap.l7tech.com:636]:" to a trusted source of the certificate.
Verify the LDAPS server certificate is in "/etc/openldap/cacerts". Verify TLS_REQCERT is set to demand in "/etc/openldap/ldap.conf". If the LDAPS server certificate is not in "/etc/openldap/cacerts", this is a finding. If "TLS_REQCERT" is not set to demand in "/etc/openldap/ldap.conf", this is a finding.
Configure LDAPS/LDAPS+RADIUS to use LDAPS server certificates for bidirectional authentication that is cryptographically based. Place the LDAPS server certificate in "/etc/openldap/cacerts". Set "TLS_REQCERT" to demand in "/etc/openldap/ldap.conf".
Verify the CA API Gateway drops packets by default and only puts non-Gateway services on trusted interfaces. Check for the following lines in "/etc/sysconfig/iptables": :INPUT DROP [0:0] :FORWARD DROP [0:0] [0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT Check for the following lines in "/etc/sysconfig/ip6tables": :INPUT DROP [0:0] [0:0] -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT [0:0] -A INPUT -i eth0 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth2 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth3 -p udp -m udp --dport 123 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 3306 -j ACCEPT [0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT If the CA API Gateway does not drop packets by default or puts non-Gateway services on untrusted interfaces, this is a finding. Verify the CA API Gateway logs and drops TCP packets with bad flags. Check for the following lines in "/etc/sysconfig/iptables": [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags [0:0] -A badflags -m limit --limit 15/min -j LOG --log-prefix "Badflags:" [0:0] -A badflags -j DROP Check for the following lines in "/etc/sysconfig/ip6tables": [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j badflags6 [0:0] -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j badflags6 [0:0] -A badflags6 -m limit --limit 15/min -j LOG --log-prefix "Badflags6:" [0:0] -A badflags6 -j DROP If the CA API Gateway does not log and drop TCP packets with bad flags, this is a finding. Verify the CA API Gateway only allows certain ICMPs and rate limits pings. Check for the following lines in "/etc/sysconfig/iptables": [0:0] -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT [0:0] -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 2/sec -j ACCEPT [0:0] -A INPUT -p icmp -j badflags [0:0] -A OUTPUT -p icmp -m state --state INVALID -j DROP Check for the following lines in "/etc/sysconfig/ip6tables": [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 1 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 3 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 129 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 128 -m limit --limit 2/sec -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 133 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 134 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 135 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 136 -j ACCEPT [0:0] -A INPUT -p icmpv6 -m icmpv6 --icmpv6-type 137 -j ACCEPT [0:0] -A INPUT -p icmpv6 -j badflags6 If the CA API Gateway does not only allow certain ICMPs and rate limits pings, this is a finding.
If the "iptables" file is not consistent, replace it with one from the distribution RPM. You may need to add additional permissions if some services are required.
Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.
Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"
Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.
Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"
Confirm the CA API Gateway file "/etc/audit/audit.rules" is the file as distributed using command: rpm -Vf /etc/audit/audit.rules If the string returned contains a "5" (ok: .......T., failure: S.5....T.), this is a finding.
Obtain a copy of the appropriate audit package RPM file from CA Support and install it using RPM: rpm -i "RPMFILE"
Verify by confirming the following lines are part of "rsyslogd.conf": # auditd audit.log $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor Further verify that this line is also part of the rsyslogd.conf file: local6.* @@loghost.ca.com If "rsyslogd.conf" does not contain the above lines, this is a finding.
Setup steps: Configure rsyslogd to monitor "/var/log/auditd/auditd.log" file for updates by adding stanza: # auditd audit.log $ModLoad imfile $InputFileName /var/log/audit/audit.log $InputFileTag tag_audit_log: $InputFileStateFile audit_log $InputFileSeverity info $InputFileFacility local6 $InputRunFileMonitor to the "/etc/rsyslogd.conf" file. Note: This creates audit log entries for facility "local6" and priority "info." This can be changed to suite. Configure "rsyslogd" to forward this combination (local6.info) to the appropriate loghost by adding logging rule to the rule section of the "rsyslogd.conf" file: local6.* @@loghost.ca.com Note that the syntax "@@loghost.ca.com" means that the records are forwarded via TCP. A single "@" before the remote loghost would mean the records are forwarded via UDP.
Examine "/etc/audit/audit.rules" to confirm any custom developed rules are contained within the file. If the "/etc/audit/audit.rules" does not contain the custom developed rules within the file, this is a finding.
The Gateway relies on the standard Linux audit subsystem. The subsystem is configurable by modifying /etc/audit/audit.rules. Custom rules can be added to this file. See the Linux man-page for audit.rules(7) for detail about specifying custom rules.
Verify "/etc/modprobe.d/ssg-harden.conf" contents are: install dccp /bin/false install sctp /bin/false install rds /bin/false install tipc /bin/false install net-pf-31 /bin/false install bluetooth /bin/false install usb-storage /bin/false options ipv6 disable=1 If the "/etc/modprobe.d/ssg-harden.conf" contents do not contain the above, this is a finding.
Set contents of "/etc/modprobe.d/ssg-harden.conf" file to: install dccp /bin/false install sctp /bin/false install rds /bin/false install tipc /bin/false install net-pf-31 /bin/false install bluetooth /bin/false install usb-storage /bin/false options ipv6 disable=1
Verify the CA API Gateway forwards all log audit log messages to the central log server. Within the "/etc/rsyslog.conf" file, confirm a rule in the format "*.* @@loghost.log.com" is in the ruleset section. If the CA API Gateway "/etc/rsyslog.conf" file does not have a rule in the format "*.* @@loghost.log.com" in the ruleset section, this is a finding.
Configure the CA API Gateway to forward all log audit log messages to the central log server. - Log in to CA API Gateway as root. - Open "/etc/rsyslog.conf" for editing. - Add a rule "*.* @@loghost.log.com" to the ruleset section of the rsyslogd.conf file.
This STIG is sunset and no longer updated. Compare the version running to the supported version by the vendor. If the system is using an unsupported version from the vendor, this is a finding.
Upgrade to a version supported by the vendor.