23 Hardening Tips to Secure your Linux Server It is important to secure a Linux system as much as possible in order to reduce the likelihood of compromise. Here are 23 security tips to guide you through hardening your Linux operating system. Index 1. Patch the Operating System 2. Patch Third Party Applications 3. Disable Remote Root Access 4. Disable Root Console Access 5. Restrict Root Privileges 6. Enable and Configure Firewall 7. Encrypt Network Transmissions 8. Two Factor Authentication 9. SecurityEnhanced Linux (SELinux) 10. Reduce Attack Surface 11. Log Review 12. Limit SSH Access 13. Physical Security 14. Securing the BIOS 15. Securing the Boot Loader 16. Encrypt Data 17. Centralized Authentication 18. Enforce Strong Passwords 19. Password Aging 20. Account Lockout 21. Using SSH Keys 22. Host Based Intrusion Detection System (HIDS) 23. Virus/Malware Scanning Note: This guide refers to a Linux system as a server, computer, or client. These terms should be read interchangeably as all tips apply to any system running Linux. Posted by Jarrod on September 1, 2015 Leave a comment (1) Go to comments RootUsers Guides, tutorials, reviews and news for System Administrators. Home Categories Archives About Contact Search: type, hit enter
19
Embed
23 Hardening Tips to Secure Your Linux Server _ RootUsers
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
23 Hardening Tips to Secure your Linux Server
It is important to secure a Linux system as much as possible in order to reduce the likelihood of
compromise.
Here are 23 security tips to guide you through hardening your Linux operating system.
Index
1. Patch the Operating System
2. Patch Third Party Applications
3. Disable Remote Root Access
4. Disable Root Console Access
5. Restrict Root Privileges
6. Enable and Configure Firewall
7. Encrypt Network Transmissions
8. Two Factor Authentication
9. SecurityEnhanced Linux (SELinux)
10. Reduce Attack Surface
11. Log Review
12. Limit SSH Access
13. Physical Security
14. Securing the BIOS
15. Securing the Boot Loader
16. Encrypt Data
17. Centralized Authentication
18. Enforce Strong Passwords
19. Password Aging
20. Account Lockout
21. Using SSH Keys
22. Host Based Intrusion Detection System (HIDS)
23. Virus/Malware Scanning
Note: This guide refers to a Linux system as a server, computer, or client. These terms should be read
interchangeably as all tips apply to any system running Linux.
Posted by Jarrod on September 1, 2015 Leave a comment (1)Go to comments
RootUsers Guides, tutorials, reviews and news for System Administrators.
Home Categories Archives About ContactSearch: type, hit enter
Another good option when installing Linux is to select a minimal installation, this will install a base set of
important packages that are required with not much extra bloat. This is preferable as you will have fewer
packages installed, you can easily install anything that you require after installation from the repository
rather than having a bunch of packages preinstalled that may never even be used.
Your attack surface can be reduced by disabling services that are not needed and by uninstalling or
removing packages and software that are not required. The following commands can be used to view the
status of installed services, they will list services that are configured to start up on boot.
CentOS 6 and earlier
chkconfig list
CentOS 7
systemctl listunitfiles type=service
Should you find a service that you know is not required it can be disabled so that it does not start on boot,
only do this if you are sure that the service is not required as some may be needed by the operating system
or other services that you make use of.
CentOS 6 and earlier
chkconfig off servicename
CentOS 7
systemctl disable servicename
To view a full list of installed packages you can run ‘yum list installed’, should you determine that there are
packages that are no longer required you can remove them with ‘yum remove packagename‘.
With the netstat command you can list the ports that a process on the server is actively listening for
connections on. This can help identify something malicious that is running waiting to accept an external
connection, or may show an already established connection that should not be allowed. This is why you
would want to restrict the connectivity in the firewall as outlined in point 6 – Enable and configure firewall. If
you find something malicious you can try to stop the service or kill the listed PID, though this likely will not
stop it from starting up again.
[root@centos ~]# netstat antup Active Internet connections (servers and established) Proto RecvQ SendQ Local Address Foreign Address State PID/Program nametcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1218/sshd
central directory such as Active Directory or Identity Management. Ideally you’re using a central directory to
make these policy changes much easier, you would set them in one place and they would apply for all
users that log in over a multitude of servers.
It is possible to manage password aging on a per server basis locally, it will just require more administration
time and increases the likelihood of a configuration mistake which can result in less secure accounts. Below
are some example commands to apply password aging.
Show account aging information, these values can be modified further with the chage command.
[root@centos ~]# chage l bob Last password change : Aug 19, 2015 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
To run chage interactively to set these values on a user account run ‘chage username‘.
20. Account Lockout
While having strong passwords in place for user accounts can help thwart brute force attacks as mentioned
previously in point 18 – Enforce strong passwords, this is only one way of slowing down this type of attack.
A good indication of brute force attack is a user account that has failed to log in successfully multiple times
within a short period of time, these sorts of actions should be blocked and reported. We can block these
attacks by automatically locking out the account, either at the directory if in use or locally.
The pam_tally2.so PAM module can be used to lock out local accounts after a set number of failures. To
get this working I have added the below line to the /etc/pam.d/passwordauth file.
will allow only the corresponding private key access.
It is therefore extremely important that you protect your private key, if an attacker is able to access this key
then they will be able to log in as your user. Best practices dictate that your private key be encrypted with a
passphrase which can be configured when you create the key pair. It’s also important that the private key
file be readable and writable only by the user that owns the key, this would be permissions 0600 and is set
as default on creation.
Create the key pair with the sshkeygen command, the t specifies the type of key to create, here we are
using rsa version 2.
[bob@centos root]$ sshkeygen t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/bob/.ssh/id_rsa): Created directory '/home/bob/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/bob/.ssh/id_rsa. Your public key has been saved in /home/bob/.ssh/id_rsa.pub. The key fingerprint is: 8e:dc:08:bb:8d:0e:12:04:22:ae:5e:f5:0a:21:3e:b0 bob@centos The key's randomart image is: +[ RSA 2048]+ |+ | |= | |.+ . . | |=.. o . | |Eo o. .S | |..o .+.= | |... ..+ o | | . . + | | .+ . | ++
[bob@centos ~]$ ls la /home/bob/.ssh/ rw. 1 bob bob 1766 Aug 19 16:41 id_rsa rwrr. 1 bob bob 398 Aug 19 16:41 id_rsa.pub
In the above example we created the id_rsa private key file and corresponding id_rsa.pub public key file.
Next upload the public key to the remote server that you wish to access, this can be done manually or with
the sshcopyid command as shown below.
[bob@centos .ssh]$ sshcopyid [email protected] The authenticity of host '1.2.3.4' can't be established. ECDSA key fingerprint is 97:b6:fc:11:49:20:3c:10:ac:16:49:46:e5:56:03:30. Are you sure you want to continue connecting (yes/no)? yes /usr/bin/sshcopyid: INFO: attempting to log in with the new key(s), to filter out any that are already installed/usr/bin/sshcopyid: INFO: 1 key(s) remain to be installed if you are prompted now it is to install the new [email protected]'s password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh '[email protected]'" and check to make sure that only the key(s) you wanted were added.
This will place the id_rsa.pub public key file on the destination server, in this case ‘1.2.3.4’ within the
~/.ssh/authorized_keys file, you can then SSH to the destination by simply running ‘ssh [email protected]’ and
you should be prompted for the passphrase for your private key.
Once an account has been set up to make use of SSH keys rather than a password you can optionally
disable password authentication through /etc/ssh/sshd_config to increase security as shown below.
PasswordAuthentication no PubkeyAuthentication yes
Reload sshd to apply these changes.
22. Host Based Intrusion Detection System (HIDS)
Even after implementing additional security measures it is still possible that your server may become
compromised, no server should ever be considered 100% secure. Should this happen you would want to be
alerted so that you can investigate further. This can be done by using a host based intrusion detection
system which is typically installed on the server as an agent which monitors the internals of the system and
can alert if an attempted or successful intrusion is detected. While this definitely will not detect and alert for
every possible intrusion it is a good protection measure to put in place.
OSSEC is a crossplatform open source HIDS that is capable of performing log analysis, file integrity
checking, policy monitoring, rootkit detection and real time alerting and response.
23. Virus/Malware Scanning
In addition to detecting intrusion it is also important to frequently scan the file system, memory and running
processes for known viruses or malware threats that may have made it onto your Linux server. The scan
should be able to actively quarantine known bad files that are detected and send out a notification alert for
further investigation.
It is a good idea to run such scans during periods of low resource usage so that the scan does not conflict
with normal service. This will depend on the work load of your server, however scanning over night or on
the weekend usually works well and most tools allow you to specify a load level threshold to pause at and
continue after it drops back down.
ClamAV is a popular open source antivirus available for Linux to detect viruses, trojans, malware and other
malicious threats and works quite well. A lot of other tools also incorporate ClamAV such as Maldet which is
another great tool. Other options such as Config eXploit Scanner (CXS) also makes use of ClamAV and will
actively scan files as they are uploaded or modified, for instance if an attacker is able to modify a file with
NOTE You can use these HTML tags and attributes:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquotecite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s><strike> <strong>
NAME
EMAIL
Website URL
S U BM I T
Notify me of followup comments by email.
Notify me of new posts by email.
Trackbacks and Pingbacks:
How To Configure KeyBased Authentication for SSH | RootUsers Pingback on 2015/11/21/ 22:26