13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Suricata

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

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

    목차

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

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

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

    Suricata IDS/IPS 기반 홈랩 네트워크 보안 아키텍처 이미지

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

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

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

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

    구분 IDS 모드 IPS 모드
    목적 탐지와 경보 탐지 후 차단
    장점 업무 영향이 적음 즉각 대응 가능
    단점 후속 대응이 필요 오탐 시 정상 서비스 영향
    추천 시작점 초기 도입 단계 검증 후 점진 적용

    제가 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

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

    Suricata IDS/IPS 설정과 로그 흐름 구성 다이어그램

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

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

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

    운영 전후 비교 항목 초기 상태 6개월 후 체감
    알림 피로도 높음 확실히 감소
    이벤트 해석 시간 길었음 짧아짐
    정상/비정상 구분 애매함 기준선이 생김
    차단 정책 신뢰도 낮음 선별 적용 가능

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

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

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

    Suricata IDS/IPS 운영 결과와 오탐 감소 대시보드 이미지

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

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

    혹시 지금 막 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에서 제일 힘든 부분이 오탐인지, 차단 정책인지, 아니면 로그 해석인지 한 번 점검해보세요. 거기서부터 개선 방향이 꽤 선명해집니다. 🎉

  • [보안] IDS IPS 비교: Snort vs Suricata 선택 가이드

    [보안] IDS IPS 비교: Snort vs Suricata 선택 가이드

    목차

    [보안] IDS IPS 비교: Snort vs Suricata 선택 가이드

    IDS IPS 비교를 하다 보면 결국 같은 질문으로 돌아오게 됩니다. Snort와 Suricata 중 우리 환경에는 뭐가 맞을까? 저도 처음엔 이게 뭔가 싶었거든요. 둘 다 오픈소스 IDS/IPS라서 비슷해 보이는데, 실제로 운영에 올려보면 성격이 꽤 다릅니다. 특히 홈랩(Home Lab, 개인 실험용 인프라)이나 소규모 사내망에서는 성능, 룰(rule, 탐지 규칙) 관리, 로그 분석 방식에서 체감 차이가 꽤 크게 납니다.

    제가 직접 해보니, 이 선택은 단순히 기능표 한 줄로 끝나는 문제가 아니었습니다. 침입 탐지 시스템(IDS, Intrusion Detection System)으로만 쓸 건지, 침입 방지 시스템(IPS, Intrusion Prevention System)까지 확장할 건지에 따라 접근이 달라지더라고요. 이번 글에서는 Snort와 Suricata를 실무 관점에서 비교하고, 실제로 어떻게 붙여서 테스트하면 되는지, 그리고 어디서 많이 막히는지까지 정리해보겠습니다.

    IDS IPS 비교를 위한 Snort와 Suricata 네트워크 보안 아키텍처 이미지

    Snort와 Suricata가 스위치 미러링 포트 또는 TAP에서 트래픽을 받아 분석하는 전체 구조를 보여주는 이미지입니다.

    1. 왜 아직도 Snort vs Suricata 이야기가 중요한가

    요즘 보안 이야기를 하면 EDR(Endpoint Detection and Response, 엔드포인트 탐지 및 대응), XDR(Extended Detection and Response, 확장형 탐지 대응) 같은 단어가 더 많이 보이죠. 근데 네트워크 레벨에서 뭔가 이상한 패턴을 빠르게 잡아내는 역할은 여전히 중요합니다. 특히 내부망에서 이상 트래픽이 보이거나, 외부에서 들어오는 스캔(scan, 포트 탐색)이나 익스플로잇(exploit, 취약점 공격 시도)을 보고 싶을 때 오픈소스 IDS/IPS는 아직도 꽤 유용합니다.

    혹시 이런 경험 있으신가요? 방화벽(Firewall, 네트워크 접근 제어)은 잘 돌아가는데, 막상 어떤 패킷(packet, 네트워크 데이터 조각)이 오가는지는 감이 안 잡히는 상황이요. 저도 처음엔 로그만 보면 되겠지 했었는데, 실제로는 방화벽 로그만으로는 애플리케이션 계층의 이상 징후가 잘 안 보이는 경우가 있었습니다. 그럴 때 Snort나 Suricata 같은 네트워크 보안 도구가 꽤 든든합니다.

    2. IDS와 IPS, 쉽게 말해 뭐가 다른가

    쉽게 말해 IDS는 보고하는 역할이고, IPS는 막는 역할입니다. 둘 다 패킷을 들여다보면서 시그니처(signature, 알려진 패턴)나 이상 징후를 찾는데, IDS 모드에서는 경고(alert)를 남기고, IPS 모드에서는 패킷을 드롭(drop, 차단)하거나 세션을 끊어버린다는 차이가 있어요.

    여기서 중요한 포인트! 같은 엔진이라도 배치 방식에 따라 완전히 다른 운영 경험이 됩니다. 미러 포트(SPAN port, 스위치 복제 포트)에 물리면 주로 IDS처럼 쓰게 되고, 인라인(inline, 트래픽 경로 중간 삽입)으로 넣으면 IPS처럼 동작시키는 구조가 많습니다.

    항목 Snort Suricata
    기본 성격 오랫동안 널리 사용된 전통적인 IDS/IPS 멀티스레드 기반 처리에 강점이 있는 IDS/IPS
    룰 호환성 Snort 룰 중심 Snort 스타일 룰을 상당수 활용 가능
    성능 접근 가볍게 시작하기 쉬운 편 코어를 잘 활용하는 환경에서 유리한 편
    로그 환경에 따라 별도 연계가 필요 EVE JSON 같은 구조화 로그 활용이 편리함
    사용자 인상 전통적이고 자료가 많음 현대적인 운영 파이프라인과 잘 맞음

    3. Snort vs Suricata, 실무에서 체감한 차이

    3-1. Snort의 장점

    • 역사가 길어서 참고 자료가 많습니다. 오래된 블로그 글이나 포럼까지 포함하면 트러블슈팅 힌트가 많아요.
    • 룰 기반 탐지 개념을 익히기 좋습니다. 처음 IDS를 공부할 때 구조를 이해하기 편하더라고요.
    • 작게 시작하기 부담이 적습니다. 테스트 VM 한 대에서 감 잡기 좋았습니다.

    3-2. Suricata의 장점

    • 멀티스레드(Multi-thread, 다중 스레드) 활용이 강점입니다. CPU 코어를 여러 개 활용하는 환경에서 유리하더라고요.
    • EVE JSON 로그가 편합니다. Elasticsearch, OpenSearch, Loki 같은 로그 스택과 연결할 때 손이 덜 갑니다.
    • 프로토콜 가시성(visibility, 식별 가능성)이 좋습니다. 나중에 분석할 때 정보가 잘 남는 편입니다.

    3-3. 언제 무엇을 고르면 좋을까

    제가 실제로 써보니까 기준은 생각보다 단순했습니다.

    1. 가볍게 개념 검증(PoC, Proof of Concept)을 하고 싶다면 Snort가 더 직관적일 수 있습니다.
    2. 로그 파이프라인까지 포함해 운영 자동화를 생각한다면 Suricata 쪽이 손에 잘 붙습니다.
    3. CPU 코어가 여유 있고 트래픽이 많은 편이다면 Suricata가 더 편했던 경우가 많았습니다.
    4. 기존 룰 자산이나 운영 경험이 Snort 중심이다면 무리해서 갈아탈 필요는 없습니다.

    결국 IDS IPS 비교의 핵심은 기능 숫자보다 운영 방식입니다. 성능이냐, 익숙함이냐, 로그 활용성이냐. 이 세 가지를 먼저 정리해두면 선택이 빨라집니다.

    4. 실전 구현: 홈랩에서 빠르게 비교해보기

    이제 진짜 중요한 부분이죠. 말로만 비교하면 감이 잘 안 옵니다. 그래서 저는 보통 같은 트래픽 소스에 대해 두 엔진을 각각 돌려보고 경고와 로그를 비교해봅니다. 아래 예시는 Debian/Ubuntu 계열 리눅스에서 테스트할 때 많이 쓰는 흐름입니다. 배포판에 따라 패키지 이름이나 설정 경로는 조금 다를 수 있습니다.

    4-1. 테스트 환경 준비

    1. 분석용 리눅스 서버 1대 준비
    2. 미러링된 인터페이스 또는 테스트용 NIC(Network Interface Card, 네트워크 카드) 연결
    3. 패킷 캡처 도구와 룰셋 준비
    4. 공격 시뮬레이션용 테스트 트래픽 생성
    sudo apt update
