15 tips to enhance security of your Linux Server

It is not possible for me to tell you with all the possible features because that is out of my knoweldge level but I will try to put everything I know which can be used to make sure that your Linux server security is not compromised.

1. hosts.allow and hosts.deny
These two files are explicitly used in corporate environment to grant and deny access accordingly.

Now manually allow the list of hosts and services who can communicate with your machine

In the below file you are giving the subnet range of IP who are allowed to communicate with your machine and all other would be denied
# cat /etc/hosts.allow
# localhost
ALL: umask 077: allow
ALL : umask 077: allow
ALL : umask 077: allow
ALL : umask 077: allow

If you have a internal dns server like example.com

Here you are allowing all the machine in example.com domain
# cat /etc/hosts.allow
ALL: .example.com
Deny all other connections from any other hosts in hosts.deny file
# cat /etc/hosts.deny
ALL: ALL: deny

2. IPtables
In IPtables we have 3 chains INPUT, OUTPUT, FORWARD. By default all the incoming connections from any host or any service is allowed as shown below
# iptables -L
Chain INPUT (
policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh
DROP       tcp  --  anywhere             anywhere            tcp dpt:telnet
which can not be a good idea in all the cases. So it is always a good idea to block all the incoming connections and allow the required host/services manually using iptables

You can manually BLOCK all the incoming connections
# iptables -P INPUT DROP
# iptables -L
Chain INPUT (
policy DROP)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:ssh
DROP       tcp  --  anywhere             anywhere            tcp dpt:telnet
You can do the same for all the 3 chains in mangle table
# iptables -P FORWARD DROP
# iptables -P OUTPUT DROP
For more information on iptables follow the below links
Basic iptables tutorials I
Basic iptables tutorials II

3. Separate log file for iptables
Prefer to use separate log files for all iptables related logs as /var/log/messages can get flooded with unnecessary info messages reducing the chances of monitoring important kernel/iptables related logs

Follow the subsection Logging in the below link for more information
Basic iptables tutorials II

4. SElinux
Keep SElinux always in enforcing mode. It can sometimes become tricky to add extra acl to allow selinux for certain services but it is always a good practice to improve the security level for services like DNS, Apache, FTP etc
$ cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#       enforcing - SELinux security policy is enforced.
#       permissive - SELinux prints warnings instead of enforcing.
#       disabled - SELinux is fully disabled.
# SELINUXTYPE= type of policy in use. Possible values are:
#       targeted - Only targeted network daemons are protected.
#       strict - Full SELinux protection.

5. Separate partition
It is always a good exercise to create separate partition for different filesystem
For example
                      4.4G  3.3G  879M  80% /
                      3.0G  2.1G  740M  74% /var
                      1.5G  804M  578M  59% /home
/dev/sda1              99M   26M   69M  28% /boot
tmpfs                 502M     0  502M   0% /dev/shm
                      2.0G  294M  1.6G  16% /opt
                      512M  224K  512M   1% /tmp
                      756M  407M  312M  57% /usr

  • In case of any accidents only one of your partition is likely to suffer the damage and all other partitions would have a higher probability to be saved or recover.
  • Individual permissions can be allotted to users as per their work for various partitions
  • Partition size can be increased/decreased whenever required (Possible when partitions are created using LVM)
  • Important data can be isolated in different partition and can be backed up separately
  • Third party software can be installed inside /opt without disturbing the files in other partitions(as per the user policy implemented and packages to be installed)

5. Do not share root password
In a corporate always encourage user to login using their local credential even though they have full sudo access. Because in that way it makes easier to keep track of any system changes made by a individual user for critical data.
# cat /var/log/secure
Jan 29 23:42:58 server1 sshd[23768]: Accepted keyboard-interactive/pam for deepak from port 64883 ssh2
Jan 29 23:42:58 server1 sshd[23768]: pam_unix(sshd:session):
session opened for user deepak by (uid=0)
Jan 30 00:26:41 server1 sshd[24695]: Accepted publickey for user1 from port 54641 ssh2
Jan 30 00:26:41 server1 sshd[24695]: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Jan 30 01:41:24 server1 unix_chkpwd[26197]: check pass; user unknown
Jan 30 01:41:24 server1 unix_chkpwd[26197]: password check failed for user (deepak)
Jan 30 01:41:24 server1 sudo: pam_unix(sudo:auth): authentication failure; logname=deepak uid=0 euid=0 tty=/dev/pts/96 ruser= rhost=  user=deepak
Jan 30 01:41:26 server1 sudo: deepak : TTY=pts/96 ; PWD=/home/deepak ; USER=root ; COMMAND=/bin/cat /var/log/secure

6. Verifying signed packages
All Red Hat Enterprise Linux packages are signed with the Red Hat GPG key. GPG stands for GNU Privacy Guard, or GnuPG, a free software package used for ensuring the authenticity of distributed files. For example, a private key (secret key) locks the package while the public key unlocks and verifies the package. If the public key distributed by Red Hat Enterprise Linux does not match the private key during RPM verification, the package may have been altered and therefore cannot be trusted

To display a list of all keys installed for RPM verification, execute the following command
$ rpm -qa gpg-pubkey*
To display details about a specific key, use the rpm -qi command

$ rpm -qi gpg-pubkey-147645k7-15h2a987
 Name        : gpg-pubkey                   Relocations: (not relocatable)
Version     : 147645k7                          Vendor: (none)
Release     : 15h2a987                      Build Date: Mon Nov  4 16:56:11 2013
Install Date: Mon Nov  4 16:56:11 2013         Build Host: localhost
Group       : Public Keys                   Source RPM: (none)
Size        : 0                                License: pubkey
Signature   : (none)
Summary     : gpg(Fedora EPEL <epel@fedoraproject.org>)
Description :
Version: rpm- (NSS-3)

To verify any of the downloaded packages, issue the following command:
# rpm -K python-dmidecode-3.10.13-1.el5_5.1.x86_64.rpm
(sha1) dsa sha1 md5 gpg OK
For each package, if the GPG key verifies successfully, the command returns gpg OK. If it does not, make sure you are using the correct Red Hat public key, as well as verifying the source of the content. Packages that do not pass GPG verification should not be installed, as they may have been altered by a third party.

In order to have automatic GPG signature verification enabled when installing or updating packages via Yum, ensure you have the following option defined under the [main] section of your /etc/yum.conf file:

7. Scanning host with nmap
Nmap is a popular tool that can be used to determine the layout of a network. Nmap is a competent first step in vulnerability assessment. You can map out all the hosts within your network and even pass an option that allows Nmap to attempt to identify the operating system running on a particular host. Nmap is a good foundation for establishing a policy of using secure services and restricting unused services.

# nmap localhost
# nmap remote_machine

8 SSH related tweaks

  • change the default port

Everyone of us know that SSH runs on port 22 so in case you want to harden the security, change the port no. to a random no. so that it becomes harder to breach into your network for any ssh connection
[prasadee@aid-po ~]$ sudo cat /etc/ssh/sshd_config | grep Port
#Port 22
(Uncomment and change the port no. then restart the services)

  • Disable root ssh login

[prasadee@aid-po ~]$ sudo cat /etc/ssh/sshd_config | grep PermitRootLogin
#PermitRootLogin yes
(Uncomment and change it to "NO")

  • Allow individual users login

AllowUsers This keyword can be followed by a list of user name patterns, separated by spaces.

9. Use password expiry
You can use chage command to set password exipiry date for all the users.
To view the expiry related information for a user
# chage -l username

  -d, --lastday LAST_DAY        set last password change to LAST_DAY
  -E, --expiredate EXPIRE_DATE  set account expiration date to EXPIRE_DATE
  -I, --inactive INACTIVE       set password inactive after expiration to INACTIVE
  -l, --list                    show account aging information
  -m, --mindays MIN_DAYS        set minimum number of days before password change to MIN_DAYS
  -M, --maxdays MAX_DAYS        set maximim number of days before password change to MAX_DAYS
  -W, --warndays WARN_DAYS      set expiration warning days to WARN_DAYS
To assign an expiry
# chage username

10. User account management
Delete or lock any user account which is no more in use. For example in case a user has left the organisation but there are important files in his home directory which is still useful so lock the user account and do not delete it. So that atleast all the files under his ownership could still be accessible.

The below commands will disable him from logging in and will lock his account
# usermod -L username
# usermod -s /sbin/nologin username

11. Audit regularly
The 2.6 Linux kernel has the ability to log events such as system calls and file access. These logs can
then be reviewed by the administrator to determine possible security breaches such as failed login attempts or a user failing to access system files. This functionality, called the Linux Auditing System.

You can manually track a file or directory for any changes done by any user using audit.

The below command will list all the events which has occurred on your Linux machine (successful/failed/attempts..)
# aureport
For more information please follow the below link
Using audit in Linux to track all the logs

12. Monitor logs regularly
Apart from using audit you should manually check your logs especially kernel related and authentication related to make sure there was no attempt made for an unauthorized access
# less /var/log/secure

13. Regular Backup
Take regular backup of your critical data or partitions.

Backups can be taken using any of the below options

14. GRUB password
It is always safer to keep a password at GRUB menu during the Linux Boot Process
# vi /boot/grub/grub.conf
Add an extra parameter as shown below
password example@156
Change the permission of this file to 600 so that only root can access it and no other user
$ ll /boot/grub/grub.conf
-rw------- 1 root root 1160 Jan 21  2011 /boot/grub/grub.conf

15. chattr command
You can protect critical files from accidental deletions by any user. Once the attribute is set for any file, it can not be edited or deleted by any user including root unless attribute is again removed.

For more details follow the below link
Increase security with extended file attributes

These are just a glimpse of some security features which can be utilized by organisation for better security. But apart from these there can be many other steps which can be taken to enhance the security but that would again depend upon the type of environment and working parameters.

I would welcome any point from my readers if I missed in my article.

Related Articles