계정 잠금 임계값 점검, 실수하기 쉬운 faillock 설정 5가지

📌 3줄 요약

1. SRV-127은 로그인을 일정 횟수 이상 실패하면 계정을 잠그는 계정 잠금 임계값이 설정되어 있는지 보는 위험도 4.0 항목입니다.

2. 리눅스는 PAM 스택에 pam_faillock이 들어가야 동작합니다. faillock.conf 파일만 고쳐서는 잠기지 않고, 옛 가이드의 pam_tally2는 최신 배포판에서 이미 삭제됐습니다.

3. 윈도우는 계정 잠금 정책의 임계값·잠금 기간·카운터 초기화를 함께 정하고, 기본 Administrator 계정도 잠금 대상에 넣었는지 확인해야 합니다.

혹시 /etc/security/faillock.conf에 deny = 5를 적어 두고 안심하고 계신가요? 그런데 테스트 계정으로 비밀번호를 열 번 틀려도 계정이 멀쩡하다면, 그 설정은 지금 아무 일도 하지 않고 있는 것입니다.

 

계정 보안 3부작의 마지막 편입니다. 1편에서 비밀번호 정책을 걸고, 2편에서 남아 있던 약한 비밀번호를 정리했다면, 이제 남은 일은 비밀번호를 무한히 시도하지 못하게 막는 것입니다.

---

🧭 SRV-127은 무엇을 보는 항목인가

SRV-127은 금융보안원 전자금융기반시설 보안 취약점 평가기준(제2026-1호)의 서버 분야 항목으로, 위험도는 4.0입니다. 주요정보통신기반시설 기준의 U-03(유닉스)·W-04(윈도우) 계정 잠금 임계값 설정에 대응하고, 윈도우는 W-08 계정 잠금 기간 설정과도 연결됩니다. 판정은 계정 잠금 임계값 설정이 존재하는지를 기준으로 합니다.

 

계정 잠금은 세 가지 값이 짝을 이뤄 동작합니다. 리눅스와 윈도우는 이름만 다를 뿐 같은 개념입니다.

개념	리눅스 (faillock.conf)	윈도우 (계정 잠금 정책)
잠금 기준 횟수	deny (기본값 3)	계정 잠금 임계값 (0이면 잠금 안 함)
잠금 유지 시간	unlock_time, 초 단위 (기본값 600, 0이면 관리자 해제 전까지)	계정 잠금 기간, 분 단위 (0이면 관리자 해제 전까지)
실패 집계 구간	fail_interval, 초 단위 (기본값 900)	다음 시간 후 계정 잠금 수를 원래대로 설정 (잠금 기간 이하여야 함)
관리자 계정	even_deny_root (기본은 root 제외)	관리자 계정 잠금 허용

리눅스에서 실제 집계는 PAM의 pam_faillock 모듈이 합니다. 로그인할 때마다 이미 잠겼는지 먼저 확인하고, 비밀번호가 틀리면 횟수를 하나 올리고, 맞으면 기록을 지웁니다. faillock.conf는 이 모듈이 쓸 값을 담아 두는 파일일 뿐입니다.

---

⚠️ 잠금이 없으면, 그리고 너무 세게 걸면

잠금 정책이 없으면 공격자는 자동화 도구로 같은 계정에 비밀번호를 끝없이 넣어 볼 수 있습니다. 1편과 2편에서 비밀번호를 아무리 강하게 만들어도, 시도 횟수에 제한이 없다면 결국 시간 문제가 됩니다.

 

반대로 기준을 너무 낮게 잡거나 자동 해제 없이 걸면 다른 문제가 생깁니다. Microsoft도 공식 문서에서 경고하듯, 공격자가 일부러 틀린 비밀번호를 넣어 여러 계정을 한꺼번에 잠가 버리는 서비스 거부 공격이 가능해집니다. 그래서 잠금은 "횟수는 적당히, 해제는 자동으로, 이상 징후는 로그로" 설계하는 것이 기본입니다.

---

💡 실수하기 쉬운 설정 5가지

