[PATCH] [RHEL6] Move the closing quote in sshd disable root login remediation script at the end
by Jan Lieskovsky
When checking SSH remediation / fixes prior including them into Fedora,
noticed there's a slight typo in RHEL6/input/fixes/bash/sshd_disable_root_login.sh:
..
echo "PermitRootLogin "no >> /etc/ssh/sshd_config
..
This by itself wouldn't cause the remediation to fail, but it to be more
consistent with form of other fixes, moved the closing quote at the end
(as assuming that's what was originally intended).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 5 months
RE: Should the remediation enforce the restart of serviceconfiguration of which it's changing?
by Nunez, Luis K
The reboot and the disruption attributes may help to provide indicators to a
management system. The term reboot may not be accurate for this scenario but
certainly conveys the intent. The disruption attribute may also help in
gauging impact of a restart. Although far from accurately expressing this
scenario it does provide some level of information for decision makers.
-ln
-----Original Message-----
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of
Robert Sanders
Sent: Tuesday, December 17, 2013 10:24 AM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: RE: Should the remediation enforce the restart of service
configuration of which it's changing?
As you expand from must the local machine to an Enterprise environment, this
can be even more important. Suppose an over-eager admin decides to remediate
(via SCAP or some other process) an entire Enterprise installation. If boxes
are rebooted automagically after the remediation you can unintentionally take
out the entire installation. Factor in cases where there is a required start
order (which I bet we've all seen), and you've got the makings of a first
class mess, with really upset users/higher-ups. I'd submit that having the
option of a reboot is worthwhile, but it needs to be wrapped in a couple
layers of 'mother-may-I'.
-Rob
________________________________________
From: scap-security-guide-bounces(a)lists.fedorahosted.org
[scap-security-guide-bounces(a)lists.fedorahosted.org] on behalf of Steve Grubb
[sgrubb(a)redhat.com]
Sent: Tuesday, December 17, 2013 9:51 AM
To: scap-security-guide(a)lists.fedorahosted.org
Subject: Re: Should the remediation enforce the restart of service
configuration of which it's changing?
On Tuesday, December 17, 2013 05:33:29 AM Jan Lieskovsky wrote:
> in relation with applying sshd remediations, wondering if
> the fix should enforce restart of sshd (include command ensuring it).
No. The update itself takes care of what is sane to do. If you force a
restart, you can kill rsync or an admin session at a really bad point in time.
There can be a check that shows unrestarted daemons if that is desirable. The
sectool content used to do that. So, its possible to script. But I'd leave the
decision about when to restart to the local admins.
-Steve
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
10 years, 5 months
SSG Kickoff: RHEL7 Content
by Shawn Wells
The following is a new meeting request:
Subject: SSG Kickoff: RHEL7 Content
Organizer: "Shawn Wells" <swells(a)redhat.com>
Location: 1-800-451-8679,,,147-852-369-00#
Time: Friday, December 13, 2013, 10:30:00 AM - 11:30:00 AM GMT -05:00 US/Canada Eastern
Required: blank(a)eclipse.ncsc.mil; davsmith.work(a)gmail.com; leland.j.steinke.ctr(a)mail.mil
Optional: scap-security-guide(a)lists.fedorahosted.org
*~*~*~*~*~*~*~*~*~*
U.S. Bridge: 1-800-451-8679
Passcode: 147-852-360-00
Full international bridge numbers:
https://fedorahosted.org/scap-security-guide/wiki/conferenceline
-----------
RHEL7 beta has been released, time to start on SSG content!
Goals of this call:
- Quickly overview Red Hat's RHEL7 STIG intent
- Identify required steps to port SSG from RHEL6 -> RHEL7
- Form initial work breakdown structure, assign "task leads"
- What OVAL standards will be needed? e.g. systemctl vs init, firewalld, etc
- RHEL6 STIG community feedback: What worked? What should be dropped?
Historically this kickoff call was held only with RH/NSA/DISA FSO stakeholders. In air of transparency, and part science project, we'll have this as an open call. Community members are VERY welcome to join; either to chirp up & give productive feedback on areas of improvement, volunteer to own a piece of the work (e.g. handling the PAM, filesystem, or some other subcomponent), or perhaps silently listen in on the process.
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
NOTE: As many community members may join the call, and to avoid the inevitable background noises, ALL LINES WILL DEFAULT TO MUTED. To unmute your line, you will NEED to hit *6.
We'll also idle on #ssg-rhel7 on freenode.
~=~=~=~=~=~=~=~=~=~=~=~=~=~=~
10 years, 5 months
[PATCH] [Fedora] Fix typo in OVAL check for sshd disable empty passwords
by Jan Lieskovsky
[Fedora] Fix typo in OVAL check for sshd disable empty passwords
When searching for 'PermitEmptyPasswords yes' regex in previous
version was too liberal (even case like:
# PermitEmptyPasswords yes
permitemptypasswords no
would match the \s+ expression, meaning corresponding OVAL object
wouldn't be found in the system, and test failed even in case it
should pass) =>
FAIL only in case there's explicit '(?i)\n\s*PermitEmptyPasswords\s+yes'
in /etc/ssh/sshd_config.
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 5 months
[PATCH] Service check was still being used and header suggested it was being maintained by template, but that proved to be incorrect. Reimplementing line in templated code to maintain this going forward.
by Maura Dailey
This was a weird one. I noticed that the check was still in use, and the check clearly referenced the templated script in its header, but it had been removed at some point, meaning that it was no longer a templated check. I verified that the output hadn't been customized and readded it here to the list of checks to generate by template.
- Maura Dailey
---
RHEL6/input/checks/package_ntpdate_removed.xml | 5 +++--
RHEL6/input/checks/service_ntpdate_disabled.xml | 1 -
RHEL6/input/checks/templates/packages_removed.csv | 1 +
RHEL6/input/checks/templates/services_disabled.csv | 1 +
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/RHEL6/input/checks/package_ntpdate_removed.xml b/RHEL6/input/checks/package_ntpdate_removed.xml
index a78fb82..fbfa68e 100644
--- a/RHEL6/input/checks/package_ntpdate_removed.xml
+++ b/RHEL6/input/checks/package_ntpdate_removed.xml
@@ -8,6 +8,7 @@
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
<description>The RPM package ntpdate should be removed.</description>
+ <reference source="swells" ref_id="20130829" ref_url="test_attestation"/>
</metadata>
<criteria>
<criterion comment="package ntpdate is removed"
@@ -17,9 +18,9 @@
<linux:rpminfo_test check="all" check_existence="none_exist"
id="test_package_ntpdate_removed" version="1"
comment="package ntpdate is removed">
- <linux:object object_ref="obj_package_ntpdate" />
+ <linux:object object_ref="obj_package_ntpdate_removed" />
</linux:rpminfo_test>
- <linux:rpminfo_object id="obj_package_ntpdate" version="1">
+ <linux:rpminfo_object id="obj_package_ntpdate_removed" version="1">
<linux:name>ntpdate</linux:name>
</linux:rpminfo_object>
</def-group>
diff --git a/RHEL6/input/checks/service_ntpdate_disabled.xml b/RHEL6/input/checks/service_ntpdate_disabled.xml
index 5a9559e..67fcbbd 100644
--- a/RHEL6/input/checks/service_ntpdate_disabled.xml
+++ b/RHEL6/input/checks/service_ntpdate_disabled.xml
@@ -8,7 +8,6 @@
<platform>Red Hat Enterprise Linux 6</platform>
</affected>
<description>The ntpdate service should be disabled if possible.</description>
- <reference source="DS" ref_id="20130918" ref_url="test_attestation" />
</metadata>
<criteria comment="package ntpdate removed or service ntpdate is not configured to start" operator="OR">
<extend_definition comment="ntpdate removed" definition_ref="package_ntpdate_removed" />
diff --git a/RHEL6/input/checks/templates/packages_removed.csv b/RHEL6/input/checks/templates/packages_removed.csv
index 02d786f..a153bf9 100644
--- a/RHEL6/input/checks/templates/packages_removed.csv
+++ b/RHEL6/input/checks/templates/packages_removed.csv
@@ -16,6 +16,7 @@ libcgroup
mdadm
net-snmp
nfs-utils
+ntpdate
oddjob
openldap-servers
openssh-server
diff --git a/RHEL6/input/checks/templates/services_disabled.csv b/RHEL6/input/checks/templates/services_disabled.csv
index 7045072..e748cd0 100644
--- a/RHEL6/input/checks/templates/services_disabled.csv
+++ b/RHEL6/input/checks/templates/services_disabled.csv
@@ -21,6 +21,7 @@ netconsole,
netfs,
nfs,nfs-utils
nfslock,nfs-utils
+ntpdate,ntpdate
oddjobd,oddjob
portreserve,portreserve
qpidd,qpid-cpp-server
--
1.7.1
10 years, 5 months
[PATCH] Check for FTP Banner.
by Caleb Cooper
In order to resolve ticket #411 (https://fedorahosted.org/scap-security-guide/ticket/411),
I created an OVAL check titled "ftp_present_banner.xml" and added it to the ftp XCCDF content.
Caleb Cooper (1):
Created a OVAL check for the presence of a FTP banner.
RHEL6/input/checks/ftp_present_banner.xml | 31 +++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 RHEL6/input/checks/ftp_present_banner.xml
10 years, 5 months
