Considering the operating systems (OSs) in general, this article will particularly attempt to inquire about the issue of maintaining the Linux operating system environment secure.
Starting the computer: If we are to proceed with an issue concerning the computer security, physical security is a good starting point. The environmental and physical factors to be remedied first and foremost include the following ones: the temperature of the room you placed your computer in, the general condition of the electrical equipment, protection against any fire hazards, ensuring the privacy of the computer -that it is not being used by unauthorized users- etc.
Before the OS starts: Before the operating system runs, the system must initially load BIOS information. One of the information that BIOS keeps is start-up sequence info. To prevent the inexperienced users or the people you do not authorize to make changes on the BIOS features, you should use a BIOS password. Unless it is necessary for a particular purpose, the user must disable the start-up options from the diskette or the CD driver. If the user does not disable these features, this may pose a vulnerability and malicious intruders may commit hazardous changes on the OSs or storage devices using these features.
Loader settings: All the OSs are started through the help of a loader program. Linux operating systems basically use LILO or GRUB loaders. The section of the disc where the OS is located and the location of the kernel are basically taken as the parameters by the loaders. That they can be booted in different modes is a well known feature of Unix OSs and one can easily set the booting mode option the way s/he likes as a parameter within the loader. However, keeping in mind the security concerns, one should password-protect the loader to restrict access to the parameter settings. To do this, enter the following statement into the configuration file /etc/lilo.conf of Lilo loader;
and another statement should be entered into the configuration file /boot/grub/menu.lst of GRUB loader with the help of grub-md5-crypt program;
Installing Linux: It is especially important to maintain a security policy during the installation phase of the Linux operating system and one should be mindful of a number of such concerns:
All the Linux OSs can be installed on one single disc partition. However, especially with server systems, it is recommended that one should use different dics partitions for diversified purposes. For instance, all of these can be kept at different partitions; /var directory which is useful for keeping system logs, /tmp directory which is a common working ground, /home directory where user home directories are located, /usr directory where programs are loaded.
During or after the installation phase, the (mount) options for different disc partitions can be set in the (/etc/fstab) directory. For instance, one can define noexec for the disc partitions that does not contain executable files or ro for the disc partitions that are read-only; or one can define one of the nosuid, noguid options to prevent the usage of private rights. Likewise, it is also possible to use ro, noexec, nodsuid, nodev parameters in /etc/exports file for NFS mount partitions.
The level of security can be set in some Linux versions during the installation phase. However, if one sets high security level on the systems that will particularly be used as workstations, this may impose restrictions on some programs which may cause inconveniences. Hence, the security level should be fixed reasonably which fits your expectancies.
User Accounts and Passwords: On Linux OSs, as apart from the system users, there exist normal user accounts which were created in a later time. One should be alert about the following security concerns on user accounts:
Use shadowing as a method to store user accounts. Shadowing is supported by all the new versions. Also, use md5 encryption algorithm when encrypting.
Unless necessary, do not use root user account. Root user owns all the rights and privileges on a system. Should the necessity arise, log on to the system as an ordinary user, then pass on to root account with the su- command.
User passwords should be strong, well-chosen and effective. They should not be comprised of easily guessed words or numbers which are derived from ones personal information. It is strongly recommended that the password be a blend of upper and lowercase letters, numbers and special characters. However, make sure that you do not forget it. Moreover, the passwords must be changed periodically and one should not circulate a specific set of passwords, but use an original one (one not used beforehand).
The right to use su command should only be assigned to a particular user or user groups.
/etc/securetty file lists the consoles that the root user can mount to. Make sure the /etc/securetty file is arranged at the lowest level. Restrict remote connection wherever possible and applicable.
Terminate the user accounts that stand idle and are unnecessary (those accounts that the users no longer use).
Remote Connection: When you are connecting to the other Unix/Linux systems on Internet/intranet environment, you should use ssh, stelnet protocols that provide encrypted connections. Do establish connections as a normal user, not as a root user. I definitely recommend you to use alternative and more secure commands such as scp, sftp rather than using less secure rsh, rexec, .rhosts between the remote systems.
Keeping back-ups: Troubles with the systems may happen at any time; therefore, you should always keep in mind that backup becomes an integral and vital part of the solution in times of trouble. Once the initial installation of the OS is completed, a backup of the entire system, as well as the periodical backup of important data should be kept in reserve on a regular basis.
Updates: New vulnerabilities of nearly all of the software are found through the time and these new weaknesses pose great threats to the systems. For this very reason, you should obtain up-to-date versions of the software you have installed on your system. The updating procedures must be observed regularly and in accordance with the information derived from the security sites and other related sites.
System check: Since RedHat- and Debian-based Linux versions use package programs, one should periodically compare the database list (where packages are stored), installed files and security signatures with their original status through employing programs like rpm. Furthermore, one should check the security rights of primarily the important system files and then all the files and directories available. To achieve this, you can use the parametres of find command.
Some of the security permissions and the descriptions of the files are provided below:
|File Name ||Permission ||Description|
|/etc/passwd ||644 ||Database of user information |
|/etc/shadow ||600 ||Encrypted user account passwords |
|/etc/hosts.allow (deny) ||600 ||Access control files |
|/etc/lilo.conf ||600 ||LILO loader configuration file|
|/etc/securetty ||600 ||root login secure TTY list|
|/etc/rc.d/init.d ||750 ||System service files|
|/etc/init.d/* ||750 ||System service files|
|/etc/sysconfig/* ||751 ||System configuration files|
|/etc/syslog.conf ||640 ||System daemon configuration file|
|/var/log ||751 ||System log index|
|/var/log/messages ||644 ||System messages|
|/etc/ssh/ ||750 ||SSH service configuration files|
Kernel security: To improve security, some preventive measures should be taken at the kernel level on Linux OSs. To provide a firewall at the level of kernel during kernel configuration phase, one should add the use of CONFIG_FIREWALL, CONFIG_IP_FORWARD, CONFIG_SYN_COOKIES, CONFIG_IP_FIREWALL, CONFIG_FILTER, CONFIG_IP_MASQUERADING to the kernel. Whether they will be activated during the operation of the system depends on the fact that the content of such files as icmp_echo_ignore_all, icmp_echo_ignore_broadcasts, ip_forward, tcp_syncookies, which are located within /proc/sys/net/ipv4 directory, are either 1 or 0. In RedHat-based new systems, these processes can be carried out from within the /etc/sysctl.conf configuration file.
Before exhausting my words in the first part of this article, I wish to extend my gratitude to my colleagues Ahmet ÖZTÜRK and Mustafa ATAKAN; their documents helped me a great deal with this piece of work. And I am also grateful to the Linux-phile authors that created the documents at http://www.LinuxSecurity.com and http://scrye.com/~kevin/lsh.
Hope to see you in the following article...
Selçuk Han AYDIN