[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

DISA STIG (Security Technical Implementation Guides) Audit Tool for Debian

Something interesting here?

Similar to:

1 Like

These type of guides are usually aimed at servers and not desktop computers. Hence a lot of the content is securing things like mail servers and not stuff that would apply to us.

1 Like

A lot things worth checking. Started.

https://www.whonix.org/wiki/Dev/STIG

1 Like

Went through all the “fails”.

[ FAIL ] The cryptographic hash of system files and commands must match vendor values.

Seems like verified boot?

[ FAIL ] The operating system must have the screen package installed.

I don’t see how this is relevant.

[ FAIL ] When passwords are changed …
[ FAIL ] Passwords for new users must be restricted to a 24 hours/1 day minimum lifetime.
[ FAIL ] Passwords must be restricted to a 24 hours/1 day minimum lifetime.
[ FAIL ] Existing passwords must be restricted to a 60-day maximum lifetime.
[ FAIL ] Passwords must be prohibited from reuse for a minimum of five generations.
[ FAIL ] Passwords must be a minimum of 15 characters in length.
[ FAIL ] When passwords are changed or new passwords are established, pwquality must be used.

pam_cracklib has been discussed before.

[ FAIL ] The operating system must disable account identifiers (individuals, groups, roles, and devices) if the password expires.

We don’t set password expiry limits and they’re more likely to just annoy users.

[ FAIL ] Accounts subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period.
[ FAIL ] If three unsuccessful root logon attempts within 15 minutes occur the associated account must be locked.

We do lock accounts although after 50 failed logins rather than 3.

[ FAIL ] The delay between logon prompts following a failed console logon attempt must be at least four seconds.

pam_faildelay has been discussed before.

[ FAIL ] The SSH daemon must …
[ FAIL ] The operating system must not allow users to override SSH environment variables.
[ FAIL ] The operating system must not allow a non-certificate trusted host SSH logon to the system.
[ FAIL ] All networked systems must have SSH installed.
[ FAIL ] All networked systems must use SSH for confidentiality and integrity of transmitted and received information as well as information during preparation for transmission.
[ FAIL ] All network connections associated with SSH traffic must …
[ FAIL ] The system must display the date and time of the last successful account logon upon an SSH logon.
[ FAIL ] The system must not permit direct logons to the root account using remote access via SSH.
[ FAIL ] A FIPS 140-2 approved cryptographic algorithm must be used for SSH communications.

We don’t use SSH.

[ FAIL ] The operating system must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization.

Apt does signature verification.

[ FAIL ] The x86 Ctrl-Alt-Delete key sequence must be disabled.

I see no security benefit for this at all but if you want to, it can be disabled via the kernel.ctrl-alt-del sysctl.

[ FAIL ] The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.

permission-lockdown does this.

[ FAIL ] The system must not have accounts configured with blank or null passwords.
[ FAIL ] Users must provide a password for privilege escalation.
[ FAIL ] The operating system must enable AppArmor.
[ FAIL ] The operating system must be a vendor supported release.
[ FAIL ] Vendor packaged system security patches and updates must be installed and up to date.
[ FAIL ] All local interactive user accounts, upon creation, must be assigned a home directory.
[ FAIL ] All local interactive user home directories defined in the /etc/passwd file must exist.

False positives.

[ FAIL ] All files and directories contained in local interactive user home directories must be owned by the owner of the home directory.
[ FAIL ] All files and directories contained in local interactive user home directories must be group-owned by a group of which the home directory owner is a member.
[ FAIL ] All files and directories contained in local interactive user home directories must have mode 0750 or less permissive.
[ FAIL ] All local initialization files must have mode 0740 or less permissive.

Doesn’t matter if the home directory itself is only accessible by the user which is done via permission-lockdown.

[ FAIL ] File systems that contain user home directories must be mounted to prevent files with the setuid and setgid bit set from being executed.

remount-secure does this.

[ FAIL ] File systems that are being imported via Network File System (NFS) must be mounted to prevent files with the setuid and setgid bit set from being executed.
[ FAIL ] File systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed.

We don’t use NFS.

[ FAIL ] The umask must be set to 077 for all local interactive user accounts.

Was discussed before and permission-lockdown is a better approach.

[ FAIL ] The system must use a separate file system for /var.
[ FAIL ] The system must use a separate file system for the system audit data path.
[ FAIL ] The system must use a separate file system for /tmp (or equivalent).

https://phabricator.whonix.org/T522

[ FAIL ] Cron logging must be implemented.
[ FAIL ] The file integrity tool must be configured to verify Access Control Lists (ACLs).
[ FAIL ] The file integrity tool must use FIPS 140-2 approved cryptographic hashes for validating file contents and directories.
[ FAIL ] Auditing must be configured to produce records containing information to establish what type of events occurred, where the events occurred, the source of the events, and the outcome of the events.
[ FAIL ] The operating system must shut down upon audit processing failure, unless availability is an overriding concern. If availability is a concern, the system must alert the designated staff (System Administrator [SA] and Information System Security Officer [ISSO] at a minimum) in the event of an audit processing failure.
[ FAIL ] The operating system must off-load audit records onto a different system or media from the system being audited.
[ FAIL ] The operating system must encrypt the transfer of audit records off-loaded onto a different system or media from the system being audited.
[ FAIL ] The audit system must take appropriate action when the audit storage volume is full.
[ FAIL ] The operating system must immediately notify the System Administrator …
[ FAIL ] All uses of the … command must be audited.
[ FAIL ] The operating system must generate audit records for all …
[ FAIL ] The audit system must take appropriate action when there is an error sending audit records to a remote system.
[ FAIL ] The system must send rsyslog output to a log aggregation server.

We don’t use any auditing/integrity/logging/etc. tools and I don’t think we should.

[ FAIL ] The system must use a DoD-approved virus scan program.
[ FAIL ] The system must update the DoD-approved virus scan program every seven days or more frequently.

Virus scanners are essentially useless.

[ FAIL ] The operating system must limit the number of concurrent sessions to 10 for all accounts and/or account types.
[ FAIL ] All network connections associated with a communication session must be terminated at the end of the session or after 10 minutes of inactivity from the user at a command prompt, except to fulfill documented and validated mission requirements.

Vague. What’s a “session”?

[ FAIL ] The Standard Mandatory DoD Notice and Consent Banner must be displayed immediately prior to, or as part of, remote access logon prompts.

Attackers won’t care about a banner.

[ FAIL ] The operating system must, for networked systems, synchronize clocks with a server that is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

Sdwdate is far better.

[ FAIL ] The operating system must protect against or limit the effects of Denial of Service (DoS) attacks by validating the operating system is implementing rate-limiting measures on impacted network interfaces.

The firewall doesn’t even allow incoming connections.

[ FAIL ] The system must display the date and time of the last successful account logon upon logon.

This is only useful on multi-user systems.

[ FAIL ] Remote X connections for interactive users must be encrypted.

We don’t use any remote X connections.

[ FAIL ] An X Windows display manager must not be installed unless approved.

We need X.

TLDR: Nothing useful and this is why I really dislike these types of hardening guides.

1 Like

Found this.

https://help.ubuntu.com/lts/serverguide/console-security.html

Anyone that has physical access to the keyboard can simply use the Ctrl+Alt+Delete key combination to reboot the server without having to log on. While someone could simply unplug the power source, you should still prevent the use of this key combination on a production server. This forces an attacker to take more drastic measures to reboot the server, and will prevent accidental reboots at the same time.

This doesn’t seem very helpful to me.

1 Like

We can document that here (new page):
https://www.whonix.org/wiki/Server_Security_Guide

Threat models where this is useful are limited indeed. Makes more sense when there are visitors who could use a keyboard but power plug is considered secured (in a case). Maybe kiosk mode or something.

1 Like

Me too as per https://www.whonix.org/wiki/Dev/STIG#Commented_Output

https://www.whonix.org/wiki/Dev/STIG#Commented_Output

bash scripts/check-package-verify.sh >/dev/null 2>&1 & spinner $! output “SV-86479r2_rule” $?

Probably porting issue. check-package-verify.sh [archive] does not test anything security relevant.

Yes, comments added there and linked to open discussions.

[1] Defended in other ways. See [[Dev/Permissions]]. Unclear rationale. Discussed here: enforce minimum password strength / pam-cracklib

Agreed. Added comment:

Same as [1].

Expiry limits would likely just annoy users. This might be more useful in an enterprise context where shoulder surfing might be an issue.

TODO: document shoulder surfing

Right. Added comment:

Same as [1].

Set to 50 before unlockk procedure is required. 50 attempts is far to less for bruteforce.

Setting it to 3 might fall victim to some bugs. There are cases involving sudo where 1 login attempt is recognized as 3 due to pasting text by mistake into the terminal emulator. We might incrementally lower 50 over the releases if that seems worthwhile but not to 3. Can be discussed in protect Linux user accounts against brute force attacks

Same as [1].

Likely a false positive but should check the code of the test just to make sure.

Likely also a false positive but need to check the test code. Similar for other false positives.

needs development, tracked in (re-)mount home [and other?] with noexec (and nosuid [among other useful mount options]) for better security?

Mostly agreed with your other comments

https://www.whonix.org/wiki/Dev/STIG#Conclusion

Initial impression:

  • Mostly applicable to governmental or enterprise environments.
  • Whonix / Kicksecure is not an enterprise operating system yet. Such a flavor might be possible in future if an enterprise pays for implementation of these features / such a flavor.
  • Lots of false positives.
  • Doesn’t test for and/or find anything catastrophic such as remote exploitable vulnerabilities.
  • Would still be useful to work through the list and add comments for any reported failure.
1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]