OS and Security:Attack Prevention Methods.

Attack Prevention Methods

Attack prevention may be attempted at several levels. These include individual screening and physical controls in operations. Individual screening would require that users are screened to authenticate themselves and be responsible individuals. Physical controls involve use of physical access control. Finally, there are methods that may require configuration controls. We shall begin the discussion on the basic attack prevention with the defenses that are built in Unix. These measures are directed at user authentication and file access control.

User Authentication

First let us consider how a legitimate user establishes his identity to the system to access permitted resources. This is achieved typically by username/password pair. When the system finishes booting, the user is prompted for a username and then a password in succession. The password typed is not echoed to the screen for obvious reasons. Once the password is verified the user is given an interactive shell from where he can start issuing commands to the system. Clearly, choosing a clever password is important. Too simple a password would be an easy give away and too complex would be hard to remember.

So how can we choose a nice password?

Choosing a good password: A malicious user usually aims at obtaining a complete control over the system. For this he must acquire the superuser or root status. Usually, he attacks vulnerable points like using badly installed software, bugs in some system software or human errors. There are several ways to hack a computer, but most ways require extensive knowledge. A relatively easier way is to log in as a normal user and search the system for bugs to become superuser. To do this, the attacker will have to have a valid user code and password combination to start with. Therefore, it is of utmost importance that all users on a system choose a password which is quite difficult to guess. The security of each individual user is closely related to the security of the whole system. Users often have no idea how a multi-user system works and do not realize that by choosing an easy to remember password, they indirectly make it possible for an attacker to manipulate the entire system. It is essential to educate the users well to avoid lackadaisical attitudes. For instance, if some one uses a certain facility for printing or reading some mails only, he may think that security is unimportant. The problem arises when someone assumes his identity. Therefore, the users should feel involved with the security of the system. It also means that it is important to notify the users of the security guidelines. Or at least make them understand why good passwords are essential.

Picking good passwords: We will look at some methods for choosing good passwords. A typical good password may consist up to eight characters. This means passwords like`members only' and `members and guests' may be mutually inter-changeable. A password should be hard to guess but easy to remember. If a password is not easy to remember then users will be tempted to write down their password on yellow stickers which makes it futile. So, it is recommended that a password should not only have upper or lowercase alphabets, but also has a few non-alphanumeric characters in it. The non-alphanumeric characters may be like (%,,*, =) etc. The use of control characters is possible, but not all control characters can be used, as that can create problems with some networking protocols. We next describe a few simple methods to generate good passwords.

• Concatenate two words that together consist of seven characters and that have no connection to each other. Concatenate them with a punctuation mark in the middle and convert some characters to uppercase like in 'abLe+pIG'.
• Use the first characters of the words of not too common a sentence. From the sentence “My pet writers are Wodehouse and Ustinov", as an example, we can create password “MpwaW+U!”. Note in this case we have an eight-character password with uppercase characters as well as punctuation marks.
• Alternatively, pick a consonant and one or two vowels resulting in a pronounceable (and therefore easy to remember) word like 'koDuPaNi'.

This username/password information is kept traditionally in the /etc/passwd file, commonly referred to simply as the password file. A typical entry in the password file is shown below:

user:x:504:504::/home/user:/bin/bash

There are nine colon separated fields in the above line. They respectively refer to the user name, password x (explained later), UID, GID, the GECOS field 1, home directory and users' default shell. In the early implementations of the Unix, the password information was kept in the passwd file in plain text. The passwd file has to be world readable as many programs require to authenticate themselves against this file. As the expected trust level enhanced, it became imperative to encrypt the password as well. So, the password field is stored in an encrypted format. Initially, the crypt function was used extensively to do this. As the speed of the machines increased the encrypted passwords were rendered useless by the brute force techniques. All a potential attacker needed to do is to get the passwd file and then do a dictionary match of the encrypted password. This has led to another innovation in the form of the shadow suite of programs. In modern systems compatible with the shadow suite the password information is now kept in the/etc/shadow file and the password field in the passwd file is filled with an x (as indicated above). The actual encrypted password is kept in the /etc/shadow file in the following format :

user:$1$UaV6PunD$vpZUg1REKpHrtJrVi12HP.:11781:0:99999:7:::

