File Transfer Protocol (FTP) Service Considerations
FTP is used to exchange files between systems on a computer network in its simplest form. There are a number of security considerations to think about when using FTP on servers. First, determine whether you are going to allow unencrypted file transfers, which is the default, or whether you are going to implement an encrypted file transfer using FTPS or SFTP.
Next, when securing your FTP implementations, you must create an FTP users file. This file contains a list of accounts not authorized to use FTP and generally consists of system accounts that do not need to transfer files back and forth. This file should be owned by root to protect it from unauthorized modification and enforce least privilege, which limits access only to those who need it, when and where they need it. A permissions level like 640 gives only the owner (root) write permissions, ensuring that only root determines what is placed in the file. Least privilege should further be enforced by restricting users from transferring files through FTP when necessary, even if FTP is available.
Mail Service Considerations
Another heavily used service on AIC machines that needs securing is mail. If you don’t use mail, make sure to disable sendmail and Postfix unless it is required.
First, make sure that logging is set appropriately. If sendmail is not configured to log at the default of level nine, your system logs may not have enough information for tracking unauthorized use of the service. Configure etc/syslog.conf to log information on SMTP services, so abnormal or malicious activity will be recorded in the syslog system or will be prioritized by a SIEM, enabling you to take immediate action.
Check that the mail and SMTP service log files are owned and only writable by root, with the mode of at least 644 or more restrictive. This ensures that no one can go in and make changes to cover their tracks.
Your aliases file should also be owned by root and reside in a root owned directory, otherwise a threat actor may go in and modify that file to run malicious code or redirect emails. Typically, an aliases file is located in etc/mail/aliases, but may also be found through usr/lib/aliases. Make sure that the permissions are not more than 644 so that access to that file is properly restricted.
SMTP Service Considerations
Keep the version of your SMTP (Simple Mail Transfer Protocol) service private, as it can be used by attackers to plan an attack based on vulnerabilities present in that specific version. For example, if your greeting includes a version reference, alter it to something more generic so people don't know what to target. Telnet to the port and see what is returned to ensure the version is now hidden.
O SmptGreetingMessage= Mail Server Ready ; $b
The version information may also be displayed on default when a user utilizes the help command. The easiest way to mask this information is to disable SMTP HELP by creating an empty sendmail HELP file that can be tailored to have help topics listed without any additional information that can help malicious actors to get in and target your system.
Finally, the .forward file should be found and removed. While it allows users to automatically forward mail to other systems, it unfortunately can also be used for unauthorized forwarding of mail. It can also degrade your system performance and be used as a denial of service type attack by essentially setting up recursive mail loops that burn up system resources. Find:
/ -name .forward –print & # > /etc/mail/help
SNMP Service Considerations
Let’s now focus on another service, SNMP (Simple Management Network Protocol). Whether it’s active or not, default SNMP passwords, users, and passphrases should be regularly changed to maintain your system security. Unauthorized changes should be prevented by restricting permissions to 600. If the service is running, either on purpose or inadvertently, and it has default authenticators like a password of ‘password’ or permissions level of 777, then anybody can grab data about the system and network, and use it to potentially compromise the integrity of your systems.
You also want to protect configuration files from changes in Management Information Bases (MIB) files. Make sure they are mode 640 or less permissive since even being able to even read the MIB files can impart special knowledge to intruders or malicious actors about how to extract compromising information about your system and network.
Restricting these configurations by default is not done only to meet best practices, but because it is an effective way for your organization to take proactive security measures before issues arise, instead of having to focus on response and remediation efforts to internal and external threats.
Cron Service Considerations
The cron facility is a common service that allows you to execute reoccurring jobs on a regularly scheduled basis. Since it’s able to run repetitive tasks unattended, it’s a great place for internal and external attackers to strike, creating jobs that can constantly re-infect the environment, reopen back doors, or abuse the system in any number of ways. While the cron.allow file designates accounts that are allowed to enter and execute such jobs, cron.allow or cron.deny controls and prevents unlimited access to the cron facility.
Secure var/adm/cron/cron.allow and var/adm/cron/cron.deny by setting permissions at 0600, with read-write abilities retained exclusively by the owner. Cron should never execute group writable or world writable programs because there is a possibility that unauthorized users can manipulate those programs with malicious intent. Check your crontabs, follow all the program paths, and remove any identified world or group writable permissions inside of those paths. From there, set the crontabs permissions to 600 to prevent future group or world writable programs.
- Control access with cron.allow and/or cron.deny
- Make sure these files are set to mode 0600 owned by root
- List the cron jobs and determine what they execute and from where
- ls /var/spool/cron/crontabs/
- The crontab directory should be 0755 and crontab file should have a mode of 600
- The crontab directory owner should be root or bin with a group of sys, system, bin or preferably cron
- Cron logging should be implemented
- These same things also apply to the at service
The same should be done for executing programs for world writable directories. If cron programs are located in, or subordinate to, world writable directories, then they are vulnerable to removal or replacement by malicious users or system intruders. Make sure your crontab directory is set to at least mode 755, with the owner set as root or bin and the group set as sys, system, bin, or even preferably cron.
Cron logging not only allows you to trace successful or unsuccessful execution of those cron jobs, it can also be used to spot intrusions into the use of the cron facility by unauthorized or malicious users. Verify var/adm/cron/log exists and that it is set to 600 to ensure no one can access and alter it to cover their tracks.