sudo apt install -y suricata snort tcpdump

    패키지 설치는 이 정도로 시작할 수 있습니다. 환경에 따라 Snort는 추가 설정 질문이 나올 수 있습니다. 저도 처음엔 여기서 네트워크 대역 설정을 대충 넣었다가, 왜 경고가 이상하게 뜨지 하고 삽질 좀 했습니다 ㅎㅎ

    4-2. Snort 기본 점검

    Snort는 먼저 설정 파일에서 내부망 대역과 룰 파일 경로를 확인하는 게 중요합니다.

    sudo snort -T -c /etc/snort/snort.conf

    위 명령은 테스트 모드입니다. 설정 문법에 문제가 없는지 먼저 확인합니다. 이거 안 하고 바로 돌리면 나중에 경고가 안 뜨는 이유를 한참 찾게 되거든요.

    sudo snort -A console -q -c /etc/snort/snort.conf -i eth1

    <code>eth1은 미러링된 인터페이스 예시입니다. 실제 인터페이스명으로 바꿔야 합니다. 콘솔 경고 출력으로 반응을 바로 보기에 좋습니다.

    4-3. Suricata 기본 점검

    Suricata는 YAML 기반 설정이라 가독성은 괜찮은데, 인터페이스와 룰 경로, 출력 포맷을 꼭 확인해야 합니다.

    sudo suricata -T -c /etc/suricata/suricata.yaml
    sudo suricata -i eth1 -c /etc/suricata/suricata.yaml

    기본 로그는 보통 /var/log/suricata/ 아래에 쌓입니다. 여기서 eve.json이 특히 편합니다. JSON 구조라 후처리가 쉬워요.

    Snort와 Suricata 설정 및 패킷 미러링 구성 이미지

    룰 파일, 인터페이스, 로그 경로를 연결해서 보여주는 설정 중심 이미지가 들어갈 자리입니다.

    4-4. 테스트용 룰 추가

    비교할 때는 복잡한 규칙보다 단순한 룰 하나로 먼저 동작 확인하는 게 좋습니다. 예를 들어 ICMP(ping, 핑) 트래픽을 잡는 간단한 룰입니다.

    alert icmp any any -> any any (msg:"ICMP test detected"; sid:1000001; rev:1;)

    Snort나 Suricata에서 로컬 룰 파일에 추가한 뒤 다시 테스트합니다. 그런 다음 다른 장비에서 핑을 보내보면 됩니다.

    ping -c 4 192.168.0.10

    이 정도만 해도 침입 탐지 시스템이 어떻게 반응하는지 감이 옵니다. 이후 HTTP, DNS, SMB 같은 프로토콜 단위로 확장해보면 훨씬 재미있습니다.

    5. 운영 관점에서 보는 로그와 분석 편의성

    여기서부터는 실무 냄새가 좀 납니다. 탐지 엔진 자체도 중요하지만, 경고를 어떻게 읽고 쌓고 검색할지가 더 중요하거든요. 실제로 써보니까 이 부분 때문에 Suricata를 선호하는 분들이 많다는 걸 이해하게 됐습니다.

    5-1. Suricata의 EVE JSON

    EVE JSON은 구조화 로그(structured log, 필드가 정리된 로그)라서 SIEM(Security Information and Event Management, 보안 정보 이벤트 관리)이나 로그 스택에 붙이기 편합니다.

    {
  "event_type": "alert",
  "src_ip": "192.168.0.20",
  "dest_ip": "192.168.0.10",
  "alert": {
    "signature": "ICMP test detected"
  }
}

    이런 식으로 필드가 보이니까 나중에 대시보드 만들 때 편하더라고요. 제가 홈랩에서 OpenSearch로 연동했을 때도 필드 매핑이 비교적 수월했습니다.

    5-2. Snort는 어떤가

    Snort도 충분히 운영 가능합니다. 다만 어떤 포맷으로 남길지, 후단에서 어떻게 수집할지에 대해 설계를 조금 더 해줘야 하는 경우가 있었습니다. 이게 꼭 단점은 아닙니다. 기존 체계가 있으면 오히려 맞춰 넣기 쉬운 경우도 있거든요.

    6. ⚠️ 주의사항과 트러블슈팅

    이 섹션은 꼭 보셨으면 합니다. 이론보다 여기서 시간이 더 많이 날아갑니다. 저도 처음엔 엔진이 이상한 줄 알았는데, 대부분은 배치나 설정 문제였어요.

    6-1. 미러 포트에서 패킷이 안 보이는 경우

    • 스위치 미러링 설정이 잘못되면 아무리 엔진이 좋아도 데이터가 안 들어옵니다.
    • NIC 오프로딩(offloading, 네트워크 처리 일부를 하드웨어에 위임) 때문에 캡처가 이상하게 보일 때가 있습니다.
    • 가상화 환경에서는 promiscuous mode(무차별 수신 모드) 설정이 필요할 수 있습니다.

    저는 한 번 ESXi 기반 테스트에서 미러링은 됐는데 게스트 OS가 패킷을 기대만큼 못 받는 문제가 있었어요. 알고 보니 가상 스위치 설정 쪽이 문제더라고요. 드디어 됐다! 싶었던 순간이 아직 기억납니다.

    6-2. 경고가 너무 많이 뜨는 경우

    False Positive(오탐)는 생각보다 흔합니다. 특히 기본 룰셋을 넓게 켜두면 내부 정상 트래픽도 많이 잡힙니다.

    1. 내부 자산의 정상 패턴을 먼저 파악합니다.
    2. 시끄러운 룰은 threshold(임계치)나 suppress(억제) 설정을 검토합니다.
    3. 바로 IPS로 가지 말고 IDS로 관찰 기간을 둡니다.

    근데 여기서 성급하게 룰을 꺼버리면 나중에 진짜 이상 징후를 놓칠 수도 있습니다. 그래서 저는 꼭 주석을 남기고, 왜 비활성화했는지 기록해둡니다.

    6-3. IPS 모드 전환 시 주의할 점

    침입 방지 시스템으로 쓰려면 차단 정책이 실제 서비스에 미치는 영향을 먼저 봐야 합니다. 운영망에 바로 인라인으로 넣는 건 꽤 공격적인 접근입니다. 저도 처음엔 자신 있게 넣었다가 특정 업무 트래픽이 끊겨서 식은땀 났었습니다.

    • 초기에는 IDS 모드로 충분히 학습
    • 차단보다는 경고 중심으로 베이스라인 확보
    • 업무 시간 외 테스트 권장
    • 롤백 경로 미리 준비
    IDS IPS 비교 결과를 보여주는 경고 로그와 대시보드 이미지

    로그가 어떻게 쌓이고 어떤 필드로 분석되는지 보여주는 결과 중심 이미지가 들어가면 이해가 훨씬 쉬워집니다.

    7. 검증: 무엇을 기준으로 비교하면 되나

    단순히 경고가 떴다 안 떴다만 보면 아쉽습니다. 비교 기준을 몇 가지 잡아두면 좋습니다.

    1. 탐지 정확도: 테스트 트래픽에 대해 기대한 경고가 뜨는가
    2. 로그 가독성: 분석할 때 필요한 정보가 잘 남는가
    3. 운영 편의성: 룰 수정, 재시작, 배포가 부담 없는가
    4. 성능 체감: 트래픽이 늘어도 드롭 없이 버티는가
    5. 확장성: SIEM, 대시보드, 알림 시스템과 쉽게 연결되는가

    제가 홈랩에서 비교했을 때는, 단순 패킷 탐지 자체보다도 운영 이후의 피로도가 꽤 크게 느껴졌습니다. 처음 도입은 Snort가 편한 순간도 있었지만, 로그 후처리와 대시보드 연계까지 생각하면 Suricata가 더 손에 맞는 경우가 있었습니다. 반대로 기존 Snort 룰 자산이 많다면 굳이 무리해서 바꿀 필요는 없겠더라고요.

    sudo tail -f /var/log/suricata/eve.json
