[Network] ELK Stack (Elastic Stack)

오늘 포스팅은 ELK Stack에 대해 살펴보겠습니다

저번에 https://poiri3r.tistory.com/149

[Network] SIEM & Wazuh 설치 실습

SIEM과 Wazuh에 대해 다루면서 간단하게 다뤘었는데, 이번엔 조금 더 깊게 살펴보겠습니다.

SIEM은 SIM과 SEM으로 나뉩니다. SIM은 로그 저장 + 검색 + 분석이고, SEM은 실시간 이벤트 분석 + 알림 + 대응까지 포함합니다.

그 중 ELK Stack은 SIM에 해당이 됩니다.

사진 출처 : https://suyeon96.tistory.com/38

ELK는 Elasticsearch, Logstash, Kibana라는 3가지 툴의 앞글자를 딴 SIM 솔루션입니다.

 

2015년 부터는 Beats라는 도구가 추가로 들어와서 Elastic Stack이라고 부릅니다.

사진 출처 : https://accordions.co.kr/accordion_tip/accordion-elk/

이 elasticsearch, logstash, kibana, beats에 대해 각각 살펴보겠습니다.

 

elasticsearch

elasticsearch는 Apache Lucene 라이브러리 기반의 오픈소스 검색 및 분석 엔진입니다.

원래 보안목적으로 사용되는 툴인줄 알았는데, 그런 건 아니고 그냥 텍스트 검색에 특화된 엔진입니다.

로그는 전부 텍스트로 적혀져 있기 때문에 elastic이 효율적입니다.

 

DB와 비슷하게 일반 데이터를 저장하지만, 검색 기능에 특화되어 있기 때문에, 로그를 저장한 뒤 검색 (ex: 특정 IP가 몇 번 접속했는지, 에러가 시간대별로 얼마나 발생했는지)이 아주 빠릅니다. 

 

https://frozenpond.tistory.com/208

[elastic search] 엘라스틱 서치란(elastic search, kibana 사용법)

elasticsearch는 역색인(inverted index)이라는 어떤 단어가 어디에 있는지 미리 정리해두는 방식을 사용하기에 속도가 아주 빠릅니다. 역색인이라는 구조가 조금 낯선데 다음과 같은 예시를 보겠습니다.

문서 1: I love apple
문서 2: apple is red

여기서 apple이라는 단어를 찾으려면 문서들을 뒤져가면서 apple과의 일치를 찾아야합니다.

하지만 자원을 조금 더 쓰더라도, 데이터를 저장할 때

apple -> [문서 1, 문서 2]
love -> [문서 1]
red -> [문서 2]

와 같이 미리 저장을 해둠으로 검색 속도를 높입니다.

 

또 HTTP Restful api를 사용하기에 사용이 어렵지 않습니다

 

또한 분산 구조가 존재해서, 데이터를 여러 노드에 나눠서 저장하는데 이를 sharding이라고 합니다.

자세한 사용법은 위에 블로그에 잘 나와있으니 읽어보면 좋을 것 같네요.

logstash

logstash는 데이터를 받아서 가공한 뒤 Elasticsearch로 보내는 도구입니다.

크게 어려운건 아닌데 data source(파일, syslog, Beats etc. . )로부터 Input을 받아 Filter -> Output -> Elasticsearch로 보내는 구조입니다.

 

그렇게 어렵진 않아서, 예시를 살펴보면 

192.168.0.10 - - [30/Apr/2026:10:00:00 +0900] "GET /login HTTP/1.1" 200

다음과 같이 로그가 찍힌다고 생각해보겠습니다.

logstash는 이 로그를 받아서 elasticsearch가 이해하기 좋은 JSON형식으로 보냅니다.

{
  "client_ip": "192.168.0.10",
  "method": "GET",
  "url": "/login",
  "status": 200
}

이러면 elasticsearch에서는 client_ip,와 같은 제목을 뗀 뒤 192.168.0.10 같은 값만 떼서 역색인 과정을 거쳐서 저장을 할것입니다.

즉, logstash는 ELK에서 로그 수집 + 파싱 + 정규화 + 전달의 역할을 한다고 살펴보시면 될 것 같습니다.

다만 logstash는 Java 기반이라 메모리를 많이 드는 장점이 있어서, Beats에게 어느정도 역할을 넘겨준 추세입니다.

출처 : https://www.elastic.co/kr/webinars/getting-started-logstash?baymax=rtp&elektra=docs&storm=top-video&iesrc=ctr

그에 반해 beats는 go언어 기반이라 경량화가 잘 되어있고, 로그 수집에서 훨씬 빠르기 때문에, beats를 사용하고 beats에서 logstash로 보내서 logstash는 데이터를 json으로 정규화만 해서 Elasticsearch에 보내는 방식으로 자주 사용됩니다.

(dataflow 엔진으로써의 서버 역할)

단순한 로그(이미 JSON형식)는 beats에서 바로 Elasticsearch로 보내기도합니다.

 

Kibana

Kibana는 Elasticsearch에 저장된 데이터를 사람이 보기 좋게 보여주는 오픈소스 데이터 시각화 및 분석 플랫폼입니다.

사용자는 Kibana에서 로그를 검색하고, 필터를 걸고, 차트를 만들고, 대시보드를 구성할 수 있습니다.

Beats

beats는 경량 데이터 수집기로, 다양한 시스템과 서비스에서 데이터를 수집하여, Elasticsearch나 Logstash로 전송하는 역할을 수행합니다.

Wazuh에 비교해서 설명을 하면 Wazuh는 통합서버에 manager를 설치하고, 각 서버에 wazuh agent를 설치했지만 ELK 스택을 구성할경우 beats가 agent역할로 각 서버에서 로그를 수집해서 통합서버인 Elasticsearch로 보내는 역할입니다.

아까 설명했듯 go 언어 기반의 아주 빠른 경량툴이기 때문에 장점이 있습니다

 

beats는 제일 많이 쓰는 filebeats 외에도 엄청 다양한 종류가 있는데, 주로 filebeats를 사용합니다.

출처 : https://hyem207.tistory.com/71

filebeat.yml 설정 파일을 수정해서, 읽어올 파일들과 나가는 경로를 설정할 수 있습니다.

 

전체적인 구조를 보면

각 서버 (agent)에서 beats가 중앙 서버로 로그를 보내면 중앙서버에서는 log4stsh, elasticsearch, kibana로 파싱/저장/대시보드에 띄워서 관제하는 형식입니다.

해당 ELK stack은 보안 탐지 기능이 많이 부족합니다. 따라서 이 위에 보안 탐지 로직을 추가로 붙인게 Wazuh입니다.

Wazuh가 내부적으로 ELK를 사용합니다. wazuh dashboard도 kibana 기반입니다.

 

일단 이렇게 해서 ELK stack 에 대한 포스팅을 마치겠습니다.

생각보다 엄청 유익한 공부가 된 것 같네요.

읽어주셔서 감사합니다!