시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 38/50편 (전체 038/450)
학습 단계: 3단계 · 이상 징후
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
기준선 diff는 "무엇이 바뀌었는가" 만 알려줍니다. 사고 보고서에는 "누가, 언제, 어디서 접속해, 어떤 명령으로" 바꿨는지가 필요합니다. 이 연결 고리가 auditd의 세 필드입니다.
변경 파일 (기준선 diff)
↓ key / name 으로 검색
audit SYSCALL 이벤트 ── auid (최초 로그인 사용자, sudo 후에도 유지)
── ses (로그인 세션 번호)
↓ 같은 ses 로 검색
USER_LOGIN / USER_START 이벤트 ── addr (출발지 IP), terminal (ssh/pts)
↓
sshd 로그 (Accepted ... from IP) 와 시각 대조 → 인증 방식·키 지문
uid는 sudo 후 0(root)로 바뀌지만 auid와 ses는 로그인 시점 값이 유지됩니다. 그래서 여러 관리자가 sudo를 써도 실제 행위자를 구분할 수 있습니다.
ses)에서 일어난 다른 행위를 함께 꺼내면, 단일 변경이 아니라 공격 흐름 전체가 보입니다.| 명령 | 용도 |
|---|---|
ausearch -k 키 -i --start 시각 --end 시각 | 키·시간 범위 검색 |
ausearch -f /etc/파일 -i | 특정 파일 관련 이벤트 |
ausearch --session 12 -i | 같은 로그인 세션의 모든 이벤트 |
ausearch -ua 1002 -i | 특정 사용자(auid/uid) 이벤트 |
ausearch -m USER_LOGIN,USER_START --session 12 -i | 세션의 로그인 정보(addr) |
aureport -f -i --start today | 파일 접근 요약 |
last -i, lastlog | 로그인 기록(wtmp) 교차 확인 |
# 1) 변경 파일로 시작: sshd drop-in 관련 이벤트
sudo ausearch -f /etc/ssh/sshd_config.d/00-tmp.conf -i | grep -E 'type=SYSCALL' | head -3
# 2) 이벤트의 ses 값으로 같은 세션 전체 추출
SES=12
sudo ausearch --session $SES -i | grep -E 'type=(EXECVE|USER_LOGIN|USER_START|USER_CMD)' | head -20
# 3) 세션의 출발지와 sshd 로그 대조
sudo ausearch -m USER_LOGIN --session $SES -i | grep -oE 'addr=[^ ]+|acct=[^ ]+' | sort -u
sudo grep 'Accepted' /var/log/secure | grep '02:1[0-2]'
auditd 시간 검색은 --start 10/01/2026 02:00:00 처럼 로케일 형식을 따르므로, 형식이 맞지 않으면 --start today, recent(10분)부터 확인합니다.
정상적인 변경이라면 추적 결과가 변경관리 기록과 맞아떨어집니다.
변경: /etc/httpd/conf.d/ssl.conf (2026-10-02 14:02)
auid=admin1 ses=31 addr=192.168.56.5 (관리망) 인증=publickey (SHA256:Qm9...)
같은 세션 행위: dnf install mod_ssl → vi ssl.conf → systemctl restart httpd
변경관리: CHG-2026-1002 (작업자 admin1, 14:00~15:00)
변경: /etc/ssh/sshd_config.d/00-tmp.conf (2026-10-01 02:13)
auid=devops ses=12 addr=192.168.56.77 (관리망 아님) 인증=password
같은 세션 행위: sudo -i → tee 00-tmp.conf → systemctl reload sshd → useradd -o -u 0 sysbak → ...
변경관리: 없음 / devops 계정 담당자는 휴가 중
ses에서 계정 생성까지 이어져 단일 세션이 공격의 중심임을 확인세션 단위 추적의 실제 형태입니다(가상의 예시 로그, ausearch -i 해석 결과).
type=USER_LOGIN msg=audit(10/01/2026 02:10:44.120:690) : pid=5201 uid=root auid=devops ses=12 msg='op=login id=devops exe=/usr/sbin/sshd hostname=? addr=192.168.56.77 terminal=ssh res=success'
type=USER_CMD msg=audit(10/01/2026 02:11:30.008:695) : pid=5260 uid=devops auid=devops ses=12 msg='cwd=/home/devops cmd=-i exe=/usr/bin/sudo terminal=pts/1 res=success'
type=SYSCALL msg=audit(10/01/2026 02:13:00.551:701) : arch=x86_64 syscall=openat success=yes exit=3 auid=devops uid=root ses=12 comm=tee exe=/usr/bin/tee key=sshd_config
type=EXECVE msg=audit(10/01/2026 02:14:09.001:705) : argc=7 a0=useradd a1=-o a2=-u a3=0 a4=-s a5=/bin/bash a6=sysbak
| 필드 | 연결 의미 |
|---|---|
USER_LOGIN addr=192.168.56.77 | 세션 12의 출발지 |
USER_CMD cmd=-i | sudo -i로 root 셸 진입 |
auid=devops uid=root | root로 실행했지만 실제 행위자는 devops |
ses=12 공통 | 네 이벤트가 하나의 세션 |
auid=unset(4294967295) 변경은 로그인 세션이 아닌 데몬 경유이므로 부모 프로세스(웹 서버 등)를 추적합니다.SIEM에서는 같은 세션의 이벤트를 묶어 보는 것이 핵심입니다.
# Kibana(KQL) 예시: 세션 12의 모든 audit 이벤트
agent.name : "rocky9-web01" and data.audit.session : "12"
# 변경 Alert → 같은 auid의 1시간 내 다른 Alert
data.audit.auid : "1002" and rule.groups : "audit"
Wazuh audit 디코더는 audit.auid, audit.session, audit.key 등을 필드로 추출하므로, 대시보드에 세션 단위 보기를 만들어 두면 분석 시간이 크게 줄어듭니다(필드명은 디코더 버전에 따라 wazuh-logtest로 확인).
last) 출력을 보존합니다.| 필드 | 의미 |
|---|---|
| auid | 최초 로그인 사용자(sudo 후에도 유지) |
| ses | 로그인 세션 번호 → 같은 세션 행위 묶기 |
| USER_LOGIN addr | 세션 출발지 IP |
| key | 감사 정책의 목적별 태그 |
| 면접 포인트 | "root가 했다가 아니라 auid·ses로 실제 행위자와 접속 경로까지" |
다음 편 039. Linux 서버 보안 — 하드닝 해제 징후 — SELinux·방화벽·auditd 중지 에서는 침해 직후 자주 나타나는 하드닝 해제 징후(SELinux·방화벽·auditd 중지) 를 종합합니다.
이전 편: 037. Linux 서버 보안 — 설정 드리프트(Drift)와 취약 설정 탐지
📚 시리즈 전체 보기: 시스템 보안 · 취약점