sudo tail -f /var/log/snort/alert

    이렇게 두 로그를 나란히 보면서 테스트 트래픽을 넣어보면 꽤 많은 게 보입니다. 특히 어떤 정보가 더 풍부하게 남는지 비교하기 좋습니다. 이거 진짜 편하더라고요.

    8. 정리: 우리 환경에 맞는 선택은 결국 이것입니다

    정리해보면 이렇습니다. Snort는 전통적이고 학습 자료가 많아서 시작 장벽이 낮습니다. Suricata는 멀티스레드 활용과 구조화 로그 측면에서 현대적인 운영 환경과 잘 맞습니다. 그래서 IDS IPS 비교에서 정답은 하나가 아니라, 현재 환경과 운영 목적에 따라 달라집니다.

    • 작게 시작하고 싶다면: Snort
    • 로그 분석과 확장을 중요하게 본다면: Suricata
    • 기존 룰과 경험이 있다면: 익숙한 쪽 유지도 좋은 선택
    • 운영망 차단이 목표라면: IPS 전환 전 충분한 관찰 필수

    저도 처음엔 무조건 최신스럽고 편해 보이는 쪽으로 가야 하나 싶었는데, 실제로 써보니까 네트워크 보안 도구는 기능보다 운영 맥락이 더 중요했습니다. 결국 사람 손이 덜 가고, 로그가 잘 보이고, 문제 났을 때 빨리 원인을 찾을 수 있는 쪽이 오래 갑니다.

    다음 글에서는 Suricata를 EVE JSON 기반으로 시각화해서 대시보드까지 붙이는 과정을 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 로그 수집 구조와도 연결되는 내용이라, 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    Snort vs Suricata 선택 기준을 정리한 IDS IPS 비교 인포그래픽

    어떤 환경에서 어떤 도구가 더 어울리는지 한눈에 보는 요약 이미지 자리입니다.

    자주 묻는 질문

    Q1. 처음 입문이면 Snort와 Suricata 중 무엇이 더 쉬운가요?

    완전 처음이면 Snort가 더 직관적으로 느껴질 수 있습니다. 다만 로그 활용까지 생각하면 Suricata도 금방 익숙해집니다.

    Q2. 두 도구를 동시에 운영해도 되나요?

    테스트 목적이라면 가능합니다. 다만 같은 트래픽을 두 엔진이 동시에 볼 때 리소스 사용량과 로그 중복을 고려해야 합니다.

    Q3. 바로 IPS로 써도 될까요?

    추천하지는 않습니다. 먼저 IDS로 베이스라인을 잡고, 오탐을 줄인 뒤 점진적으로 전환하는 편이 훨씬 안전합니다.

    결론만 짧게 말하면, 침입 탐지 시스템부터 안정적으로 운영해보고, 그 다음에 침입 방지 시스템으로 확장하는 순서가 가장 덜 아픕니다. 저도 그렇게 가는 게 결국 제일 덜 힘들더라고요.

  • [HomeLabs] pfSense/OPNsense 홈랩 방화벽 구축: 네트워크 보안 강화 완벽 가이드

    목차

    홈랩에 방화벽이 필요한 이유 — 공유기로는 부족하더라고요

    홈서버를 처음 구축했을 때 저도 그랬어요. “집에서 쓰는 건데 뭐, 공유기 방화벽이면 충분하지 않나?” 싶었거든요. 그런데 포트포워딩 몇 개 열어두고 Jellyfin이랑 Nextcloud 운영하다 보니까 생각이 바뀌었습니다. 어느 날 서버 로그를 들여다봤더니 중국, 러시아 IP에서 SSH 브루트포스 시도가 하루에도 수백 건씩 들어오고 있는 거예요. 그때부터 진지하게 홈랩 방화벽 구축을 고민하기 시작했죠.

    일반 가정용 공유기의 NAT(Network Address Translation, 네트워크 주소 변환) 기능이 기본적인 외부 접근은 막아주지만, 세밀한 트래픽 제어나 IDS/IPS(침입 탐지/방지 시스템), VPN 게이트웨이 기능 같은 건 기대하기 어렵거든요. 그래서 선택한 게 바로 pfSense와 OPNsense였습니다.

    이 글에서는 제가 직접 구축하면서 겪었던 경험을 바탕으로, 두 솔루션의 차이점부터 실제 설치·설정까지 단계별로 정리해드릴게요. 홈서버 보안을 한 단계 끌어올리고 싶으신 분들께 도움이 됐으면 합니다.

    ▲ 일반적인 홈랩 방화벽 구성 — 인터넷 → 방화벽(pfSense/OPNsense) → 내부 네트워크 세그먼트로 트래픽이 흐르는 전체 아키텍처

    pfSense vs OPNsense — 뭐가 다른 건가요?

    둘 다 FreeBSD 기반의 오픈소스 방화벽 소프트웨어인데, 뿌리는 같지만 지향점이 조금 달라요. 저도 처음엔 “그냥 비슷한 거 아냐?” 했는데, 직접 써보니 체감 차이가 꽤 있더라고요.

    항목 pfSense CE (Community Edition) OPNsense
    기반 OS FreeBSD FreeBSD (HardenedBSD 기반)
    UI 스타일 전통적, 기능 중심 모던, 직관적
    업데이트 주기 비교적 느림 격주 릴리즈 (빠른 보안 패치)
    IDS/IPS Snort, Suricata Suricata (기본 통합)
    플러그인 생태계 pfSense 패키지 OPNsense 플러그인 (더 활발)
    라이선스 Apache 2.0 BSD 2-Clause
    상업적 지원 Netgate (유료 플랜) Deciso (유료 플랜)

    솔직히 말씀드리면, 저는 최근에는 OPNsense를 메인으로 쓰고 있어요. 이유는 단순한데, UI가 훨씬 깔끔하고 보안 업데이트가 빠르거든요. 특히 CVE(Common Vulnerabilities and Exposures, 공개된 보안 취약점)가 나왔을 때 OPNsense 쪽이 패치 대응이 빠르더라고요. 다만 pfSense가 커뮤니티 문서나 유튜브 튜토리얼이 훨씬 많아서, 처음 입문하시는 분들한테는 pfSense가 진입 장벽이 낮을 수 있어요.

    하드웨어 선택 — 어디에 설치할 건가요?

    방화벽 소프트웨어를 고르는 것만큼 중요한 게 하드웨어 선택이에요. 저는 세 가지 방법을 다 써봤는데, 각각 장단점이 있더라고요.

    옵션 1: 전용 x86 미니PC / 어플라이언스

    • Intel NIC(Network Interface Card, 네트워크 인터페이스 카드)가 달린 미니PC 추천 — Realtek NIC는 FreeBSD 드라이버 이슈가 있어서 고생할 수 있어요
    • 듀얼 포트 이상의 NIC가 필요 (WAN 1개, LAN 1개 이상)
    • 전력 소비가 낮고 팬리스 모델이면 24/7 운영에 유리
    • 💡 팁: AES-NI(하드웨어 암호화 가속) 지원 CPU를 선택하면 VPN 성능이 크게 올라가요

    옵션 2: 기존 홈서버의 VM (가상머신)

    • Proxmox 같은 하이퍼바이저에서 VM으로 운영 가능
    • NIC 패스스루(PCIe Passthrough)나 VLAN 트렁킹 설정이 필요
    • 서버가 꺼지면 인터넷도 끊기는 단점 있음 ⚠️

    옵션 3: Raspberry Pi (제한적)

    • pfSense/OPNsense 공식 지원은 x86/amd64 기준 — Pi는 공식 지원 아님
    • 소규모 트래픽 환경에서만 대안 고려 가능 (이 경우 OpenWrt 쪽이 더 현실적)

    OPNsense 설치 — 단계별 가이드

    이제 본격적으로 설치해봅시다. 제가 설치할 때 가장 헷갈렸던 부분을 중심으로 설명할게요.

    ▲ OPNsense 웹 관리 인터페이스(WebGUI) — 설치 후 처음 접속하면 보이는 대시보드 화면. 시스템 상태, 인터페이스 정보, 게이트웨이 상태를 한눈에 확인할 수 있어요.

    1. ISO 다운로드: opnsense.org 공식 사이트에서 최신 DVD ISO 이미지 다운로드 (amd64 기준)
    2. 부팅 USB 제작: Rufus(Windows) 또는 dd 명령어(Linux/Mac)로 부팅 USB 제작
    3. 설치 진행: 기본 계정으로 로그인 후 installer 실행
    4. 인터페이스 할당: WAN / LAN 인터페이스 지정 (가장 중요!)
    5. WebGUI 접속: LAN IP(기본 192.168.1.1)로 브라우저 접속

    부팅 USB 제작할 때 dd 명령어 쓰시는 분들 참고하세요:

    # Linux/macOS에서 USB 부팅 디스크 만들기
