1. 개요

서버 취약점 진단을 받게 되면 종종 "계정 잠금 임계값 설정", "SU 명령어 사용 제한" 등의 항목에서 "PAM 모듈을 이용하여 취약점을 조치하세요."라는 안내받게 된다. 그러나 막상 PAM 설정 파일을 열어 가이드에 명시되어 있는 대로 변경했다가는 낭패를 보기 십상이다.

PAM 설정은 단순히 한 줄 수정한다고 해서 되는 것이 아니라 위/아래 줄에 선언된 설정에 의해 그 결과값이 달라지기 때문에 자칫하다간 SU 명령어를 사용할 수 없게 되거나, 로그인 잘 되던 계정이 갑자기 로그인할 수 없게 될 수 있어 설정에 주의가 필요하다.

따라서 이번 테크노트에서는 PAM 이란 무엇이며 어떻게 동작하는지 등 PAM에 대한 전반적인 내용을 알아보고자 한다.

2. PAM(Pluggable Authentication Modules)이란​

PAM은 리눅스 시스템에서 사용하는 '인증 모듈(Pluggable Authentication Modules)'로써 응용 프로그램(서비스)에 대한 사용자의 사용 권한을 제어하는 모듈이다.

PAM을 사용하기 이전 리눅스 시스템에서는 사용자를 인증하기 위해 각 응용프로그램에서 자체적으로 로직을 구현하여 사용했다. 특히 시스템에 저장된 사용자 정보를 통해 인증할 경우, 응용프로그램이 사용자 정보가 담긴 주요 시스템 파일(etc/passwd)​에 대한 접근 권한을 가지고 있어야 하므로 침해사고의 위험이 존재했다. 그 뿐만 아니라 응용프로그램마다 사용자 인증 방식이 상이하여 관리하기에 많은 어려움이 따랐다. 

이를 해결하기 위해 PAM이 등장하게 되었으며, PAM의 동작 원리는 다음과 같다.

1. 인증이 필요한 응용프로그램은 더 이상 passwd 파일을 열람하지 않고 ‘PAM’ 모듈에 사용자 인증을 요청한다.

2. PAM은 인증을 요청한 사용자의 정보를 가지고 결과를 도출하여 응용프로그램에 전달한다.

[그림 1] 응용프로그램 자체적으로 사용자 인증하는 과정

[그림 2] PAM 모듈을 통한 사용자 인증 과정

PAM 모듈은 소프트웨어의 개발과 인증 및 안전한 권한 부여 체계를 분리하고자 하는 목적으로 만들어졌기 때문에 이를 통한 인증을 수행할 경우, 응용프로그램에서 직접 인증 로직을 구현하지 않아 개발이 간소화될 뿐만 아니라 passwd 파일 등 시스템 파일을 열람하지 않아도 되는 장점이 있다. 무엇보다도 가장 큰 장점은 시스템 운영자가 응용프로그램의 인증 동작을 제어할 수 있어 더욱 안전하게 시스템을 운영할 수 있다.

3. PAM 구성

1) PAM 기본구조

· 기본 구조

· 기본 구조의 예

2) Module Type

모듈 타입 필드는 PAM에 어떤 종류의 인증을 사용할 것인가를 지정하는 필드로 아래와 같이 4종류의 타입을 설정할 수 있다.

3) Control Flag

PAM에서 사용되는 모듈들이 결과에 따라 어떤 동작을 해야하는지 결정하는 필드이다.

5개의 Control Flag 중 “Required”의 경우, 해당 모듈의 결과와 상관없이 다음 모듈을 실행시킨다. 심지어 다음에 실행된 모듈의 결과보다 더 높은 우선순위를 가지므로 “Required”에서 실패가 되면 최종 인증 결과는 실패가 된다는 사실에 주의해야 한다.

4) Module Name

이 필드는 사용하고자 하는 모듈의 경로와 이름을 지정하는 필드이며 PAM 모듈은 대부분 /lib/security 또는 /etc/pam.d 디렉터리에 위치한다. 다음은 주요 모듈에 대한 설명이다.

5) Module Arguments

모듈-인수는 모듈에게 전달되는 인수를 나타낸다. 각각의 모듈은 각각의 인수를 가지고 있다. 모듈마다 인수가 필요할 수도 필요 없을 수도 있다.

4. PAM을 통한 인증과정 상세

그럼 이제 PAM을 통한 인증 과정을 상세하게 분석 해보자. 여기서는 “su” 명령어 응용프로그램을 기준으로 분석해보고자 한다.

※ try_first_pass

이전 모듈에서 입력받은 패스워드가 있을 경우, 해당 패스워드로 먼저 인증 시도한다. 이전에 입력받은 패스워드가 없을 경우, 패스워드 입력을 요청한다.

