가상 환경 내 ELK 스택 및 Filebeat 직접 구축 실습, 침입자 사후 추적(디지털 포렌식) 및 로그 복구 실습 매뉴얼 > 네트워크/보안/해킹

분류 1: 가상 환경 내 ELK 스택 및 Filebeat 직접 구축 실습 매뉴얼

 

운영 서버(Ubuntu 22.04 LTS 가정) 환경에 로그 분석 플랫폼을 구축하고 가벼운 로그 전송기인 Filebeat를 연동하는 체계적인 가이드입니다. 테스트 편의를 위해 단일 가상머신 내부 또는 두 대의 가상머신(수집 서버, 운영 서버) 간 통신으로 실습할 수 있습니다. [1, 2]

 

1단계: Elasticsearch 및 Kibana 설치 (수집 서버)[1, 2]

우분투 패키지 저장소에 Elastic 공식 레포지토리를 등록하고 핵심 엔진을 설치합니다. [1]

bash

# 공식 GPG 키 및 레포지토리 등록

wget -qO - https://elastic.co | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://elastic.co stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

 

# 패키지 목록 업데이트 후 설치

sudo apt-get update

sudo apt-get install elasticsearch kibana -y

코드를 사용할 때는 주의가 필요합니다.

설치가 완료되면 화면에 Elasticsearch 초기에 설정된 elastic 계정의 슈퍼유저 비밀번호와 인증 토큰이 출력됩니다. 이 내용을 텍스트 파일에 따로 기록해 두어야 합니다. [1]

 

2단계: Elasticsearch 및 Kibana 환경 설정 및 구동

외부 통신 허용 및 내부 보안 바인딩 설정을 진행합니다.

bash

# Elasticsearch 설정 파일 수정

sudo nano /etc/elasticsearch/elasticsearch.yml

코드를 사용할 때는 주의가 필요합니다.

파일 내부에서 다음 항목을 찾아 수정합니다.

yaml

network.host: 0.0.0.0

http.port: 9200

xpack.security.enabled: true

코드를 사용할 때는 주의가 필요합니다.

bash

# Kibana 설정 파일 수정

sudo nano /etc/kibana/kibana.yml

코드를 사용할 때는 주의가 필요합니다.

파일 내부에서 다음 항목을 찾아 수정합니다.

yaml

server.port: 5601

server.host: "0.0.0.0"

elasticsearch.hosts: ["https://localhost:9200"]

코드를 사용할 때는 주의가 필요합니다.

설정 저장 후 두 서비스를 시스템 백그라운드에 등록하고 작동시킵니다.

bash

sudo systemctl daemon-reload

sudo systemctl enable elasticsearch kibana

sudo systemctl start elasticsearch kibana

코드를 사용할 때는 주의가 필요합니다.

 

3단계: Filebeat 설치 및 운영 서버 로그 수집 연동 (운영 서버)

실제 서비스가 돌아가는 운영 서버(혹은 동일 가상머신)에 가벼운 수집기인 Filebeat를 설치합니다.

bash

# Filebeat 설치 (레포지토리가 등록되어 있다면 바로 설치 가능)

sudo apt-get install filebeat -y

 

# Filebeat 설정 파일 수정

sudo nano /etc/filebeat/filebeat.yml

코드를 사용할 때는 주의가 필요합니다.

설정 파일 내부에서 수집할 로그 경로와 데이터를 던질 목적지(Elasticsearch) 정보를 입력합니다. [1]

yaml

# 1. 입력 세션 (수집할 시스템 로그 지정)

filebeat.inputs:

- type: filestream

  enabled: true

  paths:

    - /var/log/auth.log

    - /var/log/syslog

 

# 2. 출력 세션 (Elasticsearch 서버 주소 및 인증 정보 입력)

output.elasticsearch:

  hosts: ["https://192.168.56.200:9200"] # 수집 서버 IP로 변경

  username: "elastic"

  password: "1단계에서_발급받은_비밀번호"

  ssl.verification_mode: "none" # 실습 환경 사설 인증서 검증 우회

코드를 사용할 때는 주의가 필요합니다.

 

4단계: Filebeat 모듈 활성화 및 서비스 시작

리눅스 시스템 로그 구조를 자동으로 파싱해주는 내장 시스템 모듈을 켜고 구동합니다.

bash

# 시스템 로그 전용 모듈 활성화

sudo filebeat modules enable system

 

# 초기 인덱스 템플릿 강제 셋업 명령

sudo filebeat setup --dashboards

 

# Filebeat 서비스 가동

sudo systemctl enable filebeat

sudo systemctl start filebeat

코드를 사용할 때는 주의가 필요합니다.

이제 웹 브라우저를 열고 http://수집서버IP:5601에 접속하여 elastic 계정으로 로그인한 뒤, Kibana의 Discover 메뉴로 이동하면 실시간으로 운영 서버의 auth.log 데이터가 유입되는 정형화된 차트를 확인할 수 있습니다.

 

 

분류 2: 침입자 사후 추적(디지털 포렌식) 및 로그 복구 실습 매뉴얼

 