함정	흔한 오해	실제 동작	해결
pam_tally2	예전 가이드의 pam_tally2 줄을 복사하면 된다	pam_tally·pam_tally2는 Linux-PAM 1.5.0(2020년)에서 삭제됐다. 없는 모듈을 required로 넣으면 인증 자체가 실패할 수 있다	pam_faillock 사용
설정 파일만	faillock.conf에 deny를 쓰면 잠긴다	PAM 스택에 pam_faillock 줄이 없으면 값이 쓰이지 않는다. Ubuntu는 기본 설정에 이 줄이 없다	PAM 스택에 모듈이 있는지 함께 확인
관리자 예외	root·Administrator도 똑같이 잠긴다	리눅스는 기본적으로 root를 잠그지 않는다. 윈도우 기본 Administrator도 별도 정책을 켜야 잠금 대상이 된다	even_deny_root, 관리자 계정 잠금 허용
SSH 설정	sshd의 MaxAuthTries가 계정 잠금이다	MaxAuthTries는 연결 하나당 시도 횟수(기본 6)일 뿐이다. 다시 접속하면 또 시도할 수 있다	계정 단위 잠금은 faillock으로
낮을수록 안전	임계값은 낮을수록, 잠금은 길수록 좋다	잠금을 악용한 서비스 거부가 쉬워지고, 운영자가 스스로 잠기는 사고도 늘어난다	5회 내외 + 자동 해제 + 로그 모니터링

첫 번째 함정은 특히 조심해야 합니다. 검색해서 나오는 국내 가이드 중에는 아직도 pam_tally2 예시를 그대로 싣고 있는 것이 많습니다. RHEL 9 계열이나 Ubuntu 24.04에서 이 줄을 붙여 넣으면 점검 대응은커녕 관리자 본인이 로그인하지 못하는 상황이 생길 수 있습니다.

 

참고로 잠금 기준값에 정답은 없습니다. 평가기준은 임계값 설정 존재 여부를 보고, 미 국방부 STIG는 3회, Microsoft 보안 기준선은 10회를 권합니다. 이 글에서는 둘 사이의 5회, 10분 자동 해제를 예시로 씁니다. 내부 지침에 정한 값이 있다면 그 값을 따르세요.

---

🛠 조치 방법: RHEL 9·Rocky Linux 9 계열

⚠️ 주의 인증 스택을 바꾸는 작업입니다. root 세션 하나를 끊지 말고 열어 둔 채, 새 터미널에서 테스트 계정으로 확인하세요. 잘못되면 열어 둔 세션에서 바로 되돌립니다.

1단계. 현황 확인과 백업 (root 권한)

# 현재 authselect 프로파일과 켜진 기능 확인
sudo authselect current

# PAM 스택에 pam_faillock이 실제로 들어 있는지
grep -n pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth

# 옛 모듈 흔적이 남아 있지 않은지
grep -rn 'pam_tally' /etc/pam.d/

# 백업
sudo cp -a /etc/pam.d /root/pam.d.bak.$(date +%F)
sudo cp -a /etc/security/faillock.conf /etc/security/faillock.conf.bak.$(date +%F)

2단계. faillock 기능 켜기

# PAM 파일을 직접 고치지 말고 authselect로 켠다
sudo authselect enable-feature with-faillock

# 되돌리기
# sudo authselect disable-feature with-faillock

1편에서 말했듯 RHEL 9 계열의 system-auth·password-auth는 authselect가 만들어 덮어쓰는 파일입니다. 직접 편집하면 다음 authselect 작업 때 사라집니다.

3단계. 잠금 값 설정

# /etc/security/faillock.conf 에 아래 값을 넣거나 주석을 해제
deny = 5
unlock_time = 600
fail_interval = 900
even_deny_root
audit
silent

15분(900초) 안에 5번 틀리면 10분(600초) 동안 잠기고, root도 같은 기준을 받습니다. audit는 존재하지 않는 계정명으로 시도한 기록까지 로그에 남기고, silent는 잠김 상태를 사용자에게 알려 주지 않아 공격자가 잠금 여부를 알기 어렵게 합니다.

💡 팁 실패 기록은 기본적으로 /var/run/faillock에 저장되는데, 이 위치는 보통 재부팅 때 비워집니다. 그래서 잠긴 계정도 재부팅하면 풀립니다. 장애 대응 때 알아 두면 좋은 점이지만, 잠금 이력을 따로 남기려면 로그(/var/log/secure)를 보관해야 합니다.

