049. Linux 서버 보안 — 실전 시나리오 — 하드닝 해제 후 침해 시도 타임라인

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 49/50편 (전체 049/450)
학습 단계: 6단계 · 실전 시나리오
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

• 048. 설정 변경 Alert 정탐·오탐 판단
• 46. Linux 로그 기반 침해사고 타임라인
• 299. IDS Incident 분석

1. 개념

이 편은 가상의 실습 시나리오입니다. 지금까지 각 편에 예시로 등장한 로그(같은 서버 rocky9-web01, 같은 출발지 192.168.56.77, 같은 계정 devops)를 하나의 사건으로 엮어, 관제원이 실제로 작성해야 하는 사고 타임라인을 만들어 봅니다.

[시나리오 개요 — 가상]
대상   : rocky9-web01 (192.168.56.10, 웹 서버)
출발지 : 192.168.56.77 (관리망 아님)
계정   : devops (정상 계정, 담당자 휴가 중 → 탈취 가정)

흐름
 계정 탈취 로그인 → 인증 정책 완화 → 백도어 계정·권한 → 도구 설치·지속성
      → 하드닝 해제 → 관제 차단·은폐 시도 → 재부팅

2. 왜 중요한가

• 실제 사고에서 Alert는 순서 없이, 서로 다른 화면에서 들어옵니다. 이를 시간순·행위자 기준으로 재조립하는 능력이 관제 분석의 핵심입니다.
• 타임라인은 사고 보고서의 뼈대이며, "언제부터 영향을 받았는가(영향 시작점)"와 "무엇을 되돌려야 하는가(조치 범위)"를 결정합니다.
• 각 단계에서 어느 탐지가 먼저 울렸어야 했는가를 돌아보면 룰 개선점이 나옵니다.

3. 핵심 명령어 / 설정

타임라인 작성에 쓰는 로그원과 역할입니다.

로그원	이 시나리오에서 제공한 정보	관련 편
sshd (secure)	로그인 출발지·인증 방식	008·009
audit (audit.log)	파일 변경·실행 명령·세션(auid/ses)	030·038
sudo	권한 사용 명령	006·007
dnf / cron / systemd 로그	도구 설치·지속성 등록	024·026·040
FIM / SCA	변경 사실·상태 전환	021·045
관제 서버	agent disconnected, 수신 공백	029·039

4. 실습 (실습 예시)

실습 예시: 타임라인 재구성 절차

# 1) 원격 수집본에서 대상 호스트·시간 범위 추출 (로컬 로그는 변조 가능성 고려)
#    Kibana: agent.name:"rocky9-web01" and timestamp >= "2026-10-01T02:00" and timestamp <= "2026-10-01T04:00"

# 2) 서버 측에서는 세션 기준으로 보강
sudo ausearch --session 12 -i > /root/ir/ses12.txt
sudo grep -E '192\.168\.56\.77' /var/log/secure > /root/ir/src77.txt

# 3) 모든 사건을 "시각 | 출처 | 행위자 | 이벤트 | 의미" 표로 정렬
sort -k1,1 /root/ir/events.tsv | column -t -s $'\t' | less

시간 보정(032편)이 필요한 서버가 있다면 보정값을 먼저 적용한 뒤 정렬합니다.

5. 정상 상태

같은 서버의 평소 하루는 다음처럼 보입니다(비교 기준).

09:12  sshd   admin1   Accepted publickey from 192.168.56.5
09:13  sudo   admin1   COMMAND=/usr/bin/systemctl status httpd
14:00  dnf    admin1   update (CHG-2026-1002)
05:00  timer  -        hardening-check summary result=PASS

관리망 출발지, 키 인증, 변경관리된 작업, 점검 PASS — 이것이 이 서버의 정상 기준선입니다.

6. 이상 상태

사고 타임라인 (가상, 2026-10-01)

시각      출처        행위자       이벤트                                         단계
02:10:44  sshd/audit  devops       Accepted password from 192.168.56.77, ses=12   초기 접근
02:11:30  sudo        devops       sudo -i (root 셸)                               권한 사용
02:13:00  audit       auid=devops  sshd_config.d/00-tmp.conf 생성 + SIGHUP          인증 정책 완화
02:14:09  secure      auid=devops  useradd -o -u 0 sysbak                            백도어 계정
02:15:40  secure      auid=devops  usermod apache shell → /bin/bash                  서비스 계정 악용 준비
02:16:00  audit       auid=devops  sudoers.d/99-sysupdate (apache NOPASSWD:ALL)      권한 백도어
02:40:15  dnf         devops       install nmap gcc socat                            도구 확보
02:58:09  cron        apache       crontab REPLACE (*/5 /var/tmp/.font-unix/fc)      지속성
03:15:41  journald    auid=devops  Storage=volatile drop-in, journal 재시작            은폐 준비
03:20:05  boot        -            재부팅                                           로컬 로그 소실
03:28:40  audit       auid=devops  /etc/hosts에 wazuh·미러 → 127.0.0.1               관제·패치 차단
03:30:01  audit       auid=devops  setenforce 0                                     하드닝 해제
03:30:20  audit       -            SERVICE_STOP firewalld                           하드닝 해제
03:30:43  audit       -            SERVICE_STOP wazuh-agent                         관제 차단
03:30:45  manager     -            agent disconnected                               (관제 측 마지막 신호)
03:31:05  audit       auid=devops  CONFIG_CHANGE remove_rule res=0                  감사 무력화 시도(실패)

