plus3it / ash-linux-formula Goto Github PK
View Code? Open in Web Editor NEWAutomated System Hardening (ash-linux) is a Salt formula to apply SCAP benchmarks to Linux systems
License: Other
Automated System Hardening (ash-linux) is a Salt formula to apply SCAP benchmarks to Linux systems
License: Other
Need to determine method for locating improperly configured NFS mounts
Need to come up with a way to determine if reliance on outside component can be satisfied or at least determined
Verify client-signing in autofs-style CIFS mounts. Not directly-specified in STIG. No relevant functions in current Saltstack module-list - probably requires fully custom code/helper-scripts to effect [do in second or third iteration of packaging SLSes]
Need to sort out a (preferably efficient) method for managing a dynamic list of log files
Handler currently forces "max_log_file" value to STIG-recommended ("6"). Handler should:
Need to determine method for locating improperly configured NFS mounts
Need to find a (reliable) way to dynamically determine appropriate max disk space for audit logs
Need to find a way to strip world-write permissions from dynamic file list
Need to find a (preferably efficient) way to handle the relative permissions-stripping for a non-fixed, recursive file-list
Config max audit space warning (suggest: borrow from pam_cracklib technique)
Using the following code-segment to determine whether to update /etc/fstab (and to apply update if condition returns true):
`
# Update fstab (if necessary)
{% if salt'file.search' %}
notify_V38652-{{ mountPoint }}-remount:
cmd.run:
fstab_V38652-{{ mountPoint }}:
module.run:
However, {% if %} statement fails to properly evaluate to "True"
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Current handler for V-38652 only works when the NFS mount point doesn't have another filesystem mounted over or into it (i.e., /mount/ will work only if there is no /mount//)
Need to add fstab functionality ...possibly via iterative-matching of mount.fstab function [needed in initial roll]
Need to add mtab functionality ...most likely via iterative-matching of mount.mounted function [needed in initial roll]
Need to come up with a (preferably efficient) way to handle the permissions-subtraction requirements of this STIG V-ID
Seems similar to #47
ID: file_V38583-hardlink
Function: module.run
Name: file.link
Result: False
Comment: Module function file.link threw an exception. Exception: Could not create '/boot/grub.conf'
Started: 22:00:46.043873
Duration: 0.881 ms
Changes:
While not expressly required by the STIGs, should probably iterate all the IPs/interfaces and ensure they have boot-time configuration files.
Use 'service.enable' instead of 'service.running' and use 'module.run' to 'watch' the pkg and execute 'service.start'.
Actual AIDE configuration likely out of scope. Set as advisory-only handler for initial rollout; explore config basics for subsequent updates
Description:
Due to run-time processing-precedence of Jinja-based code, the /etc/pam.d/system-auth-ac
file can end up with redundant edits applied. If the named-handlers are all run as part of higher-level include - such as:
include:
- STIGbyID.cat2.V38501
- STIGbyID.cat2.V38573
- STIGbyID.cat2.V38592
Symptoms:
The edits contained within will be multiply-applied, creating a faillock-config
that looks like:
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth sufficient pam_unix.so try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
The desired end-state should be:
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=900
auth sufficient pam_unix.so try_first_pass
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=900 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=900 fail_interval=900
Work-Around
Iterative, individual invocation of handlers will avoid the redundant edits.
Script currently works fine when a logging-target's definition starts with a unique facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.
Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add
'*',
To the facilityList list-variable.
The /etc/profile shipped in the setup RPM has a starting umask definition-block that looks like:
if [ $UID -gt 199 ] && [ "`id -gn`" = "`id -un`" ]; then
umask 002
else
umask 022
fi
This handler doesn't deal with this structure very well. Currently, falls back and clobbers the above - replacing with "077". Might be better to either have the handler nuke this entire block or append a umask 077
to the file (not tidy but should override all prior umask defines).
Need to apply method for configuring pam_faillock similar to those used for pam_cracklib
Need to sort out a (preferably efficient) method for managing a dynamic list of log files
Need to find a (preferably efficient) method for scanning for, reporting on and nuking .netrc files anywhere on the system
STIG-ID V-38702 only specifically examines and specifies fixes for vsftpd; however, other ftpds are available in the standard Enterprise Linux repos. Probably want to extend where other ftpds are available and support equivalents to the STIG-mandated logging settings.
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Need to figure out a way to do permissions checking/setting on a dynamic file list extracted from syslog service's configuration file(s)
Having trouble following the logic in the sls, need to study it more.
ID: file_V38581-hardlink
Function: module.run
Name: file.link
Result: False
Comment: Module function file.link threw an exception. Exception: Could not create '/boot/grub.conf'
Started: 22:00:46.027891
Duration: 0.881 ms
Changes:
STIG specifies a fix for an indeterminate list. The following only addresses the Linux default scratch directories /tmp and /var/tmp. Prior STIGS require looking for other objects with overly-generous permissions and resetting them. Will explore appropriate resetting permissions against an indeterminite directory-list in future iterations of this SLS.
Current rpm update method individually updates all packages listed as requiring an update via:
{% set updatePairs = salt'pkg.list_upgrades' %}
{% for pkgName in updatePairs %}
remediate_V38481-{{ pkgName }}:
pkg:
If system is kept well-patched, the number of updates is low, handler functions as expected. However, in a large update delta (e.g., as happens at a new ELx point-release) the number of items seems to exceed Salt's capacity causing the Salt-run to crash.
This is why we verify out file counts against our STIG counts...
Currently sourcing a shell script (STIGbyID/cat2/files/V38465-helper.sh) to do the heavy-lifting. More style-conformant to recode as a python module.
Due to issues in mount.mounted
/mount.set_fstab
(detailed in mainline salt Issue ID #17198) this handler will butcher the /etc/fstab
file if there is more than one file of type 'tmpfs'.
Test systems are currently using tmpfs for both /tmp
and /dev/shm
: latter is required; former is best-practices for EL6 and higher.
Upstream fix to the Salt modules for mount.mounted
/mount.set_fstab
should fix this issue. Closure should only require verification. Per comment on original Salt Issue ID this will be in the 2015 code-trees but won't be back-ported into the 2014.7.x code-trees
Script currently works fine when a logging-target's definition starts with a unique first-facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.
Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add
'*',
To the facilityList list-variable.
Need to apply method for configuring pam_faillock similar to those used for pam_cracklib
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Can't disable DHCP in AWS. Need to either set this as an advisory-only handler or put logic in to determine whether it's safe to summarily disable DHCP (probably phase 1 for advisory-only; phase 2+ for conditional)
Currently sourcing a shell script (STIGbyID/cat2/files/V38469-helper.sh) to do the heavy-lifting. More style-conformant to recode as a python module.
This is why we verify out file counts against our STIG counts...
Tried setting a flag in the for-loop and checking for its presence in a state-ending if, but logic wasn't working (would display the "all good" protected output regardless of defined-state).
Need to find a way to run the "all good" test just once.
Finish up support for additional FTP daemons
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Placed logic inside SLS file to check for existence of system-auth-ac file:
{% if not salt['file.file_exists'](checkFile) %}
cmd_V38497-linkSysauth:
cmd.run:
- name: '/usr/sbin/authconfig --update'
{% endif %}
If interpreted in order listed in SLS file, all is good. However, salt-call seems like it's doing out-of-order execution, rendering the above essentially useless. Need to force Salt to do the Right Thing.
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Script currently works fine when a logging-target's definition starts with a unique facility name (e.g., "kern"). However, if the first-defined facility-name isn't unique (specifically encountered error with "*" facility), handler will only set ownership on the last-defined logging-target that matches the facility.
Note: Handling of "*" facility is currently disabled. When the above-noted issue is fixed, add
'*',
To the facilityList list-variable.
Handler assumes that pam_cracklib is in place. While generally valid on EL6, not 100% safe assumption as starting-point: need to add logic for adding cracklib and associated token-setting.
Handler for STIG-ID V-38655 only notifies about some cases - doesn't actually address anything. Will require a major rewrite to perform remidiative actions.
Due to issues in mount.mounted
/mount.set_fstab
(detailed in mainline salt Issue ID #17198) this handler will butcher the /etc/fstab
file if there is more than one file of type 'tmpfs'.
Test systems are currently using tmpfs for both /tmp
and /dev/shm
: latter is required; former is best-practices for EL6 and higher.
Upstream fix to the Salt modules for mount.mounted
/mount.set_fstab
should fix this issue. Closure should only require verification. Per comment on original Salt Issue ID this will be in the 2015 code-trees but won't be back-ported into the 2014.7.x code-trees
This is why we verify out file counts against our STIG counts...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.