[PATCH] [Shared] Add shared remediation script for sshd disable root login rule
by Jan Lieskovsky
Hello Rui, folks,
as correctly observed by Rui Pedro Bernardino in [*]:
[1] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Decembe...
[2] https://lists.fedorahosted.org/pipermail/scap-security-guide/2013-Decembe...
current implementation of sshd related remediation scripts for RHEL-6 SSG content
does't handle presence of Match block directive present in sshd config correctly.
Attached patch is a prototype solution, which should deal with this problem.
It is proposed to be a shared remediation script (since the same would affect
Fedora).
Couple of notes:
* while it looks overly / more complex against the original version:
[3] https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/inpu...
actually it shouldn't be that bad. While actions for selected (sub)cases
are identical ( -- examples:
- when there isn't Match block and already one PermitRootLogin directive present
in sshd config with case when there are Match block and PermitRootLogin (PRL) directives
present in sshd config already, and PRL is sooner than Match block or,
- in case when there's Match block present, no PRL yet with case when
there's Match block present, PRL present too, and PRL is placed after
first Match block directive),
and therefore corresponding if statements could be merged, I would prefer
to keep this version (including the comments), as it's straightforward /
visible in each case what the remediation (sub)action would look like.
* I am aware this "Match block issue" isn't problem just of 'sshd disable root
login' rule, but problem of RHEL-6's sshd remediation scripts in general =>
have created upstream ticket:
[4] https://fedorahosted.org/scap-security-guide/ticket/429
to track this, took it, and will gradually propose (shared) patches,
taking this into account during the process / as adding them for Fedora SCAP
content.
* Besides that noticed another issue - search for whitespace (other than
space character itself) prefixed directives wouldn't succeed, thus we would
end up adding new directive at the end of sshd config, resulting into
situation the remediation wouldn't actually correct the configuration.
Example case for the former implementation wouldn't work being:
^\t*PermitRootLogin yes
present in sshd config. Have filed another ticket:
[5] https://fedorahosted.org/scap-security-guide/ticket/430
to track this deficiency across RHEL-6's sshd remediation scripts.
The attached patch deals also with this situation for the case of
'sshd disable root login' rule. For the remaining rules, took the [5] ticket,
and will provide (shared) patches gradually aligned with as I will provide
sshd remediation fixes for Fedora.
* The above proposal has been tested against following subcases:
-- no PRL, no MB present in sshd config,
-- PRL present, no MB present in sshd config,
-- MB present, no PRL present yet in sshd config,
-- MB present, PRL present before MB directive in sshd config, and finally
on sample Fedora sshd configuration and seems to be working. Would appreciate
further testing / any objections though.
* Last but not least the current proposal intentionally doesn't apply the
remediation for 'PermitRootLogin' directive being present within Match block directive
(since I am taking presence of MB as some kind of exception case).
Example - considering sshd config:
# PermitRootLogin not yet in sshd config
Match Address some_IP
PermitRootLogin yes
it would transform it into:
# PermitRootLogin not yet in sshd config
PermitRootLogin no
Match Address some_IP
PermitRootLogin yes
IOW any occurrence of PRL within Match block would be kept intact. If this should
be changed too, let me know (and we can adjust in subsequent version).
Please review / test the proposal (since it should work for both
of RHEL-6 and Fedora, and if acceptable could be used as prototype for
remediation scripts also for other sshd rules).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
[*] Thank you again for opening this (sub)case, Rui.
P.S.: Apologize for such a long post, but too much information to share.
10 years, 4 months
[PATCH] [RHEL6] Fix SSH remediation scripts to be case-insensitive
by Jan Lieskovsky
[RHEL6] Fix SSH remediation scripts to be case-insensitive
Current version of various SSH remediation scripts for RHEL-6
is searching (grep) and replacing (sed) particular /etc/ssh/sshd_config
configuration file's option in case-sensitive manner (searching
and replacing only strict matching exact case), therefore
having, e.g:
permitrootlogin yes
in /etc/ssh/sshd_config would end up (in current state) the 'PermitRootLogin no'
string to be appended at the end of the file, but keep the
root logins allowed (since first option present in /etc/ssh/sshd_config
is honoured by sshd).
The proposal changes searches and replacements for various SSH daemon
remediations to be case-insensitive, fixing this problem.
Please review.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
Generate Fix
by joescap@mm.st
Going through the SCAP & STIG Workshop March 2013 I learned that I can
generate a shell script to fix items that were discovered during the
scan:
# oscap xccdf generate fix --result-id
xccdf_org.open-scap_testresult_stig-rhel6-server
/var/www/html/studentX-results.xml
Is it possible to generate a shell script that has all the available
remediations regardless of a pass or fail. In other words I want to
generate a remediation shell script that doesn't rely on the output
results file, but has every remediation that is available in the xccdf
included in the shell script.
10 years, 4 months
Cross DISA STIG to the SCAP Profiles
by joescap@mm.st
Can anyone suggest a way I can cross the tests in the SCAP profiles
(specifically the stig-rhel6-server) with the tests in the official DISA
STIG? I've looked through the various xml files as well as this
catalog
(http://people.redhat.com/swells/scap-security-guide/RHEL6/output/rhel6-gu...).
I don't see any numbers that correspond between the two. The only way I
can see to do it is read every test narrative and try to correlate the
two.
The reason, I have an automated tool that has the full DISA stig loaded
that I'd like to modify to resemble the stig-rhel6-serve profile. The
tool can not import the SCAP content yet (should be able to soon
though), so in the meantime I'd like to make the DISA STIG look like the
stig-rhel6-server profile as much as I can. Any suggestions?
10 years, 4 months
Should the remediation enforce the restart of service configuration of which it's changing?
by Jan Lieskovsky
Hello folks,
in relation with applying sshd remediations, wondering if
the fix should enforce restart of sshd (include command ensuring it).
>From my point of view it should (the configuration till not reloaded
is still unsafe, even when configured safely), but since this touches
area of runtime state again, rather checking with you first (prior
proposing enhancement).
Justification:
--------------
Absence of service restart past modification of its configuration file
can be misleading, since though service configuration is safe already
(and the subsequent check passes), it isn't really safe till not reloaded
(which might happen in timeframe of months from the time point service
configuration got changed).
On the other hand, should the service configuration file remediation /
fix cause any issues, preventing the service from start (unlikely,
but let's consider such a case might happen), in my opinion it's
more straightforward the service to stop working immediately rather
than in timeframe (possibly of months) making it subsequent debugging /
identifying the reasons why it stopped to work more difficult.
Thoughts appreciated.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months
NIST 800-53 reference
by Kordell, Luke T
Hello,
Is there a flag or setting that can be changed to include the NIST 800-53 number on SCAP scan output or guide generation in-place of the CCE number? I know the guides contain a reference to the NIST 800-53 pdf file but it doesn't appear to list the control it satisfies.
Luke
10 years, 4 months
Worthy to add XCCDF rule to ensure regular system reboots?
by Jan Lieskovsky
Hello folks,
slightly related with my previous post, and with experience seen
from customer systems (whole system not rebooted for many of days,
possibly even for years to ensure its work / compatibility), wondering if
the agencies focused on computer security have a recommendation /
requirement underlying system reboots to be scheduled on regular
basis (like once per month).
As already mentioned, on one hand there can be often seen scenarios
when customer(s) don't reboot the system due the fear of breaking
the functionality / compatibility. Such behaviour on the other hand
obviously means, that for example fixes for selected security flaws
(mainly in the kernel) can't be applied completely / correctly,
leaving the system in question still vulnerable to particular attack.
Therefore was thinking if we would want to introduce XCCDF rule /
recommendation requiring the system to be rebooted on regular basis
(like once per month looks reasonable, but opened for proposals),
to ensure this (kernel still being vulnerable) wouldn't happen.
Besides that (I think) even when the reboot should result into
system not being bootable, it's better to find it immediately,
than after period like ~3 years (many of fixes applied at once =>
harder to find out which concrete one actually caused the failure
to boot).
The corresponding OVAL check could see if there exists particular crontab
entry scheduling reboot once per month (and fail if not). The fix then
would be to add such crontab entry (possibly including "wall" notification
with some delay prior actually performing the reboot).
Opinions appreciated.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 4 months