Use PAM to enhance Linux Server Security

Server System Security is indeed a headache for most users: how to ensure that the users who use applications or services in the system are indeed users themselves? How do I specify a time period for these users to restrict access to the service? And how to limit the usage of system resources by various applications or services? Conventional security measures cannot properly address all these problems.

Server System Security is indeed a headache for most users: how to ensure that the users who use applications or services in the system are indeed users themselves? How do I specify a time period for these users to restrict access to the service? And how to limit the usage of system resources by various applications or services? All these problems cannot be properly solved by conventional security measures. In the REdHat Enterprise Linux3 has integrated a plug-in authentication module (Pluggable Authenti)CatIon MoDuLes), which can be used to complete the preceding tasks.

The Pluggable Authentication Module (PAM) is a modular design-based verification method independent of applications. After PAM is used, the application can be completed by PAM without integrating the verification function. For example, in Linux, the Login service provides the system logon service for users. It prompts the user to enter the corresponding user name and password to verify the user's validity. When PAM is used, this verification process can be replaced by PAM. PAM has great flexibility, and the system administrator can use it to freely select the authentication method needed for the application. In view of the advantages of PAM, this article will use RedHat Enterprise Linux3 as the application platform to discuss how to use PAM to enhance the security performance of Linux servers.

1. PAMGetting startedMandatory

When an application or service on a Linux server needs to use PAM for verification, as long as the application or service supports the PAM verification function, you can modify the corresponding PAM Configuration File, add the corresponding authentication method. When some services or applications are re-enabled, the PAM module reads its configuration file through its dedicated API, provide the verification function based on the content in the configuration file. All verification functions are provided through some library files.

Therefore, before using PAM, it is necessary to know how to set the PAM Configuration File and some common verification modules.

When an application that supports PAM Authentication is started, it reads its PAM Configuration file through the pam api, and then according to the content specified by the authentication item in the configuration file, the authentication module required by the API call is used to complete the verification task specified in the configuration file. It can be seen from this that to master the use of PAM, you must understand the configuration rules of the configuration file and the significance and role of various verification modules.

Note that an application in a Linux system can use the PAM function. The most important thing is that it has integrated the code that supports the PAM function into the original code. If you can get the original code of an application, you can add the functional code that supports PAM. However, if the obtained binary file does not have the PAM function code, this application does not support the PAM verification function. Check whether the application has the PAM verification function. You can useDdCommandCheck whether libpam and libpam_misc are available in the dynamic Connection Library.

1. Set the PAM Configuration File

In the RedHat Enterprise Linux3 system, each application or service that supports PAM verification has a corresponding PAM Configuration File, which is stored in the/etc/pam. d/directory. To make these configuration files valid, you must write the names of these configuration files into the program source code. Generally, the names of these configuration files are the same as those of their corresponding applications.

To set these configuration files, you only need to open them through VI or VIM, and then add or delete the verification items.

Open any configuration file in the/etc/pam. d/directory. The validation rules for each row use the syntax format shown below:

Type ConTrOl-flag Module-path Module-arguments

Each row represents an independent authentication method. Each configuration file can be composed of multiple authentication rules. During verification, the PAM-API reads these verification rules one by one from the top-down approach and acts accordingly based on the control flag.

Be careful when editing the configuration file. Because the validation of rules is divided into upper and lower order, be careful to determine that some dangerous validation rules are in the correct position in the configuration file. Once an error occurs, some functions of the system or the entire system may be inaccessible, so you have to restore the backup.

To properly configure the PAM Configuration File, you should understand the content of each column in the configuration file method format. The following is a brief description of these columns:

(1) Type column, mainly used to specify the Type to be verified. There are four types of verification:

1. Authenticate the user's identity and prompt to enter the account and password;

2. The account provides further verification of the account. For example, it verifies whether the account has expired, the permissions, and the validity period of the account;

3. password provides detailed control over the password, such as the password's validity period, the number of repeated input times, and the time limit for unblocking after the password is locked.

4. The session tracks and records each session. The recorded content includes the user name, Logon Time, and number of times.

(2) The Control-flag column is mainly used to Control the action and return result in the verification process. There are two types of expressions: simple is to use a simple keyword, complex can be nested with square brackets to control the flag, value = action can be used in square brackets.

There are four simple keywords:

1. required

When this control flag is used, the verification process will continue when verification fails. It will return an error message, however, because it does not stop the verification process due to verification failure, the user does not know which rule item Verification Failed.

2. requisite

This control flag is similar to the Verification Method of required. However, if a rule item fails to be verified, the entire verification process is completed immediately and an error message is returned. This keyword can be used to prevent brute-force password cracking attacks. However, because it returns information to users, it may also disclose the system's user structure information to attackers.

3,SuFficient

As long as a rule item with this control flag is successfully verified, the PAM architecture immediately terminates all subsequent verifications, regardless of whether the items with the preceding required flag are successfully verified, it will still be ignored and the verification will pass.

4. optional

It indicates that the verification is successful or failed, and all items are ignored. (Usually used for session type)

The complex control flag allows administrators to specify actions that can be performed when an event occurs during verification. These control flags are enclosed in square brackets and are composed of a series of value = action. Each value is separated by a space.

In the new version of PAM, the list of values available for you to choose exists in/usr/INcIn the lude/security/_ pam_types.h file. The content includes: success, open_err, symbol_err, ervice_err, system_err, buf_err, peRm_ Denied, auth_err, cred_insufficient, authinfo_unavail, user_unknown, maxtries, new_authtok_reqd, acct _ExPired, session_err, primary, cred_expired, cred_err, primary, conv_err, authtok_err, primary, try_again, ignore, abort, primary, primary, bad_item, conv_again, incomplete, and default.