4단계. 동작 검증과 잠금 해제

# 다른 터미널에서 testuser로 일부러 5번 틀린 뒤, 실패 기록 확인
sudo faillock --user testuser

# 잠금 해제 (관리자)
sudo faillock --user testuser --reset

# 잠금 관련 로그
sudo grep faillock /var/log/secure | tail -n 20

---

🛠 조치 방법: Ubuntu 24.04 LTS

Ubuntu에는 authselect가 없어서 PAM 파일에 직접 줄을 넣어야 합니다. 앞의 주의사항(root 세션 유지, 백업)은 똑같이 지킵니다.

sudo cp -a /etc/pam.d /root/pam.d.bak.$(date +%F)
grep -n '^auth' /etc/pam.d/common-auth

기본 설치 상태의 common-auth가 pam_unix → pam_deny → pam_permit 순서라면, 아래처럼 pam_faillock 세 줄을 더합니다. 핵심은 pam_unix 줄의 [success=1 ...] 숫자입니다. 성공했을 때 바로 다음 한 줄(authfail)만 건너뛰도록 1로 둡니다.

# /etc/pam.d/common-auth (auth 부분)
auth    requisite                      pam_faillock.so preauth
auth    [success=1 default=ignore]     pam_unix.so nullok
auth    [default=die]                  pam_faillock.so authfail
auth    sufficient                     pam_faillock.so authsucc
auth    requisite                      pam_deny.so
auth    required                       pam_permit.so

# /etc/pam.d/common-account 맨 아래에 추가
account required                       pam_faillock.so

faillock.conf 값은 RHEL 계열 3단계와 같이 넣고, 검증과 해제도 같은 명령을 씁니다(로그 위치만 /var/log/auth.log). 기존 common-auth에 다른 모듈(SSSD, 2단계 인증 등)이 섞여 있다면 success 숫자가 달라지므로, 위 예시를 그대로 붙이지 말고 줄 수를 다시 세어 맞추세요.

참고로 기본 설정의 nullok는 빈 비밀번호 로그인을 허용하는 옵션입니다. 2편에서 빈 비밀번호 계정을 모두 정리했다면 이 옵션을 빼는 것도 검토해 볼 만합니다.

---

🛠 조치 방법: 윈도우

Windows Server 2022·2025 기준이며, 관리자 권한으로 진행합니다.

1단계. 현황 확인과 백업

# 잠금 임계값·기간·관찰 창 확인 (로컬 / 도메인)
net accounts
net accounts /domain

# 백업 (1편과 같은 방식)
secedit /export /cfg C:\backup\secpol_before_lockout.inf /areas SECURITYPOLICY

net accounts 결과에서 잠금 임계값이 "안 함(Never)"으로 나오면 취약입니다.

2단계. 계정 잠금 정책 설정

secpol.msc → 계정 정책 → 계정 잠금 정책에서 설정합니다.

정책	예시 값과 설명
잠금 임계값	5회. 0이면 잠금을 하지 않으므로 취약입니다.
잠금 기간	15분. Microsoft 문서도 15분 안팎을 권합니다. 0으로 두면 관리자가 풀어 줄 때까지 잠깁니다.
카운터 초기화	15분. 반드시 잠금 기간 이하로 설정합니다.
관리자 계정 잠금 허용	사용. 기본 Administrator 계정도 잠금 대상에 넣습니다.

'관리자 계정 잠금 허용'은 2022년 10월 누적 업데이트로 추가된 정책입니다. 그 이후 새로 설치한 장비에는 기본으로 켜지지만, 그 전에 설치한 서버에는 켜져 있지 않을 수 있으니 직접 확인하세요.

3단계. 도메인 환경과 잠금 해제

# 도메인 기본 잠금 정책 확인 (ActiveDirectory 모듈)
Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutThreshold, LockoutDuration, LockoutObservationWindow

# 잠긴 도메인 계정 해제
Unlock-ADAccount -Identity user01

# 잠금 이벤트 확인 (도메인 컨트롤러 보안 로그, 이벤트 ID 4740)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20

