99.x% DISA STIG kickstart NOT USING heavy-handed stig-profile

This for RHEL 8.

There are two methods to do STIG loads. The heavy-handed way with less hope of operational function, and the one where you must do some homework, but has the hope of actually working. We use the latter in my environments and have been for years with operational functional capability.

• The super-heavy-handed STIG-profile load at a DVD build which just gives you the entire enchilada and will probably not work for things such as Oracle Database servers, or specific servers.
• Alternatively, this non-STIG-profile of kickstart works well when you tailor the build to your operational needs. We use this form with the customers I work with have been using for years. This method demands that you remove the things you have determined soundly will break your world and you've properly justified it to those you should justify it to (we did).

In short, the method we use can be either through a PXE server or a traditional kickstart.

We use both methods, and both go to a kickstart. You can of course use a Satellite, but that would be a different discussion.

So this method uses...

• A kickstart you build with identifying the partitions needed at build time to comply (and exceed). The partitions we use may seem excessive, but we've discovered it works best for later discussions
• A collection of STIG mitigation scripts I've created (and will share here soon)
• A collection of files such as audit.rules and sshd_config, among others. These two files among others carry the brunt of the mitigations and i'm not writing dozens of individual scripts for all these. I have a tar file for /etc/ that is overlaid afterwards.
• Unlike RHEL 7 where you could do the overwhelming majority AT BUILD during the anaconda loader, with RHEL 8, your work in a kickstart for what was pam files now in /etc/authconfig - those files get clobbered at the end of the kickstart, so it is useless to edit them during the kickstart, so I ingest the files after build in a postscript.

Are there more elegant ways to do what I've done?? Certainly, and I'm all ears. However our builds surpass what our inspectors want, and we have no operational needs and we've been doing it for years... Yeah, I'm still gladly open to discussion for better methods.

There may be something in the build that may need editing. There is NO POSSIBILITY my build can anticipate every single environment - that's impossible. However, my build has the means to shut off individual things through commenting out specific STIG scripts. You can edit the sshd_config file as needed and other files, and you can have a clearer idea of what is being edited.

I plan on sharing this more in detail soon, I'm tidying this up and testing it a bit more.

Kind Regards,
RJ

Your actual percentage may vary depending on your operational needs.