보안 로그와 사건 연결
Security logging · 보안 로그 분석
보안 로그는 주체가 어떤 자원에 어떤 작업을 시도했고 결과가 무엇인지 남긴 기록이다. 로그의 ··저장 위치가 다를 수 있으므로 출처와 시간 기준을 함께 보존한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 인증·권한 변경· 실패의 전후 관계를 찾는다.
- 요청 ID·세션·부팅 식별자 등으로 서로 다른 기록을 연결한다.
- 탐지와 복구에 필요한 증거를 비밀값 노출 없이 남긴다.
02어떤 순서로 동작하나
- 현상과 시간 정하기
어느 서비스가 언제부터 영향을 받았는지 범위를 정하고 시간대·시계 차이를 확인한다.
- 서비스 기록 조회
unit 로그에서 종료 코드·재시작·실패 원인을 읽고 관련 PID·시각을 연결한다.
- 하위 원인 추적
같은 시점의 커널·저장 장치·인증·감사 기록을 대조하여 I/O timeout 같은 선행 조건을 찾는다.
- 인과와 동시성 구분
장치 지연→앱 정체→종료→재시작의 연결 근거를 확인한다. 가까운 시각의 두 줄만으로 원인을 확정하지 않는다.
- 원본·누락 점검
원본과 수집 지연·중복·회전 상태를 확인하여 보이지 않는 기록이 실제 미발생인지 수집 누락인지 구분한다.
03먼저 알아둘 용어와 구성요소
- 실제 사건이 소스 시스템에서 일어난 시점.
- 수집기가 이벤트를 받은 시점.
- 하나의 요청이나 작업을 여러 구성 요소에서 연결하는 식별자.
- 환경에서 메타데이터와 함께 기록하는 구조화된 이벤트 저장소.
- 필드 추출·변환 이전의 기록으로 해석을 다시 검증하는 근거.
- 수집기 또는 저장소가 자료를 받은 시간.
- 같은 요청·거래의 여러 기록을 연결하는 식별자.
SSH 인증 로그와 서비스 로그를 사건 단위로 묶기
시간··세션 필드를 따라 로그 줄의 의미를 구분하고 원인을 과장하지 않는다.
실습 구성과 전제
- 로그 파일의 읽기 전용 작업 사본을 사용하고 원본 시각·시간대·해시를 기록한다.
- 서로 다른 가 섞인 출력은 화면 순서만으로 한 사건이라고 합치지 않는다.
인증과 세션의 서로 다른 메시지를 나눈다
- Accepted password는 인증 수락, opened는 세션 시작, closed는 세션 종료의 단서다. -logind의 세션 번호와 sshd PID를 연결해 순서를 좁힌다.
- 로그인 성공이 정당한 사용자였다는 의미는 아니다. 허가된 계정·출발지·시간 범위와 함께 조사한다.
원본 크기로 보기 ↗- sshd의 Accepted password·pam_unix session opened/closed와 logind 메시지가 같이 보인다.
- 각 줄에 PID와 Session 번호가 있어 한 화면 안에서도 서로 다른 세션을 분리할 수 있다.
확인 기준출발지 주소만 같다고 다른 PID의 사건을 하나로 합치지 않는다.
서비스 메시지의 주체를 먼저 확인한다
- 질의· 세션· 정리 작업이 섞인 에서는 프로그램 태그를 먼저 읽는다. grep 문자열 하나로 추출한 출력도 다른 프로그램의 줄을 포함할 수 있다.
- Started·Deactivated successfully는 서비스 수명주기 정보다. 그 자체를 침해나 장애로 분류하지 않는다.
shelljournalctl -u sshd --since '2026-06-01 00:00:00' --until '2026-06-02 00:00:00' --no-pager journalctl -u ssh --since today --no-pager배포판에 따라 서비스 이름은 sshd 또는 ssh다. 날짜는 자신의 시험 범위로 바꾼다.
원본 크기로 보기 ↗- named·systemd·phpsessionclean 메시지가 같은 시간축에 섞여 있다.
- 성공적으로 종료된 작업과 DNS 질의를 구분할 수 있다. 서로 인접한 줄이라는 이유만으로 인과관계를 만들면 안 된다.
확인 기준서비스별 시간 범위로 다시 조회해 앞선 오류와 후속 상태를 확인한다.
관찰 사실과 가설을 분리한다
- 보고서에는 '인증 수락 기록이 있다'와 '계정 탈취가 의심된다'를 구분해 쓴다. 후자는 계정 소유자 확인·접근 대상·후속 증거를 더 요구한다.
- 시각이 어긋나면 시간대와 시간 동기화 상태를 먼저 확인하고 원본 로그는 수정하지 않는다.
확인 기준한 문장마다 뒷받침하는 로그와 아직 확인되지 않은 조건을 남긴다.
실습에서 확인한 동작 원리
- 로그의 프로그램·PID·세션이 사건 묶음의 기준이다.
- 성공 메시지는 정상 사용자라는 보증이 아니며 종료 메시지는 공격 증거가 아니다.
로그 묶음에서 인증·정책 로드·패키지 변경을 분리해 타임라인 만들기
일상 관리 이벤트를 침해 흔적으로 오인하지 않으면서 조사 우선순위와 증거 연결을 정한다.
실습 구성과 전제
- 원본 로그를 보존하고 해시를 기록한 작업 사본에서만 분석한다.
- 다음 화면들은 여러 종류의 호스트 기록을 비교하는 자료이며 하나의 침해 사건으로 확정된 연속 증거가 아니다.
인증 기록에서 조사할 세션을 고른다
- 계정·인증 방식·출발지·PID·세션 시각을 표로 옮긴다. 운영자의 승인된 작업 시간과 비교해 확인할 대상을 정한다.
- 인증 성공은 시작점일 뿐이다. 이후 어떤 자원에 접근했는지와 ·파일 변화를 연결해야 범위를 판단할 수 있다.
원본 크기로 보기 ↗- 인증 수락과 세션 시작·종료가 별도 메시지로 나타난다.
- 같은 화면에 여러 PID와 세션이 있어 단일 로그인으로 묶지 않아야 한다.
확인 기준세션별 행을 만들고 추정과 확정 값을 표시한다.
정책 로드와 차단 이벤트를 구분한다
- AppArmor 로그의 profile_load는 보안 프로파일이 로드됐다는 상태 이벤트다. 보안 정책이 등장했다는 이유만으로 악성 행위 차단이라고 판단하지 않는다.
- 차단을 주장하려면 DENIED 등 실제 판단 필드, 대상 경로, 실행 주체를 확인한다.
원본 크기로 보기 ↗- audit type=1400과 apparmor 상태, profile_load 관련 필드가 반복된다.
- 프로파일 이름과 apparmor_parser가 보여 정책 로드 작업임을 조사할 수 있다.
확인 기준상태 변경과 접근 거부를 다른 이벤트 유형으로 분류한다.
패키지 작업과 영향 시점을 대조한다
- Unpacking·Setting up·Processing triggers는 과정의 기록이다. 서비스 장애 시각과 겹치면 변경 작업의 영향 가능성을 조사하되 곧바로 악성 설치라고 쓰지 않는다.
- 패키지 이력·관리자 작업 기록·파일 해시를 연결해 타임라인을 보강하고, 복구 작업이 원본 증거를 덮지 않게 한다.
원본 크기로 보기 ↗- 여러 패키지의 Unpacking과 Setting up 단계가 순서대로 표시된다.
- 버전 정보와 trigger 처리가 있어 변경 작업 범위의 단서가 되지만 시작 원인이나 승인 여부는 화면에 없다.
확인 기준승인 이력과 변경 결과를 확인한 뒤 사건 범위를 확정한다.
실습에서 확인한 동작 원리
- 포렌식은 모든 특이 로그를 악성으로 분류하는 작업이 아니다.
- 이벤트 의미·시각·주체를 분리해야 복구와 증거 보존을 함께 설계할 수 있다.
TCP 수신 설정과 수집된 웹 로그를 한 경로로 읽기
수신 포트, 머리말, 웹 서버의 원래 메시지를 구분하여 전달 실패와 애플리케이션 오류를 가려낸다.
실습 구성과 전제
- 격리 실습망의 송신기와 수신기에서 시간대·호스트 이름·전송 포트를 기록한다.
- 이 실습의 514/ 예시는 평문 수신이다. 를 적용하려면 인증서와 스트림 드라이버 등 별도 설정이 필요하다.
수신 모듈과 소켓이 같은 조건인지 확인하기
- imtcp 모듈은 연결에서 메시지를 받는 입력 모듈이다. 모듈을 불러오는 행과 실제 514번 포트를 여는 input 행이 모두 있어야 의도한 수신 구성이 된다.
- 설정 파일이 존재하는 것, 문법 검사가 통과하는 것, 현재 가 포트를 열고 있는 것은 별개다. 문법 검사 뒤 실제 LISTEN 소켓과 방화벽 경로를 확인한다.
bashrsyslogd -N1 ss -lntp현재 설정의 문법과 수신 소켓을 조회한다. 설정 검사만으로 서비스가 재시작되지는 않는다.
원본 크기로 보기 ↗- module(load="imtcp")와 input(type="imtcp" port="514")가 함께 보인다. 입력 모듈과 수신 포트가 각각 지정되어 있다.
- 이 부분에는 TLS 인증서나 암호화 모드 지정이 보이지 않는다. TCP라는 이유만으로 암호화 전송이라고 할 수 없다.
확인 기준설정 검사 결과와 514/ LISTEN이 일치해야 수신 준비가 됐다고 판단한다.
고유 표식 한 건을 보내 저장 경로를 찾기
- 다른 이벤트와 구별되는 lab-event-001 같은 표식을 보내고, 송신 시각··저장 파일에서 같은 문자열을 찾는다. 재전송 시험에서는 같은 이벤트의 중복 저장 여부도 센다.
- 수신 파일의 머리말 뒤에는 원래 애플리케이션 메시지가 그대로 들어갈 수 있다. 외부 호스트명과 내부 시간 문자열은 서로 다른 필드이므로 하나의 으로 무리하게 합치지 않는다.
bashlogger --tcp --server 127.0.0.1 --port 514 --tag lab-source 'lab-event-001'수신기 자체의 로컬 입력 확인 예. 원격 경로 시험은 자신이 관리하는 수신기 주소로 바꿔 별도로 진행한다.
원본 크기로 보기 ↗- 각 행의 앞에는 Jun 9 시각, localhost, httpd-access가 있고 그 뒤에 대괄호로 감싼 Apache 요청 시각이 다시 나타난다.
- 같은 수집 파일에서 GET 요청의 상태 코드 500과 정적 파일 요청의 304가 함께 보인다. 수집 파일에 기록됐다는 사실과 웹 요청 성공 여부는 별도다.
확인 기준표식이 없으면 송신→포트→ruleset→action→파일 권한 순으로 좁힌다. 웹 500을 전송 실패로 분류하지 않는다.
Severity와 웹 상태 코드의 의미를 분리하기
- severity는 0이 가장 긴급하고 7이 디버그인 메시지 분류다. HTTP 500의 숫자와 같은 척도가 아니며, 전달된 메시지 내용만 보고 severity를 임의로 바꾸면 안 된다.
- 필터가 severity 범위를 제한하면 전달은 됐어도 선택한 저장 action에는 남지 않을 수 있다. 수신 원본과 최종 파일에서 표식을 비교하여 필터에 의한 누락인지 판단한다.
원본 크기로 보기 ↗- 표에는 emerg 0부터 debug 7까지 여덟 단계가 나온다. 숫자가 커질수록 더 긴급해지는 구조가 아니다.
- notice는 5, info는 6으로 별도 행이다. 정상 동작 중에도 주목할 사건과 일반 정보 메시지를 나누어 분류할 수 있다.
확인 기준내용의 HTTP 상태 코드, severity, 최종 저장 action을 각각 기록하면 누락과 애플리케이션 장애를 혼동하지 않는다.
실습에서 확인한 동작 원리
- 연결 성립과 로그 파일 저장 사이에는 입력·필터·action·파일 권한 단계가 있다.
- 머리말과 원래 메시지를 함께 보존하면 전송 경로와 애플리케이션 사건을 나중에 다시 해석할 수 있다.
날짜별 파일과 압축 결과에서 회전 중 수집 위치 추적하기
로그 파일명이 바뀌거나 내용이 잘리는 순간에 경로··읽기 offset이 어떻게 달라지는지 설명하고 누락·중복을 구분한다.
실습 구성과 전제
- 시험용 로그 디렉터리와 고유 번호가 붙은 가상 이벤트를 사용한다. 서비스 운영 로그를 임의로 자르지 않는다.
- 날짜별 웹 로그 화면과 alert_fast 수집 설계는 서로 다른 자료다. 파일 회전의 공통 원리를 비교하며 동일 실행의 전후 사진이라고 가정하지 않는다.
현재 파일명과 수집 상태를 따로 기록하기
- 날짜가 파일명에 들어가면 하루가 바뀔 때 다른 경로가 생길 수 있다. 수집기가 한 경로만 계속 열고 있으면 새 파일을 발견하지 못할 수 있으므로 파일 발견 정책부터 확인한다.
- 파일명을 기억하는 것만으로는 부족하다. 와 읽기 offset을 함께 기록해야 같은 이름으로 새 파일이 생긴 경우와 기존 파일이 자라난 경우를 구별할 수 있다.
bashstat -c '%i %s %n' ./lab.log logrotate -d ./lab-logrotate.conflab.log와 시험 설정을 준비한 뒤 메타데이터와 회전 계획만 확인하는 예. -d는 실제 회전을 수행하지 않는다.
원본 크기로 보기 ↗- web/access 아래에 20260617.log와 20260618.log가 별도 파일로 나열되어 있다. 날짜가 바뀐 파일을 하나의 고정 경로로 볼 수 없다.
- web/error가 access와 분리된 디렉터리로 보인다. 정상 접근 로그와 오류 로그의 수집 대상·규칙도 각각 지정할 필요가 있다.
확인 기준고유 이벤트 번호, , 크기, offset의 기준값을 저장한 뒤 회전 시험을 시작한다.
회전 후 압축 파일과 새 파일의 경계를 찾기
- rename 회전에서는 기존 파일을 열고 있던 수집기가 그 파일의 끝까지 읽고, 새 의 활성 파일로 넘어가야 한다. 작성 도 새 파일을 다시 열 수 있어야 한다.
- copytruncate는 복사 후 같은 파일을 비우므로 가 유지될 수 있다. 복사와 비우기 사이에 추가된 데이터의 손실 가능성이 있고, 파일이 빠르게 다시 자라면 단순 크기 감소 검사만으로 회전을 놓칠 수도 있다.
원본 크기로 보기 ↗- 20260617.log-20260618.gz처럼 원래 날짜와 회전 접미 날짜가 함께 들어간 압축 파일명이 보인다.
- 압축 파일이 존재한다는 것은 보관 결과가 있다는 뜻이다. 그 안에 모든 이벤트가 들어 있는지, 수집기가 읽었는지는 파일명만으로 알 수 없다.
확인 기준회전 직전·직후 이벤트 번호가 활성 파일과 압축 파일 중 어디에 있는지 읽어서 확인한다. copytruncate와 create를 함께 썼다고 새 가 생성되는 것은 아니다.
읽은 번호와 전송 완료 번호를 대조하기
- 파일에서 읽은 이벤트 번호와 중앙 저장소가 확인한 번호를 분리한다. 수집기가 읽은 직후 종료되면 메모리 버퍼에만 있던 이벤트는 아직 저장 성공이 아니다.
- 가상 이벤트 101·102·103을 기준으로 회전 전후와 수집기 재시작을 나누어 시험한다. 원본 파일의 세 번호, 송신 기록의 세 번호, 최종 저장소의 세 번호를 비교해야 손실과 중복을 셀 수 있다.
bashgzip -cd -- ./20260617.log-20260618.gz실습 디렉터리의 압축 보관 내용을 표준 출력으로 읽는 예. 실제 파일명에 맞춰 사용하며 원본을 덮어쓰지 않는다.
확인 기준번호가 빠지면 작성·회전·읽기·전송 중 최초로 사라진 구간을 찾는다. 같은 번호가 둘이면 재전송과 체크포인트 저장 순서를 검사한다.
실습에서 확인한 동작 원리
- 압축 파일 생성은 보관의 증거이며, 수집 완전성의 증거는 이벤트 번호 대조다.
- 파일 회전과 중앙 전송 확인을 별도로 설계해야 재시작 때 누락과 중복을 설명할 수 있다.
동작·명령 참고 문서
SSH 실패 로그에서 Jail 집계와 실제 차단까지
주석 처리된 설정, 실행 중인 Jail 통계, 방화벽 action을 구분하여 차단 동작의 증거를 읽는다.
실습 구성과 전제
- 자신의 격리 SSH 서버에서 관리 접속을 복구할 콘솔과 정상 접속원을 준비한다.
- 그림은 설정 설명과 실행 상태를 비교한 자료다. 보이는 통계를 특정 시험 횟수와 자동으로 같다고 간주하지 않는다.
설정 설명과 활성 Jail을 구분하기
- 설정 행 앞의 #은 주석이다. 예제에 enabled=true라는 글자가 있더라도 주석이면 그 행 자체가 Jail을 활성화하지 않는다.
- 실제로 적용된 값은 .local 덮어쓰기와 다른 설정 파일을 합친 결과다. 배포본 파일의 한 부분만 보는 대신 실행 중인 Jail 목록과 maxretry·findtime·bantime을 조회한다.
bashsudo fail2ban-client status sshd sudo fail2ban-client get sshd maxretry sudo fail2ban-client get sshd findtime sudo fail2ban-client get sshd bantime실행 중인 Jail의 상태와 시간 조건을 조회하는 예. 인증 실패 트래픽을 생성하지 않는다.
원본 크기로 보기 ↗- # [sshd]와 # enabled = true 앞에 주석 기호가 보인다. 이 두 줄만으로 sshd Jail이 켜졌다고 판단할 수 없다.
- 주석 옆에는 enabled와 filter 등의 역할을 설명하는 메모가 있다. 옵션 설명과 현재 유효 설정을 구분해 읽어야 한다.
확인 기준sshd Jail이 목록에 있고 유효 설정이 의도한 값인지 확인한다. 설정 파일 수정 후에는 문법 검사와 해당 Jail 재적용이 필요하다.
로그 일치 건수와 차단 건수를 나누어 읽기
- Filter가 로그에서 뽑아낸 주소별 실패 이벤트를 findtime 범위에서 집계한다. 한 번의 로그인 시도에서 여러 줄이 발생할 수 있으므로 Total failed를 사람이 입력한 비밀번호 횟수와 동일시하지 않는다.
- backend는 journalmatch로 저널 항목을 고른다. 서비스 이름과 프로그램 이름이 실제 로그와 다르면 파일이 존재해도 이 Jail에 이벤트가 들어오지 않을 수 있다.
원본 크기로 보기 ↗- 상태 출력은 Currently failed 1, Total failed 12와 Currently banned 1, Total banned 1을 별도 구역에 표시한다.
- Journal matches에 sshd.service와 sshd·sshd-session 조건이 보인다. 파일 경로 하나를 tail하는 방식과 입력 선택 조건이 다르다.
확인 기준같은 시간대의 인증 로그·Found·Ban 사건을 대응시킨다. 통계가 증가했어도 현재 차단 주소와 시험 주소가 같은지는 별도 확인한다.
action에서 실제 패킷 경로로 내려가기
- action_은 banaction 이름을 참조하고, action_mw는 여기에 메일 보고 동작 등을 묶는다. 템플릿에 적힌 이름만으로 실제 방화벽 백엔드를 iptables라고 고정하면 안 된다.
- 내부의 Ban 상태와 커널의 차단 규칙은 서로 다른 확인 지점이다. 설치 환경의 action과 규칙을 읽고, 시험 접속원의 접근 제한과 정상 접속원의 유지 여부를 함께 검증한다.
bashsudo fail2ban-client get sshd actions sudo journalctl -u fail2ban --since '-10 min' --no-pager선택된 action과 최근 서비스 기록을 조회한다. 운영 주소나 인증 비밀을 결과 보고서에 복사하지 않는다.
원본 크기로 보기 ↗- action_ 정의가 %(banaction)s를 참조하므로 실제 실행할 차단 방식은 치환된 설정에 달려 있다.
- action_mw는 차단 템플릿 다음에 메일 관련 동작을 붙인다. 알림 발송과 패킷 차단이 하나의 성공 조건은 아니다.
확인 기준자동 해제 시간이 지난 뒤 Jail 상태와 방화벽 규칙이 함께 해제되는지도 확인한다. 규칙만 사라졌다면 방화벽 reload와 action 오류를 조사한다.
실습에서 확인한 동작 원리
- 설정 설명→유효 Jail→로그 일치→Ban 상태→방화벽 규칙→접속 결과를 순서대로 연결한다.
- 실패 로그 수, 로그인 시도 수, 고유 주소 수는 서로 다른 지표다.
동작·명령 참고 문서
04예제로 따라가기
- 첫 사건: Boot A에서 monotonic=10초, 표시 시각=10:00:10에 서비스 종료가 기록되었다고 가정한다.
- 다음 사건: 재부팅 뒤 Boot B에서 monotonic=2초, 표시 시각=10:00:30에 서비스 시작이 기록된다.
- 잘못된 정렬: monotonic 숫자만 정렬하면 2초가 10초보다 앞이므로 시작을 종료보다 먼저 놓게 된다. 서로 다른 기준점을 혼합한 오류다.
- 올바른 문맥: Boot ID와 부팅 순서를 먼저 구분하고 각 부팅 안에서 monotonic 값을 비교한다. 전체 시각은 재부팅 기록·실시간 시각을 함께 사용한다.
- 불확실성 표시: 시계가 뒤로 조정된 구간에서는 표시 시각만으로 밀리초 순서를 확정하지 않는다. · 순서·요청 ID를 보조 증거로 남긴다.
05혼동하기 쉬운 점과 확인 기준
- 시간대 누락: 시간대 없는 문자열을 어느 지역 시각으로 파싱했는지 확인한다. 이미 UTC인 값을 다시 변환하면 일정 시간 차이가 생긴다.
- 발생과 수집: 네트워크 지연·큐 적체가 있으면 수집 순서가 발생 순서와 달라진다. 두 시각을 같은 필드에 덮어쓰지 않는다.
- 신원 출처: 로그인 사용자·실효 UID·감사 auid·본문의 계정 문자열이 같은 의미인지 구분한다. 권한 상승 뒤 서로 달라질 수 있다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.