Local security [Peń] [Hatb] is basic for protecting the system [Deb][Hatc], since normally following a first attempt from the network, it is the second protection barrier before an attack that manages to obtain partial control of the machine. Also, most attacks end up using the system's internal resources.
Example 9-10. Note
Various attacks, although they may come from the outside, are designed to obtain local access.
With regards to local security, problems can already start with booting with the physical access that an intruder could gain to a machine.
One of the problems starts when the system boots. If the system can be booted from disk or CD, an attacker could access the data of a GNU/Linux (or also Windows) partition just by mounting the file system and placing themselves as root users without needing to have any password. In this case, we need to protect the system's boot from the BIOS, for example, by protecting the access with a password, so that booting from a CD is not allowed (for example through a Live CD or diskette). It is also reasonable to update the BIOS, since it can also have security failures. Plus, we need to be careful because many BIOS manufacturers offer additional known passwords (a sort of backdoor), meaning that we cannot depend exclusively on these measures.
The following step is to protect the boot loader, whether lilo or grub, so that the attacker is not able to modify the start up options of the kernel or directly modify the boot (in the case of grub). Either of the two can also be protected using passwords.
In grub, the file /sbin/grub-md5-crypt asks for the password and generates an associated md5 sum. Then, the obtained value is entered into /boot/grub/grub.conf. Under the timeout line, we introduce:
password --md5 sum-md5-calculated
For lilo we place, either a global password with:
password = <selected password>
or one in the partition that we want:
image = /boot/vmlinuz-version password = <selected password> restricted
In this case restricted also indicates that we will not be able to change the parameters passed onto the kernel from the command line. We need to take care to set the file /etc/lilo.conf as protected so that only the root user has read/write privileges (chmod 600).
Another issue related to booting is the possibility that someone with access to the keyboard could reinitiate the system because if they press CTRL+ALT+DEL, (in some distributions it is now disabled by default) they will cause the machine to shutdown. This behaviour is defined in /etc/inittab, with a line like:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
If commented, this possibility of reinitiating will become deactivated. Or on the other hand, we can create a file /etc/shutdown.allow, which allows certain users to reinitiate.
The typical passwords of the initial UNIX systems (and of the first versions of GNU/Linux) were encrypted using DES algorithms (but with small keys and a system call that was responsible for encrypting and decrypting, specifically crypt, see the man).
Normally, they were in the file /etc/passwd, in the second field, for example:
But the problem lies in the fact that this file is legible by any user, meaning that an attacker could obtain the file and use an attack of brute force, until decrypting the passwords that the file contained, or use an attack of brute force with dictionaries.
The first step is to use the new files /etc/shadow, where the passwords are now saved. This file is only legible by the root user and by nobody else. In this case, in /etc/passwd an asterisk (*) appears where previously the encrypted password was. By default, current GNU/Linux distributions use passwords of the shadow type unless told not to use them.
A second step is to change the system of encrypting the passwords for one that is more complex and difficult to break. Now, both Fedora and Debian offer passwords by md5; we are usually allowed to choose the system at the time of the installation. We need to take care with md5 passwords, because if we use NIS, we could have a problem; otherwise, all clients and servers will use md5 for their passwords. Passwords can be recognised in /etc/shadow because they have a "$1$" prefix.
Other possible actions include obliging users to change password frequently (the change command can be useful), imposing restrictions on the size and content of the passwords, and validating them with dictionaries of common terms .
Regarding the tools, it is interesting to have a password cracker (i.e. a program for obtaining passwords), in order to check the real security situation with our users' accounts, and thus forcing change in the ones we detect to be insecure. Two of the ones most commonly used by administrators are John the Ripper and crack. They can also work with a dictionary, so it will be interesting to have some ASCII dictionary in English (can be found on the web). Another tool is "Slurpie", which can test several machines at the same time.
An issue that we always need to take into account is to run these tests on our systems. We must not forget that the administrators of other systems (or the access or ISP provider) will have intrusion detection systems enabled and that we could be denounced for attempts at intrusion, either before the competent authorities (computer crime units) or before our ISP so that they close down our access. We need to be very careful with the use of security tools, which are always on the edge of security or intrusion.
Another important problem affects some special permissions used on files or script.
The sticky bit is used especially on temporary directories, where we want in some (sometimes unrelated) groups for any user to be able to write, but only the owner of the directory to be able to delete, or the owner of the file that is within the directory. A classical example of this bit is the temporary directory /tmp. We need to make sure that there are no directories of this type, since they can allow anyone to write on them, so that we must check that there are no more than those that are purely necessary as temporaries. The bit is placed using (chmod +t dir), and can be removed with -t. In an ls command it will appear as a directory with drwxrwxrwt permissions (take note of the last t).
The bit setuid allows a user to execute (whether an executable or a shell script) with another user's permissions. In some cases this can be useful, but it is also potentially dangerous. This is the case, for example, of programs with setuid as root: a user, although without root permissions, can execute a program with setuid that could have internal root user permissions. This is very dangerous in the case of scripts, since they could be edited and modified to do anything. Therefore, we need to keep these programs controlled, and if setuid is not necessary, we need to eliminate it. The bit is placed using chmod +s, whether applying it to the owner (then it is called suid) or to the group (then it is called bit sgid); it can be removed with -s. In the case of viewing with ls command, the file will appear with -rwSrw-rw (take note of the S), if it is only suid, in sgid the S would appear after the second w.
In the case of using chmod with octal notation, four numbers are used, where the last three are the classical rwxrwxrwx permissions (remember that we have to add in the number 4 for r, 2 w, and 1 for x), and the first has a value for every special permission that we want (which are added): 4 (for suid), 2 (sgid), and 1 (for sticky).
The system has several special configuration files that make it possible to enable the access of a number of hosts to some network services, but whose errors could later allow local security to come under attack. We can find:
user .rhosts: allows a user to specify a number of machines (and users) that can use their account through "r" commands (rsh, rcp...) without having to enter the account's password. This is potentially dangerous, since a poor user configuration could allow entry to unwanted users or could allow an attacker (with access to the user account) to change the addresses in .rhosts in order to enter comfortably without any type of control. Normally, we should not allow these files to be created and we should even delete them completely and disable the "r" commands.
/etc/hosts.equiv: this is exactly the same as with the .rhosts files but at the level of the machine, specifying what services, what users and what groups can access "r" commands without the need for password control. Also, an error such as putting a "+" on a line of that file allows access to "any" machine. Nowadays, this file does not usually exist either and there is always the alternative of the ssh service to "r".
/etc/hosts.lpd: in the LPD printing system it was used to put the machines that could access the printing system. We need to be very careful, if we are not serving, to completely disable access to the system, and if we are serving, to restrict to a maximum the machines that really make use of it. Or try to change to a CUPS or LPRng system, which has far more control over the services. The LPD system is a common target of worm-type or buffer overflow attacks and several important bugs are documented. We need to be on the lookout if we use this system and the hosts.lpd file.
PAM modules [Peń][Mor03] are a method that allows the administrator to control how the user authentication process is performed for certain applications. The applications need to have been created and linked to the PAM libraries. Basically, PAM modules are a set of shared libraries that can be incorporated into applications as a method for controlling their user authentication. Also, the authentication method can be changed (by means of the PAM modules configuration), without having to change the application.
The PAM modules (libraries) tend to be in the /lib/security directory (in the form of dynamically loadable file objects). And the PAM configuration is present in the /etc/pam.d directory, where a PAM configuration file appears for every application that is using PAM modules. We find the authentication configuration of applications and services such as ssh, graphic login of X Window System, like xdm, gdm, kdm, xscreensaver... or, for example, the system login (entrance with username and password). Old PAM versions used a file (typically in /etc/pam.conf), where the PAM configuration was read if the /etc/pam.d directory did not exist.
Example 9-11. Web site
For further information, see "The Linux-PAM System Administrators' Guide": http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html
The typical line of these files (in /etc/pam.d) would have this format (if using /etc/pam.conf we would have to add the service to which it belongs as a first field):
module-type control-flag module-path arguments
a) module type: if it is a module that requires user authentication (auth), or has restricted access (account); things we need to do when the user enters or leaves (session); we the user has to update the password.
b) control flags: they specify whether it is required, a requisite, whether it is sufficient or whether it is optional. This is a syntax. There is another more up to date one that works in pairs of value and action.
c) the module path.
d) arguments passed onto the module (they depend on each module).
Because some services need several common configuration lines, it is possible to have operations for including common definitions for other services, we just have to add a line with:
A small example of the use of PAM modules (in a Debian distribution), could be their use in the login process (we have also listed the lines included from other services):
This specifies the PAM modules required to control user authentication during login. One of the modules, pam_unix.so, is the one that really verifies the user's password (looking at files password, shadow...).
Others control the session to see when the latest entry was or save when the user enters and leaves (for the lastlog command), there is also a module responsible for verifying whether the user has mail to read (authentication is also required) and another that controls that the password changes (if the user is obliged to do so with the first login) and that it has 4 to 8 letters, and that md5 can be used for encryption.
In this example we could improve user security: the auth and the passwords allow passwords of length nil: this is the module's nullok argument. This would allow having users with empty passwords (potential source of attacks). If we remove this argument, we no longer allow empty passwords for the login process. The same can be done in the password configuration file (in this case, the passwords change command), which also presents nullok. Another possible action is to increase the maximum size of the passwords in both files, for example, with max = 16.
Another problem can be the alteration of basic system commands or configurations, through the introduction of Trojans, or backdoors, by merely introducing software that replaces or slightly modifies the behaviour of the system's software.
A typical case is the possibility of forcing the root to execute false system commands; for example, if the root were to include the "." in its variable PATH, this would allow commands to be executed from its current directory, which would enable the placing of files that replaced system commands and that would be executed as a priority before the system's commands. The same process can be done with a user, although because a user's permissions are more limited, it may not affect the system as much, rather the security of the user itself. Another typical case is the one of false login screens, replacing the typical login process, password, with a false program that would store the entered passwords.
In the case of these alterations, it will be vital to enforce a policy of auditing changes, whether through a calculation of signatures or sums (gpg or md5), or using some type of control software such as Tripwire or AIDE. For Trojans we can have different types of detections or use tools such as chkrootkit, if these come from the installation of some known rootkit.