공격자가 침입하여 흔적을 지우기 위해 rm -f /var/log/auth.log 등의 명령어로 로그를 의도적으로 파괴했거나 내용을 공백으로 변조했을 때, 디스크 원본 이미지에서 데이터를 안전하게 추출·복구하는 가상 실습 시나리오입니다.

 

1단계: 무결성 유지를 위한 디스크 비파괴 이미징 덤프

분석 대상 시스템의 디스크를 직접 건드리면 파일 시스템 타임스탬프가 변경되어 법적 증거 능력을 상실합니다. 칼리 리눅스 포렌식 모드로 부팅하거나 대상 디스크를 분리해 연결한 후 이미지 파일로 통째로 복제해야 합니다. [1, 2, 3]

bash

# 로컬 디스크(/dev/sdb라 가정)를 raw 포맷 이미지 파일로 무결하게 복제

sudo dd if=/dev/sdb of=/var/tmp/suspect_disk.dd bs=4M status=progress

 

# 복제 완료 후 원본 훼손 방지를 위해 이미지 파일을 '읽기 전용'으로 권한 변경

chmod 444 /var/tmp/suspect_disk.dd

 

# 이미지 파일의 무결성 검증용 해시값 생성 및 기록

sha256sum /var/tmp/suspect_disk.dd > /var/tmp/evidence_hash.txt

코드를 사용할 때는 주의가 필요합니다.

 

2단계: Sleuth Kit (TSK) 명령어를 이용한 메타데이터 및 삭제 파일 분석

파일 시스템 내부 구조를 파악하여 지워진 파일의 Inode 번호를 추적합니다.

bash

# 1. 디스크 이미지 내부에 존재하는 파티션 레이아웃 및 시작 섹터(Offset) 확인

mmls /var/tmp/suspect_disk.dd

 

# 출력 결과 중 Linux 파티션의 시작 섹터 번호가 2048이라고 가정합니다.

 

# 2. 해당 파티션 내에서 삭제된 파일(-d 옵션) 및 전체 디렉터리 구조를 추적

# -o 2048: 섹터 오프셋 지정

fls -r -d -o 2048 /var/tmp/suspect_disk.dd | grep -i "auth.log"

코드를 사용할 때는 주의가 필요합니다.

명령어 수행 시 화면에 아래와 같은 메타데이터 결과가 도출됩니다.
d/d * 123456: /var/log/auth.log
여기서 * 표시는 삭제된 파일을 뜻하며, 바로 뒤의 123456이 파일 시스템 내부 고유 주소인 Inode 번호입니다.

bash

# 3. 확보한 Inode 번호(123456)를 이용하여 삭제된 로그 데이터 섹션을 강제 추출

icat -o 2048 /var/tmp/suspect_disk.dd 123456 > /var/tmp/recovered_auth.log

코드를 사용할 때는 주의가 필요합니다.

 

3단계: Foremost / Scalpel을 활용한 파일 카빙 복구 (비할당 영역 스캔)

만약 공격자가 메타데이터 구조마저 완전히 초기화하여 fls 명령어로 파일명을 찾을 수 없는 극단적인 상황이라면, 디스크의 비할당 영역(Unallocated Space) 전체에서 텍스트 스트링 패턴을 긁어모으는 파일 카빙 방식을 수행해야 합니다.

Bash

# Foremost 도구를 사용하여 이미지 내에서 텍스트(txt/log) 패턴 파일만 추출

# -t: 확장자 지정, -i: 입력 이미지, -o: 출력 폴더

sudo foremost -t txt -I /var/tmp/suspect_disk.dd -o /var/tmp/foremost_output

 

# 결과 분석

ls -l /var/tmp/foremost_output/txt/

코드를 사용할 때는 주의가 필요합니다.

추출된 폴더 내부의 텍스트 파일들을 하나씩 열어보면 파일 시스템 구조와 상관없이 과거 디스크 데이터 블록에 남아있던 Failed password나 Accepted 같은 실제 보안 로그 문장 파편들이 복구된 것을 확인할 수 있습니다.

 

4단계: Volatility를 이용한 휘발성 메모리(RAM) 침해 사고 흔적 분석

침입자가 디스크 로그를 파괴했더라도 분석 당시 시스템이 켜져 있었다면 덤프해둔 RAM 메모리 파일(memory.raw) 내부에 파괴 전 로그 문자열과 백도어 프로세스가 고스란히 상주해 있습니다.

bash

# 1. 윈도우 또는 리눅스 메모리 덤프 파일의 기본 OS 정보 분석 파악

python3 vol.py -f /var/tmp/memory.raw windows.info

 

# 2. 공격자가 실행한 뒤 숨겨두었거나 은폐를 시도한 악성 프로세스 트리 확인

python3 vol.py -f /var/tmp/memory.raw windows.pstree

 

# 3. 로그 삭제 명령을 내렸던 당시의 터미널(CMD/Bash) 실행 명령어 라인 전수 복구

python3 vol.py -f /var/tmp/memory.raw windows.cmdline

코드를 사용할 때는 주의가 필요합니다.

출력되는 결과물에서 공격자가 로그 파일 파괴를 위해 실행한 cmd.exe /c del /f /q ... 형태의 실제 타임라인 명령 흔적을 확보하여 보고서에 기재하고 후속 법적 조치 단계로 넘어가게 됩니다.