This improvement was originally proposed by Tomas Heinrich for USGCB content.
But it is applicable to SSG content too, therefore this post.
When checking the system for underlying value of ClientAliveInterval sshd config
variable it's not sufficient to check just for upper bound (if the present value is
less than required maximum), but it is necessary to check also for lower bound. Because
from the sshd_config manual page:
Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the
encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the
client. This option applies to protocol version 2 only.
The current form worked only for instances, not having ClientAliveInterval at all in the
config. But having had that value set to zero, would still pass (which is wrong, since as
mentioned above these messages would still not be sent). Thus this patch adds also check
if actual value is greater than zero.
Besides that it add some blank lines for better readability. Also removes Fedora version
of sshd_set_idle_timeout.xml rule and links to shared one.
Has been tested on RHEL-7 & Fedora-20 and seems to be working properly.
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
I remember that there were issues with the SSG content and RHEL6 (due to SCC
not supporting a sufficient version of...XCCDF? SCAP?). But previously, I
could still use SCC with the SSG content; it would just generate a few more
false positives than using OpenSCAP. Admittedly, it has been a while since
Now, when trying SCC 3.1.2, I can't make it run at all. After importing the
zip file (generated from git) and selecting the stig-rhel6-server-upstream
profile, a scan finishes almost immediately with:
The SCAP content stream <ssg-rhel6-> is not applicable to this
platform per the CPE definitions
I've tried on both RHEL6 Workstation and Server, and I've also tried
stripping the <platform> information from the XML files.
I'm attempting this for two reasons, as otherwise I'm perfectly happy
scanning with OpenSCAP. SCC has the ability to run a check on a single rule
at a time, which is useful. Also, I have an inspection soon, and they may
want me to use it.
Ray Shaw (Contractor, STG)
Army Research Laboratory
CIO, Unix Support
My systems failed the scans for CCE-26844-1 (Set Deny For Failed Password
Attempts), CCE-27110-6 (Set Lockout Time For Failed Password Attempts) and
CCE-27215-3 (Set Interval For Counting Failed Password Attempts). I was able
to resolve the first and last by following the fix text, but CCE-27110-6
remains a problem.
The fix text instructs me to add the following lines:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800
auth required pam_faillock.so authsucc deny=3 unlock_time=604800
... directly beneath the following line in /etc/pam.d/system-auth:
auth required pam_env.so
However, following these instructions results in a system whose GDM prompts
me for a username, but never gets to the password. The logs show "gkr-pam:
no password is available for user." I performed many Google searches, not
really finding much that helped me other than an old message in this group:
Unfortunately, I didn't see a resolution. The person who started that thread
opened a ticket, but it doesn't look like it was addressed:
He also referenced a Red Hat Solution that provides instructions on enabling
faillock; following this, I was able to restore my system to functionality.
I could login; if I failed my attempt three times, I could no longer login;
pam_tally2 no longer reported failed logins, but faillock did. I haven't yet
spent the week to determine whether or not the unlock_time parameter is
being applied (if you know of a way to report remaining time until an
account unlocks, that would help).
Is there any guidance available regarding passing this scan without
disabling my system?
Unix support, Army Research Labs