도메인 계정은 1편과 마찬가지로 GPMC의 Default Domain Policy에서 같은 경로를 설정합니다. 로컬 계정이 잠겼을 때는 lusrmgr.msc의 사용자 속성에서 '계정 잠김' 체크를 해제하면 풀립니다. 되돌릴 때는 1단계에서 내보낸 파일로 secedit /configure를 실행합니다(1편 참고).

---

🎉 정리: 계정 보안 3부작

계정 잠금은 "설정 파일에 숫자를 적는 것"이 아니라 인증 흐름 안에서 실패를 세는 장치가 실제로 돌아가게 하는 것입니다. 리눅스는 PAM 스택에 pam_faillock이 들어가 있는지, 윈도우는 임계값과 관리자 계정 포함 여부를 함께 확인하면 됩니다. 그리고 너무 세게 걸면 잠금 자체가 공격 도구가 될 수 있으니 자동 해제와 로그 확인을 함께 운영하세요.

세 편을 합치면 계정 보안의 흐름이 완성됩니다. 약한 비밀번호를 못 만들게 하고(1편), 이미 있던 약한 비밀번호를 정리하고(2편), 남은 비밀번호를 무작정 두드리지 못하게 막는 것(3편)입니다.

✅ 점검 체크리스트

대상	확인할 것
리눅스	PAM 스택에 pam_faillock(preauth·authfail·account)이 들어 있는가
리눅스	/etc/pam.d에 pam_tally·pam_tally2 흔적이 없는가
리눅스	faillock.conf에 deny·unlock_time이 있고, even_deny_root가 켜져 있는가
윈도우	잠금 임계값이 0이 아니고, 카운터 초기화 시간이 잠금 기간 이하인가
윈도우	관리자 계정 잠금 허용이 켜져 있고, 도메인 정책도 같은 기준인가
공통	테스트 계정으로 실제 잠금과 해제를 확인하고 결과를 증적으로 남겼는가

💬 자주 묻는 질문

Q. SSH 키로 접속하는 계정도 잠기나요?
pam_faillock은 PAM의 비밀번호 인증 흐름에서 실패를 셉니다. 키 인증은 이 흐름을 거치지 않으므로 키 접속 실패는 집계되지 않을 수 있습니다. 키 인증 남용 대응은 접근 IP 제한 같은 다른 항목(SRV-027 등)과 함께 보아야 합니다.

 

Q. root를 잠그면 장애 때 아무도 못 들어가지 않나요?
잠금은 unlock_time이 지나면 자동으로 풀리고, 콘솔 접근이나 다른 관리자 계정의 sudo로도 해제할 수 있습니다. 그래도 걱정된다면 root에는 root_unlock_time으로 더 짧은 해제 시간을 따로 줄 수 있습니다. 운영 절차에 해제 방법을 적어 두는 것이 핵심입니다.

 

Q. 잠금 이벤트는 어떻게 감시하나요?
리눅스는 /var/log/secure(RHEL 계열) 또는 /var/log/auth.log(Ubuntu)의 faillock 메시지를, 윈도우는 보안 로그의 이벤트 ID 4740(계정 잠김)을 관제 시스템으로 보내 알림을 거는 방식이 일반적입니다.

🔗 참고 자료

· faillock.conf(5) 매뉴얼 (deny·unlock_time·even_deny_root 기본값)
· Linux-PAM 릴리스 노트 (1.5.0 pam_tally2 삭제)
· RHEL 9 STIG V-258055 (authselect with-faillock, even_deny_root)
· Ubuntu 24.04 STIG V-270690 (common-auth의 pam_faillock)
· Microsoft Learn: 계정 잠금 기간
· Microsoft Learn: 계정 잠금 임계값 권장값과 서비스 거부 위험
· Microsoft 지원 KB5020282: 기본 관리자 계정 잠금

---

※ 이 글은 공개된 벤더 문서와 공개 가이드를 바탕으로 작성한 일반 가이드이며, 특정 조직과 무관합니다. 계정명은 가상 예시입니다. 금융보안원 평가기준 원문은 배포가 제한된 문서이므로, 원문의 판단 문구와 점검 절차는 싣지 않았습니다. 실제 판정은 각 조직이 적용하는 최신 평가기준을 따르세요.