OS 보안 취약점 대응: 패스워드 복합도·deny 설정과 PAM 안전 작업 순서

OS 보안 취약점 : 계정 패스워드 복잡도 설정 및 deny 설정 (PAM 안전 작업 순서)

Linux에서 패스워드 복잡도(복합도)와 로그인 실패 누적(deny) 정책은 보통 PAM을 통해 적용합니다. 문제는 /etc/pam.d를 잘못 수정하면 바로 SSH 접속 불능이 될 수 있다는 점입니다.

운영 환경에서는
PAM 변경은 “설정 작업”이 아니라 “접속 경로를 유지해야 하는 변경 작업”입니다.
작업 전에 반드시 CLI root 권한(복구용 세션)을 미리 켜놓고, 되돌리기(rollback)까지 준비한 뒤 진행하세요.

개요

이번 문서에서 다루는 범위는 아래와 같습니다.

• 패스워드 복잡도(복합도): 영문 대/소문자, 숫자, 특수문자 조합/길이 기준을 강제
• deny(계정 잠금): 로그인 실패 누적 시 잠금(예: 5회 실패 시 60초 잠금)
• PAM 안전 작업 순서: pam.d 수정으로 접속 불능을 피하기 위한 절차/테스트

중요한 구분
복잡도 정책은 주로 password 스택에서 동작하고,
deny(실패 누적 잠금)는 주로 auth 스택에서 동작합니다.
같은 파일을 수정하더라도 “라인의 위치(순서)”가 결과를 바꿉니다.

환경

항목	확인 포인트
접속 경로	SSH 외에 콘솔(가상 콘솔/ILO/IPMI/VM 콘솔) 접근이 가능한가
대상 파일	/etc/pam.d/system-auth (배포판/버전에 따라 auto-generated일 수 있음)
복잡도 모듈	pam_pwquality 또는 pam_cracklib 사용 여부(환경에 따라 다름)
deny 모듈	pam_faillock (신규) 또는 pam_tally2 (구형) 사용 여부

증상

• pam.d 수정 직후 SSH가 끊기거나 재접속이 되지 않음
• sudo 인증이 막혀 root 권한을 다시 얻지 못함
• deny 정책이 과도해 정상 사용자도 반복적으로 잠김

가장 흔한 장애 시나리오
“원격 SSH 한 세션만 열린 상태”에서 /etc/pam.d/system-auth 저장 → 다음 인증부터 막힘 → 복구 경로 없음

1차 점검: 작업 전 필수 안전 장치

1) 복구용 root 세션을 먼저 확보

• 최소 2개 세션: 작업 세션 + 복구 세션(가능하면 다른 접속 경로)
• root 권한을 미리 확보: sudo -i 또는 root 로그인 세션을 열어둠
• 복구 세션은 절대 닫지 않기: 변경 검증이 끝날 때까지 유지

2) 변경 전 백업(rollback) 준비

# 핵심 PAM 파일 전체 백업(권장)
cp -a /etc/pam.d /root/pam.d.backup.$(date +%F_%H%M%S)

# 변경 전 해당 파일만 별도 백업(추가 안전)
cp -a /etc/pam.d/system-auth /root/system-auth.backup.$(date +%F_%H%M%S)

3) “auto-generated” 경고 확인

system-auth 상단에 “auto-generated / 다음 실행 시 변경이 파괴됨” 같은 문구가 있으면, 추후 도구(authconfig 등) 실행으로 설정이 덮일 수 있습니다.
실무 기준으로 보면, 이런 환경에서는 “직접 수정”을 하더라도 표준 운영 절차(재적용/형상관리)까지 같이 설계해야 합니다.

심화 분석: PAM 수정 시 반드시 지켜야 하는 순서 원칙

원칙 3가지
1) 변경은 한 번에 하나씩(복잡도 → deny 순 추천)
2) 저장 후 즉시 새 SSH 세션으로 테스트(현재 세션은 “성공했던 과거”라 착시가 생김)
3) 실패 시 즉시 원복할 수 있게 복구 루트 세션을 유지

PAM 라인 한 줄이 “인증 성공/실패”를 결정합니다. 특히 required, requisite, sufficient 조합과 라인의 순서가 바뀌면, 동일 모듈이라도 결과가 달라질 수 있습니다.

복구: 안전 적용 절차(권장 순서)

Step 1) 복잡도 정책을 먼저 정리

요구사항(정책)은 아래처럼 정리할 수 있습니다.

패스워드 복잡도 설정(요구사항)
다양한 문자를 조합하여 패스워드 복잡도를 올려야 한다.
영문 대소문자, 숫자, 특수 문자 중 2종류 이상을 조합하여 최소 10자리 이상
3종류 이상을 조합하면 최소 8자리 이상