# /dev/sdX 부분은 본인 USB 장치 경로로 변경 필요 (lsblk 명령어로 확인)
sudo dd if=OPNsense-버전-dvd-amd64.iso of=/dev/sdX bs=4M status=progress
sync

    ⚠️ 주의: dd 명령어는 잘못 입력하면 다른 디스크를 덮어쓸 수 있어요. of= 경로를 반드시 두 번 확인하세요. 저도 처음에 식은땀 흘렸던 기억이 있어요 ㅎㅎ

    기본 방화벽 규칙 설정 — 여기가 핵심이에요

    설치 후 WebGUI에 접속하면 Setup Wizard(설정 마법사)가 뜨는데, 이걸 따라가면 기본 설정은 금방 끝나요. 근데 여기서 멈추면 안 됩니다. 진짜 보안 강화는 방화벽 규칙 설정에서 시작하거든요.

    WAN 규칙 — 기본 원칙은 “모두 차단, 필요한 것만 허용”

    OPNsense/pfSense 모두 기본적으로 WAN에서 들어오는 모든 인바운드(Inbound, 외부→내부) 트래픽을 차단해요. 이 기본값을 유지하는 게 맞습니다.

    # OPNsense Shell에서 현재 방화벽 규칙 확인 (pfctl 명령어)