Action can be an unsigned integer. When the value of the control flag of a row verification rule refers to a regular unsigned integer, it indicates that the n-row verification module is skipped directly.

Action can also be the following values:

Ignore: When this value is set, the specified event is ignored.

Bad: When this value is set, the return value when a specified event occurs is considered as a failure of the verification module. If this verification module is the first failed module in the entire verification stack, its status value will act as the status of the entire stack.

Die: it serves the same purpose as bad. However, when such an event is set to this value, subsequent verification of the entire verification module is terminated and immediately returned to the application.

OK: set this value to overwrite all the values of PAM_SUCCESS returned before the validation rule for this row. However, if a validation rule returns an incorrect value, it will not overwrite it.

Done: it serves the same purpose as OK. However, when this type of event is set, subsequent verification of the entire verification module will be terminated and will be immediately returned to the application.

ReSet: Set this value to clear the original authentication module status in the memory and re-start the next verification group.

The third column is Module-path, which is used to provide the required verification Module for the Service to be verified. In the Fedora Core 6 system, when the referenced module is in the/lib/security/or/lib64/security/directory, you can only enter the full name of the module; if the two default storage directories do not exist for the referenced module, you must add the complete module path name before the complete name of the module. For example,/usr/lib/security /.

The fourth column is Module-arguments, which is used to specify special options for the referenced Module. Multiple options can be separated by spaces, you can also use "[]" in the options to enter nested commands or strings. When the options exceed one line, use the "" symbol to connect the next line.

3. Description of common verification modules in PAM

To understand the use of PAM, we should also understand the role of some common PAM verification modules. After all, the specific verification functions of PAM are completed by these pluggable verification modules. In the RedHat Enterprise Linux3 system, the default PAM Authentication Files exist in the/lib/security/or/lib64/security/directory. They are all files suffixed with ". so.

The object used by each PAM verification module always corresponds to the PAM verification type. Some verification modules only apply to one verification method. For example, the pam_access.so verification module only works with the account Verification type, while some verification modules can work with all verification types, for example, the pam_unix.so verification module. When you understand these verification modules, you should also understand what they belong to the verification category.

The following is a brief description of some common verification modules:

(1) pam_access verification module

The pam_access authentication module is generally used together with the account authentication type. It is mainly used for access entry management. It provides access control based on the login name, host name or domain name, public IP address or network number, and the tty name during non-network login. The pam_access Authentication Module performs verification based on the content in the/etc/security/access. conf configuration file. If the access. conf file is not in the default/etc/security/directory, you can use accessFileThe parameter specifies the absolute path of the custom configuration file.

Each line in the/etc/security/access. conf configuration file consists of the following three fields separated by a colon:

Permission: users/groups: origins

The permission (permission) field can be accessed with "+", that is, "-" to indicate the corresponding permissions.

The users/groups (user or group) field can be a list of one or more login names, group names, and ALL (indicating anyone. To distinguish the username and group name, you can add the group name to a bracket, for example, groups ).

The origins field can be a tty name, host name, or domain name (start), host address, network number (with ". "end"), a public IP address with a subnet mask, and ALL (indicating any host) and LOCAL as long as they do not contain ". all characters ). The distinct t operator can also be used to represent the division... .

(2) pam_cracklib verification module

The pam_cracklib verification module is generally used only with the password verification type. This verification module can provide plug-in password strength detection for special applications by inserting the password stack. It first prompts the user to enter the password, and then uses a system dictionary and a set of rules to check whether the entered password does not meet the Robustness Requirements. The password strength check is performed twice. The first check is only a part of the comparison dictionary provided by the password. If the check result is negative, then it will provide some additional detection to further detect its strength. For example, it will detect the proportion of Characters in the new password to the old password, the length of the password, and the case sensitivity of the characters used, and whether special characters are used.

Since the pam_cracklib verification module provides a detailed password strength check, we must specify additional detection options for it when using it. These options include:

Debug: This option indicates Writing module information to system logs.

Type = xxx: This option is used to modify the default password prompt text. For example, if the default prompt text is "New Passwork :", then you can change the prompt text by setting type = my password.

Retry = N: This option defines the number of times the user enters the password again, an error message is returned, and the input is not allowed to continue. The default value is 1.

Difok = N: This option defines the number of characters in the new password to be different from the old password. If the new password contains more than 1/2 characters different from the old password, the new password will be accepted.

Difignore = N: This option is used to set the number of characters received before difok. The difok setting is ignored. The default value is 23.

Minlen = N: This option is used to set the minimum length of the new password.

Dcredit = N: This option is used to set the maximum number of numbers that can be included in the new password.

Ucredit = N: This option is used to set the maximum number of uppercase letters that a new password can contain.

Lcredit = N: This option is used to set the maximum number of lowercase letters that a new password can contain.

Ocredit = N: This option is used to set the maximum number of special characters that a new password can contain.

Minclass = N: specifies the minimum number of character classes in a new password. There are generally four types of characters: Numbers, uppercase letters, lowercase letters, and special characters.

Use_authtok: This option is used after a password-related verification module, for example, the pam_unix.so verification module, can force this module to not prompt for a password, but use another method set above, for example, pam_cracklib.so.

Dictpath =/path/to/dict: Specifies the cracklib directory path.

(3) pam_limit verification module

The pam_limits verification module is usually used together with the session verification category. It is mainly used to restrict the use of system resources during the session process, even if the UID is 0, the user is also limited by it. This module uses an independent configuration file to set limits on system resources. The default configuration file is/etc/security/limits. conf. You can use the conf option to specify the location of the configuration file. When you use the pam_limits verification module, it is always a good choice to set the configuration file first.