The second field here is the password in an md5 hash 2. The other fields relate to special features which the shadow suite offers. It offers facilities like aging of the passwords, enforcing the length of the passwords etc. The largest downside to using the shadow passwords is the difficulty of modifying all of the programs that require passwords from the appropriate file to use /etc/shadow instead. Implementing other new security mechanisms presents the same difficulty. It would be ideal if all of these programs used a common framework for authentication and other security related measures, such as checking for weak passwords and printing the message of the day.

Pluggable authentication modules Red Hat and Debian Linux distributions ship with “Pluggable Authentication Modules" (PAM for short) and PAM-aware applications. PAM offers a flexible framework which may be customized as well. The basic PAM- based security model is shown in Figure 9.1. Essentially, the figure shows that one may have multiple levels of authentication, each invoked by a separate library module. PAM aware applications use these library modules to authenticate. Using PAM modules, the administrator can control exactly how authentication may proceed upon login. Such authentications go beyond the traditional /etc/passwd file checks. For instance, a certain application may require the pass-word as well as a form of bio-metric authentication. The basic strategy is to incorporate a file (usually called /etc/pam.d/login) which initiates a series of authentication checks for every login attempt. This file ensures that a certain authentication check sequence is observed. Technically, the library modules may be selectable. These selections may depend upon the severity of the authentication required. The administrator can customize the needed choices in the script. At the next level, we may even have an object based security model in which every object access would require authentication for access, as well as methods invocation.

For now we shall examine some typical security policies and how Unix translates security policies in terms of access control mechanisms.

Security Policy and Access Control

Most access control mechanisms emanate from a stated security policy. It is important to learn to design a security policy and offer suitable access mechanisms that can support security policies. Security policy models have evolved from many real-life operating scenarios. For instance, if we were to follow a regime of defense forces, we may resort to a hierarchy based policy. In such a policy, the access to resources shall be determined by associating ranks with users. This requires a security-related labeling on information to permit access. The access is regulated by examining the rank of the user in relation to the security label of the information being sought. For a more detailed discussion the reader may refer where there is a discussion on how to specify security policies as well.

If we were to model the security policies based on commercial and business practices or the financial services model, then data integrity would take a very high precedence. This like, the accounts and audit practices, preserves the integrity of data at all times. In practice, however, we may have to let the access be governed by ownership (who own the information) and role definitions of the users. For instance, in an organization, an individual user may own some information but some critical information may be owned by the institution. Also, its integrity should be impregnable. And yet the role of a system manager may require that he has access privileges which may allow him a free reign in running the system smoothly.

Almost all OSs provide for creating system logs of usage. These logs are extremely useful in the design of Intrusion Detection Systems (IDS). The idea is quite simple. All usages of resources are tracked by the OS and recorded. On analysis of the recorded logs it is possible to determine if there has been any misuse. The IDS helps to detect if a breach has occurred. Often this is after the event has taken place. To that extent the IDS provides a lot of input in designing security tools. With IDS in place one can trace how the attack happened. One can prevent attacks from happening in future. A full study and implementation of IDS is beyond the scope of this book. We would refer the reader to Amoroso's recent book on the subject.

Defenses in Unix: Defenses in Unix are built around the access control 3. Unix's access control is implemented through its file system. Each file (or directory) has a number of attributes, including a file name, permission bits, a UID and a GID. The UID of a file specifies its owner. In Chapter 2, we had explained that the permission bits are used to specify permissions to read (r), write (w), and execute (x). These permissions are associated with every file of every user, for the members of the user's group, and for all other users of that system. For instance, the permission string rwxr-x--x specifies that the owner may read, write and execute, the user's group members are allowed to read and execute it, while all the other users of the system may be permitted to only execute this file. A dash (`-') in the permission set indicates that the access rights are not permitted. Furthermore, each process in Unix has an effective and a real UID as well as an effective and a real GID associated with it. The real UID (and GID) are the primary identifications that Unix systems continually maintain based on the identifications assigned at the time of accounts creation. However, access rights and privileges evolve over time. The effective identifications precisely reflect that. A process's effective identification indicates the access privileges. Whenever a process attempts to access a file, the kernel will use the process's effective UID and GID to compare them with the UID and the GID associated with the file to decide whether or not to grant the request.

