051. 계정 · 인증 보안 — Linux 사용자 계정 구조와 인증 흐름 전체 지도

Soc pam 계정 · 인증 보안 리눅스 보안관제 시스템 보안 · 취약점 시스템보안 인증흐름

시스템 보안 · 취약점

목록 보기

51/150

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

선행 학습

1. 개념

A영역에서는 서버 설정을 "점검 대상"으로 봤습니다. B영역은 사용자가 실제로 로그인할 때 남는 기록을 중심으로 계정 탈취·권한 상승을 탐지합니다. 그러려면 먼저 로그인 한 번이 어떤 구성 요소를 거치고, 각 단계에서 어떤 로그가 남는지 알아야 합니다.

사용자 (192.168.56.50) ─ ssh devops@server
   ↓
sshd ── 연결 수락, 알고리즘 협상                     → "Connection from ... port"
   ↓
PAM auth     : 비밀번호/키 확인 (pam_unix, pam_faillock) → "Accepted / Failed password", faillock
PAM account  : 계정 유효성(만료·잠금·접근 제어)       → "account expired", "Access denied"
PAM password : (비밀번호 변경 시에만)                  → "password changed"
PAM session  : 세션 생성(limits, systemd-logind)      → "session opened for user devops"
   ↓
NSS  ─ /etc/passwd·shadow·group 조회 (getent)
   ↓
세션 기록 ─ utmp(현재), wtmp(성공 이력), btmp(실패), lastlog(최근 로그인)
   ↓
auditd ─ USER_AUTH, USER_ACCT, CRED_ACQ, USER_LOGIN, USER_START

이 흐름에서 어느 단계에서 실패했는지를 읽을 수 있으면, "비밀번호를 틀린 것"과 "계정이 잠긴 것", "허용되지 않은 계정인 것"을 구분할 수 있습니다.

2. 왜 중요한가

인증 로그는 SOC에서 가장 많이 보는 로그입니다. 같은 "로그인 실패"라도 단계에 따라 의미(무작위 대입, 잠긴 계정 시도, 정책 위반)가 다릅니다.
계정 탈취는 정상 로그인과 로그 형태가 같습니다. 차이는 시간·출발지·인증 방식·이후 행위 같은 맥락에서 드러나므로, 흐름 전체를 알아야 맥락을 읽을 수 있습니다.
B영역 50편은 이 지도 위의 각 지점(파일, PAM, SSH, 로그인 기록, 계정 변경, 권한 상승)을 하나씩 깊게 다룹니다.

3. 핵심 명령어 / 설정

단계	핵심 구성 요소	Rocky 9 로그	Ubuntu 22.04 로그
연결·인증	sshd, pam_unix	`/var/log/secure`	`/var/log/auth.log`
계정 확인	pam_access, pam_faillock, AllowGroups	`/var/log/secure`	`/var/log/auth.log`
세션	pam_systemd, systemd-logind	`secure` + journal	`auth.log` + journal
세션 기록	utmp/wtmp/btmp/lastlog	`last`, `lastb`, `lastlog`	동일
감사	auditd	`/var/log/audit/audit.log`	동일(설치 시)

확인 명령	용도
`cat /etc/pam.d/sshd`	sshd가 사용하는 PAM 스택
`getent passwd devops`	NSS를 통한 계정 조회
`who`, `w`	현재 세션(utmp)
`last -i -n 10`	최근 로그인 성공 이력(wtmp)
`sudo ausearch -m USER_LOGIN -i --start today`	감사 로그의 로그인 이벤트

4. 실습 (실습 예시)

# 1) 테스트 클라이언트에서 정상 로그인 1회, 비밀번호 오류 1회 수행 후 서버에서 확인

# 2) 같은 로그인의 흔적을 로그원별로 모아 보기
sudo grep 'devops' /var/log/secure | tail -6          # Ubuntu: /var/log/auth.log
last -i -n 3 devops
sudo lastb -i -n 3 devops                              # 실패 기록(btmp)
sudo ausearch -m USER_AUTH,USER_LOGIN,USER_START -ua devops -i --start recent | grep -E 'type=' | tail -6

# 3) sshd가 쓰는 PAM 스택 확인
grep -vE '^\s*(#|$)' /etc/pam.d/sshd

5. 정상 상태

Oct  2 09:12:01 rocky9-web01 sshd[11001]: Connection from 192.168.56.5 port 51010 on 192.168.56.10 port 22 rdomain ""
Oct  2 09:12:03 rocky9-web01 sshd[11001]: Accepted publickey for devops from 192.168.56.5 port 51010 ssh2: ED25519 SHA256:Qm9vZ2xlU2VjdXJpdHlLZXlGcm9tTGFi
Oct  2 09:12:03 rocky9-web01 sshd[11001]: pam_unix(sshd:session): session opened for user devops(uid=1002) by devops(uid=0)
$ last -i -n 1 devops
devops   pts/1        192.168.56.5     Fri Oct  2 09:12   still logged in

