058. 계정 · 인증 보안 — su 사용 로그와 권한 전환 추적

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

선행 학습

• 057. 계정 · 인증 보안 — sudo 사용 로그 분석 심화
• 008. Linux 서버 보안 — root 로그인 제한

1. 개념

su는 현재 세션에서 다른 사용자로 전환하는 명령입니다. sudo가 "한 명령만 권한을 빌리는" 방식이라면, su는 "그 사용자로 셸을 여는" 방식에 가깝습니다.

su user      : 환경변수 일부 유지, 대상 사용자로 전환
su - user    : 로그인 셸(대상 사용자의 환경·홈·PATH 전체 적용) → 흔적이 더 깨끗
su           : (대상 생략) root로 전환

로그 흐름
 성공:  su: pam_unix(su-l:session): session opened for user <대상>(uid=X) by <원래>(uid=Y)
 실패:  su: FAILED SU (to <대상>) <원래> on pts/N
 auditd: USER_AUTH(su) → USER_START/USER_END, auid=원래 사용자 유지

핵심은 su로 전환해도 auid(최초 로그인 사용자)는 바뀌지 않는다는 점입니다. 전환 후 한 행위도 원래 사용자로 추적됩니다.

2. 왜 중요한가

• su는 대상 계정의 비밀번호를 알아야 하므로, FAILED SU 반복은 비밀번호 추측 시도를 의미합니다.
• 공격자는 sudo 로그를 피하려고 su로 root 셸을 열기도 합니다. A영역 008편의 pam_wheel 제한이 없으면 일반 계정이 su를 자유롭게 쓸 수 있습니다.
• 서비스 계정으로의 su(su - apache)는 정상 운영에서 드물어, 그 자체로 확인 대상입니다.

3. 핵심 명령어 / 설정

확인	명령
su 성공 세션	sudo grep 'session opened' /var/log/secure | grep 'su-l|su:'
su 실패	sudo grep 'FAILED SU' /var/log/secure
pam_wheel 제한 여부	grep pam_wheel /etc/pam.d/su
audit로 원래 사용자 추적	sudo ausearch -m USER_START -i | grep 'su'
세션 짝 맞추기	session opened ↔ session closed(같은 PID)

4. 실습 (실습 예시)

LOG=/var/log/secure        # Ubuntu: /var/log/auth.log
# 1) su 성공: 누가 누구로 전환했나
sudo grep -E 'su(-l)?:session\): session opened' $LOG | sed -E 's/.*opened for user ([^ ]+).* by ([^ ]+).*/전환: \2 -> \1/' | sort | uniq -c

# 2) su 실패: 대상·원래 사용자·터미널
sudo grep 'FAILED SU' $LOG | tail

# 3) 서비스 계정으로의 su만 추출
sudo grep 'session opened for user' $LOG | grep -E 'user (apache|nginx|www-data|mysql|postgres)\('

# 4) 원래 사용자 추적 (audit): su로 연 세션의 auid
sudo ausearch -c su -i --start today 2>/dev/null | grep -E 'type=USER_START' | tail

5. 정상 상태

      8 전환: admin1 -> root
      2 전환: admin1 -> postgres
$ sudo grep 'FAILED SU' $LOG
$ grep pam_wheel /etc/pam.d/su
auth		required	pam_wheel.so use_uid

관리자만 su를 쓰고, 실패 기록이 없으며, pam_wheel로 su 사용이 제한된 상태가 정상입니다.

6. 이상 상태

      1 전환: devops -> root
      5 전환: devops -> postgres
$ sudo grep 'FAILED SU' $LOG
Oct  2 02:40:11 rocky9-web01 su[11901]: FAILED SU (to postgres) devops on pts/1
Oct  2 02:40:19 rocky9-web01 su[11903]: FAILED SU (to postgres) devops on pts/1

• devops가 postgres로 전환 시도 중 실패 2회 후 성공 → 비밀번호 추측 끝에 DB 계정 획득
• 이어서 root로도 전환 → 하나의 세션에서 여러 계정으로 수평·수직 이동
• pam_wheel 제한이 있었다면 devops의 su 자체가 차단됐을 수 있음(A영역 008편과 연결)

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

