10.2. PAM 구성 파일 정보
각 PAM 인식 애플리케이션 또는 서비스에는
/etc/pam.d/
디렉터리에 파일이 있습니다. 이 디렉터리의 각 파일의 이름은 액세스를 제어하는 서비스와 동일합니다. 예를 들어 로그인 프로그램은 서비스 이름을 login 로 정의하고 /etc/pam.d/login
PAM 구성 파일을 설치합니다.
주의
PAM 구성 파일을 수동으로 편집하는 대신 authconfig 도구를 사용하여 PAM을 구성하는 것이 좋습니다.
10.2.1. PAM 구성 파일 형식 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
각 PAM 구성 파일에는 모듈(인증 구성 영역)을 정의하는 지시문 그룹과 모든 제어 또는 인수를 포함합니다.
지시문에는 모듈 목적(인터페이스)과 모듈의 구성 설정을 식별하는 간단한 구문이 있습니다.
module_interface control_flag module_name module_arguments
module_interface control_flag module_name module_arguments
PAM 구성 파일에서 모듈 인터페이스는 정의된 첫 번째 필드입니다. 예를 들어 다음과 같습니다.
auth required pam_unix.so
auth required pam_unix.so
PAM 인터페이스는 특정 모듈이 수행할 수 있는 인증 작업의 유형입니다. 각각 인증 및 권한 부여 프로세스의 다른 측면에 해당하는 4가지 유형의 PAM 모듈 인터페이스를 사용할 수 있습니다.
- auth - 이 모듈 인터페이스는 사용자를 인증합니다. 예를 들어 암호의 유효성을 요청하고 확인합니다. 이 인터페이스의 모듈은 그룹 멤버십과 같은 자격 증명을 설정할 수도 있습니다.
- account - 이 모듈 인터페이스는 액세스가 허용되는지 확인합니다. 예를 들어 사용자 계정이 만료되었는지 또는 사용자가 특정 시간에 로그인할 수 있는지 확인합니다.
- password - 이 모듈 인터페이스는 사용자 암호를 변경하는 데 사용됩니다.
- 세션 - 이 모듈 인터페이스는 사용자 세션을 구성하고 관리합니다. 이 인터페이스의 모듈은 사용자의 홈 디렉터리를 마운트하고 사용자의 사서함을 사용할 수 있도록 액세스를 허용하는 데 필요한 추가 작업도 수행할 수 있습니다.
개별 모듈은 일부 또는 모든 모듈 인터페이스를 제공할 수 있습니다. 예를 들어
pam_unix.so
는 4개의 모듈 인터페이스를 모두 제공합니다.
pam_unix.so 와 같은 모듈 이름은 PAM에 지정된 모듈 인터페이스가 포함된 라이브러리 이름을 제공합니다. 애플리케이션이 올바른 버전의 모듈을 찾을 수 있는
libpam
의 적절한 버전에 연결되어 있기 때문에 디렉터리 이름이 생략됩니다.
모든 PAM 모듈은 호출 시 성공 또는 실패 결과를 생성합니다. Control 플래그는 PAM에 결과와 함께 수행할 작업을 지시합니다. 모듈은 특정 순서로 나열(스택)될 수 있으며, 제어 플래그는 특정 모듈의 성공 또는 실패가 사용자를 서비스에 인증하는 전체 목표에 얼마나 중요한지를 결정합니다.
몇 가지 간단한 플래그가 있습니다.[2], 키워드만 사용하여 구성을 설정합니다.
- required - 인증을 계속하려면 모듈 결과가 성공해야 합니다. 이 시점에서 테스트가 실패하면 해당 인터페이스를 참조하는 모든 모듈의 결과가 완료될 때까지 사용자에게 알리지 않습니다.
- 필수 조건 - 모듈 결과가 인증을 계속하려면 성공해야 합니다. 그러나 이 시점에서 테스트에 실패하면 첫 번째 실패 또는 필수 모듈 테스트를 반영하는 메시지와 함께 사용자에게 즉시 알림을 받습니다.
- sufficient - 모듈 결과가 실패하는 경우 무시됩니다. 그러나 모듈 결과에 sufficient 으로 플래그가 지정되어 있고 필요한 이전 모듈이 실패한 경우 다른 결과가 필요하지 않으며 사용자가 서비스에 인증됩니다.
- 선택 사항 - 모듈 결과가 무시됩니다. 다른 모듈이 인터페이스를 참조하지 않는 경우 성공적인 인증에만 선택 옵션으로 플래그가 지정됩니다.
- include - 다른 제어와 달리 모듈 결과가 처리되는 방법과 관련이 없습니다. 이 플래그는 지정된 매개 변수와 일치하는 구성 파일의 모든 행을 가져와 모듈에 인수로 추가합니다.
모듈 인터페이스 지시문을 스택 하거나 서로 배치하여 여러 모듈을 한 용도로 함께 사용할 수 있습니다.
참고
모듈의 제어 플래그에서
sufficient
또는 requisite
값을 사용하는 경우 모듈이 나열되는 순서가 인증 프로세스에 중요합니다.
관리자는 스태킹을 사용하여 사용자가 인증하기 전에 특정 조건을 사용해야 할 수 있습니다. 예를 들어 설정 유틸리티는 일반적으로 PAM 구성 파일에 표시된 대로 여러 개의 스택된 모듈을 사용합니다.
auth sufficient pam_rootok.so
- 이 행은pam_rootok.so
모듈을 사용하여 UID가 0인지 확인하여 현재 사용자가 root인지 확인합니다. 이 테스트에 성공하면 다른 모듈이 확인되지 않고 명령이 실행됩니다. 이 테스트가 실패하면 다음 모듈이 참조됩니다.auth include system-auth
- 이 행에는/etc/pam.d/system-auth
모듈의 콘텐츠가 포함되어 인증을 위해 이 콘텐츠를 처리합니다.계정 필수 pam_permit.so
- 이 줄은pam_permit.so
모듈을 사용하여 root 사용자 또는 콘솔에 로그인한 모든 사용자가 시스템을 재부팅할 수 있도록 허용합니다.세션 필수 pam_permit.so
- 이 행은 세션 설정과 관련이 있습니다.pam_permit.so
를 사용하면설정
유틸리티가 실패하지 않습니다.
PAM은 인수를 사용하여 일부 모듈에 대한 인증 중에 플러그형 모듈에 정보를 전달합니다.
예를 들어
pam_pwquality.so
모듈은 암호가 얼마나 강하고 여러 개의 인수를 사용할 수 있는지 확인합니다. 다음 예에서 enforce_for_root
는 루트 사용자의 암호도 강력한 검사를 성공적으로 통과해야 하며 재시도는 사용자가 강력한 암호를 입력할 수 있는 세 가지 기회를 수신하도록
정의합니다.
password requisite pam_pwquality.so enforce_for_root retry=3
password requisite pam_pwquality.so enforce_for_root retry=3
잘못된 인수는 일반적으로 무시되며 그렇지 않으면 PAM 모듈의 성공 또는 실패에 영향을 주지 않습니다. 그러나 일부 모듈은 유효하지 않은 인수에서 실패할 수 있습니다. 대부분의 모듈은
journald
서비스에 오류를 보고합니다. journald
및 관련 journalctl
툴을 사용하는 방법에 대한 자세한 내용은 시스템 관리자 가이드를 참조하십시오.
참고
journald
서비스는 Red Hat Enterprise Linux 7.1에서 도입되었습니다. 이전 버전의 Red Hat Enterprise Linux에서 대부분의 모듈은 오류를 /var/log/secure
파일에 보고합니다.
10.2.2. 주석이 있는 PAM 구성 예 링크 복사링크가 클립보드에 복사되었습니다!
링크 복사링크가 클립보드에 복사되었습니다!
예 10.1. “간단한 PAM 구성” 샘플 PAM 애플리케이션 구성 파일입니다.
예 10.1. 간단한 PAM 구성
- 첫 번째 줄은 행 시작 부분에 해시 표시(#)로 표시된 주석입니다.
- 로그인 인증을 위해 2-4개의 스택 3개 모듈을 행합니다.auth required pam_securetty.so - 이 모듈은 사용자가 root로 로그인하려고 하는 경우 해당 파일이 있는 경우 사용자가 로그인하는 TTY가
/etc/securetty
파일에 나열되도록 합니다.TTY가 파일에 나열되지 않은 경우 root로 로그인하려고 하면로그인 잘못된
메시지와 함께 실패합니다.auth required pam_unix.so nullok - 이 모듈은 사용자에게 암호를 묻는 다음/etc/passwd
에 저장된 정보를 사용하여 암호를 확인하고, 존재하는 경우/etc/shadow
.nullok 인수는pam_unix.so
모듈을 지시하여 빈 암호를 허용합니다. - auth required pam_nologin.so - 최종 인증 단계입니다.
/etc/nologin
파일이 있는지 확인합니다. 존재하고 사용자가 root가 아닌 경우 인증에 실패합니다.참고이 예제에서는 첫 번째 auth 모듈이 실패하더라도 세 개의 auth 모듈이 모두 확인됩니다. 이렇게 하면 사용자가 인증에 실패한 단계에서 알 수 없습니다. 공격자는 이러한 지식을 통해 시스템을 크래핑하는 방법을 보다 쉽게 줄일 수 있습니다. - 계정 필수 pam_unix.so - 이 모듈은 필요한 계정 확인을 수행합니다. 예를 들어 shadow 암호가 활성화된 경우
pam_unix.so
모듈의 계정 인터페이스에서 계정이 만료되었는지 또는 사용자가 허용된 유예 기간 내에 암호를 변경하지 않았는지 확인합니다. - 암호 required pam_pwquality.so retry=3 - 암호가 만료된 경우
pam_pwquality.so
모듈의 password 구성 요소에서 새 암호를 입력하라는 메시지를 표시합니다. 그런 다음 새로 생성된 암호를 테스트하여 사전 기반 암호 크래킹 프로그램으로 쉽게 결정할 수 있는지 확인합니다.retry=3 인수는 테스트가 처음으로 실패하면 사용자에게 강력한 암호를 만들 가능성이 두 개 더 있음을 나타냅니다. - 암호 required pam_unix.so shadow nullok use_authtok - 이 줄은 프로그램이
pam_unix.so
모듈의 암호 인터페이스를 사용하여 사용자의 암호를 변경하는 경우 를 나타냅니다.- 인수 shadow 는 사용자의 암호를 업데이트할 때 섀도우 암호를 생성하도록 모듈에 지시합니다.
- nullok 인수는 사용자가 빈 암호 에서 암호를 변경할 수 있도록 모듈에 지시합니다. 그렇지 않으면 null 암호가 계정 잠금으로 처리됩니다.
- 이 행의 마지막 인수인 use_authtok 에서는 PAM 모듈을 스택할 때 순서가 중요합니다. 이 인수는 모듈에 새 암호를 요청하는 메시지를 표시하지 않도록 지시합니다. 대신 이전 암호 모듈에서 기록한 암호를 허용합니다. 이렇게 하면 모든 새 암호가 허용되기 전에 보안 암호를 위해
pam_pwquality.so
테스트를 전달해야 합니다.
- 세션 required pam_unix.so - 최종 줄은
pam_unix.so
모듈의 세션 인터페이스에 세션을 관리하도록 지시합니다. 이 모듈은 사용자 이름과 서비스 유형을 각 세션의 시작과 종료 시/var/log/secure
에 기록합니다. 이 모듈은 추가 기능을 위해 다른 세션 모듈과 스택하여 보완할 수 있습니다.