As it was well received last year, we decided to do another security-focused holiday calendar this year. The concept was roughly the same, but instead of only adding security hardening modules, we’ve also added in some other security advice and blog posts to improve the variety. Now that we’re halfway through to 24 (or 25), let’s recap the first half of the calendar.
The problematic remote shell (rsh) (1/25)
Remote shell (rsh) allows you to log in and send commands to another computer over the network.
It is notoriously insecure, sending traffic in an unencrypted manner.
In some implementations of rsh, passwords are also sent over the network in plaintext.
rsh should no longer be used, as much more secure alternatives exist, such as ssh.
This module helps you uninstall rsh:
build.cfengine.com/modules/uninstall-rsh-server
Recommendation: Do not have the rsh-server module installed on any of the machines in your infrastructure, as it presents a substantial security risk.
Use CFEngine Enterprise’s software inventory to verify that it isn’t installed anywhere, and this module to enforce it (uninstalling the module if it appears somewhere).
This ensures you are protected in the future, if somebody installs the package on a machine, or if somebody adds a machine with the package installed to the infrastructure.
Updates, upgrades, and uptime (2/25)
On December 2nd, we discussed updates to software packages as well as operating systems, how you can find hosts which need attention and why uptime can help you look for the most neglected hosts in your infrastructure:
cfengine.com/blog/2022/updates-upgrades-and-uptime
Recommendations:
- Ensure you are running recent operating systems and at the very least operating systems supported by the vendor.
- Use automation to help you effectively upgrade software packages.
- Set up reports / alerts to help highlight which hosts need attention and prioritize which hosts to work on first.
Limit access to /etc/motd (3/25)
In unix-like systems the /etc/motd file is used to display relevant information to users after logging in.
When a user logs in, it is quite common that they get information about the machine, where to find documentation, who to contact if you need help, etc.
Since users may trust and rely on the information there, it is important to prevent misuse by limiting access.
Possible attack vectors include telling users to run a specific command or give them a wrong (malicious) web address or email address for help.
This module enforces access to /etc/motd:
build.cfengine.com/modules/etc-motd-access
Recommendation: Limit access to /etc/motd by setting its owner and group to root, and permission bits to 0644.
No longer talking (4/25)
The talk program allowed users on early unix systems in the 80’s and 90’s to chat with each other.
As it does not encrypt communication, and has been proven vulnerable in several ways, its use today is discouraged.
The best approach is to uninstall it:
build.cfengine.com/modules/uninstall-talk
Recommendation: Do not use talk as it is insecure (provides no encryption for communication).
Uninstall both talk and talk-server, and ensure it isn’t used / installed in your infrastructure.
Address space layout randomization (ASLR) (5/25)
Address space layout randomization (ASLR) helps prevent exploits by randomly changing the address at which programs are located. Without ASLR an exploit can rely on the location of various aspects of a program and more easily perform an attack. This feature was first introduced around 2005 in Linux and subsequently in most other operating systems in the following years. 64-bit systems benefit more from this feature because the larger address space allows for greater entropy in randomizing the locations of programs. At this time there are known exploitations even of this protection mechanism but it is still best practice to ensure this feature is fully enabled on your systems.
build.cfengine.com/modules/enable-aslr
Recommendation: Ensure that ASLR is fully enabled on all systems to make exploits relying on address space layout more difficult.
Delete .shosts files in home directories (6/25)
Host-based authentication with ~/.shosts is the equivalent to /etc/ssh/.shosts.equiv.
It allows individual users to define a list of trusted remote machines, or user-machine pairs, which are allowed to try host-based authentication.
However a global .shosts.equiv is preferable to having .shosts in each and every home directory.
This module helps you delete the undesirable files:
build.cfengine.com/modules/delete-home-dotshosts
Recommendation: Do not use user defined host based authentication. Use this delete-home-dotshosts module to inventory and delete ~/.shosts files. This ensures you are protected in the future, if somebody adds a ~/.shosts file.
Limit access to /etc/issue (7/25)
In unix-like systems the /etc/issue file is used to display relevant information to users before logging in.
Since users may trust and rely on the information there, it is important to prevent misuse by limiting access.
Possible attack vectors include telling users to run a specific command or give them a wrong (malicious) web address or email address for help.
This module helps you enforce strict access to /etc/issue across your infrastructure:
build.cfengine.com/modules/etc-issue-access
Recommendation: Limit access to /etc/issue by setting its owner and group to root, and permission bits to 0644.
Unshadowed passwords in /etc/passwd (8/25)
The /etc/passwd file contains information about local users on the system.
This file is readable by different users on the system to allow them to look up usernames and translate between UIDs and usernames.
The /etc/shadow file was introduced to prevent users from seeing eachothers password hashes (thus prevent them from performing an offline brute force attack).
Use this inventory module to add reporting data for users which don’t use shadowed passwords, as they present a security risk:
build.cfengine.com/modules/inventory-unshadowed-users
Recommendation: In the /etc/passwd file, only x should be allowed in the second column (password field).
This indicates that the /etc/shadow file is used.
Any other users (“unshadowed” users) should be deleted or forced to change password.
Building compliance reports (9/25)
On December 9th, Craig Comstock wrote about using modules which provide reporting data (called inventory) to create custom compliance reports:
cfengine.com/blog/2022/compliance-report-based-on-inventory-modules
Recommendation: Build custom Compliance Reports to check the reporting data from your hosts, ensuring they are compliant with your security requirements. Update and expand these reports over time as your infrastructure grows and security requirements change.
Access to cron-related files (10/25)
The cron utility enables running commands or programs periodically.
System-wide cron-related configuration files exist in the /etc directory.
For these files, enforcing strict access is essential, as editing them allows you to run commands as any user, including root.
This module continuously enforces owners, groups and permission bits on cron-related files and directories:
build.cfengine.com/modules/cron-access
Recommendation: Limit access to the various cron-related files and directories in /etc.
All of them should be owned by root and have group set to root as well.
For the directories, permissions should be 0700.
The /etc/crontab file should have permissions 0600, and /etc/cron.allow can have slightly less restrictive permissions, 0640.
Use AIDE for integrity checking (11/25)
The AIDE (Advanced Intrusion Detection Environment) software enables integrity checking of installed software. It works by taking a snapshot of files, storing metadata about them (including hashes), and then comparing with the know values later, when you perform a “check”. When software / files change unexpectedly, this can indicate an attacker is making changes to the system (Intrusion Detection).
build.cfengine.com/modules/install-aide
Recommendation: Install and use AIDE to detect changes to installed software, potentially from attackers. Run the check at least once per week, and set it up to alert you (via email) when there are unexpected changes.
Subscribe to the calendar
We are just halfway through the calendar, there’s about 12 more days left, so it’s not too late to sign up. To receive daily security recommendations through Dec. 25th, sign up here.