위 요구사항을 구현하기 위해 /etc/pam.d/system-auth의 password 스택에 복잡도 모듈을 적용합니다. 아래 예시는 pam_cracklib 기반이며, 환경에 따라 pam_pwquality를 사용하는 경우도 있습니다.

주의
/etc/pam.d/system-auth는 로그인/SSH/sudo 등 광범위하게 영향을 줄 수 있습니다.
수정 전에 반드시 root CLI를 미리 켜놓고 진행하세요.

Step 2) system-auth 예시(추가 라인 포함)

아래는 사용자가 제시한 구성 예시입니다. “추가” 대상은 password 스택의 cracklib 라인이며, deny 예시는 auth 스택의 pam_tally2 라인입니다.
(실제 적용 전, 환경이 pam_tally2/pam_cracklib를 지원하는지 반드시 확인하세요.)

# /etc/pam.d/system-auth (예시)
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_tally2.so deny=5 unlock_time=60 no_magic_root reset
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so


account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so


#password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    requisite     /usr/lib64/security/pam_cracklib.so retry=3 minlen=8 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so


session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session    optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

Step 3) 복잡도 옵션 의미(요약)

패스워드 복잡도에 사용되는 옵션은 아래와 같습니다.

• retry=5 : 패스워드 입력 실패 시 재시도 가능 횟수
• difok=10 : 기존 패스워드와 비교하는 정도(기본값 10, 약 50% 수준으로 이해하는 경우가 많음)
• minlen=5 : 패스워드의 최소 길이
• dcredit=-1 : 숫자를 최소 1자 이상 사용
• ucredit=-1 : 영어 대문자를 최소 1자 이상 사용
• lcredit=-1 : 영어 소문자를 최소 1자 이상 사용
• ocredit=-1 : 숫자/영어 대·소문자를 제외한 기타 문자(특수문자)를 1자 이상 사용

참고
-1의 의미는 “해당 종류 문자를 반드시 1개 이상 포함해야 한다”는 뜻입니다.

Step 4) deny(계정 잠금) 적용은 마지막에

deny는 잘못 적용하면 정상 사용자도 쉽게 잠깁니다. 적용 전 “잠금 해제 절차”를 먼저 정하세요.

• 잠금 기준: deny=5 같은 실패 횟수
• 해제 정책: unlock_time=60 같은 자동 해제 시간(또는 관리자 해제)
• root 포함 여부: 운영 정책에 따라 매우 신중(포함 시 장애 위험 증가)

재발 방지: 작업 중 테스트 시나리오(필수)

테스트는 “현재 세션”이 아니라 “새 세션”으로
변경 저장 후, 반드시 새 터미널/새 SSH 연결로 테스트해야 합니다.
현재 세션은 이미 인증을 통과한 상태라, 변경이 실패해도 당장은 멀쩡해 보일 수 있습니다.

순서	테스트 항목	성공 기준
1	일반 계정으로 새 SSH 로그인	정상 로그인/세션 생성
2	sudo 인증	sudo 패스워드 입력 후 root 권한 획득
3	비밀번호 변경 테스트	단순 비밀번호 거부, 정책에 맞는 비밀번호만 허용
4	의도적 로그인 실패 누적	정책대로 잠금/해제가 동작(과도 잠금 없는지 확인)
5	복구 세션 유지 상태에서 원복 리허설	백업 파일로 즉시 복원 가능

복구 절차: 접속이 막혔을 때(간단 원칙)

PAM 변경 후 접속이 막히면, 결국 열어둔 root 복구 세션(또는 콘솔)로 들어가 원복하는 방식이 가장 빠릅니다.

# 예시: 백업해둔 pam.d로 즉시 원복
# (환경에 따라 파일 단위로 복원하는 게 더 안전할 수 있음)
cp -a /root/pam.d.backup.YYYY-MM-DD_HHMMSS/* /etc/pam.d/

# 혹은 system-auth만 원복
cp -a /root/system-auth.backup.YYYY-MM-DD_HHMMSS /etc/pam.d/system-auth

실무 팁
“접속 불능 사고”는 대부분 복구 경로 부재에서 커집니다.
관리자 입장에서 PAM 변경은 복구 세션 확보 → 백업 → 작은 변경 → 새 세션 테스트만 지켜도 사고 확률이 크게 줄어듭니다.

마무리

패스워드 복잡도와 deny 정책은 보안 수준을 높이는 데 효과적이지만, PAM 파일은 시스템 전체 인증에 영향을 주기 때문에 “올바른 정책”보다 “안전한 적용 순서”가 먼저입니다. 변경 전 루트 CLI를 미리 켜놓고, 백업과 새 세션 테스트를 단계별로 수행하면 접속 불능 리스크를 현실적으로 관리할 수 있습니다.