scap-security-guide November 2017

scap-security-guide@lists.fedorahosted.org

14 participants
8 discussions

Issue with Repo GPG Checking
by Trevor Vaughan 20 Oct '18

20 Oct '18

Hi All, I've been re-roaming through the SSG and this is probably the first of a many part thread regarding different checks. TL;DR; The potential risk caused by enabling 'repo_gpgcheck' outweighs any potential benefit if TLS is enabled. In my opinion, the following check should *only* be enabled if all of your repositories are internally managed xccdf_org.ssgproject.content_rule_ensure_gpgcheck_repo_metadata. The reason for this is that YUM presently does not (to my knowledge) have any way to differentiate between package signing GPG keys and repo signing GPG keys. This means that if, for instance, I host my packages via some shared Nexus, then I have to add the Nexus GPG key to my trust list for the repo. I fundamentally do *not* want to do this! I shouldn't be allowing my Nexus maintainer to potentially install software on my system without my explicit knowledge. You should use TLS, and the repo should have a trusted certificate there and that should be sufficient for the metadata until RPM can tell the difference between these two certificates. Please let me know if I've missed something, but I don't remember seeing options to split out the two sets of certs. Additionally, this is marked as 'high' severity and that seems to be massive overkill considering that 1) the packages are still signed and validated and 2) TLS is required. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

7 20

Re: Reg: Openscap scanning for SSH
by Jan Cerny 25 Nov '17

25 Nov '17

Hello, Great! Thanks for clarification. I have reported this issue upstream. You can track fixing the problem there. https://github.com/OpenSCAP/scap-security-guide/issues/2296 Regards Jan Černý Security Technologies | Red Hat, Inc. ----- Original Message ----- > From: "Jakub Jelen" <jjelen(a)redhat.com> > To: "Jan Cerny" <jcerny(a)redhat.com> > Cc: "Dushyant Uge" <duge(a)redhat.com>, "tech-list" <tech-list(a)redhat.com>, "SCAP Security Guide" > <scap-security-guide(a)lists.fedorahosted.org> > Sent: Tuesday, September 5, 2017 1:26:01 PM > Subject: Re: Reg: Openscap scanning for SSH > > On Tue, 2017-09-05 at 07:22 -0400, Jan Cerny wrote: > > Hi, > > > > Thank you very much for letting us know. > > > > I have looked into this issue. The rule "Allow Only SSH Protocol 2" > > checks if /etc/sshd_config cotains string "Protocol 2". > > See the implementation of this check: > > https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/te > > mplates/static/oval/sshd_allow_only_protocol2.xml > > > > Jakub, do I understand it well, that since RHEL 7.4 this > > configuration > > option doesn't exist anymore? Will the system always satisfy the > > requirement > > that only SSHv2 is allowed? What way do you recommend to check that > > this requirement is satisfied? > > > > I think If SSH v2 is the only option on RHEL 7.4, we should remove > > this rule from SCAP Security Guide for RHEL7 completely. > > I would not remove it. Some people might be running the old openssh > from RHEL7.3. I would say that every OpenSSH RPM package >=7.4 will > satisfy this rule. If we have older version, I would leave the check as > it was. Though not sure how to write it in your language :) > > Jakub > > > Dushyant, FYI, rules for OpenSCAP comes from "SCAP Security Guide" > > project, > > https://github.com/OpenSCAP/scap-security-guide > > which has a special mailing list: > > https://lists.fedorahosted.org/admin/lists/scap-security-guide.lists. > > fedorahosted.org/ > > If you run in similar problem in future, you can ask there directly > > :D > > I'm including the mailing list to this thread so that experts can > > chime in. > > > > > > Regards > > > > Jan Černý > > Security Technologies | Red Hat, Inc. > > > > ----- Original Message ----- > > > From: "Jakub Jelen" <jjelen(a)redhat.com> > > > To: "Dushyant Uge" <duge(a)redhat.com> > > > Cc: "tech-list" <tech-list(a)redhat.com>, jcerny(a)redhat.com > > > Sent: Tuesday, September 5, 2017 10:29:19 AM > > > Subject: Re: Reg: Openscap scanning for SSH > > > > > > On Tue, 2017-09-05 at 08:07 +0530, Dushyant Uge wrote: > > > > Hello Jakub Jelen, > > > > > > > > Thank you for your response. > > > > > > > > > > The rules in OpenSCAP needs to be updated to reflect this > > > > > > > > So, Are we in the process of updating OpenSCAP scanning rules? > > > > or Do we need to file a bugzilla ? > > > > > > I am not sure if the OpenSCAP team or SGG is aware of this issue. I > > > added Jan, who should know better. > > > > > > > > > > > On Mon, Sep 4, 2017 at 5:08 PM, Jakub Jelen <jjelen(a)redhat.com> > > > > wrote: > > > > > > > > > On Mon, 2017-09-04 at 11:02 +0530, Dushyant Uge wrote: > > > > > > Hello, > > > > > > > > > > > > While scanning RHEL7 system with openscap below are results > > > > > > for > > > > > > ssh > > > > > > protocol2 > > > > > > > > > > > > ------------------------------------- > > > > > > oval:ssg-sshd_allow_only_protocol2:def:1 false compliance > > > > > > [20140414], > > > > > > [sshd_allow_only_protocol2] Ensure Only Protocol 2 > > > > > > Connections > > > > > > Allowed > > > > > > ------------------------------------- > > > > > > > > > > > > Customer has below concern -- > > > > > > > > > > > > The description in the openscap-workbench: > > > > > > Only SSH protocol version 2 connections should be permitted. > > > > > > The > > > > > > default > > > > > > setting in /etc/ssh/sshd_config is correct, and can be > > > > > > verified > > > > > > by > > > > > > ensuring > > > > > > that the following line appears: Protocol 2 > > > > > > > > > > > > While doing Since this is the default, the check should NOT > > > > > > be > > > > > > for > > > > > > "2", but > > > > > > to make sure that "1" is NOT present. > > > > > > > > > > > > Is this a valid implementation request ? > > > > > > > > > > > > Please suggest. > > > > > > > > > > > > > > > > The SSH-1 protocol was removed in RHEL7.4 (openssh-7.4p1 and > > > > > newer) > > > > > therefore the configuration files will not contain Protocol > > > > > option > > > > > nor > > > > > sshd -T will output it. The rules in OpenSCAP needs to be > > > > > updated > > > > > to > > > > > reflect this > > > > > > > > > > https://access.redhat.com/articles/3022681 > > > > > > > > > > > -- > > > Jakub Jelen > > > Software Engineer > > > Security Technologies > > > Red Hat, Inc. > > > > -- > Jakub Jelen > Software Engineer > Security Technologies > Red Hat, Inc. >

