OpenSCAP scan results questions about IPv6 and others
After running a scan against on of our lab systems I noticed that I failed the "Result for Disable Accepting IPv6 Redirects" . So I go back and do the remediation steps:
# sysctl -w net.ipv6.conf.default.accept_redirects=0
Which returns:
# error: "net.ipv6.conf.default.accept_redirects" is an unknown key
I found the reason here:
https://access.redhat.com/solutions/1308033
The solution in the link above essentially says to re-enable the ipv6 module which will allow sysctl to read the params and set them. Problem with this is that one of the other SCAP rule ID calls for disabling the ipv6 module. So either way it looks like I'll take a hit on this scan. These rule ID's on ipv6 do not seem to make much sense. If you have the module disabled you should not need to worry about the other parameters in /etc/sysctl.conf such as the redirects as ipv6 is essentially disabled anyway. Am I wrong? So not sure what to do here.
Next question - I am testing with xccdf and the pre-canned stig profile. What constitutes a "passing" score against STIG? And are there any more pre-canned profiles/xml files that I can download for RHEL6? Are most non-DOD enterprises that use SCAP using a STIG profile or creating customized profiles?
Responses
Are you running your scap scan against files provided by DISA?
http://iase.disa.mil/stigs/scap/Pages/index.aspx
For example, for the RHEL5 systems, I download the .zip file (to say /tmp/openscap). I also confirm that I have openscap and openscap utils installed and then from the CLI, this is what I run:
oscap xccdf eval --profile MAC-2_Senstive --results /tmp/openscap/starting_scan.xml /tmp/starting_scan.html --cpe /tmp/openscap/U_RedHat_5_V1R12_STIG_SCAP_1-1_Benchmark-cpe-dictionary.xml /tmp/openscap/U_RedHat_5_V1R12_STIG_SCAP_1-1/Benchmark-xccdf.xml
Once you run this, view the .html in a browser and it will give you the score. From here is will show pass/fail for what stigs still need to be implemented.
Guru
6435 points
The other fun one that you'll run into - if you're in a CentOS Dev/Test with Red Hat Prod environment is CPE incompatibilities in the OpenSCAP profiles. I'd submitted a bug to the CentOS team to fix that, but it had sat several months (before I stopped checking) and they hadn't even reviewed the bug-filing. It's especially annoying given that I included a simple fix-suggestion in the bug.
The profiles you download from DISA usually don't have the CPE definition problem - probably because of DoD guidance around "use free where you can". That said, the July STIG update (v1 r8) had a regression on that front. Be interesting to see if that regression gets fixed in subsequent profile updates.
Guru
6435 points
Welcome to the fun that is STIG compliance. If you're extremely lucky, your accreditor will understand "getting V-NNNNN1 to go green will cause V-NNNNN2 to go red: which one do you need green so you can certify this system". If you're other than extremely lucky, you get to go round and round with the script-monkey accreditor ...and then you'll finally have to file a POA&M (that never actually gets followed up on)
Guru
6222 points
Hello Brian,
I would like to ask you to open a support case, for at the EMEA Partnership Conference it was mentioned that OpenSCAP is a project Red Hat is taken very seriously. So this issue should be addressed IHMO.
A self contradicting set of rules is not a good thing in a security audit.
Kind regards,
Jan Gerrit
Guru
6435 points
The STIGs (the documents that specifically get published through the DISA portal) have had conflicting test/fixes since at least the early 2000s. This has been true of far more than just ELx. It's pretty much "expected" at this point that there'll be conflicting guidances within the test suite.
The other thing to remember there are a couple sets of SCAP profile-sets available. At the very least, there's the ones that Red Hat packages up and makes available and the ones that DISA publishes. Technically, while the Red Hat community is a/the primary source for SCAP profiles, the profiles published by DISA are ones that Red Hat only has advisory access to. While Red Hat could decide "we should deactivate the V-NNNNNN rule/handler in our profiles", it's not guaranteed that DISA wouldn't simply decide "nope: we're not deactivating that".
Guru
6435 points
The main OpenScap prject is at OpenSCAP.Org. The profiles that go into Red Hat are maintained on the Fedora web-site.
Though, if you're trying to meet STIG compliance, none of that really matters. The only thing your IA team will care about is what's at the DISA site.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.