064. 계정 · 인증 보안 — 계정 잠금 — pam_faillock 설정과 해제

시스템 보안 · 취약점 › B. 계정 · 인증 보안 강화 · 14/50편 (전체 064/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 09. 계정 잠금과 해제
• 013. 계정 · 인증 보안 — PAM 설정 변조 탐지

1. 개념

pam_faillock은 인증 실패가 일정 횟수를 넘으면 계정을 일시 잠급니다. brute-force·password spraying에 대한 서버 측 자동 방어입니다(pam_tally2의 후속).

auth required pam_faillock.so preauth  deny=5 unlock_time=900 fail_interval=900
auth sufficient pam_unix.so ...
auth required pam_faillock.so authfail deny=5 unlock_time=900
   │
 preauth  : 인증 전 — 이미 잠긴 계정이면 차단
 authfail : 인증 실패 시 — 실패 카운트 증가
 deny=5          : 5회 실패 시 잠금
 unlock_time=900 : 900초 후 자동 해제
 fail_interval   : 이 시간 안의 실패만 누적

실패 기록은 /var/run/faillock/<계정>에 저장되고, faillock 명령으로 조회·초기화합니다.

2. 왜 중요한가

• 잠금이 없으면 공격자가 무제한으로 비밀번호를 시도할 수 있습니다. deny 값이 너무 크거나 faillock이 빠지면 brute-force 방어가 사라집니다.
• 반대로 공격자가 특정 계정을 일부러 잠가 정상 사용자를 막는(DoS) 경우도 있습니다. 잠금 이벤트의 출발지를 봐야 공격인지 사용자 실수인지 구분됩니다.
• 공격자는 성공 후 faillock --reset으로 실패 흔적을 지우기도 합니다.

3. 핵심 명령어 / 설정

항목	확인
faillock 설정	grep faillock /etc/pam.d/system-auth /etc/pam.d/common-auth 2>/dev/null 또는 /etc/security/faillock.conf
현재 잠금 상태	sudo faillock (계정별 실패·잠금 표시)
특정 계정	sudo faillock --user devops
실패 기록 위치	ls /var/run/faillock/
초기화 흔적	faillock --reset 실행 로그(audit)

Rocky 9은 authselect가 faillock.conf를 참조하도록 구성되는 경우가 많으므로, 설정 위치를 함께 확인합니다.

4. 실습 (실습 예시)

# 1) 설정 확인
grep -nE 'faillock' /etc/pam.d/system-auth /etc/pam.d/password-auth 2>/dev/null
grep -vE '^\s*(#|$)' /etc/security/faillock.conf 2>/dev/null

# 2) 현재 잠금/실패 현황
sudo faillock | head -20

# 3) 기준선: deny·unlock_time 값
grep -hoE 'deny=[0-9]+|unlock_time=[0-9]+' /etc/security/faillock.conf /etc/pam.d/system-auth 2>/dev/null | sort -u

5. 정상 상태

auth required pam_faillock.so preauth silent deny=5 unlock_time=900
auth required pam_faillock.so authfail deny=5 unlock_time=900
$ sudo faillock
devops:
When                Type  Source           Valid
2026-10-02 09:30:11 RHOST 192.168.56.5     V

deny=5·unlock_time=900이 설정되고, 잠금 현황이 소수의 정상 실패(관리망 출발지)만 보이는 상태가 정상입니다.

6. 이상 상태

$ grep faillock /etc/pam.d/system-auth
(출력 없음)
$ sudo faillock --user devops
devops:
When                Type  Source           Valid
... (대량 실패 기록 후 비어 있음 — reset 흔적)

• faillock 줄이 사라짐 → 잠금 방어 해제, 무제한 시도 가능
• 또는 대량 실패 후 기록이 초기화됨 → faillock --reset으로 흔적 제거
• 072편 brute-force 분석과 반드시 함께 봐야 하는 설정입니다.

7. 로그 분석 (분석 방법)

잠금·해제·초기화 로그입니다(가상의 예시 로그).

Oct  2 02:10:40 rocky9-web01 sshd[12401]: pam_faillock(sshd:auth): Consecutive login failures for user devops account temporarily locked
Oct  2 02:12:00 rocky9-web01 sshd[12420]: pam_faillock(sshd:auth): User devops (1002) has 6 login failures, limit reached
Oct  2 02:55:10 rocky9-web01 faillock[12450]: reset the failure records for devops
type=EXECVE msg=audit(1759341310.004:4205): argc=3 a0="faillock" a1="--user" a2="devops" a3="--reset"

관찰	해석
account temporarily locked	잠금 발동(방어 동작)
limit reached	임계값 도달
faillock ... --reset	실패 기록 초기화 → 흔적 제거 또는 정상 해제

--reset이 대량 실패 직후에 실행되면 성공적 침입 후 흔적 정리로 의심합니다. 정상 해제는 보통 사용자 요청·업무 시간에 이뤄집니다.

8. SOC 관제 포인트

• faillock 설정(deny·unlock_time)을 기준선에 넣고, 제거·약화(deny 값 과다)를 탐지합니다.
• 잠금 이벤트는 출발지로 공격/실수를 구분하고, 072편 실패 빈도 분석과 연계합니다.
• faillock --reset은 대량 실패와의 시간 관계를 보고 정상/의심을 판단합니다.

9. 탐지 규칙

<group name="local,syssec_b,authentication,">
  <rule id="101120" level="10">
    <match>pam_faillock</match>
    <regex type="pcre2">account temporarily locked|limit reached</regex>
    <description>계정 잠금 발동(인증 실패 임계값 도달)</description>
  </rule>
  <rule id="101121" level="10">
    <if_group>audit</if_group>
    <match>a0="faillock"</match>
    <match>--reset</match>
    <description>faillock 실패 기록 초기화</description>
  </rule>
</group>

잠금 Alert는 정상 사용자의 실수로도 발생하므로, 015편의 잠금 이벤트 분석과 함께 출발지·반복 여부로 우선순위를 조정합니다.

10. 대응 방법

1. 초기 확인 — faillock 설정값과 현재 잠금 현황, reset 실행 이력을 확인합니다.
2. 범위 확인 — 잠금을 유발한 실패의 출발지·대상 계정과 reset의 시간 관계를 확인합니다.
3. 증거 확보 — faillock 설정 사본, 잠금·reset 로그, 실패 기록을 보존합니다.
4. 차단/조치 — 설정을 복원하고, 흔적 제거가 의심되면 해당 계정·출발지를 조사·차단합니다.
5. 재발 방지 — faillock 설정 기준선과 잠금·reset 탐지 룰을 운영합니다.

11. 핵심 정리

설정	의미
deny	잠금까지 허용 실패 횟수
unlock_time	자동 해제 시간(초)
preauth/authfail	인증 전 차단 / 실패 카운트 증가
위험 신호	faillock 제거, deny 과다, 대량 실패 직후 --reset
면접 포인트	"잠금은 brute-force 자동 방어 — 해제·초기화 시점이 핵심"

12. 다음 편 예고

다음 편 065. 계정 · 인증 보안 — faillock 로그 분석과 잠금 이벤트 대응 에서는 잠금 이벤트를 깊게 읽는 faillock 로그 분석과 잠금 이벤트 대응을 다룹니다.

---

이전 편: 063. 계정 · 인증 보안 — PAM 설정 변조 탐지
📚 시리즈 전체 보기: 시스템 보안 · 취약점