As we stated earlier, Unix logs the systems' usage. Unix kernel, and system processes, store pertinent information in the log files. The logs may be kept either locally, or centrally, on an network server. Sometimes logs are prepared for a fixed duration of time (like for 1 to 30 days) or archived. The logs may be analyzed on-line or off-line on a secured isolated system. An analysis on a secured isolated system has the advantage that it cannot be modified by an attacker (to erase his trace). Also, the analysis can be very detailed as this is the only purpose of such a system.

With the security concerns coming into focus, security standards have emerged. Usually the security standards recommend achieving minimal assured levels of security through some form of configuration management. Most OSs, Unix included, permit a degree of flexibility in operations by appropriately configuring the system resources. In addition, modern Unix systems support a fairly comprehensive type of auditing known as C2 audit. This is so named because it fulfils the audit requirements for the TCSEC C2 security level.

Networking concerns: Realistically speaking almost all machines are networked. In any case every machine has built-in network (NW) support. The default NW support is TCP/IP or its variant. This is very assuring from the point of compatibility. The range of NW services support includes remote terminal access and remote command execution using rsh, rlogin commands and remote file transfer using ftp command. The remote service soliciting commands are collectively known as the r commands. The NW File System (NFS) is designed to offer transparency to determine the location of the file. This is done by supporting mounting of a remote file as if it was on the local file system. In fact, NFS technically supports multiple hosts to share files over a local area network (LAN). The Network Information System (NIS), formally known as the Sun Yellow Pages, enables hosts to share systems and NW databases. The NW databases contain data concerning user account information, group membership, mail aliases etc. The NFS facilitates centralized administration of the file system. Basically, the r commands are not secure. There are many reasons why these are insecure operations. We delineate some of these below.

• The primary one being that Unix was designed to facilitate usage with a view to cooperating in flexible ways. The initial design did not visualize a climate of suspicion. So, they assumed that all hosts in the network are trusted to play by the rules, e.g. any request arising out of a TCP/IP port below 1024 is considered to be trusted.
• These commands require a simple address-based authentication, i.e. the source address of a request is used to decide whether or not to grant an access or offer a service.
• They send clear text passwords over the network.

Now a days there are other better alternatives to the r commands, namely ssh, slogin and scp, respectively, which use strong ssl public key infrastructure to encrypt their traffic. Before an NFS client can access files on a file system exported by an NFS server, it needs to mount the file system. If a mount operation succeeds, the server will respond with a file handle, which is later used in all accesses to that file system in order to verify that the request is coming from a legitimate client. Only clients that are trusted by the server are allowed to mount a file system. The primary problem with NFS is the weak authentication of the mount request. Usually the authentication is based on IP address of the client machine. Note that it is not difficult to fake an IP address!!. So, one may configure NIS to operate with an added security protocol as described below.

• Ensure minimally traditional Unix authentication based on machine identification and UID.
• Augment data encryption standard (DES) authentication .

The DES authentication provides quite strong security. The authentication based on machine identification or UID is used by default while using NFS. Yet another authentication method based on Kerberos is also supported by NIS. The servers as well as the clients are sensitive to attacks, but some are of the opinion that the real security problem with NIS lies in the client side. It is easy for an intruder to fake a reply from the NIS server. There are more secure replacements for the NIS as well (like LDAP), and other directory services.

Unix security mechanisms rely heavily on its access control mechanisms. We shall study the access control in more detail a little later. However, before we do that within the broad framework of network concerns we shall briefly indicate what roles the regulatory agencies play. This is because NWs are seen as a basic infrastructure.

Internet security concerns and role of security agencies: In USA, a federally funded Computer Emergency Response Team (CERT) continuously monitors the types of attacks that happen. On its site it offers a lot of advisory information. It even helps organizations whose systems may be under attack. Also, there is critical infrastructure protection board within whose mandate it is to protect internet from attack. The National Security Agency (NSA) acts as a watchdog body and influences such decisions as to what level of security products may be shipped out of USA. The NSA is also responsible to recommend acceptable security protocols and standards in USA. NSA is the major security research agency in USA. For instance, it was NSA that made the recommendation on product export restriction beyond a certain level of DES security (in terms of number of bits).

In India too, we have a board that regulates IT infrastructure security. For instance, it has identified the nature of Public Key Infrastructure. Also, it has identified organizations that may offer security-related certification services. These services assure of authentication and support non-repudiation in financial and legal transactions. It has set standards for acceptable kind of digital signatures.

For now let us return to the main focus of this section which is on access control. We begin with the perspective of file permissions.

