security checklist for a linux system administrator

Security of any operating system is one of the primary responsibilities of any Linux system administrator. I must say that, its also one of the toughest tasks, for a Linux system administrator. You cannot be very certain, that the machine that's under you is a secure machine(there exists no machine on the internet, which can be called as completely secure).

Oh yeah..You can make your machine, the most secure machine in the world, just by pulling out the Network Interface Cable(Joking...).

Although it was just a joke, if you think a bit deeper you will come to know, that its quite true. You cant make a system completely secure. Because just imagine the number security patches, a software vendor roles out each and everyday(Thanks to open source community, as they are doing a great job in this area).

In this post, i will point out some of the security checklist for Linux servers, that's documented and compiled by me from time to time. I know the fact that, not all of them can be implemented in a production infrastructure, because of the infrastructure specific restrictions that a system administrator needs to follow.

Note: As told before, the security checklist pointed out here, will not make your system a secure one. But will surely make your system, less prone to compromise, and can reduce the overall chance of risk of the machine.

1. Keep the system Updated with Latest Security Patches

Most system administrators are already aware of this first and the most important thing to do for their system. And there really is a widespread belief that, windows machine's should always be kept updated with patches, but Linux is much secure even without the patches and updates, which is totally wrong.

If you see the reports, you will come to know that out of all the compromises that took place, 80 percent of them were just because of old vulnerable version of software packages or kernel.

CVE(Common Vulnerability Exposures ) vulnerability details, always point towards a specific version of the package and the vendor of the package most of the times already roll out their patches for the same.

Use YUM or ap-get package manager, to keep the packages updated.

Also patch your kernel in an organised manner from time to time with latest patches available.

2. Keep Yourself updated with latest vulnerabilities through mailing lists, forums etc.

Many open source mailing lists (product specific as well as Linux general), offer's latest vulnerabilities with detailed information and the relevant fixes required.

Also you should always keep your team updated about a specific product by purchasing the product vendor's mailing list.

Examples: http://www.securityfocus.com/

http://www.sans.org/

3.Disable and stop unwanted services on the server.

Administrators should make note of all the services running on all their servers, and periodically also consult with respective developers of the team to ensure, only services that are required is running.

No unwanted service should be running there on the server.

Making a list of boot up services from chkconfig and ntsysv can provide you with a checklist of services that will come up at boot time.

Disabling unwanted services on the server will also improve the server performance wise.

4.Use SUDO to limit ROOT Access

Restricting certain users to some critical commands, using sudo is advisable. You can easily achieve this by modifying /etc/sudoers files.

sudo can be configured on a command by command basis, sudoers file can be used to control the commands with restrictions.

5. SSH security settings.

Almost all Linux machine's use SSH service for remote login. Although ssh is pretty secure by itself, ssh does not have the ability to protect the server against human mistakes

Some check's must always be done regarding the SSH protocol.

• Disable root login through ssh protocol, by modifying the sshd_config file and setting "PermitRootLogin no".
• Make sure that ssh protocol version 2 is used instead of 1(latest version of the packages use version 2 by default, so no need to modify)
• disable the normal password based authentication and only allow public key based authentication. And deploy the public keys of the desired users, on their respective home directories on the server.

this will help to securely allow users whose public key is deployed on the server to login through ssh.

This can be done by modifying the sshd_config file on the server as below.

ChallengeResponseAuthentication no

PasswordAuthentication no

PubkeyAuthentication yes

• Configure ssh on some other port other than the standard port.

6. Check the integrity of critical files using checksum

checking integrity of system critical files at regular intervals will mitigate the unwanted modification of files by somebody. You can do this with the help of several tools out there. Some are mentioned below.

TripWire: tripwire is an effective way to measure the changes in critical files by checking the hashes of the files with the hashes previously taken.

its an understood that inorder to affect the system severely the attacker needs to some or the other way modify files on the system. You can detect that with an another tool, which is quite similar to the tripwire tool. Its called Aide(Advanced Intrusion Detection Environment). You can download aide from sourceforge. AIDE

7.Tunnel all of your X-Window Sessions through SSH.

this will secure the graphical communications which is normally unencrypted. To do this, you need to have the following entry in your sshd_config file.

ForwardX11 yes

Now you can connect the server using ssh -X -c "server IP"

-c option is a nice way to compress the traffic. Its a good option is you have low bandwidth

8.Use SeLinux If required.

This is also a good method of securing the system. A howto for selinux is beyond the scope of this article. However you can find a lot of resources out there on the internet for configuring selinux. Although Selinux is a good security option, at times it produces undesired results, if not configured properly.

10.Only create required no of users