관리망 출발지, 키 인증, 세션 생성, wtmp 기록이 같은 시각·같은 출발지로 일관된 상태가 정상입니다. (Connection from 줄은 LogLevel VERBOSE일 때 남습니다.)

6. 이상 상태

Oct  2 02:10:41 rocky9-web01 sshd[11201]: Failed password for devops from 192.168.56.77 port 50110 ssh2
Oct  2 02:10:44 rocky9-web01 sshd[11201]: Accepted password for devops from 192.168.56.77 port 50110 ssh2
Oct  2 02:10:44 rocky9-web01 sshd[11201]: pam_unix(sshd:session): session opened for user devops(uid=1002) by devops(uid=0)
$ last -i -n 1 devops
devops   pts/1        192.168.56.77    Fri Oct  2 02:10   still logged in

각 줄은 정상 형식이지만 새벽 시간, 비관리망 출발지, password 인증, 직전 실패 1회가 겹칩니다. 개별 로그가 아니라 흐름과 맥락으로 판단해야 하는 이유입니다(A영역 049편 시나리오의 시작점).

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

같은 로그인을 auditd로 보면 PAM 단계가 이벤트 유형으로 나뉘어 보입니다(가상의 예시 로그, ausearch -i 해석).

type=USER_AUTH  ... : pid=11201 uid=root auid=unset ses=unset msg='op=PAM:authentication grantors=pam_unix acct=devops exe=/usr/sbin/sshd hostname=192.168.56.77 addr=192.168.56.77 terminal=ssh res=success'
type=USER_ACCT  ... : msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct=devops ... res=success'
type=CRED_ACQ   ... : msg='op=PAM:setcred grantors=pam_unix acct=devops ... res=success'
type=USER_LOGIN ... : auid=devops ses=12 msg='op=login id=devops exe=/usr/sbin/sshd addr=192.168.56.77 terminal=ssh res=success'
type=USER_START ... : auid=devops ses=12 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,... acct=devops ... res=success'

이벤트	PAM 단계	분석 포인트
`USER_AUTH`	auth	인증 성공·실패(`res`), 사용 모듈(`grantors`)
`USER_ACCT`	account	계정 유효성 통과 여부
`USER_LOGIN`	로그인 완료	이때부터 `auid`·`ses` 부여 → 이후 모든 행위 추적의 기준
`USER_START`	session	세션 시작

USER_LOGIN에서 부여된 ses=12가 A영역 038편에서 설정 변경을 추적할 때 사용한 바로 그 세션 번호입니다.

8. SOC 관제 포인트

로그인 이벤트를 볼 때는 항상 출발지 · 인증 방식 · 시간 · 직전 실패 · 이후 행위 다섯 가지를 함께 확인합니다.
secure/auth.log(sshd·PAM 메시지)와 audit(USER_*) 두 로그원을 모두 수집하면 한쪽이 지워져도 교차 확인이 가능합니다.
세션 번호(ses)를 기준으로 로그인과 이후 행위를 묶는 것을 B영역 전체의 기본 분석 방식으로 삼습니다.

9. 탐지 규칙

B영역 Wazuh 커스텀 룰은 101000~101999 대역을 사용합니다. 첫 룰은 "비관리망에서의 관리 계정 로그인"입니다.

<group name="local,syssec_b,authentication,">
  <rule id="101000" level="10">
    <if_sid>5715</if_sid>
    <user>^admin1$|^devops$</user>
    <srcip>!192.168.56.0/28</srcip>
    <description>관리 계정의 비관리망 SSH 로그인: $(dstuser) from $(srcip)</description>
  </rule>
</group>

관리 계정 목록과 관리망 대역은 운영 환경에 맞게 CDB 리스트로 관리하는 것이 좋습니다(045편에서 확장).

10. 대응 방법

초기 확인 — 로그인 이벤트의 출발지·인증 방식·시간·직전 실패 여부를 확인합니다.
범위 확인 — 같은 계정·같은 출발지의 다른 서버 로그인과 세션 이후 행위를 확인합니다.
증거 확보 — secure/auth.log, wtmp/btmp, audit 로그를 원격 사본과 함께 보존합니다.
차단/조치 — 탈취가 의심되면 세션 종료·계정 잠금·출발지 차단을 진행합니다.
재발 방지 — 관리 계정·관리망 기준을 정의하고 비관리망 로그인 룰을 운영합니다.

11. 핵심 정리

단계	남는 기록
연결·인증	sshd: Accepted/Failed ..., audit USER_AUTH
계정 확인	pam_account, audit USER_ACCT
세션	session opened, audit USER_LOGIN(ses 부여)·USER_START
세션 기록	utmp(who) · wtmp(last) · btmp(lastb) · lastlog
면접 포인트	"탈취된 로그인은 형식이 정상 — 맥락(출발지·방식·시간·이후 행위)으로 판단"