File permissions: The file permissions model presents some practical difficulties. This is because Unix generally operates with none or all for group permissions. Now consider the following scenario:

There are three users with usernames Bhatt, Kulish, and Srimati and they belong to the group users. Is there anyway for Bhatt to give access to a file that he owns to Kulish alone. Unfortunately it is not possible unless Bhatt and Kulish belong to an identifiable group (and only these two must be members of that group) of which Srimati is not a member. To allow users to create their own groups and share files, there are programs like sudo which the administrator can use to give limited superuser privileges to ordinary users. But it is cumbersome to say the least. There is another option in the BSD family of Unix versions, where a user must belong to the Wheel group to run programs like sudo or su. This is where the Access Control Lists (ACLs) and the extended attributes come into picture. Since access control is a major means of securing in Unix we next discuss that. More on access control in Unix: Note that in Unix all information is finally in the form of a file. So everything in Unix is a file. All the devices are files (one notable exception being the network devices and that too for historical reasons). All data is kept in the form of files. The configuration for the servers running on the system is kept in files. Also, the authentication information itself is stored as files. So, the file system's security is the

most important aspect in Unix security model. Unix provides access control of the resources using the two mechanisms:

(a) The file permissions, uid, gid.

(b) User-name and password authentication.

The file access permissions determine whether a user has access permissions to seek requested services. Username and password authentication is required to ensure that the user is who he claims to be. Now consider the following rwx permissions for user, group and others.

$ ls -l

drwxrwxr-x 3 user group 4096 Apr 12 08:03 directory

-rw-rw-r-- 1 user group 159 Apr 20 07:59 sample2e.aux

The first line above shows the file permissions associated with the file identified as a directory. It has read, write and execute permission for the user and his group and read and execute for others. The first letter `d' shows that it is a directory which is a file containing information about other files. In the second line the first character is empty which indicates that it is a regular file. Occasionally, one gets to see two other characters in that field. These are `s' and `l', where `s' indicates a socket and `l' indicates that the file is a link. There are two kinds of links in Unix. The hard link and the soft link (also known as symbolic links). A hard link is just an entry in the directory pointing to the same file on the hard disk. On the other hand, the symbolic link is another separate file pointing to the original file. The practical difference is that a hard link has to be on the same device as the original but the symbolic link can be on a different device. Also, if we remove a file, the hard link for the file will also be removed. In the case of a symbolic link, it will still exist pointing no where.

In Unix every legitimate user is given a user account which is associated with a user id (Unix only knows and understands user ids here to in referred as UIDs).The mapping of the users is maintained in the file /etc/passwd. The UID 0 is reserved. This user id is a special superuser id and is assigned to the user ROOT. The SU ROOT has unlimited privileges on the system. Only SU ROOT can create new user accounts on a system. All other UIDs and GIDs are basically equal.

A user may belong to one or more groups up to 16. A user may be enjoined to other groups or leave some groups as long as the number remains below the number permitted

by the system. At anytime the user must belong to at least one group. Different flavors of Unix follow different conventions. Linux follows the convention of creating one group with the same name as the username whenever a new user id is created. BSDs follow the convention of having all the ordinary users belong to a group called users.

It is to be noted that the permissions are matched from left to right. As a consequence, the following may happen. Suppose a user owns a file and he does not have some permission. However, suppose the group (of which he also is a member) has the permission. In this situation because of the left to right matching, he still cannot have permission to operate on the file. This is more of a quirk as the user can always change the permissions whichever way he desires if he owns the file. The user of the system must be able to perform certain security critical functions on the system normally exclusive to the system administrator, without having access to the same security permissions. One way of giving users' a controlled access to a limited set of system privileges is for the system to allow the execution of a specified process by an ordinary user, with the same permissions as another user, i.e. system privileges. This specified process can then perform application level checks to insure that the process does not perform actions that the user was not intended to be able to perform. This of course places stringent requirements on the process in terms of correctness of execution, lest the user be able to circumvent the security checks, and perform arbitrary actions, with system privileges.

Two separate but similar mechanisms handle impersonation in Unix, the so called set UID, (SUID), and set-GID (SGID) mechanisms. Every executable file on a file system so configured, can be marked for SUID/SGID execution. Such a file is executed with the permissions of the owner/group of the file, instead of the current user. Typically, certain services that require superuser privileges are wrapped in a SUID superuser program, and the users of the system are given permission to execute this program. If the program can be subverted into performing some action that it was not originally intended to perform, serious breaches of security can result.

