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: 127.0.0.1: umask 077: allow
ALL : 192.168.0.0/255.255.255.0: umask 077: allow
ALL : 10.0.0.0/255.0.0.0: umask 077: allow
ALL : 172.168.0.0/255.255.255.0: 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.
SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
5. Separate partition
It is always a good exercise to create separate partition for different filesystem
For example
/dev/mapper/VolGroup00-root
4.4G 3.3G 879M 80% /
/dev/mapper/VolGroup00-var
3.0G 2.1G 740M 74% /var
/dev/mapper/VolGroup00-home
1.5G 804M 578M 59% /home
/dev/sda1 99M 26M 69M 28% /boot
tmpfs 502M 0 502M 0% /dev/shm
/dev/mapper/VolGroup00-opt
2.0G 294M 1.6G 16% /opt
/dev/mapper/Applications-tmp
512M 224K 512M 1% /tmp
/dev/mapper/VolGroup00-usr
756M 407M 312M 57% /usr
Advantages:
- 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 172.18.249.167 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 10.26.1.143 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*
gpg-pubkey-147645k7-15h2a987
gpg-pubkey-187nh23x-17h75fg8
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 : -----BEGIN PGP PUBLIC KEY BLOCK----- Version: rpm-4.4.2.3 (NSS-3) mQGiBEXopTIRBACZDBMOoFOakAjaxw1LXjeSvh/kmE35fU1rXfM7T0AV31NATCLF l5CQiNDA4oWreDThg2Bf6+LIVTsGQb1V+XXuLak4Em5yTYwMTVB//4/nMxQEbpl/ QB2XwlJ7EQ0vW+kiPDz/7pHJz1p1jADzd9sQQicMtzysS4qT2i5A23j0VwCg1PB/ lpYqo0ZhWTrevxKMa1n34FcD/REavj0hSLQFTaKNLHRotRTF8V0BajjSaTkUT4uk /RTaZ8Kr1mTosVtosqmdIAA2XHxi8ZLiVPPSezJjfElsSqOAxEKPL0djfpp2wrTm l/1iVnX+PZH5DRKCbjdCMLDJhYap7YUhcPsMGSeUKrwmBCBJUPc6DhjFvyhA9IMl 1T0+A/9SKTv94ToP/JYoCTHTgnG5MoVNafisfe0wojP2mWU4gRk8X4dNGKMj6lic vM6gne3hESyjcqZSmr7yfrtPGhI9MNauJ6Ob8cTR2T12Fmv9w03DD3MnBstR6vhP QcqZKhc5SJYYY7oVfxlSOfF4xfwcHQKoD5TOKwIAQ6T8jyFpKbQkRmVkb3JhIEVQ RUwgPGVwZWxAZmVkb3JhcHJvamVjdC5vcmc+iGQEExECACQFAkXopTICGwMFCRLM AwAGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQEZzANiF1IfabmQCgzvE60MnHSOBa ZXXF7uU2Vzu8EOkAoKg9h+j0NuNom6WUYZyJQt4zc5seuQINBEXopTYQCADapnR/ blrJ8FhlgNPl0X9S3JE/kygPbNXIqne4XBVYisVp0uzNCRUxNZq30MpY027JCs2J nL2fMpwvx33f0phU029vrIZKA3CmnnwVsjcWfMJOVPBmVN7m5bGU68F+PdRIcDsl PMOWRLkTBZOGolLgIbM4719fqA8etewILrX6uPvRDwywV7/sPCFpRcfNNBUY+Zx3 5bf4fnkaCKxgXgQS3AT+hGYhlzIqQVTkGNveHTnt4SSzgAqR9sSwQwqvEfVtYNeS w5rDguLG41HQm1Hojv59HNYjH6F/S1rClZi21bLgZbKpCFX76qPt8CTw+iQLBPPd yoOGHfzyp7nsfhUrAAMFB/9/H9Gpk822ZpBexQW4y3LGFo9ZSnmu+ueOZPU3SqDA DW1ovZdYzGuJTGGM9oMl6bL8eZrcUBBOFaWge5wZczIE3hx2exEOkDdvq+MUDVD1 axmN45q/7h1NYRp5GQL2ZsoV4g9U2gMdzHOFtZCER6PP9ErVlfJpgBUCdSL93V4H Sgpkk7znmTOklbCM6l/G/A6q4sCRqfzHwVSTiruyTBiU9lfROsAl8fjIq2OzWJ2T P9sadBe1llUYaow7txYSUxssW+89avct35gIyrBbof5M+CBXyAOUaSWmpM2eub24 0qbqiSr/Y6Om0t6vSzR8gRk7g+1H6IE0Tt1IJCvCAMimiE8EGBECAA8FAkXopTYC GwwFCRLMAwAACgkQEZzANiF1IfZQYgCgiZHCv4xb+sTHCn/otc1Ovvi/OgMAnRXY bbsLFWOfmzAnNIGvFRWy+YHi =MMNL-----END PGP PUBLIC KEY BLOCK-----
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
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:
gpgcheck=1
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
or
# 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
- dd command
- tar command
- Third party software
- Backup script
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