위의 과정 중 가장 주목해야 하는 단계는 바로 "3" 단계이다. "3" 단계에서는 "required" flag를 사용하여 모듈을 실행했기 때문에 인증 요청자가 wheel 그룹에 속하지 않아도 다음 인증 모듈이 실행된다. 따라서 wheel 그룹원뿐만 아니라 "모든" 인증 요청자가 "5" 단계까지 인증 과정을 거치게 되며 모두 동일하게 password 입력 요청까지 받게 되는 것이다.

여기서 앞서 말한 ＂required＂ flag의 진면목이 나타난다. 인증 요청자는 wheel 그룹에 속하지 않아서 인증 실패가 났음에도 불구하고 password 입력 요청을 받았기 때문에 단순히 password 입력 오류라고 생각할 수 있다. 이는 에러 발생 원인이 직접적으로 표출되지 않기 때문에 보안상 매우 좋다는 장점을 가진다.

5. PAM 설정 예제

■ CASE 1

모듈-인수는 모듈에게 전달되는 인수를 나타낸다. 각각의 모듈은 각각의 인수를 가지고 있다. 모듈마다 인수가 필요할 수도 필요 없을 수도 있다.

위의 두 설정파일은 단순히 control flag만 다르지만, 인증 과정과 사용자에게 노출되는 에러문구는 완전히 다르다는 것을 다시한번 상기해야한다. 설정파일 #1의 경우, 인증 요청자가 “igloo”가 아니더라도 암호 입력을 요구하나, 설정파일 #2에서는 암호를 요구하지 않고 바로 인증 실패가 반환된다.

[그림 3] 설정파일 #1의 인증 결과

[그림 4] 설정파일 #2의 인증 결과

■ CASE 2

다음은 모듈 설정의 순서만 바꾼 것이다. 설정파일 #1의 인증과정은 다음과 같다.

1. su 명령어 요청자가 “igloo” 인지 확인

2. su 명령어 요청자가 “root” 인지 확인

그러나 여기서 주의할 것이 있다. “igloo” 계정인지 확인 하는 모듈의 control flag가 required 이므로 root 계정으로 su 명령어를 사용해도 결국은 인증 실패가 반환된다. 따라서 위의 설정은 “igloo” 계정만 su 명령어를 사용할 수 있는 설정이다.

그러나 설정파일 #3의 경우, “root” 계정인지 확인 하는 모듈의 control flag가 sufficient 이므로 설정파일 #1과 달리 “root” 계정과 “igloo” 계정, 즉 2개의 계정에서 su 명령어를 사용할 수 있다. 또한, root 계정으로 su 명령어를 사용할 경우, PAM은 요청자가 “igloo”인지 확인하지 않고 바로 인증 성공을 반환하며 인증을 종료한다.

[그림 5] 설정파일 #1의 인증 결과

[그림 6] 설정파일 #2의 인증 결과

언뜻 보기에는 비슷하게 보일 수 있으나, 실제로 수행되는 인증 과정과 그 결과는 앞서 확인한 설정파일 #1과 크게 다른 것을 확인할 수 있다. 이렇듯 같은 설정이라도 순서가 바뀌면 전혀 다른 결과를 초래하므로 PAM 설정에 각별한 주의가 요구된다.

6. 결론

PAM을 통한 사용자 인증은 시스템 운영에 편의성과 보안성을 높여주지만, 자칫 잘못 설정할 경우 비인가자에게 접근을 허용하여 기밀성을 침해하거나 인가받은 사용자의 접근을 차단하는 등의 가용성을 해칠 수 있어 사용에 주의해야 한다.

또한, 앞서 설명한 것 이외에 PAM 사용에 한 가지 더 주의할 점이 있는데 그것은 바로 응용프로그램 자체의 권한 설정이다. PAM이 아무리 바르게 설정되어 있더라도 응용프로그램 실행 권한이 없으면 사용자 인증 자체를 수행할 수 없기 때문에 해당 응용프로그램을 사용하기 위해서는 실행 권한부터 적절하게 부여해야 함을 간과해서는 안된다.

지금까지 PAM의 구조와 인증 과정에 대해서 살펴보았다. 위 내용을 잘 숙지하여 운영하는 시스템의 보안성을 향상시키길 바란다.

7. 참고

[1] https://www.linux.co.kr/home2/board/subbs/board.php?bo_table=lecture&wr_id=1808

[2] https://ko.wikipedia.org/wiki/%EB%A6%AC%EB%88%85%EC%8A%A4_PAM

[3] https://kimhyun2017.tistory.com/212