※ 각 줄은 앞선 편들의 예시 로그를 시나리오용으로 재배열한 것입니다. 03:20 재부팅 이후 시각의 일부 이벤트는 감사 규칙이 다시 로드된 뒤 원격으로 전송된 기록을 가정합니다.

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

분석 포인트

질문	답(근거)
최초 침입 시점은?	02:10:44 password 로그인 (키 전용 정책 서버, 비관리망)
행위자는?	모든 변경이 auid=devops, ses=12 → 단일 세션 중심
지속성 수단은?	UID 0 계정, sudoers.d, apache crontab, (023편 피벗 준비 가능성 점검 필요)
은폐 시도는?	journal volatile + 재부팅, hosts로 관제 차단, 에이전트·방화벽 중지, 감사 규칙 삭제 시도
놓친 탐지는?	02:13 password 성공(100160)에서 즉시 대응했다면 이후 단계 차단 가능

IOC(침해 지표) 목록

유형	값
출발지 IP	192.168.56.77
계정	sysbak(UID 0), devops(탈취), apache(셸·sudo·cron 악용)
파일	/etc/ssh/sshd_config.d/00-tmp.conf, /etc/sudoers.d/99-sysupdate, /var/tmp/.font-unix/fc, /dev/shm/.s, /etc/systemd/journald.conf.d/00-perf.conf
설정	/etc/hosts의 wazuh.lab.local·미러 → 127.0.0.1
패키지	nmap, gcc, socat (02:40 설치)

8. SOC 관제 포인트

• Alert 단건 판단을 넘어, 같은 행위자·같은 출발지로 묶는 순간 사고의 전체 그림이 보입니다.
• 은폐 시도(로그 소실·에이전트 중지) 이후 구간은 원격 수집본과 관제 서버 기록으로만 재구성할 수 있습니다.
• 타임라인의 "놓친 탐지" 항목은 그대로 룰 개선 과제가 됩니다.

9. 탐지 규칙

이 시나리오를 기준으로 본 탐지 지점과 개선안입니다.

단계	울렸어야 할 룰	개선
초기 접근	100160 (password 성공), 비관리망 출발지	비관리망 + 관리 계정 로그인 상관 룰 추가(B영역)
정책 완화·백도어	100110, 100360, 100130	같은 세션 3건 이상 시 자동 Incident
지속성	100320, 100321	서비스 계정 crontab은 즉시 High
하드닝 해제	100240, 100440, 100430(상관)	agent disconnected와 결합해 Critical
은폐	100340, 100370, 수신 공백	수신 공백 N분 Alert 운영

# 상관 탐지 개념 (SIEM)
동일 agent + 동일 data.audit.session 에서 30분 내
  rule.groups:"account" ≥1 AND rule.groups:"hardening_drift" ≥1
→ Critical Incident

10. 대응 방법

1. 초기 확인 — 02:10 이후 devops 세션 전체와 출발지 192.168.56.77의 접근 범위를 확정합니다.
2. 범위 확인 — 같은 IOC(IP·계정·파일 해시)로 다른 서버 전체를 조회해 확산 여부를 확인합니다(H영역 내부 확장과 연결).
3. 증거 확보 — 원격 수집본, 서버 디스크·메모리 이미지, IOC 파일 사본을 증거 절차에 따라 확보합니다.
4. 차단/조치 — 서버 네트워크 격리, devops·sysbak·apache 계정 조치, 출발지 차단, 백도어 파일·설정 제거 또는 재구축을 진행합니다.
5. 재발 방지 — 비관리망 관리 계정 로그인 차단, 세션 기반 상관 룰, 수신 공백 감시를 도입합니다.

11. 핵심 정리

구분	핵심 내용
재조립 기준	시각 + 행위자(auid/ses) + 출발지 IP
단계	초기 접근 → 정책 완화 → 백도어 → 지속성 → 하드닝 해제 → 은폐
은폐 후 구간	원격 수집본·관제 서버 기록으로만 재구성
산출물	타임라인 표 · IOC 목록 · 놓친 탐지와 개선안
면접 포인트	"Alert를 행위자 기준으로 묶는 순간 사고의 전체 그림이 보인다"

12. 다음 편 예고

다음 편 050. Linux 서버 보안 — 종합 하드닝 점검 시나리오 — 점검부터 관제 등록까지 에서는 A영역의 마지막으로, 점검부터 관제 등록까지 이어지는 종합 하드닝 점검 시나리오를 정리합니다.

---

이전 편: 048. Linux 서버 보안 — 설정 변경 Alert 정탐·오탐 판단
📚 시리즈 전체 보기: 시스템 보안 · 취약점