Make a list of all user accounts you have on the server, and delete all unwanted users on the system.

11.Maintain a good firewall policy

Writing down the IP/subnets that you want to allow access to the machine. And only allow them. Making a firewall script for both inbound and outbound connections and enabling that script for the firewall rules will be a good idea.

On most of the linux firewalls the order in which the rules are applied matters. So as mentioned managing all rules for the firewall with a firewall script, and checking periodically the set of rules applied by using a nagios check or a cron is a good idea.

There are a lot number of firewall's available for linux out there, some of them are mentioned below.

1. Iptables
2. ipcop
3. checkpoint
4. shorewall
5. pfsense

the important thing that matters is how you configure them, because almost all of them are best at what they do. According to me, Iptables which is the default firewall for most of the distributions out of the box will be a good point to start with. You can do alomost everything, that you require with this firewall.

12.Configure SSL/TLS if you are using FTP.

FTP is also considered to be an insecure protocol. So it is advisable that you do the following things while working with FTP service.

1. Use latest version of FTP package
2. Force only required users to login through ftp
3. Allow only TLS with FTP access to the server.
4. If possible keep the user in chroot jail

13.check file permissions accross filesystems.

As you already know that file permissions play an important role in securing a Linux server. So you need to periodically make sure all your important files are given permissions correctly.

Things to check regarding file permissions.

1. Check and confirm, if the UMASK value is as required periodically
2. periodically search for fiile's with absurd permissions set on them. Like world writeable files etc.

You can search them using "find / -perm -o=w ! -type l -ls"

14.Use tools like adeos for potential file state

as mentioned in the previous step. Scanning the whole system with tools like adeos for files with dangerous permissions is a good method to follow.

You can get adeos from here.

http://linux.wku.edu/~lamonml/software/adeos/adeos-1.0.tar.gz

It will search for files which are world writable,SUID etc.

15.Ensure sticky bit on /tmp Directory

Stickt bits allow's only root or owner of the file to rename or delete.

/tmp is an important directory where applications create and deletes files. Assigning sticky bit to this directory will prevent users from renaming or deleting other user's files.

16.check and lock users with blank passwords.

Some users do keep blank passwords for simplicity but for others who wants control over the system, look at it as an open door to enter.

Simply go and have a look at your /etc/shadow file to confirm that none of your user is using blank passwords.

The better option is to disable the use of blank passwords in the system by modifying the PAM configuration files. So in redhat/fedora you need to edit the file /etc/pam.d/system-auth and remove the word "nullok" from the line auth sufficient "/lib/security/pam_unix.so likeauth nullok"

17. Bootloader and BIOS security

Normally people do ignore this step as they always think attackers and intruders are always remote people tying to gain access.

Access to bios means access to do anything...Because you can easily boot the system from any disk or other media, if you have access to BIOS.  So keep a secure password for BIOS.

Also Protect your boot loader (GRUB) with a secure password, so that no toggling of options in boot loader is possible without password..

18.Give special attention to portmap related services

If you are running any portmap related services on the server. Then in that case you need to pay special attention in configuring access to port 111.

A nice set of configuration for portmapper in both tcpwrappers and iptables are advisable.

Port mapper does have a lot of security vulnerabilities, and if possible avoid using that on a production server with public interface.

19.Deploy your NFS shares with Kerberos Authentication.

Only use NFS version 4 for all the shares(NFSv2 and NFSv3 pass data over the network in an insecure manner). Using kerberos authentication for NFS shares is very much required, as this will encrypt all data transfer, and also secure the access to NFS.

Do not use no_root_squash option, as this will enable remote users to modify other's files on the share, and can easily affect others with their change.

20.Enable remote Logging

Most of the time intruders and attackers, after gaining access to the system, deletes the system logs, in order to delete their trace.

But if you have remote logging enabled, the attacker now needs to compromise multiple system's to delete logs(which sometimes is not quite easy).

You can achieve remote logging with multiple tools like the below.

Syslog

rsyslog

syslogng

21. Disable root Logins by editing /etc/securetty

You can edit the file /etc/securetty, to modify the terminal tty's where root can login to.

Note: If you dont have that file, then root can login from any where(so its not advisable)

22.Keep A good Pasword Policy

Understand the usage of chage command and use it effectively to modify password setting per user. By default the below command will show you the password information of a particular user.

"chage --list <username>"

Modify the password expiry per user with the help of chage command.

chage -M <no of days to expire> <username>

Modify the /etc/pam.d/system-auth file to suite your needs. Also check and confirm /etc/login.defs(this sets the default settings when a user is created) is as required.

We will be adding,editing,modifying this post from time to time to include more things..