[보안] Suricata IDS/IPS 6개월 운영 회고: 오탐 줄이고 위협 탐지율 높이기

홈랩과 소규모 운영망에서 Suricata IDS/IPS를 6개월 정도 굴려보면, 처음 기대했던 그림과 실제 운영 감각이 꽤 다르다는 걸 느끼게 됩니다. 처음엔 “오픈소스 보안 도구 하나 올리면 네트워크 보안이 한 단계 올라가겠지” 싶었거든요. 그런데 막상 붙여보니 알림은 많은데 중요한 이벤트가 묻히고, 정상 트래픽까지 의심해서 마음이 불편해지는 순간이 꼭 옵니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 핵심은 엔진 자체보다 룰 관리, 네트워크 맥락 이해, 로그 검증 습관이더라고요.

이번 글은 제가 직접 해보면서 겪었던 시행착오를 정리한 회고입니다. 단순 설치기가 아니라, Suricata IDS/IPS를 실제로 6개월 운영하면서 어떻게 오탐(false positive, 정상인데 경고가 나는 경우)을 줄였는지, 그리고 위협 탐지율을 높이기 위해 어떤 기준으로 튜닝했는지 차근차근 풀어보겠습니다. 혹시 알림이 너무 많아서 결국 대시보드를 안 열게 되는 단계까지 가보신 적 있으신가요? 그 상태가 딱 개선 포인트입니다.

Suricata가 스위치 미러링 또는 인라인 구간에서 트래픽을 분석하는 전체 구조를 보여주는 개요 이미지입니다.

Suricata IDS/IPS, 쉽게 말해 뭐가 다른가요?

쉽게 말해 IDS(Intrusion Detection System, 침입 탐지 시스템)는 “수상한 걸 찾아서 알려주는 역할”이고, IPS(Intrusion Prevention System, 침입 방지 시스템)는 “수상한 걸 찾아서 막는 역할”입니다. 같은 엔진을 쓰더라도 어느 위치에 두고 어떤 정책으로 동작시키느냐에 따라 체감이 꽤 달라집니다.

Suricata는 패킷(packet, 네트워크를 오가는 데이터 조각)을 보고 시그니처(signature, 알려진 패턴) 기반으로 탐지할 수 있고, 프로토콜 단위로 로그를 꽤 잘 뽑아줍니다. 실제로 써보니까 단순히 “악성 트래픽 잡는 도구”라기보다, 내 네트워크에서 평소 어떤 통신이 오가는지 이해하게 만들어주는 관찰 장비에 더 가깝더라고요. 이 관점이 생기니 운영이 훨씬 편해지더라고요.

제가 6개월 운영하면서 내린 결론은 단순했습니다. 처음부터 IPS로 크게 가면 삽질합니다 ㅎㅎ 먼저 IDS로 충분히 관찰하고, 자주 보이는 정상 패턴을 이해한 뒤 일부 룰만 선별적으로 차단하는 쪽이 훨씬 안정적이었습니다.

6개월 운영하면서 느낀 핵심: 규칙보다 맥락이 먼저다

처음에는 Emerging Threats 계열 룰셋을 넣고 경고가 많이 뜨는 걸 보면서 “오, 잘 잡히네”라고 생각했었습니다. 근데 여기서 함정이 있습니다. 경고가 많다고 탐지가 잘 되는 게 아니거든요. 오히려 운영자는 금방 피로해집니다. 제가 초반에 가장 많이 한 실수가 모든 경고를 동일한 중요도로 본 것입니다.

실제로 중요한 포인트는 아래 네 가지였습니다.

• 자산 분류: 서버, NAS, 개발 장비, IoT, 테스트 VM을 구분해야 합니다.
• 트래픽 방향: Ingress(인그레스, 외부에서 내부로 들어오는 트래픽)와 Egress(이그레스, 내부에서 외부로 나가는 트래픽)를 분리해서 봐야 합니다.
• 기준선 파악: 평소 정상 통신이 뭔지 알아야 이상 징후가 보입니다.
• 차단 범위 절제: 처음부터 광범위 차단보다 고신뢰 규칙만 선별 적용해야 합니다.

예를 들어 백업 서버가 새벽마다 외부 저장소와 대용량 TLS 통신을 하는데, 그걸 평소 패턴으로 인지하지 못하면 이상 트래픽처럼 보일 수 있습니다. 반대로 평소 조용한 관리망에서 갑자기 특정 호스트가 다수의 외부 목적지로 연결을 시도하면, 그건 규칙 경고가 약하더라도 직접 확인해볼 가치가 높습니다. 이게 운영의 감각 차이더라고요.