pfctl -sr

# 특정 인터페이스의 규칙만 보기
pfctl -sr | grep WAN

    LAN 규칙 — VLAN으로 네트워크 세분화하기

    홈랩에서 제가 가장 효과적으로 쓰는 방법이 VLAN(Virtual LAN, 가상 네트워크 분리)이에요. 예를 들어 이런 식으로 나눌 수 있어요:

    • VLAN 10 (신뢰 네트워크): 개인 PC, 노트북
    • VLAN 20 (서버 네트워크): 홈서버, NAS
    • VLAN 30 (IoT 네트워크): 스마트 TV, 공기청정기 등 IoT 기기
    • VLAN 40 (게스트 네트워크): 방문객 Wi-Fi

    IoT 기기들을 별도 VLAN으로 격리하는 게 진짜 중요해요. 스마트 TV나 IP 카메라 같은 장치들은 보안이 취약한 경우가 많거든요. 이것들이 메인 네트워크에 있으면 한 기기가 뚫렸을 때 전체가 위험해지는 거니까요.

    OPNsense WebGUI에서 VLAN 추가하는 경로: Interfaces → Other Types → VLAN

    # 방화벽 규칙 예시 — IoT VLAN에서 서버 VLAN으로의 접근 차단
# OPNsense WebGUI의 Firewall → Rules → VLAN30 에서 설정
# Action: Block
# Interface: VLAN30
# Source: VLAN30 net
# Destination: VLAN20 net
# Description: IoT to Server VLAN Block

    Suricata IDS/IPS 활성화

    OPNsense에는 Suricata(수리카타)가 기본 플러그인으로 포함돼 있어요. IDS(Intrusion Detection System, 침입 탐지 시스템)와 IPS(Intrusion Prevention System, 침입 방지 시스템) 기능을 제공하는데, 활성화해두면 알려진 악성 트래픽 패턴을 자동으로 탐지하고 차단해줘요.

    활성화 경로: Services → Intrusion Detection → Administration

    • Enabled 체크
    • IPS Mode 체크 (탐지만 할지, 실제 차단까지 할지 결정)
    • Ruleset: ET Open 룰셋 무료로 사용 가능 — 이걸로도 충분해요

    💡 처음에 IPS 모드를 바로 켜면 정상 트래픽이 차단될 수 있어요. IDS 모드로 며칠 모니터링하면서 False Positive(오탐)를 확인한 다음에 IPS 모드로 전환하는 걸 추천합니다.

    VPN 게이트웨이 설정 — WireGuard로 원격 접속

    홈랩을 외부에서 안전하게 접속하려면 VPN이 필수예요. 예전엔 OpenVPN 많이 썼는데, 요즘은 WireGuard(와이어가드)로 완전히 넘어왔어요. 설정이 훨씬 간단하고 성능도 좋거든요.

    OPNsense에서 WireGuard 설치: System → Firmware → Plugins → os-wireguard 설치

    # WireGuard 키 쌍 생성 (서버에서 실행)