su 전환 체인을 auid로 추적한 예시입니다(가상의 예시 로그).

Oct  2 02:40:25 rocky9-web01 su[11905]: pam_unix(su-l:session): session opened for user postgres(uid=26) by devops(uid=1002)
type=USER_START msg=audit(1759340425.100:3701): auid=devops ses=12 msg='op=PAM:session_open acct=postgres exe=/usr/bin/su terminal=pts/1 res=success'
Oct  2 02:45:40 rocky9-web01 su[11950]: pam_unix(su-l:session): session opened for user root(uid=0) by devops(uid=1002)
type=USER_START msg=audit(1759340740.220:3712): auid=devops ses=12 msg='op=PAM:session_open acct=root exe=/usr/bin/su terminal=pts/1 res=success'

관찰	해석
by devops(uid=1002)	전환을 수행한 원래 계정
auid=devops ses=12 동일	전환해도 auid·세션 유지 → 한 사람의 연속 행위
postgres → root 순서	서비스 계정 경유 후 root 상승

auid가 유지되므로, postgres·root로 전환한 뒤 실행한 명령도 모두 ausearch --session 12로 devops에게 귀속해 재구성할 수 있습니다.

8. SOC 관제 포인트

• FAILED SU 반복(특히 서비스·root 대상)은 비밀번호 추측으로 보고 빈도를 집계합니다.
• 서비스 계정으로의 su 성공은 단건이라도 확인합니다.
• su 전환 체인은 auid 기준으로 묶어 원래 행위자와 이동 경로를 함께 봅니다.

9. 탐지 규칙

<group name="local,syssec_b,privilege,">
  <rule id="101070" level="10" frequency="4" timeframe="120">
    <if_matched_sid>5303</if_matched_sid>
    <same_srcuser />
    <description>동일 사용자의 su 실패 반복(비밀번호 추측)</description>
  </rule>
  <rule id="101071" level="11">
    <decoded_as>su</decoded_as>
    <match>session opened for user</match>
    <regex type="pcre2">user (apache|nginx|www-data|mysql|postgres)\(</regex>
    <description>서비스 계정으로의 su 성공</description>
  </rule>
</group>

5303은 Wazuh의 su 실패(FAILED SU) 계열 기본 룰입니다. 실제 ID·필드는 wazuh-logtest로 확인한 뒤 if_matched_sid와 same_srcuser 동작을 검증합니다.

10. 대응 방법

1. 초기 확인 — su 전환 체인(원래 사용자 → 대상 계정들)과 실패 횟수를 확인합니다.
2. 범위 확인 — 전환 후 각 계정으로 실행한 명령을 auid·세션 기준으로 재구성합니다.
3. 증거 확보 — su 성공·실패 로그, audit USER_START, 세션 명령 기록을 보존합니다.
4. 차단/조치 — 비인가 전환이면 세션 종료·관련 계정 비밀번호 교체·su 제한(pam_wheel)을 적용합니다.
5. 재발 방지 — su 사용 기준선과 실패 반복·서비스 계정 su 룰을 운영합니다.

11. 핵심 정리

구분	핵심 내용
su vs su -	환경 일부 유지 vs 로그인 셸 전체 적용
성공·실패 로그	session opened for user ... by ... / FAILED SU
auid	전환해도 유지 → 원래 사용자로 추적
위험 신호	FAILED SU 반복, 서비스 계정 su, su 체인(서비스→root)
면접 포인트	"su로 바꿔도 auid는 그대로 — 전환 후 행위도 원래 사람에게 귀속"

12. 다음 편 예고

다음 편 059. 계정 · 인증 보안 — 비밀번호 정책 — pwquality 복잡도 설정 에서는 비밀번호 자체를 강하게 만드는 pwquality 복잡도 정책을 점검합니다.

---

이전 편: 057. 계정 · 인증 보안 — sudo 사용 로그 분석 심화
📚 시리즈 전체 보기: 시스템 보안 · 취약점