실전 구현: Suricata를 6개월 안정적으로 운영하는 구성

이제 제가 실제로 정착시킨 흐름을 정리해보겠습니다. 배포 환경마다 패키지명이나 경로는 조금 다를 수 있으니, 아래 예시는 운영 개념과 설정 방향 위주로 보시면 됩니다. 저는 처음부터 복잡하게 가지 않고, 미러 트래픽을 보는 IDS 성격으로 시작한 뒤 검증된 일부 정책만 IPS에 가까운 운영으로 확장했습니다.

1. 트래픽 위치 선정: 코어 스위치 미러 포트나 경계 구간처럼 관찰 가치가 높은 위치를 먼저 잡습니다.
2. HOME_NET 정의: 보호 대상 대역을 명확히 지정합니다.
3. 규칙셋 최소화: 다 넣지 말고 필요한 범주부터 켭니다.
4. EVE 로그 정리: JSON 로그를 검색 가능한 형태로 적재합니다.
5. 오탐 라벨링: 반복되는 정상 이벤트를 분류합니다.
6. 선별 차단: 충분히 검증된 규칙만 차단 동작에 연결합니다.

1. 기본 설정에서 가장 먼저 볼 항목

여기서 중요한 포인트! 설치보다 suricata.yaml의 네트워크 범위와 출력 로그가 더 중요합니다. 저도 처음엔 기본값으로 돌렸었는데, 로그는 쌓여도 운영에 쓸 만한 정보가 정리되지 않더라고요.

vars:
  address-groups:
    HOME_NET: "[192.168.10.0/24,192.168.20.0/24,10.10.0.0/16]"
    EXTERNAL_NET: "!$HOME_NET"

default-rule-path: /etc/suricata/rules

rule-files:
  - suricata.rules
  - local.rules

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert
        - http
        - dns
        - tls
        - flow
        - ssh

HOME_NET을 제대로 잡아두면 해석이 쉬워집니다. 어떤 경고가 내부 자산 보호와 직접 연결되는지 판단이 빨라지거든요. 그리고 EVE JSON 로그는 나중에 검색, 집계, 시각화할 때 정말 편합니다. 이건 진짜 편하더라고요.

2. 로컬 예외 규칙과 임계치(threshold) 조정

오탐을 줄이는 데 가장 효과가 컸던 건 거창한 차단 정책이 아니라, 예외 처리와 빈도 제한이었습니다. 같은 이벤트가 짧은 시간에 수십 번 반복되면 운영자가 무뎌집니다. 그래서 반복성 높은 이벤트는 threshold를 걸고, 정상으로 검증된 내부 서비스는 suppress 또는 pass 정책을 검토했습니다.

sudo suricata -T -c /etc/suricata/suricata.yaml -v
sudo systemctl restart suricata
sudo tail -f /var/log/suricata/eve.json

threshold:
  - gen_id: 1
    sig_id: 1000001
    type: threshold
    track: by_src
    count: 5
    seconds: 60

다만 여기서 조심해야 합니다. 무턱대고 억제하면 진짜 신호까지 가려집니다. 저는 반복되는 경고를 바로 끄지 않고, 최소 며칠은 패턴을 관찰했습니다. 특히 내부 스캐너, 취약점 점검 도구, 백업 에이전트, 모니터링 시스템은 보안 장비 입장에서 꽤 시끄러운 존재거든요.

HOME_NET, 규칙 파일, EVE JSON 출력, 로그 적재 경로를 한눈에 보여주는 구성 이미지입니다.

3. 운영자가 읽기 쉬운 로컬 규칙 추가

기본 규칙셋만 믿고 가기보다, 운영 환경에 맞는 가벼운 로컬 규칙을 추가하면 체감이 좋습니다. 예를 들어 관리망에서 외부로 나가는 비표준 포트 연결, 평소 쓰지 않는 국가 대역과의 통신, 특정 테스트 구간의 스캔 패턴 같은 것들이죠. 아래는 아주 단순한 예시입니다.