wg genkey | tee server_private.key | wg pubkey > server_public.key
wg genkey | tee client_private.key | wg pubkey > client_public.key

# 키 내용 확인
cat server_private.key
cat server_public.key

    생성된 키는 OPNsense WebGUI의 VPN → WireGuard → Local / Endpoints 설정에 입력하면 돼요. 스마트폰에서는 WireGuard 공식 앱으로 QR 코드 스캔하면 바로 연결 가능하고, 이게 진짜 편하더라고요. 드디어 외부에서 집 서버에 안전하게 붙을 수 있게 됐을 때 기분이 얼마나 좋던지 🎉

    ▲ OPNsense 방화벽 규칙 설정 화면 및 Suricata IDS 경보 로그 — 실시간으로 차단된 트래픽과 탐지된 위협을 모니터링할 수 있어요.

    ⚠️ 삽질 모음 — 제가 겪은 트러블슈팅

    설치하면서 제가 실제로 막혔던 부분들이에요. 이거 보고 같은 삽질 반복하지 않으셨으면 해서 솔직하게 적어봤어요.

    문제 1: WAN 인터페이스 인식 안 됨

    증상: 설치 후 WAN 쪽 인터페이스가 잡히지 않음
    원인: Realtek NIC의 FreeBSD 드라이버 이슈 (FreeBSD에서 Realtek은 가끔 문제가 생겨요)
    해결: Intel 기반 NIC로 교체. em(Intel PRO/1000 계열) 또는 igb 드라이버가 인식되는 NIC 사용 추천

    문제 2: NAT Reflection 설정 안 해서 내부에서 외부 도메인 접속 불가

    증상: 외부에서는 되는데 내부 LAN에서 자기 도메인으로 접속 안 됨
    원인: NAT Reflection(헤어핀 NAT) 미설정
    해결: Firewall → Settings → Advanced → Reflection for port forwards: Enable

    문제 3: Suricata 켜고 나서 일부 사이트 접속 불가

    증상: IPS 모드 활성화 후 특정 스트리밍 사이트 접속이 끊김
    원인: 공격 패턴과 유사한 정상 트래픽을 오탐(False Positive)으로 차단
    해결: 해당 룰 ID를 Suppress List에 추가하거나, 해당 IP를 Whitelist에 등록

    # OPNsense Shell에서 Suricata 로그 실시간 확인
