11. PAM 인증 흐름 분석

Linux 시스템 보안 기초 · 11/50편

이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다.

선행 학습

• 10. PAM 구조 이해
• 리눅스 시스템 기초 — SSH 구조 이해

1. 들어가며

구조를 알았으니 이제 흐름을 봅니다. SSH로 비밀번호 로그인할 때 PAM이 어떤 순서로 모듈을 거치는지 따라가면, 로그 한 줄 한 줄이 어느 단계에서 나온 것인지 해석할 수 있습니다.

2. 핵심 개념

SSH 비밀번호 로그인의 PAM 여정은 크게 네 단계입니다.

1. auth: 비밀번호 검증(pam_unix) + 실패 카운트(pam_faillock)
2. account: 계정 만료·유효성 확인(pam_unix, pam_nologin)
3. session 시작: 세션 로그 기록, 자원 제한(pam_limits), 로그인 기록
4. session 종료: 로그아웃 시 정리

각 단계가 성공해야 다음으로 넘어가며, 어느 단계에서 막혔는지에 따라 로그 메시지가 달라집니다.

SSH 클라이언트
     │ password
     ▼
   sshd
     │
     ▼
   PAM
     ├── auth      → 실패: 'Failed password'
     ├── account   → 실패: 'account expired'
     ├── session   → 'session opened for user'
     └── (logout)  → 'session closed'
     │ 모두 성공
     ▼
  로그인 성공: 'Accepted password'

3. 동작 원리

sshd는 인증 방식이 결정되면 PAM에 위임합니다. auth 단계에서 pam_unix가 shadow 해시와 비교하고, 실패하면 pam_faillock이 카운트를 올립니다. auth 통과 후 account 단계에서 만료·nologin 등을 검사하고, 마지막으로 session 단계에서 pam_systemd/pam_loginuid가 로그인 UID(auid) 를 설정합니다.

이 auid 설정이 감사의 핵심입니다. 이후 그 세션에서 실행되는 모든 행위는 이 auid로 추적됩니다(43편). 그래서 정상 로그인 세션과 비로그인 컨텍스트(예: 일부 su, 데몬)는 auid 값으로 구분됩니다.

4. 명령어 실습

# PAM/SSH 관련 인증 이벤트만 추려 흐름 관찰 (Ubuntu)
sudo grep -E 'sshd|pam' /var/log/auth.log | tail -20

# RHEL 계열
# sudo grep -E 'sshd|pam' /var/log/secure | tail -20

# journald로 sshd 유닛 로그만
sudo journalctl -u ssh --since today | tail -20

5. 실행 결과

정상 로그인 성공과 실패의 전형적 로그 흐름입니다. (예시 출력 — 표준 sshd/PAM 로그 형식)

# 실패한 로그인
sshd[2101]: Failed password for alice from 203.0.113.10 port 51512 ssh2
sshd[2101]: pam_unix(sshd:auth): authentication failure; ... rhost=203.0.113.10 user=alice

# 성공한 로그인
sshd[2140]: Accepted password for alice from 192.168.10.5 port 51999 ssh2
sshd[2140]: pam_unix(sshd:session): session opened for user alice(uid=1001) by (uid=0)

pam_unix(sshd:auth)는 auth 단계, pam_unix(sshd:session)은 session 단계 메시지입니다. 괄호 안의 sshd:auth/sshd:session을 보면 어느 PAM 단계에서 나온 로그인지 즉시 알 수 있습니다.

6. 보안 관점 — 정상 사용 vs 악용

• 정상: Accepted 뒤에 session opened가 한 세트로 이어짐.
• 공격 징후:
  • Failed password가 대량으로 이어지다 갑자기 Accepted → 무차별 대입 성공(14편)
  • session opened만 있고 대응하는 정상 auth가 불명확 → 키 인증/우회 여부 확인
  • Invalid user 다수 → 계정 열거(enumeration)

로그 흐름을 '세트'로 읽는 습관이 중요합니다. 실패→성공→세션→명령 실행의 연쇄가 침해 타임라인의 골격입니다.

7. 탐지 방법

• auth 로그의 Failed/Accepted/Invalid user 패턴 집계
• session opened for user 로 실제 성립된 세션 파악
• journald -u ssh로 유닛 단위 상관

8. SOC 관점 — SIEM · Wazuh · IOC

SIEM 파서는 sshd 로그에서 user·rhost·result·port를 필드로 추출합니다. 이 필드들이 있어야 '동일 IP의 실패 N회 후 성공' 같은 상관분석이 가능합니다. Wazuh는 sshd 디코더로 이를 자동 파싱하며, Accepted와 직전 다수 Failed의 결합을 무차별 대입 성공(고위험)으로 분류합니다.

9. 실습 체크리스트

[ ] auth 로그에서 auth/session 단계 메시지 구분
[ ] 성공 로그인의 session opened 확인
[ ] 실패→성공 전환 패턴 관찰
[ ] journalctl -u ssh로 유닛 로그 확인

10. 핵심 정리

• SSH 로그인은 auth→account→session 순으로 PAM을 통과한다.
• session 단계에서 auid가 설정되어 이후 감사의 기준이 된다.
• 로그의 (sshd:auth)/(sshd:session)으로 단계를 식별한다.
• 실패→성공→세션→명령의 연쇄가 침해 타임라인의 골격이다.
• 필드 파싱이 되어야 상관분석·탐지가 가능하다.

11. 다음 편

다음 편에서는 12. SSH 인증 방식 를 다룹니다. 인증 방식 자체를 비교합니다 — 비밀번호 vs 공개키 vs 키보드 인터랙티브.

본 실습은 격리된 테스트 VM(Rocky Linux / Ubuntu, VMware) 및 테스트 계정 환경을 기준으로 하며, 운영 서버를 대상으로 하지 않습니다. 실행 결과는 실제 캡처와 예시 출력을 명확히 구분해 표기합니다.