<div dir="ltr">Attached are my scan results. I'll be going over these today (well, more likely tomorrow) to and will let you know soonest should I find anything.<div><br></div><div>I've had difficulty generating a fix file as I'm scanning remotely using oscap-ssh which doesn't support the "generate" argument.</div><div><br></div><div>Thanks for your support - OpenSCAP rocks!<br><div>=Fen</div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 3:36 AM, Jan Cerny <span dir="ltr"><<a href="mailto:jcerny@redhat.com" target="_blank">jcerny@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Fen,<br>
<br>
The RHEL7 STIG profile contains some rules that check configuration of<br>
the SSH server. For some of them there are remediation script provided.<br>
There are quite a lot of them:<br>
- Allow Only SSH Protocol 2<br>
- Set SSH Idle Timeout Interval<br>
- Set SSH Client Alive Count<br>
- Disable SSH Support for .rhosts Files<br>
- Disable Host-Based Authentication<br>
- Disable SSH Root Login<br>
- Disable SSH Access via Empty Passwords<br>
- Enable SSH Warning Banner<br>
- Do Not Allow SSH Environment Options<br>
- Use Only Approved Ciphers<br>
- Use Only FIPS Approved MACs<br>
(Hopefully I haven't forgotten any other.)<br>
<br>
Maybe you have discovered a bug in some of the remediation scripts<br>
for some of these rules. To identify the problem, we have to check<br>
the scan results and find which rules your system didn't pass.<br>
The we can go trough each of them, find why they didn't pass and compare this<br>
with the remediation scripts. It is possible that your system was in configuration<br>
that the remediation scripts does not cover.<br>
<br>
Please, could you provide your scan results?<br>
It would greatly help us to investigate your problem.<br>
Have you done any customization of the profile?<br>
<br>
If you find any possible reason, please share it with us.<br>
Thank you<br>
<br>
Best Regards<br>
<br>
Jan Černý<br>
Security Technologies | Red Hat, Inc.<br>
<span class=""><br>
----- Original Message -----<br>
> From: "Fen Labalme" <<a href="mailto:fen@civicactions.com">fen@civicactions.com</a>><br>
> To: "open-scap-list" <<a href="mailto:open-scap-list@redhat.com">open-scap-list@redhat.com</a>><br>
</span><span class="">> Sent: Friday, April 22, 2016 12:14:04 AM<br>
> Subject: [Open-scap] oscap-ssh based remediation killing remote server<br>
><br>
</span><div><div class="h5">> Hi,<br>
><br>
> I'm running oscap-ssh on CentOS 7 using oscap-user and the `sudo` option.<br>
> Running a scan on a remote server works great (thank you!):<br>
><br>
><br>
><br>
> oscap-ssh sudo <a href="mailto:oscap-user@192.168.56.102">oscap-user@192.168.56.102</a> 22 xccdf eval --profile<br>
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream<br>
> --results-arf scans/results-arf.xml --results scans/results.xml --report<br>
> scans/results.html scap/ssg-centos7-ds.xml<br>
><br>
> Then I run a remediation with the line:<br>
><br>
><br>
><br>
> oscap-ssh sudo <a href="mailto:oscap-user@192.168.56.102">oscap-user@192.168.56.102</a> 22 xccdf eval --remediate --profile<br>
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream --results<br>
> scans/remediation-results.xml --fetch-remote-resources<br>
> scap/ssg-centos7-ds.xml<br>
><br>
> This completely kills access to the server at 192.168.56.102 (via host or<br>
> dashboard).<br>
><br>
> Am I calling remediation incorrectly? Has anyone else seen anything like<br>
> this? No obvious errors are reported.<br>
><br>
> Suggestions on how to debug what step might be killing the server are<br>
> welcome. Note that it doesn't die until the SSJ connection is closed, e.g.<br>
> after:<br>
><br>
><br>
><br>
> Shared connection to 192.168.56.102 closed.<br>
> oscap exit code: 2<br>
> Copying back requested files...<br>
> results.xml 100% 1889KB 1.9MB/s 00:00<br>
> Removing remote temporary directory...<br>
> Disconnecting ssh and removing master ssh socket directory...<br>
> Exit request sent.<br>
><br>
> The exact steps I'm using are captured in a completely self-contained ansible<br>
> role test setup (that uses vagrant) documented - shpuld you want to recreate<br>
> my process - at<br>
> <a href="https://github.com/openprivacy/ansible-role-govready/blob/master/tests/README.md" rel="noreferrer" target="_blank">https://github.com/openprivacy/ansible-role-govready/blob/master/tests/README.md</a><br>
><br>
> Thanks,<br>
> =Fen<br>
><br>
> --<br>
> Fen Labalme, CISO at CivicActions.com<br>
> Security | Quality | DevOps<br>
> mobile: <a href="tel:412-996-4113" value="+14129964113">412-996-4113</a><br>
> github/skype/twitter: openprivacy<br>
><br>
</div></div>> _______________________________________________<br>
> Open-scap-list mailing list<br>
> <a href="mailto:Open-scap-list@redhat.com">Open-scap-list@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/open-scap-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/open-scap-list</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Fen Labalme, CISO at CivicActions.com</div><div>Security | Quality | DevOps</div><div>mobile: 412-996-4113</div><div>github/skype/twitter: openprivacy</div></div></div></div></div></div></div></div></div>
</div>