While most services have become drastically more secure over the years, there are still many instances in which unsafe processes remain in place, even when more secure options are available. The following examples are common misconfigurations that can easily be remedied.
Host-based authentication only requires that a machine is set up to trust another known machine or server, bypassing other verification processes. However, this is insufficient for preventing unauthorized access since it does not require that each request be verified. If a threat actor were to spoof a trusted machine, any and all requests would be approved without the need for any other form of authentication, such as MFA or interactive identification.
In order to remove host-based authentication, you must delete all .shosts and shosts.equiv files on the system.
Check the system for the existence of these files with the following command:
# find / -name '*.shosts’
# find / -name shosts.equiv
Remove the files with the following command:
# rm <filenames>
Machines are vulnerable when booting or rebooting, since they can often be logged into without any authentication. To ensure that this security vulnerability is eliminated, you can turn off this capability in the configuration file.
Check for the value of the "AutomaticLoginEnable" in the "/etc/gdm/custom.conf" file and make sure that they are set to false:
# grep -i automaticloginenable /etc/gdm/custom.conf
# grep -i timedloginenable /etc/gdm/custom.conf
If you are using the remote access GUI, X11, it’s important to encrypt the traffic during a remote session. Unencrypted traffic is extremely vulnerable, as a threat actor can either capture your display, giving them complete control to execute whatever commands they want.
You can check that X11 connections are encrypted with the following command:
# grep -i x11forwarding /etc/ssh/sshd_config
Edit the /etc/ssh/sshd_config file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "yes."
It’s worth noting that this file may be named differently or be in a different location if you are using a version of SSH that is provided by a third-party vendor. Even if this is the case, you can still edit that file to ensure traffic is encrypted.
Simple Network Management Protocol (SNMP) enables users to get information about a machine without having to log into it. Not only should access to SNMP should be strictly limited, the current default (SNMP version 2) community strings should be changed from the default. SNMP version 3 requires user authentication and encrypts messages, providing additional security.
Check if the file exists:
# ls -al /etc/snmp/snmpd.conf
-rw------- 1 root root 52640 Mar 12 11:08 snmpd.conf
Verify that the defaults have been changed:
# grep public /etc/snmp/snmpd.conf
# grep private /etc/snmp/snmpd.conf
If changed, neither of these commands should return any output.
It is worth noting that even if SNMP is not active, the community strings should still be updated to version 3.
In order to login to SSH, a password should always be required. It is particularly important to enforce that a password be set since it is not only a basic security practice, but also because SSH is used to transmit sensitive information.
To determine if the SSH daemon's "PermitEmptyPasswords" option is set, run the following command:
# grep -i PermitEmptyPasswords /etc/ssh/sshd_config
If set to yes, change the option to no.
Additionally, SSH protocol 1 contains a vulnerability that weakens the cryptographic integrity check. Only version 2 should be running. Check to see which protocol is active by running the following command:
# grep -i protocol /etc/ssh/sshd_config