tail -f /var/log/suricata/eve.json | python3 -m json.tool | grep -E '"alert"|"src_ip"|"dest_ip"'

    문제 4: 재부팅 후 방화벽 규칙이 일부 초기화

    증상: 수동으로 추가한 규칙이 재부팅 후 사라짐
    원인: WebGUI가 아닌 Shell에서 직접 pfctl로 임시 추가한 규칙
    해결: 반드시 WebGUI를 통해 규칙 추가. Shell 명령어는 테스트용으로만 사용

    ✅ 구축 결과 확인 — 이렇게 검증하세요

    설정 다 했다고 끝이 아니에요. 실제로 제대로 동작하는지 검증하는 게 중요해요.

    외부에서 포트 스캔으로 노출 여부 확인

    Shodan(shodan.io)이나 nmap으로 외부에서 내 IP를 스캔해보세요. 방화벽이 제대로 동작한다면 열어둔 포트 외에는 아무것도 안 보여야 해요.

    # 다른 네트워크(모바일 데이터 등)에서 내 WAN IP로 포트 스캔
nmap -sV -p 1-1024 [내 WAN IP 주소]

# 결과 예시 — 방화벽이 잘 동작하면 이렇게 나와야 함
# All 1024 scanned ports on [IP] are in ignored states.

    Firewall Logs 확인

    OPNsense WebGUI에서 Firewall → Log Files → Live View로 실시간 차단 로그를 볼 수 있어요. 여기서 외부에서 들어오는 수상한 접근 시도를 확인할 수 있는데, 처음 보시면 “이렇게 많이 들어오고 있었어?” 하고 놀라실 거예요. 저도 그랬거든요 ㅎㅎ

    Dashboard 위젯으로 실시간 모니터링

    • Gateway 상태 (WAN 연결 안정성)
    • Interface 트래픽 그래프
    • Suricata 알림 카운트
    • 시스템 리소스 (CPU, 메모리)

    ▲ 방화벽 구축 완료 후 OPNsense 대시보드 — 게이트웨이 상태, 인터페이스 트래픽, IDS 탐지 현황을 실시간으로 모니터링하는 화면

    마무리 — 홈랩 네트워크 보안, 이제 시작이에요

    pfSense/OPNsense 기반의 홈랩 방화벽을 구축하고 나면 네트워크를 바라보는 눈이 달라져요. 예전엔 그냥 “인터넷 되면 됐지” 였다면, 이제는 트래픽 흐름이 보이기 시작하거든요. 어디서 뭐가 들어오고 나가는지, 어떤 시도가 차단되고 있는지.

    정리하자면 이렇게 구성하시면 됩니다:

    • ✅ Intel NIC 기반 하드웨어 선택
    • ✅ OPNsense 또는 pfSense 설치
    • ✅ WAN 기본 차단 정책 유지
    • ✅ VLAN으로 네트워크 세분화 (IoT 격리 필수!)
    • ✅ Suricata IDS/IPS 활성화
    • ✅ WireGuard VPN으로 원격 접속 구성
    • ✅ 외부 포트 스캔으로 노출 여부 검증

    다음 단계로는 pfBlockerNG(pfSense) 또는 OPNsense의 Unbound DNS 블랙리스트를 활용한 DNS 기반 광고/악성 도메인 차단을 다뤄볼 예정이에요. 이걸 적용하면 집 안 모든 기기에서 광고가 사라지는 마법을 경험할 수 있거든요 — Pi-hole 없이도요. 그 내용은 다음 글에서 자세히 다루겠습니다.

    궁금한 점이나 막히는 부분 있으시면 댓글로 남겨주세요. 같은 삽질을 덜 하셨으면 하는 마음으로 최대한 답변드릴게요 😊

    자주 묻는 질문 (FAQ)

    Q. pfSense와 OPNsense 중 초보자에게 어떤 걸 추천하나요?

    커뮤니티 자료가 많은 pfSense CE가 처음 입문하기엔 조금 더 수월해요. 다만 보안 업데이트 주기와 UI 현대성을 고려하면 OPNsense도 충분히 좋은 선택입니다. 둘 다 무료로 사용 가능하니 VM에서 먼저 테스트해보시는 걸 추천합니다.

    Q. 최소 사양이 어떻게 되나요?

    공식 권장 사양은 CPU 1GHz 이상, RAM 1GB 이상이지만, IDS/IPS나 VPN까지 쓰려면 최소 4GB RAM에 멀티코어 CPU를 권장해요. 기가비트 라인 풀로 쓰려면 더 여유 있는 스펙이 필요합니다.

    Q. 기존 공유기는 어떻게 되나요?

    pfSense/OPNsense가 공유기 역할을 대신하는 구성이 일반적이에요. 기존 공유기는 AP(액세스 포인트) 모드로 전환해서 Wi-Fi 전용으로 활용하면 됩니다.

    Q. Cloudflare Tunnel과 같이 쓸 수 있나요?

    네, 함께 사용 가능해요. Cloudflare Tunnel을 쓰면 WAN 포트포워딩 없이도 외부 접속이 가능해서 보안상 더 좋은 구성을 만들 수 있어요. 이 조합도 나중에 다뤄볼게요.