The above system works well in a surprising number of situations. But we will illustrate a few situations where it fails to protect or even facilitates the attacker. Most systems today also support some form of access control list (ACL) based schemes

Access control lists: On Unix systems, file permissions define the file mode as well. The file mode contains nine bits that determine access permissions to the file plus three special bits. This mechanism allows to define access permissions for three classes of users: the file owner, the owning group, and the rest of the world. These permission bits are modified using the chmod utility. The main advantage of this mechanism is its simplicity. With a couple of bits, many permission scenarios can be modeled. However, there often is a need to specify relatively fine-grained access permissions.

Access Control Lists (ACLs) support more fine grained permissions. Arbitrary users and groups can be granted or denied access in addition to the three traditional classes of users. The three classes of users can be regarded as three entries of an Access Control List. Additional entries can be added that define the permissions which the specific users or groups are granted.

An example of the use of ACLs: Let's assume a small company producing soaps for all usages. We shall call it Soaps4All. Soaps4All runs a Linux system as its main file server. The system administrator of Soaps4All is called Damu. One particular team of users, the Toileteers, deals with the development of new toilet accessories. They keep all their shared data in the sub-directory /home/toileteers/shared. Kalyan is the administrator of the Toileteers team. Other members are Ritu, Vivek, and Ulhas.

Username Groups Function

-------------------------------------------------------------------

Damu users System administrator

Kalyan toileteers, jumboT, perfumedT administrator ritu toileteers, jumboT

vivek toileteers, perfumedT

ulhas toileteers, jumboT, perfumedT

Inside the shared directory, all Toileteers shall have read access. Kalyan, being the Toileteers administrator, shall have full access to all the sub-directories as well as to files in those sub-directories. Everybody who is working on a project shall have full access to the project's sub-directory in /home/toileteers/shared.

Suppose two brand new soaps are under development at the moment. These are called Jumbo and Perfumed. Ritu is working on Jumbo. Vivek is working on Perfumed. Ulhas is working on both the projects. This is clearly reflected by the users' group membership in the table above.

We have the following directory structure:

$ ls -l

drwx------ 2 Kalyan toileteers 1024 Apr 12 12:47 Kalyan

drwx------ 2 ritu toileteers 1024 Apr 12 12:47 ritu

drwxr-x--- 2 Kalyan toileteers 1024 Apr 12 12:48 shared

drwx------ 2 ulhas toileteers 1024 Apr 12 13:23 ulhas

drwx------ 2 vivek toileteers 1024 Apr 12 12:48 vivek

/shared$ls -l

drwxrwx--- 2 Kalyan jumbo 1024 Sep 25 14:09 jumbo

drwxrwx--- 2 Kalyan perfumed 1024 Sep 25 14:09 perfumed Now note the following:

• Ritu does not have a read access to /home/toileteers/shared/perfumed.
• Vivek does not have read access to /home/toileteers/shared/jumbo.
• Kalyan does not have write access to files which others create in any project sub- directory.

The first two problems could be solved by granting everyone read access to the /home/toileteers/shared/ directory tree using the others permission bits (making the directory tree world readable). Since nobody else but Toileteers have access to the /home/toileteers directory, this is safe. However, we would need to take great care of the other permissions of the /home/toileteers directory.

Adding anything to the toileteers directory tree later that is world readable is impossible. With ACLs, there is a better solution. The third problem has no clean solution within the traditional permission system.

The solution using ACLs: The /home/toileteers/shared/ sub-directories can be made readable for Toileteers, and fully accessible for the respective project group. For Kalyan's administrative rights, a separate ACL entry is needed. This is the command to grant read access to the Toileteers. This is in addition to the existing permissions of other users and groups:

$setfacl -m g:toileteers:rx *
$getfacl *
# file: jumbo
# owner: Kalyan
# group: jumbo
user::rwx
group::rwx
group:toileteers:r-x
mask:rwx
other:---
# file: perfumed
# owner: Kalyan
# group: perfumed
user::rwx
group::rwx
group:toileteers:r-x
mask:rwx
other:---

Incidentally, AFS(Andrew File System), and XFS (SGI's eXtended File System) support ACLs.