scap-security-guide August 2017

scap-security-guide@lists.fedorahosted.org

16 participants
15 discussions

Re: Time to drop bash remediations?
by Sean 05 Aug '17

05 Aug '17

I agree with keeping the bash remediations. I make use of this projects bash remediations as a reference for my project...sort of a second opinion. Like Trevor said in #3, Ansible is not a great prospect to use in production environments on secured networks. Automated, remote, privileged execution isn't a concept that's easy to get past the cyber security folks. There is a catch-22 with this in the DoD arena though...We're all required to overlook RHEL-06-000529/RHEL-07-010340 with regard to allowing ACAS to run scans on our systems with unchallenged privilege escalation. I tried to propose using SSH keys, SSH Agent, and pam_ssh_agent_auth, but we can't find anyone involved with ACAS who can speak intelligently about the topic. Anyway, the project I work on is similar to Trevor's in that we use Puppet. Since Puppet is an agent process, which runs as root, and is secured with client ssl certificates, the "server" is never doing a remote execution. The agent requests it's configuration from the server, the server authenticates the agent by the ssl certificate and provides the data. Most of you probably know this already. P.S. Trevor's SIMP project is way cooler than mine, especially if you appreciate stylish, elegant, functional puppet modules! My project is more like a rusty old ford truck - it gets the job done, but don't expect better than 10 gallons to the mile. --Sean On Fri, Aug 4, 2017 at 9:34 AM, Trevor Vaughan <tvaughan(a)onyxpoint.com> wrote: > There are a few other considerations that I would like to mention. > > 1) Ansible is **NOT** agentless. It needs SSH to be an agent. SSH should > not be a requirement for a functional system since, in many production use > cases, it is an unnecessary service. And, being an unnecessary service, per > policy, SSH should not be running. > > 2) Ansible local is fine and can be run through many means, but as > mentioned by Wesley, RHEL6 isn't much fun. > > 3) Having any account that has the power that Ansible requires should be > isolated away from the rest of your production environment. IIRC, we > discourage users from running privileged commands as root without explicit > sets of sudo rules in place to constrain them. In theory, all sets of > Ansible playbooks should come with an associated set of 'sudo' rules to be > installed on the system. Additionally, use of Ansible should be constrained > to a bastion that restricts users from running in parallel so that auditing > is solid. Perhaps this could be a set of dynamically created containers > that churn out independent audits? > > Anyway, omnipotent SSH accounts were always up for tight scrutiny and > there really needs to be an addition to the SSG targeting Ansible as part > of the Red Hat stack since it's fundamentally just SSH in a loop. > > Thanks, > > Trevor > > On Thu, Aug 3, 2017 at 7:27 AM, Wesley Ceraso Prudencio < > wcerasop(a)redhat.com> wrote: > >> We discussed this idea internally as well, and we came up with the >> following reasons to not go further with it: >> >> - why remove something we already have? there is no harm in keeping it >> - ansible is problematic on rhel6 due to python version >> - --remediate would stop working >> - bash is mentioned in the XCCDF spec, ansible @system is something we >> made up >> - in RHEL8 we could have ansible as default system for remediation >> >> ----- Original Message ----- >> From: "Shawn Wells" <shawn(a)redhat.com> >> To: scap-security-guide(a)lists.fedorahosted.org >> Sent: Wednesday, August 2, 2017 1:40:18 AM >> Subject: Re: Time to drop bash remediations? >> >> >> >> On 8/1/17 7:25 PM, Gabe Alford wrote: >> > I say we keep bash scripts as other distros will probably need them. >> > Plus, I would think that we would want to handle environments where >> > ansible will never be used. >> >> Psh.... what other Linux distros? =P >> >> You're totally right. And that definitely means we need to continue >> carrying bash remediations. >> _______________________________________________ >> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo >> rahosted.org >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org >> _______________________________________________ >> scap-security-guide mailing list -- scap-security-guide(a)lists.fedo >> rahosted.org >> To unsubscribe send an email to scap-security-guide-leave@list >> s.fedorahosted.org >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 x788 <(410)%20541-6699> > > -- This account not approved for unencrypted proprietary information -- > > _______________________________________________ > scap-security-guide mailing list -- scap-security-guide@lists. > fedorahosted.org > To unsubscribe send an email to scap-security-guide-leave@ > lists.fedorahosted.org > >

2 1

sshd issues
by Paige, David B CTR USARMY ICOE (US) 04 Aug '17

04 Aug '17

There are some issues in the STIG for Red Hat Enterprise Linux 7 Server, profile: stig-rhel7-server-upstream in ssg-rhel7-xccdf.xml. The first is "Use Only FIPS Approved MACs", RHEL-07-040620. The STIG indicates that only hmac-sha2-512 and hmac-sha2-256 should be used. However, the remediation script adds hmac-sha1 to the list of MACs. Removing hmac-sha1 causes the test to fail. Also, the reference listed is incorrect. It should be RHEL-07-040400. Also, in one instance when performing a remediation, the MACs line appended to the last line of /etc/ssh/sshd_config, causing sshd to fail. The second is "Use Only Approved Ciphers", RHEL-07-040110. The STIG indicates that the line should be listed as follows: Ciphers aes128-ctr,aes192-ctr,aes256-ctr However, the remediation script adds aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc. Removing these cbc and 3des ciphers causes the check to fail.

2 1

Time to drop bash remediations?
by Shawn Wells 04 Aug '17

04 Aug '17

RHEL 7.4 is out! That means we can now be public on how Ansible is shipping as part of the rhel-7-server-extras-rpms channel: https://access.redhat.com/downloads/content/ansible/2.3.1.0-3.el7/noarch/fd… Now that we can ensure every RHEL install has access to Ansible, is it time to remove the bash scripts? The original premise of bash script inclusion was "bash is everywhere RHEL is" ..... and now Ansible carries the same truth. Potential downside for discussion: Ansible binaries ship in the extras channel versus the core rhel-7-server (or whatever it's called). Will users mind enabling the extras channel?

6 6

RHEL 7.4 oscap-anaconda - profile descriptions
by Shawn Wells 03 Aug '17

03 Aug '17

Hey Guys Just downloaded the RHEL 7.4 installation media and attempted to use the oscap-anaconda features. Selected "security" during the installer, and noticed a few things: (1) The CUI/NIST 800-171 profile has the description from OSPP: (2) There are multiple RHEL7 STIG options: I'm not sure how/why this is happening. The 800-171 profile does extend OSPP. Do we need a "extends" for the profile description field? https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/pr…

3 5

Logon Banner Text issue
by Paige, David B CTR USARMY ICOE (US) 01 Aug '17

01 Aug '17

I believe that the logon banner text is incorrect in the open-scap. The part is issue is this line: -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. There are no spaces around the double-dash. A common error is to put spaces there. The text is correct at this link, which should be publically accessible. https://iase.disa.mil/Documents/unclass-consent_banner.zip This affects RHEL-07-010030, plus checks such as RHEL-07-010050. Incidentally, the banner text in the Red Hat Enterprise Linux 7 Security Technical Implementation Guide :: Release: 2 Benchmark Date: 28 Jul 2017 ha the correct text in the check content, but not in the fix text. Even DISA has issues keeping it straight. David Paige, CISSP USAICoE CIO/G6, Contractor Sr. Systems Engineer II 520-533-6213 david.b.paige.ctr(a)mail.mil

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide August 2017