----- Original Message ----- > From: "Lesley Kimmel" <[email protected]> > To: "Jan Lieskovsky" <[email protected]> > Cc: "SCAP Security Guide" <[email protected]> > 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: [email protected] > > To: [email protected] > > CC: [email protected] > > Subject: Re: RHEL6 SSG Bug (SSH,Ciphers) > > > > Hello Lesley, > > > > thank you for your reply. > > > > ----- Original Message ----- > > > From: "Lesley Kimmel" <[email protected]> > > > To: "Jan Lieskovsky" <[email protected]> > > > Cc: "SCAP Security Guide" <[email protected]> > > > 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: [email protected] > > > > To: [email protected] > > > > CC: [email protected] > > > > Subject: Re: RHEL6 SSG Bug (SSH,Ciphers) > > > > > > > > Hello Lesley, > > > > > > > > ----- Original Message ----- > > > > > From: "Lesley Kimmel" <[email protected]> > > > > > To: "SSG" <[email protected]> > > > > > 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 > > > > > [email protected] > > > > > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide > > > > > https://github.com/OpenSCAP/scap-security-guide/ > > > > -- SCAP Security Guide mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
