All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste). I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes' and typically the checks are looking for the presence of the target string, not the absence of it.
Any input would be appreciated.
Thanks,
Les Kimmel Systems Engineer, CSC
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new <sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed. Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible. This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
Let me know if I can help.
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new <sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
I am actually running this against a RHEL7 system at the moment. I have added '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I figure this shouldn't matter since it's just doing a pattern match against a properties file that's essentially the same on RHEL6 and RHEL7. I am using the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then tailoring, deselecting all and then only selecting the following:
-Group 'Configure OpenSSH Server if Necessary' --Allow only ssh protocol 2 --Set SSH idle timeout interval --Set ssh client alive count --Disable host-based authentication --Disable SSH Root Login --Disable SSH Access via Empty passwords --Enable ssh warning banner --Do not allow ssh environment options --Use only approved ciphers
I built the system manually without any kickstart. I have not yet edited the sshd_config file and I see that some of the items being checked are in the sshd_config file but are commented out. When I run the scan all of these items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses 'check-existence='all_exist' which I assume means that it requires this value to be found in the config file. This refers to obj:1523 which looks for the following pattern:
^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
I interpret this as checking for a line that starts with (case insensitive) ClientAliveCountMax followed by one or more spaces and one or more digits. I'm not sure the point of (?:|(?:#.*))?. I assume that it was intended to possibly allow for the possibility of the keyword not existing or being commented out. However, because all of the stuff at the beginning of the line is not grouped I think it is mandatory and this should be checking firmly for the existence of an uncommented line beginning with 'ClientAliveCountMax'. While it does not exist in the config file it still passes. There must be something else going on here.
Date: Thu, 11 Jun 2015 10:18:54 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
OK, so I just ran the same test against a RHEL6 system and the items that should fail do fail. However, the PermitRootLogin options is commented out in the sshd_config but still passes. Looking into this the object defines the test as 'none_exist' against a pattern match for 'PermitRootLogin yes'. So in this case it appears to be allowing the default (PermitRootLogin no) instead of checking for the explicit existence of the key/value pair. So, it appears that these things are working as expected on RHEL6. I may have wasted your time.
Why would this not work on RHEL7?
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 09:47:28 -0500 CC: scap-security-guide@lists.fedorahosted.org
I am actually running this against a RHEL7 system at the moment. I have added '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I figure this shouldn't matter since it's just doing a pattern match against a properties file that's essentially the same on RHEL6 and RHEL7. I am using the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then tailoring, deselecting all and then only selecting the following:
-Group 'Configure OpenSSH Server if Necessary' --Allow only ssh protocol 2 --Set SSH idle timeout interval --Set ssh client alive count --Disable host-based authentication --Disable SSH Root Login --Disable SSH Access via Empty passwords --Enable ssh warning banner --Do not allow ssh environment options --Use only approved ciphers
I built the system manually without any kickstart. I have not yet edited the sshd_config file and I see that some of the items being checked are in the sshd_config file but are commented out. When I run the scan all of these items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses 'check-existence='all_exist' which I assume means that it requires this value to be found in the config file. This refers to obj:1523 which looks for the following pattern:
^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
I interpret this as checking for a line that starts with (case insensitive) ClientAliveCountMax followed by one or more spaces and one or more digits. I'm not sure the point of (?:|(?:#.*))?. I assume that it was intended to possibly allow for the possibility of the keyword not existing or being commented out. However, because all of the stuff at the beginning of the line is not grouped I think it is mandatory and this should be checking firmly for the existence of an uncommented line beginning with 'ClientAliveCountMax'. While it does not exist in the config file it still passes. There must be something else going on here.
Date: Thu, 11 Jun 2015 10:18:54 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Oh...I think it's because it also checks if sshd is disabled and since RHEL7 is using systemd the check thinks sshd is disabled the remaining checks pass.
So sorry to waste your time. I am just trying to move forward with hardening new RHEL7 servers in the absence of complete RHEL7 SSG content so I was using RHEL6. Almost all other tests worked as expected but this was written a bit differently.
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 10:07:13 -0500 CC: scap-security-guide@lists.fedorahosted.org
OK, so I just ran the same test against a RHEL6 system and the items that should fail do fail. However, the PermitRootLogin options is commented out in the sshd_config but still passes. Looking into this the object defines the test as 'none_exist' against a pattern match for 'PermitRootLogin yes'. So in this case it appears to be allowing the default (PermitRootLogin no) instead of checking for the explicit existence of the key/value pair. So, it appears that these things are working as expected on RHEL6. I may have wasted your time.
Why would this not work on RHEL7?
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 09:47:28 -0500 CC: scap-security-guide@lists.fedorahosted.org
I am actually running this against a RHEL7 system at the moment. I have added '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I figure this shouldn't matter since it's just doing a pattern match against a properties file that's essentially the same on RHEL6 and RHEL7. I am using the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then tailoring, deselecting all and then only selecting the following:
-Group 'Configure OpenSSH Server if Necessary' --Allow only ssh protocol 2 --Set SSH idle timeout interval --Set ssh client alive count --Disable host-based authentication --Disable SSH Root Login --Disable SSH Access via Empty passwords --Enable ssh warning banner --Do not allow ssh environment options --Use only approved ciphers
I built the system manually without any kickstart. I have not yet edited the sshd_config file and I see that some of the items being checked are in the sshd_config file but are commented out. When I run the scan all of these items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses 'check-existence='all_exist' which I assume means that it requires this value to be found in the config file. This refers to obj:1523 which looks for the following pattern:
^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
I interpret this as checking for a line that starts with (case insensitive) ClientAliveCountMax followed by one or more spaces and one or more digits. I'm not sure the point of (?:|(?:#.*))?. I assume that it was intended to possibly allow for the possibility of the keyword not existing or being commented out. However, because all of the stuff at the beginning of the line is not grouped I think it is mandatory and this should be checking firmly for the existence of an uncommented line beginning with 'ClientAliveCountMax'. While it does not exist in the config file it still passes. There must be something else going on here.
Date: Thu, 11 Jun 2015 10:18:54 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Jan;
Again, I really appreciate your input and I'm sorry to flood your inbox. But, since I figured out what I was doing wrong I got to looking at the state of the RHEL7 content and I see that to get around this issue there is just not a check of whether the SSHD service is installed and/or running. Presumably, it is up to the SCAP validation tool developer to implement functions that utilize the 'runlevel_test' elements to determine if a service is installed/running. Have these types of functions just not been implemented in the RHEL7 version of OpenSCAP?
(This should be my last question for a while)
-Lesley Kimmel
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 10:10:35 -0500 CC: scap-security-guide@lists.fedorahosted.org
Oh...I think it's because it also checks if sshd is disabled and since RHEL7 is using systemd the check thinks sshd is disabled the remaining checks pass.
So sorry to waste your time. I am just trying to move forward with hardening new RHEL7 servers in the absence of complete RHEL7 SSG content so I was using RHEL6. Almost all other tests worked as expected but this was written a bit differently.
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 10:07:13 -0500 CC: scap-security-guide@lists.fedorahosted.org
OK, so I just ran the same test against a RHEL6 system and the items that should fail do fail. However, the PermitRootLogin options is commented out in the sshd_config but still passes. Looking into this the object defines the test as 'none_exist' against a pattern match for 'PermitRootLogin yes'. So in this case it appears to be allowing the default (PermitRootLogin no) instead of checking for the explicit existence of the key/value pair. So, it appears that these things are working as expected on RHEL6. I may have wasted your time.
Why would this not work on RHEL7?
From: ljkimmel99@hotmail.com To: jlieskov@redhat.com Subject: RE: RHEL6 SSG Bug (SSH,Ciphers) Date: Thu, 11 Jun 2015 09:47:28 -0500 CC: scap-security-guide@lists.fedorahosted.org
I am actually running this against a RHEL7 system at the moment. I have added '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I figure this shouldn't matter since it's just doing a pattern match against a properties file that's essentially the same on RHEL6 and RHEL7. I am using the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then tailoring, deselecting all and then only selecting the following:
-Group 'Configure OpenSSH Server if Necessary' --Allow only ssh protocol 2 --Set SSH idle timeout interval --Set ssh client alive count --Disable host-based authentication --Disable SSH Root Login --Disable SSH Access via Empty passwords --Enable ssh warning banner --Do not allow ssh environment options --Use only approved ciphers
I built the system manually without any kickstart. I have not yet edited the sshd_config file and I see that some of the items being checked are in the sshd_config file but are commented out. When I run the scan all of these items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses 'check-existence='all_exist' which I assume means that it requires this value to be found in the config file. This refers to obj:1523 which looks for the following pattern:
^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
I interpret this as checking for a line that starts with (case insensitive) ClientAliveCountMax followed by one or more spaces and one or more digits. I'm not sure the point of (?:|(?:#.*))?. I assume that it was intended to possibly allow for the possibility of the keyword not existing or being commented out. However, because all of the stuff at the beginning of the line is not grouped I think it is mandatory and this should be checking firmly for the existence of an uncommented line beginning with 'ClientAliveCountMax'. While it does not exist in the config file it still passes. There must be something else going on here.
Date: Thu, 11 Jun 2015 10:18:54 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 4:47:28 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
I am actually running this against a RHEL7 system at the moment. I have added '<platform idref="cpe:/o:redhat:enterprise_linux:7"/>' to allow it to run. I figure this shouldn't matter since it's just doing a pattern match against a properties file that's essentially the same on RHEL6 and RHEL7. I am using the default profile 'C2S for Red Hat Enterprise Linux 6'. I am then tailoring, deselecting all and then only selecting the following:
-Group 'Configure OpenSSH Server if Necessary' --Allow only ssh protocol 2 --Set SSH idle timeout interval --Set ssh client alive count --Disable host-based authentication --Disable SSH Root Login --Disable SSH Access via Empty passwords --Enable ssh warning banner --Do not allow ssh environment options --Use only approved ciphers
I built the system manually without any kickstart. I have not yet edited the sshd_config file and I see that some of the items being checked are in the sshd_config file but are commented out. When I run the scan all of these items pass. As an example, tst:470 checks for 'ClientAliveCountMax'. It uses 'check-existence='all_exist' which I assume means that it requires this value to be found in the config file. This refers to obj:1523 which looks for the following pattern:
^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*(?:|(?:#.*))?$
I interpret this as checking for a line that starts with (case insensitive) ClientAliveCountMax followed by one or more spaces and one or more digits. I'm not sure the point of (?:|(?:#.*))?.
The "(?:|" part of the pattern above was added to allow the check to succeed if the ClientAliveCountMax directive would be present as the last one in the /etc/ssh/sshd_config file (IOW 'ClientAliveCountMax digit' would be last item before EOF without the newline).
And "(?:#.*)" handles case when 'ClientAliveCountMax digit' would be followed by comment in sshd_config, IOW it would have the form of:
ClientAliveCountMax digit # Set ClientAliveCountMax to digit per security requirements
where 'digit' would be the actual number.
Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Technologies Team
I assume that it was intended to possibly allow for the possibility of the keyword not existing or being commented out. However, because all of the stuff at the beginning of the line is not grouped I think it is mandatory and this should be checking firmly for the existence of an uncommented line beginning with 'ClientAliveCountMax'. While it does not exist in the config file it still passes. There must be something else going on here.
Date: Thu, 11 Jun 2015 10:18:54 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
thank you for your reply.
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "Jan Lieskovsky" jlieskov@redhat.com Cc: "SCAP Security Guide" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 3:31:14 PM Subject: RE: RHEL6 SSG Bug (SSH,Ciphers)
Jan;
Thanks for the detailed feedback. I understand the reasoning now. I also think that it is always safest to go ahead and explicitly place those options in the configuration files (in this case sshd_config). My concern, though, is that without having modified sshd_config AT ALL every OVAL check passed.
Assuming here you mean all sshd checks passed without any change being performed to sshd_config. Can you be more specific which profile you used for scan and also which Red Hat Enterprise Linux 6 version was this scan performed at? Was it RHEL-6.7 Beta already?
I will try to reproduce the behaviour in between but as much as possible concrete details would be helpful to identify the reason quicker.
Just to confirm, the system in question having the above behaviour wasn't installed using on of the kickstarts from the RHEL/6/kickstart directory, right? (because in that case it would be expected all the rules would pass when performing a scan).
Typically, I run the SCAP tools once to give me a starting point and begin fixing the Failed and Unchecked items from there. Had I not had so much experience hardening RHEL systems I would have overlooked these sshd configurations because they all reported as passed. I would submit that these tests should all fail if the setting is not present and uncommented.
Also, on a more general note/question would it be possible to do a "match all" type of scenario for configuration directives with many required options/arguments so that it wasn't necessary to ensure that they match the exact order specified in the OVAL check. For example, I was configuring auditd yesterday. I copied stig.rules from /usr/share/doc/audit-<version> to /etc/audit/rules.d. Even though the items in stig.rules meet all of the requirements outlined in the SSG many of the checks fail because the options aren't listed in the same order as they are in the OVAL. Here's a concrete example:
stig.rules contains: -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -F exit=-EACCES -f auid>=500 -F auid!=4294967295 -k acess
The OVAL, in this case, checks for: ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?-S\s+creat\s+-S\s+open\s+-S\s+openat\s+-S\s+truncate\s+-S\s+ftruncate\s+-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
As you can tell the 'stig.rules' contains an extra syscall (open_by_handle_at) which will cause this check to always fail unless either the OVAL is updated or the audit rule is modified to match the check exactly. It might make more sense to check multiple patterns and require that they all pass:
^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+creat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+open.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+openat.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$ AND ^-a\s+always,exit\s+(-F\s+arch=(b64|b32)\s+)?.*-S\s+truncate.*-F\s+exit=-EPERM\s+-F\s+auid>=500\s+-F\s+auid!=4294967295\s+-k\s+[-\w]+\s*$
Note the '.*' bookending the actual syscall being matched in each test.
This looks like reasonable request / enhancement. We are trying to write audit / OVAL rules in general as tight as possible, so they wouldn't allow invalid configurations. But on the other hand they should be flexible enough to allow / PASS on different forms of valid configuration(s).
Although I am aware that this begins to make the OVAL content much more bulky and we are probably trying to make it as terse as possible.
The OVAL content doesn't need to be terse. It should be readable (read as after looking at it it should be visible what's it is doing), but doesn't necessarily need to be short, when / where more complexity is necessary it to be appropriate.
This is probably also a special case because most services don't include templates like auditd. Anyway, I'm just trying to open up a discussion and possibly help out.
There's always space for enhancements. Couple of months ago we didn't even have audit OVAL checks for all audit rules. Now we have them (or at least for majority of them AFAICT), and we definitely can / should enhance them to properly handle all the nuances of the correct configuration(s).
Let me know if I can help.
Depends on the way you are willing to help. You are helping already showing us to see the issues not seen till now :) (or seen already, but not finding time to address them till now).
But if you want to help even more (like want to create concrete patches and GitHub pull requests for review), you are definitely welcome to do so (more eyes can recognize more issues and even fix them quicker).
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Thanks again! -Lesley Kimmel
Date: Thu, 11 Jun 2015 05:27:15 -0400 From: jlieskov@redhat.com To: ljkimmel99@hotmail.com CC: scap-security-guide@lists.fedorahosted.org Subject: Re: RHEL6 SSG Bug (SSH,Ciphers)
Hello Lesley,
----- Original Message -----
From: "Lesley Kimmel" ljkimmel99@hotmail.com To: "SSG" scap-security-guide@lists.fedorahosted.org Sent: Thursday, June 11, 2015 12:14:56 AM Subject: RHEL6 SSG Bug (SSH,Ciphers)
All;
I ran into a bug in the latest SSG for RHEL6 (0.1.21-2). There is definitely an issue with the check for approved Ciphers. Initially the check passed with no entry at all for Ciphers. I then placed a Cipher line with (1) valid cipher: pass. Finally I put an entry in sshd_config with a bogus cipher: passed. I just ran into this at the end of my workday today so I didn't get much of a chance to analyze it. Plus I'm really just starting to dig into the 'innards' of the content so I don't fully realize the connections of all the various sections (rule/def/tst/obj/ste).
Thank you for the report. I will have a look into this issue && report the findings back once obtained.
I'm also pretty sure that some of the other checks against sshd_config are off. The check for 'PermitRootLogin no' passed even though the file contains '#PermitRootLogin yes
For this part it is possible the corresponding regular expression doesn't honours comments properly. I will double check that (btw would be good if you could try the very same with the most recent scap-security-guide 0.1.22 version from upstream's Git, since it's possible it got corrected upstream in between already). But I will double check that, and report back.
' and typically the checks are looking for the presence of the target string, not the absence of it.
For the last part ("the checks are looking for the presence of the target string, not the absence of it" - this is motivated by the "nature" of the sshd service and it's config file /etc/ssh/sshd_config.
A bit longer story about sshd hopefully without too much gory details being as follows - sshd besides loading settings from /etc/sshd/sshd_config file honours also internal "default" options / settings. To mention an example -- "Protocol 2" directive has become a default setting starting from certain sshd version. The implication of these internal "default" settings being that in order to obtain the exact sshd configuration, that will be actually used, it is not sufficient to inspect the content of /etc/ssh/sshd_config file, because it will not list / contain all the settings that will be actually applied.
The only way how to obtain the real settings is to run the "sshd -T" command, which will print out the real settings. Since in the OVAL checks it is not possible to run external / arbitrary commands (this limitation is one of the features of the OVAL language), it is not possible within sshd OVAL checks to run "sshd -T" to obtain final configuration, and therefore it is not possible reliably to verify if some setting is applied or not (it might be applied despite not being explicitly present in the /etc/ssh/sshd_config file. Like it is the case for the "Protocol 2" default internal setting for some time already).
Since we can't inspect the values of internal "default" options, the only way how for sure to tell if the system is configured properly, is to require the option being explicitly present in the /etc/ssh/sshd_config file. In other words we still require the "Protocol 2" directive to be explicitly present in the /etc/ssh/sshd_config file even when "Protocol 2" internal setting has become "default" already and it's very unlikely some sshd setting would use "Protocol 1" version. The obvious implication of this approach being that the sshd OVAL checks might report false negatives in some cases (system is configured properly due to the use of safe internal "default" value, but since the particular option isn't present in /etc/ssh/sshd_config [it's the sshd's default, so it's not necessary to be listed there, since it will be used anyway], we are reporting failure like in the case the system would be configured improperly).
There of course is a way how to report proper sshd results - add a new
<sshd_test> probe to the 5.12 version of the OVAL language that would internally run "sshd -T" command when querying sshd options.
That way we would truly inspect sshd options, that would be really applied. But it is not a short-term solution (it takes time till the proposal is accepted into OVAL language, it takes time till the new feature is implemented, and last but not least it would work only on those OVAL scanner versions supporting OVAL 5.12 language versions. IOW till this is implemented, I am afraid we don't have a different option, just to explicitly require some option to be present in /etc/ssh/sshd_config even when this might lead to reporting false negatives in some cases).
Any input would be appreciated.
Hope the above explains the background / motivations behind requiring presence of an options a bit. FWIW regarding those two reported issues (Ciphers check && PermitRootLogin reporting PASS also with '#PermitRootLogin no' setting) I will inspect them yet && report the findings back.
Thanks,
Thank you && Regards, Jan.
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Les Kimmel Systems Engineer, CSC
-- SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
scap-security-guide@lists.fedorahosted.org
-
Jan Lieskovsky -
Lesley Kimmel