alert tcp $HOME_NET any -> $EXTERNAL_NET 8443 \
  (msg:\"LOCAL Suspicious outbound 8443\"; flow:to_server; sid:1000001; rev:1;)

alert icmp $EXTERNAL_NET any -> $HOME_NET any \
  (msg:\"LOCAL External ICMP to HOME_NET\"; sid:1000002; rev:1;)

물론 이런 규칙은 환경에 따라 너무 시끄러울 수 있습니다. 그래서 저는 로컬 규칙을 추가할 때마다 꼭 물었습니다. 이 알림이 떠서 내가 실제로 행동할 수 있는가? 행동으로 이어지지 않는 경고는 결국 소음이 되더라고요.

⚠️ 실제로 겪었던 문제들: 오탐 줄이다가 탐지를 망치는 순간

6개월 동안 가장 많이 배운 건 “줄이는 기술”보다 “안 줄여야 할 걸 구분하는 기술”이었습니다. 저도 초반에는 너무 시끄러워서 여러 규칙을 공격적으로 꺼봤는데, 나중에 보니 관찰 가치가 높은 이벤트까지 같이 묻힌 적이 있었습니다.

문제 1. 개발 환경 트래픽이 전부 수상해 보였던 경우

컨테이너 이미지 다운로드, 패키지 저장소 접근, 각종 API 호출이 반복되면서 외부 연결이 정말 많아집니다. 개발망을 일반 사용자망과 같은 기준으로 보면 경고가 폭증합니다.

해결: 네트워크 세그먼트(segment, 구간)별로 기대 동작을 분리했습니다. 개발망은 외부 통신이 상대적으로 많다는 걸 전제로 보고, 관리망과 서버망은 더 엄격하게 봤습니다.

문제 2. DNS 관련 경고가 너무 많아서 안 보게 된 경우

내부 DNS 포워더나 광고 차단 DNS, 테스트용 질의가 섞이면 경고 해석이 꽤 까다롭습니다. 처음엔 전부 수상해 보여서 하나하나 열어봤는데, 솔직히 금방 지치더라고요.

해결: DNS는 쿼리 양보다 희귀성과 대상을 중심으로 봤습니다. 자주 가는 정상 도메인보다, 평소 없던 패턴이나 관리 자산에서 나온 이례적 질의를 우선 확인했습니다.

문제 3. IPS 성격의 차단을 너무 빨리 건 경우

이거 삽질 좀 했습니다 ㅎㅎ 특정 시그니처를 신뢰하고 차단을 걸었는데, 정상 자동화 작업이 막히는 일이 생겼습니다. 보안은 강화됐는데 운영이 불편해지는 전형적인 상황이었죠.

해결: 차단은 아래 기준을 통과한 것만 적용했습니다.

• 최소 며칠 이상 반복 관찰된 이벤트일 것
• 정상 서비스와 충돌하지 않을 것
• 차단 시 영향 범위를 설명할 수 있을 것
• 롤백 방법이 준비되어 있을 것

문제 4. 로그는 쌓이는데 검증 루틴이 없었던 경우

Suricata가 잘 동작하는지 확인하려면, 단순히 프로세스가 떠 있는지만 보면 안 됩니다. 이벤트가 생성되고, 로그가 적재되고, 필요한 사람이 그 로그를 읽을 수 있어야 하거든요.

해결: 주 1회라도 좋으니 검증 루틴을 만들었습니다. “경고 발생 여부”가 아니라 “의미 있는 경고가 해석 가능한 상태인지”를 체크하는 습관이 생기니 운영 품질이 달라졌습니다.

검증 방법: 탐지율을 높였는지 어떻게 확인했나

보안 장비 운영에서 늘 어려운 질문이 이겁니다. “그래서 지금 더 잘 잡고 있나요?” 저도 처음엔 대답이 애매했습니다. 벤치마크 수치를 함부로 말할 수는 없고, 그렇다고 느낌만 얘기할 수는 없으니까요. 그래서 저는 정량보다는 운영 지표 중심으로 봤습니다.

제가 실제로 확인한 지표는 이런 것들이었습니다.

1. 하루 경고 수 자체보다, 확인할 가치가 있는 경고 비율이 늘었는가
2. 같은 오탐을 반복해서 보지 않게 되었는가
3. 이상 이벤트가 떴을 때 자산, 방향, 서비스 맥락을 바로 설명할 수 있는가
4. 차단 정책 적용 후 정상 업무 영향이 줄어들었는가

이 기준으로 보니 분명한 변화가 있었습니다. 초반에는 이벤트가 많아도 대응 품질이 낮았는데, 나중에는 이벤트 수가 조금 줄더라도 대응 가능한 알림의 밀도가 높아졌습니다. 드디어 됐다! 싶은 순간이 이런 때였네요.

경고 수 변화, 오탐 감소 추세, 검토 가치가 높은 이벤트 비율 상승을 시각화한 결과 이미지입니다.

제가 정착시킨 운영 체크리스트

혹시 지금 막 Suricata를 붙여놓고 “이 다음엔 뭘 해야 하지?” 싶은 분이라면, 아래 체크리스트부터 시작해보시면 좋겠습니다. 저도 처음엔 거창한 설계를 하려다가 오히려 복잡해졌고, 결국 이 기본기로 돌아왔습니다.

• 보호 대상 정의: 무엇을 지키는지 먼저 정합니다.
• 네트워크 구간 분리: 사용자망, 서버망, 관리망, 실험망을 섞어 보지 않습니다.
• 로그 우선순위 설정: alert, dns, http, tls, flow 중 필요한 것부터 봅니다.
• 오탐 기록: 같은 이벤트를 다시 분석하지 않도록 메모를 남깁니다.
• 규칙 변경 이력 관리: 왜 끄고 왜 켰는지 근거를 남깁니다.
• 차단 전 검증: IDS에서 충분히 본 뒤 IPS 성격 정책으로 넘깁니다.

특히 침입 탐지 시스템과 침입 방지 시스템을 같은 것으로 다루지 않는 태도가 중요했습니다. 엔진은 같아 보여도 운영 책임은 완전히 다르거든요. 탐지는 관찰의 문제이고, 차단은 서비스 영향까지 떠안는 결정입니다.

자주 묻는 질문: Suricata 운영에서 헷갈리는 부분들

Q1. 처음부터 IPS로 가도 될까요?

제 경험상 권장하지 않습니다. 먼저 IDS로 기준선을 잡고, 신뢰도가 높은 일부 정책만 단계적으로 차단에 연결하는 게 안전했습니다.

Q2. 오탐은 어느 정도가 정상인가요?

환경마다 다릅니다. 중요한 건 절대 숫자보다, 같은 오탐을 반복해서 방치하지 않는 운영 루틴입니다.

Q3. 규칙을 많이 넣을수록 좋은가요?

아닙니다. 많이 넣는 것보다, 내 환경에서 의미 있게 읽을 수 있는 규칙을 유지하는 게 더 중요했습니다.

Q4. 소규모 홈랩에도 가치가 있나요?

충분히 있습니다. 특히 트래픽 흐름을 이해하고, 평소와 다른 행위를 잡아내는 감각을 키우는 데 큰 도움이 됩니다.

마무리: 6개월 운영하고 나니, 진짜 중요한 건 도구보다 습관이었습니다

Suricata IDS/IPS를 6개월 운영해보니 가장 크게 남은 건 화려한 탐지 기능보다 운영 습관이었습니다. 정상 트래픽을 이해하는 습관, 오탐을 기록하는 습관, 차단 전에 충분히 검증하는 습관 말이죠. 사실 이런 기본기가 없으면 어떤 오픈소스 보안 도구를 붙여도 금방 지치게 됩니다.

반대로 이 루틴이 잡히면, 네트워크 보안은 훨씬 현실적인 수준으로 올라갑니다. 로그가 더 이상 소음이 아니라 단서로 보이기 시작하거든요. 저도 처음엔 경고가 많아 반쯤 포기할 뻔했는데, 환경별 기준선과 규칙 정리를 해놓고 나니 운영이 훨씬 편해졌습니다. 이건 생각보다 큰 차이입니다.

도입 초기와 6개월 후의 차이, 오탐 감소 원칙, 차단 적용 기준을 요약한 인포그래픽 이미지입니다.

다음 글에서는 EVE JSON 로그를 조금 더 실무적으로 다뤄보려고 합니다. 예를 들어 어떤 필드를 우선 봐야 하는지, 검색 시스템과 붙일 때 무엇을 남기고 무엇을 버릴지 같은 부분이요. 이전 글에서 다뤘던 홈랩 네트워크 분리 전략과 같이 보면 더 이해가 잘 되실 겁니다. 혹시 지금 운영 중인 Suricata IDS/IPS에서 제일 힘든 부분이 오탐인지, 차단 정책인지, 아니면 로그 해석인지 한 번 점검해보세요. 거기서부터 개선 방향이 꽤 선명해집니다. 🎉