2 1

Question about missing OVAL checks
by Olivier BONHOMME 22 Nov '17

22 Nov '17

Hello everybody, I'm still working in checking how many STIG rules have implemented checks in OpenSCAP profiles. When executing oscap eval command, I identified that there are several checks in status notchecked. After some investigation, I identified that there was no oval checks availables for these rules. After reading some documentation about OVAL language, I was wondering if it will be possible to implement a check for these rules. For example, for the rule "homedirs must exist", the check consists in doing a "pwchk -r" in order to identify if the homedirs exists or not. With a shell script I know how to do that but in OVAL, i'm not sure if it is possible. So I have several questions about these kind of checks : - Is it possible to implement them using OVAL with an oval rule which can do result command checks ? - Is it possible to implement these checks using another language. I heard about SCE but it seems to be only for OpenSCAP. - Will these checks stay manual checks with notchecked status on SSG ? Thanks for your answers. Regards, Olivier Bonhomme

4 4

Why does this test fail?
by Geller, Gregory Maximilian 16 Nov '17

16 Nov '17

First of all, apologies in advance if this is not the correct forum for this question. I'm new to all things SCAP. I'll try to be as concise as possible. Here's the command I'm running: oscap oval eval --report $OUTDIR/$OUTFILE /usr/share/scap_content/vulnerabilities/Red_Hat_Enterprise_Linux_7.xml Here's the result I get for a specific test having to do with java-1.7.0-openjdk: Rule oval:com.redhat.rhsa:def:20162658 Result false Class patch Ident [RHSA-2016:2658-03], [CVE-2016-5542], [CVE-2016-5554], [CVE-2016-5573], [CVE-2016-5582], [CVE-2016-5597] Title RHSA-2016:2658: java-1.7.0-openjdk security update (Important) My first question is...why does this test return false if I don't have java installed at all? My second question is...how can I modify the test to make it return true if java is not installed on the machine? Thanks! Greg

2 2

stig-overlays.xml usage
by Olivier BONHOMME 16 Nov '17

16 Nov '17

Dear OpenScap community, I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 version) coverage against STIG 1.3 release. While browsing the 0.1.36 release, I discovered the stig-overlays.xml which shows the matching between SSG rule and STIG rule. Can anybody confirm that I can use that file in order to check the coverage rate of the SSG profile ? Thanks for your answers. Regards, Olivier Bonhomme

3 5

CentOS CESA OVAL file
by 面和毅 16 Nov '17

16 Nov '17

Dear all, I'm writing openscap article for Web magazine(ThinkIT/Japan) , then I found CentOS OVAL file's CESA-2017:XX is not included on it. https://oval.cisecurity.org/repository/download/5.11.1/compliance/centos_li… Does somebody know how is the status for the xml file? I wish to update it if it will not be released, but before do it I just want to know is there any reason to stop to develop the xml file. Also, I modified Red Hat OVAL file for CentOS 7. But I guess there is some problem if I publish it on my github, right? https://www.redhat.com/security/data/oval/ Kind Regards, OMO -- Kazuki Omo: ka-omo(a)sios.com OSS &Security Evangelist OSS Business Planning Dept. CISSP #366942 Tel: +81364015149

3 3

screen vs vlock
by Trevor Vaughan 15 Nov '17

15 Nov '17

Is there a reason that 'screen' was chosen over or 'vlock' for xccdf_org.ssgproject.content_rule_package_screen_installed? 'vlock' is the more target specific and allows for locking *all* user consoles by running 'vlock -a'. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

4 8

Email vs Syslog
by Trevor Vaughan 14 Nov '17

14 Nov '17

Hi Again, I'm noticing that there are a LOT of items that say to push to Email when Syslog is a viable option but there is no mandate to set up an Email server on the system. Personally, I'm finding that automated Syslog analysis is more ubiquitous than automated Email alert processing and think that these should be changed to Syslog by default since that is guaranteed to be working on the system per the SSG. If Email is going to be the mechanism in use, then the SSG should require that an Email server be installed and configured properly on the local host since firing messages off into the ether is not a guaranteed delivery mechanism for critical alerts. Additionally, like Syslog, there would need to be a check to ensure that the system is forwarding Email to a remote host. Thoughts? Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 -- This account not approved for unencrypted proprietary information --

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide November 2017