Red Hat Enterprise Linux 7 STIG
With the release of RHEL 7.1 imminent, I was wondering if there was an ETA for the RHEL 7 STIG?
Is it possible to access pre-release or beta versions of the document/guide?
Responses
Red Hat
Active Contributor
312 points
We're actively working with NSA and DISA FSO to finalize RHEL7 STIG content. This work is performed entirely under the SCAP Security Guide project. The project homepage is on GitHub:
https://github.com/openscap/scap-security-guide
And specific to your question, the RHEL7 "Project Status" page is here:
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Project-Page
Ultimately, we currently have the DISA FSO requirements for what a RHEL7 STIG must look like (there's a spreadsheet posted to the URL above), however have not finalized an official Red Hat submission (which will consist of implementation guidance, and SCAP automation content). Generally, customers who want to deploy RHEL7 and who must meet STIG requirements can implement a baseline against the DISA FSO requirements, document their implementation in the form of a Requirements Traceability Matrix, and submit that paperwork as part of your C&A package.
At time of posting, there's some 115 requirements of which implementation guidance must be authored for. You can review that list here:
https://github.com/OpenSCAP/scap-security-guide/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Draft+RHEL+7+STIG+%22
If you're interested in helping form the RHEL7 STIG, or would like to follow progress, the developer mailing list is here:
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
It is now Dec 22 2015, over a year since this discussion was active and still no approved STIG - who is to blame, who do I start a fire under? Why is DISA and DoD so incompetent? - just a rhetorical question.
Guru
6435 points
You always have the choice of running the SCAP content outside of a DISA-blessed context. That's how we proceeded when the EL6 STIG was still pending.
If you're DoD (in you are DoD, you're essentially calling yourself incompetent ; if you're not DoD, then why do you care about STIGs), it will take you several months to achieve certification regardless of the state of the STIGs. Using the current SCAP content as "beta" guidance will likely get you about 98% of the way towards what you need to get your authorization. Further, using the SCAP content as such guidance will also allow you teams to start prepping your ICD 503 CCP and other BOE documents.
Guru
6827 points
We downloaded the SCAP for that very reason and are (have been) proceeding with it... Yet customers and our security groups still are eager for the actual published STIG whenever it is available (I understate) even though the SCAP we've adopted will carry us pretty far. For those that are not DoD, they just might want to see what is there from a security standpoint to see if (any of) it is sensible for their own environment. For those that are, there are security groups that "must have" the published STIG, even though the SCAP performs as you mention.
Tom, you clearly do not understand the situation. It should take one week to get a system approved with a proper procedure. If I have an approved STIG, as I do with 6.x, I can work a system and create the scripts to get a system locked down for approval in about a day. With those scripts, I can then lock down the next fresh installed system, update, scan and ready for approval in about an hour (if I had virtual systems I would have a STIG'ed deployment scripts). Because we are using an "approved" STIG, getting systems ATO'd take less than a week.
When you have an approving authority, that has all the good faith of the community and Red Hat to help produce a quantified guideline and check, yet fails to do so for over a year after OS release, and then defaults that responsibility to every individual Sys Admin/ Developer throughout the whole DoD, it goes beyond incompetence and is approaching the realm of waste fraud and abuse. For some reason I think the Tax payers deserve a little more than an approving authority just kicking the can down the road and abdicating their responsibility.
If you are a Civilian DoD employed, you are locked in to a job where you can take months to get system approved. Who is going to light a fire under you @$$. They can't fire you, only transfer you to another location to sit. And where do you get this team to prep your ICD and 503 CCP and other BOE documents? If you want to have an off-line discussion about DoD incompetence and lack of commitment to IT, I would be glad to rip into that. But all you need to do is look at this example where DoD and DISA conveniently abdicates it's responsibility so everyone else can pick up the pieces.
If DoD was serious about IT, it would have someone come on here, at least once a month, and provide a status. But don't worry, I will not hold my breath.
@Tom Jones - "if you're not DoD, then why do you care about STIGs"? Well, there are thousands of defense contractors who are non-DoD but who must comply with STIG requirements. Not having a STIG means that products based on RHEL7 can't be offered. The lack of visibility, transparency and apparent progress in the RHEL7 STIG process is a genuine disappointment. By comparison, the Windows 10 STIG was published within 4 months of that operating system's release date! I will say that, after working more and more with RHEL7, the best general description I can come up with is "uneven". There is some real weirdness there. Could RHEL7 be the "Windows Vista" of Red Hat Linux? Maybe.
Guru
6435 points
Doesn't matter what color your badge is, if you're working on projects or producing product for DoD, then you're (essentially) DoD. If your networks, products, etc., are never going to connect (directly or indirectly) to DoD assets, then STIGs are optional.
Not having a STIG doesn't mean a product can't be offered, it means that you need to have someone with sufficient authority (typically talking C-level) to accept the risk and plow forward. That's the whole point of ICD 503 in the first place: provide a framework through which risk can be assessed and managed. Use the public SCAP content to show your compliance and demonstrate your POA&Ms, map the SCAP content to your relevant ICD 503 controls, get someone to sign off on your "best effort" security efforts.
As to "transparency", that's on DISA. The bulk of the content they're mulling over was done in the SCAP projects. Those are publicly reviewable.
As to EL7's "weirdness": it's really not any weirder than the moving from SysV-init in Solaris 9 to SMF in Solaris 10 was (or frankly, using any of the non-SysV UNIX variants). Pretty much any Linux implementing systemd is going to seem "weird" to anyone that's only ever really done SysV-init types of UNIX/Linux systems.
STIGs are NOT optional when you have been compliant with previous STIGs and multiple customers, DoD or otherwise, have come to expect that compliance from you. We can't build out our RHEL 7 infrastructure because we're not compliant with the STIGs that don't exist, while at the same time that compliance is viewed as a requirement by our customers (not to mention the management that authorize the operation of the systems). It's policy, but it's a real world issue. Welcome to government work.
High level management like to see a trusted, approved baseline source and the STIGs provide that. We use the STIGs among other things as a baseline for securing multi-tenant capabilities and by doing so we are trusted by multiple customers as well as internally.
The delay and lack of transparency on this approval is holding us up, and I know we're not the only ones.
Guru
6435 points
With respect to Government work, an organization's AO or DAO can choose to take the stance "the SCAP (or other) guidance is good enough - our priority is getting onto this platform". Whether that's good enough for peer organizations (though it should be more than good enough for subordinate organizations) to accept for inheritance is another matter.
Let's face it: not everything that goes into production environments even have STIGs (least of all GOTS stuff). If something's a high enough priority for your organization, it can be waived on through.
Guru
6827 points
This is what we are working on, but our various customers are still in the position of "must have" for a STIG at some point when it is available, and we are asked to ask for it. We recognize who we must wait on for the STIG release,
However, we are proceeding - and pursuing the SCAP method with what is already available, along with some other concurrent methods we have in place.
Guru
6435 points
It's definitely a non-trivial effort to get an AO/DAO to buy-off on. Fortunately, the SCAP process makes it a bit easier when you can explain "the stuff in here will probably get you 90% of the way towards what's in the eventual STIGs" and point them to the documents that corroborate the content-flow. Fortunately, particularly with ICD 503, "outs" for an AO/DAO are semi-codified (at least to the extent of telling them "you're sufficiently-empowered to make such a determination").
Why are there two RHEL7 STIG sites? How are these related?
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Project-Page
http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-stig-rhel7-server-upstream.html
Well, even though some of these comments are like therapy to me (a supporting member of the DoD) I think we all fall under slightly different guidance, even though we all are suppose to be reading the same or very similar regulations. I know for a fact that some sites/customers in the DoD go WAY overboard (or underboard) on STIGs and their respective documentation per system, while other sites continue to use the excuse, "we have little time to do more". I use to use that excuse, but now we have more people. We're STIG'd to the high-heavens. OMG.
By having a "completed and approved" RHEL7 STIG, I can understand how an IT team could then, and ONLY then, move forward with learning RHEL7 and testing it in their own environments. I agree with Tom on some things, the RHEL5 folks to don't dabble at home with RHEL7 are in for a very rude awaking.
All of our customers in the DoD are like your own children. You raise them the same, but be damned if they don't all come out a little different in regards to their personalities. It is quite maddening.
There are too many "good idea fairies" and arm-chair bandits out there and they keep many of us way too busy on BS. Not to say that any security measures are BS. Just saying.
Guru
6827 points
Okay,
Take the following with the previous comments by previous posters in mind... like C Scarff, Tom Jones, Pixel etc... [I'm pretty sure I left someone out here... like Shawn Wells himself...]
2) Take the following with "your mileage may vary for your own environment" because your environment may differ in some way than mine.
I have been whittling away on my own hardened RHEL 7.2 load and in the absence of a STIG, but availability of the pre-release "STIG" in the form of the GIT project cited by Shawn Wells (and others) in this thread - I used the available mitigations from that upstream project, and added a few things of my own in specific cases. I had to fix some citing of functions in a few scripts. I omitted a few things that were not applicable to my environment. I tested the success of every script and added it to an overlay.bash script.
ADDED: One interesting thing I noticed is when doing a flat manual load just for "entertainment", you can select security profiles. I tried the pre-release STIG security profile and it placed a bit into the resultant /root/anaconda-ks.cfg:
%addon org_fedora_oscap
content-type = scap-security-guide
profile = stig-rhel7-server-upstream
%end
That can be added to one's kickstart as well, just keep in mind to use caution that further mitigations are not duplications.
I made my %packages section as minimalist as possible, yet offering what was certainly necessary in terms of "needs vs. wants".
My current load that I tested today reports no findings. Sorry, I can't immediately share any of the work, but that being said, using what is available via Shawn Wells, & the SCAP project, that's what I based my own load from. I've been given the "green light" to proceed with 7.2 based on (as others have stated) a clear best effort and the results of no findings (only 'info' level findings, no crits/high/medium/lows at all).
As Tom Jones said, (okay, i'm paraphrasing a tad) the SCAP (and other sources cited in this discussion) mitigations (appropriately applied for one's environment) carried the weight of 90[+]% of the mitigations (for my case) and again, your mileage may vary.
It can be done, it takes a bit of effort, and discussion with the powers that be to let them know the current "source" of what the STIG will be (as described within the context of this discussion), and then demonstrating [think demonstrating work in a math class, how you found the proper answer] how we got to the final product.
Red Hat
Active Contributor
312 points
It's great to hear you got the green light! If/when you can share your work, I'd be most interested to see it!
For those who have related goals (e.g. provisioning directly into a STIG-compliant baseline): If you have a public-facing system, the upstream development community publishes a kickstart file that will take the SCAP Security Guide package (shipping natively in RHEL7) and provision your machine into a given profile.
For example, here is the kickstart for OSPP (the profile that aligns to Common Criteria, USGCB, and working towards STIG): https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/kickstart/ssg-rhel7-ospp-ks.cfg
If you want to change the profile, review line 123 and swap out for another profile name (e.g. for PCI compliance).
It's not perfect -- and will HOPEFULLY be rebased come RHEL 7.3 -- but should give the "90% solution" that would be useful for many people. If you have any issues, file a support case with Red Hat or engage upstream @ https://github.com/OpenSCAP/scap-security-guide.
Guru
6435 points
Customers have been pestering me about "when can we get draft CM modules for EL7 STIGs coded-up".
After encountering a really egregious bug in the draft STIGs, tried to file a bug-report with DISA. Got notification back stating that, due to the major problems with the currently-published draft STIGs, they're planning a new draft-release and that they're no longer accepting bug-submissions on the currently-published draft release.
Does Red Hat have any insight into: when the new draft might be published; how close to "final" that draft is likely to be; how long after the updated-draft is published a "final" V1 release might be published?
At this point, it's feeling like I have to tell my customers "don't expect to get a RHEL7 system into production till at least 2017". Given that the Docker/Kubernetes deployments will likely ride on RHEL7, the delay in the EL7 STIGs has knock-on effects for projects relying on those technologies, as well.
So... Anything I can tell the people that are screaming at me about "where is it"?
Shawn,
Thanks, this is good info. I have a couple of questions I was hoping you or someone else could answer.
1) Where can I find this OSPP profile? Is it available in oscap or just the anaconda addon? I don't see it as a profile under ssg-rhel7-ds.xml
2) When adding the below addon directive to our ks file nothing is being remediated (based on a post install report) and there is no output showing it was attempted. Any suggestions? " %addon org_fedora_oscap content-type = scap-security-guide profile = stig-rhel7-server-upstream %end "
3) When running openscap with online remediation i.e. oscap xccdf eval --profile stig-rhel7-server-upstream --remediate --results /root/hostname-ssg-results.xml --cpe /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml
/usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml a number of items are fixed and pass the evaluation, however there are a number of items that show as notselected. Some of these I would fully expect to see on the STIG once it is finalized i.e. root logins permitted, SELINUX etc. Why aren’t these checks being "fixed" or even checked?
Thanks for any insight in to these questions.
Thanks.
Mike
Guru
6827 points
This link http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx shows the January 2016 draft RHEL 7 stig.
For those of you that have proactively taken the pre-release "STIG" in the form of the GIT project cited by Shawn Wells (and others) in this thread, you're probably 90+% already there (thanks for the tips Tom). It was good to take what ==was== available and to work with that. (note, please see the previous replies to this discussion).
Has anyone seen anything with a more current release? I suspect that link I just posted above is the place to look. That being said, I'm continuing with the pre-release "STIG" previously discussed, and have approval to build systems as I mentioned earlier in this thread..
Guru
6435 points
Unfortunately for my primary customer-base, no platform-specific, official STIG means that systems can't go on anything other than lab networks. Worse, while it's likely that it will only take a man-month or so to write up the automation modules for whatever official STIG finally emerges, it typically takes 1-3 quarters from the official publication of a STIG for the IA tools to be updated and verified. Given that it's May 2016, I'm guessing we won't be able to have "blessed" EL7-based systems till 2017 at the earliest.
Sadly, containers are even further away because of all of this.
RHEL 7 was released in April of 2014 and is now 2 years old! The project on which I work is in need of an upgrade which looks like it will be approved soon. I would prefer to use RHEL7, but it looks like I will not be able to recommend it for a system that requires A&A given the lack of an official STIG. Major upgrades only occur on our project every 8 years or so. I'm disappointed to have to recommend an operating system that is already 6 years old (November 2010) due to the red tape created by a cumbersome security process.
Guru
6827 points
Agree on the length of time... that being said, last week my security folks heard rumors that the next draft was to be released/published at http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx, however, I do not see it there. That being said, the consternation involves various entities (see discussion above), which of course does not resolve it's availability, but does shed perspective on all parties needed to complete it.
I've received approval to use RHEL 7.2/Cent 7.2 in my environment, see previous posts and in particular Tom Jone's salient points; I did the 'best effort" work against what's available (see this thread in context, previous replies), and based on that work, many local scans, and discussions with proper local folks, we were able to satiate what could be done to our current point.
As stated in the previous discussions in this thread, digging into what can be done will take one 90+% of the way.
NOTE NOTE: All of this being said, I too wish as do my multiple customers wish to have a current STIG, and I too wish this were a faster process.
Guru
6435 points
When I contacted DISA to ask "how do I submit bugs against this", I was told that they'd closed bug submissions due to the sheer volume of them ...and that a new draft would be out "soon". That conversation happened a in either April or May, so, not sure what "soon" means in practical terms. I know that what it means to the orgs I work with, they typically don't start to authorize OSes for deployment until they've updated and tested their tools against the (non-beta) security guidances. That typically lags the publication of guidance by a few months.
Given the glacial pace that DISA seems to work at and that I'm decidedly not optimistic that any immediately-pending guidance will be anything approaching "bug-free" (given how horrible the draft was, it's very difficult to be optimistic). I've had to tell my customers' representatives, "be prepared to not be able to have a production-deployable option until 2017".
Similar vein: when I asked the DISA rep about the status of the Docker components for EL7, was told that they were in queue behind VMware's NSX (and not yet started). I figure by the time EL7-based docker is approvable, most of my containers-wanting customers will have already moved to ECS.
Sadly, I sense some major windows closing for my Red Hat customers. :(
Guru
6827 points
Guru
6435 points
Yeah ...and they're only accepting "comments" (by way of an emailed Excel spreadsheet?!?) until the 27th. That's according the the PDF in the three-file release ...while the Excel spreadsheet says July 22.
Spent as many free hours as I could, today, getting my comments into the spreadsheet. While it's better than rev 1 was, it's still kind of a mess (some fix texts were clearly not tested or show wanton disregard for how globbing actually works). Some of the bugs fall into "yeah, that's one way to do it, but not if you care about scanning a system quickly" category, while others fall into the "will straight-up wreck your system" category. I'm about halfway through the STIG items and at about forty comments.
At any rate, if you want to make sure that they don't charge ahead "as is", you'll want to get cracking on formulating and submitting your comments. Right now, it feels like there's really going to need to be a Release 0.3.
Guru
6827 points
I'm curious how the listed scripts in the upstream project Shawn Wells mentioned (https://github.com/openscap/scap-security-guide) much earlier in this thread correspond with the listed recommended mitigations listed in the extracted file "U_Red_Hat_Enterprise_Linux_7_STIG_V1R0-2_Manual-xccdf.xml"
Red Hat
Active Contributor
312 points
Red Hat reviewed DISA's V1R0-2 draft and submitted returned comments on 29-JULY (end of DISA's public comment period). Out of the 237 rules in the draft: - 109 rules contained errors that need to be fixed; - 64 rules were identified that should be dropped, for either being out of scope or frivolous; - 3 rules needed to be added to Red Hat Vendor STIG/OpenSCAP content (in progress now, should be done this week); - Only 61 of the 237 rules were "production ready," and did not include any immediate noticeable errors
Red Hat received notification from DISA FSO on 1-AUG that DISA does not intend to incorporate any of the feedback or findings into their published/finalized STIG. DISA stated that "any other modifications that need to be done will be part of the normal quarterly release cycle." Note that we've yet to see quarterly releases of RHEL6 STIG content include Red Hat or other government-requested updates.
So, where does that leave us?
In regards to DISA publishing their RHEL7 STIG: Public comments on the second draft ended Friday 29-JULY. With current schedule, DISA has two weeks to decide what comments to incorporate. That places their finalized STIG to be published no earlier than Monday 8/15. It remains unknown what comments they'll chose to incorporate, however I'd wager on very very few. They're under extreme pressure to release something -- anything -- seemingly irregardless of quality, supportability, or technical accuracy. Once a finalized edition is published, I will work within Red Hat to release "supplementary guidance" to correct known errors.
For example, RHEL-07-030530 audits the usage of /bin/mount. Malicious (or innocently mistaken) software need only use the mount system call to subvert this audit rule. For this reason, the NSA, NIST, and Red Hat content recommend auditing the mount system call instead.
Or more egregiously, the DISA V1R0-2 content only audits the use of SELinux unconfined users running commands. If you assign yourself an SELinux context/role, e.g. staff_u, nothing you do will be audited!
Note the RHEL7 Vendor STIG is included natively via the scap-security-guide package. It's this content that we put through NIST and NSA approval, and that is shipped and supported by Red Hat. ISSM/AO staff have the authority to allow the use of Red Hat's Vendor STIG vs the content published by DISA. Would highly encourage that conversation with your accreditation officials.
Wish I had better news. As the age of DoD STIGs end, with DoD Secure Host Baselines taking their place, we've already began working with NSA's Information Assurance Directorate to use OpenSCAP/SCAP Security Guide content.
Guru
6435 points
So, what you're saying is, the multi-page complaint-spreadsheet(?!?) I submitted - that was packed full of "this test is wrong, here's how you should do it" and "this 'fix' would render your system a brick" types of comments pretty much lines up with Red Hat's comments? At least you guys got a reply back. I submitted mine on the 21st (since the spreadsheet listed one comment closure-date and and the PDF listed a different one - and one of those dates was the 22nd).
It was nice to see that some of the horribleness of the first draft had been addressed, but was really hoping there'd be a third draft that actually had content useful beyond "customers can start deploying if they wave this list in front of their approvers".
:-\
Is there any update on when the first non-draft version of the STIG is expected to be released?
Red Hat
Active Contributor
312 points
Still waiting on DISA. No ETA.
Note there really isn't any reason to keep waiting on them. Per their FAQ at http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG:
Question:
May I deploy a product if no STIG exists?
Answer:
Yes, based on mission need and with DAA approval.
Question:
What do I use if there is no STIG?
Answer:
DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies. If there is no applicable SRG or STIG, industry or vendor recommended practices may be used. Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation.
Question:
Does DISA FSO certify products for use in the DoD?
Answer:
No. DISA FSO certifies Information Systems for use in DISA. DISA FSO not does certify products for DoD use. SRGs/STIGs are designed to assist in implementing the secure deployment of products.
Important to note a STIG does not reflect DoD permission to use RHEL7. For configuration content, RHEL ships the SCAP Security Guide which contains the supported Red Hat Vendor STIG.
Guru
6827 points
Yesterday, Red Hat released the announcement for "Red Hat Achieves Common Criteria Security Certification for Red Hat Enterprise Linux 7".
Red Hat
Active Contributor
312 points
Thanks Hinton! Some things you won't find in the press release....
The security target and certification report can be found here: https://www.bsi.bund.de/SharedDocs/Zertifikate_CC/CC/Betriebssysteme/0999.html;jsessionid=8AF267E0D4D9BBB8FEB429AD11035817.2_cid286
The associated kickstart and testing scripts can be found here: https://access.redhat.com/downloads/content/rhel---7.1/x86_64/4117/cc-config-rhel71/1.0-3.el7_1/noarch/fd431d51/package
Is this available for Red Hat Enterpise Linux? I have an active subscription but I have trouble getting to a download for the kickstart and testing package.
Red Hat
Active Contributor
312 points
The link should take you directly to the package download. Any RHEL subscription would have access. I don't have access to see your subscription(s) or what may be going on with them -- so I'd try pinging Red Hat support by opening a ticket @ https://access.redhat.com/support/cases/#/case/new
You could also try the RPM package search (note: it's still tech preview): https://access.redhat.com/downloads/content/package-browser
Enter "cc-config-rhel71" as the package query
Active Contributor
107 points
Does anyone here know someone on the project stighub at https://stighub.com/ ? It seems to be well done and by searching "RHEL" in the search box RHEL 7 stigs top the list. I have not dug into the individual STIGs yet however.
Thanks,
Active Contributor
392 points
Have you tried the provider's webpage? They may know who to reach out to.
http://beaconcloudsolutions.com/products/stighub
http://beaconcloudsolutions.com/contact
Red Hat
Active Contributor
312 points
Seems like a cool page! From the rule IDs and titles, they're using the DISA Draft Red Hat 7 STIG Version 1, Release 0.2 from http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx.
Guru
6435 points
Which, sadly, still has some system-breaking "fixes" in it. Fortunately, some of them are egregious enough that they're immediately evident that "you really don't want to do this."
Red Hat
Active Contributor
312 points
We're still running into the NIST+NSA+RedHat Vendor STIG versus the DISA STIG issues.
With that said, progress is being made to bring DISA back into community curated DoD consensus content, which should boost quality of their content.
Just this morning DISA submitted a pull request to the upstream OpenSCAP/SCAP Security Guide project :)
Guru
6435 points
Whoa... So there may be hope.
Just this afternoon, I had a tenant asking what the progress was. Had to tell him, "they usually make releases during the back half of the first month of a quarter. They missed that date, so, if they're otherwise following following prior schedules, another draft or first release might be out in January".
Any chance that whoever wrote their 2.x Java-based STIG-viewer can be pimp-slapped to restore the functionality that was present in the version 1.x viewer and did a better job or rendering content? The 2.x viewer's pretty horrid ...and, with the way it interprets text, it renders already iffy content in completely broken ways (prime example being RHEL-07-020700).
Pages
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.