Suricata NAT Instance 기반 IPS/IDS 실습 랩 구축 (3편) : Suricata 설치 및 NFQUEUE 기반 인라인 구성

NAT Instance 환경에서 Suricata 설치 및 NFQUEUE 기반 인라인 탐지 설정

이번 편에서는 NAT Instance 위에 Suricata를 설치하고,
NFQUEUE 기반 인라인 처리 구조를 구성한다.

중요한 점은 이 단계에서는 차단(drop)을 하지 않는다는 것이다.
목표는 단 하나다.

패킷이 Suricata를 반드시 통과하면서 정상적으로 분석되고,
eve.json 로그가 생성되는 상태를 만드는 것

---

1. Suricata 설치 (Ubuntu 기준)

1.1 Suricata 설치

# apt -y install suricata suricata-update

설치 후 버전 확인으로 정상 설치 여부를 확인한다.

# suricata -V

버전 정보가 출력되면 정상이다.

---

1.2 룰 다운로드 / 갱신

# suricata-update

• Emerging Threats Open 룰 기준
• 이 시점에서는 alert 룰만 사용
• drop 룰은 아직 적용하지 않는다

---

2. Suricata 기본 설정

설정 파일 경로:

/etc/suricata/suricata.yaml

---

2.1 HOME_NET 지정

Suricata에서 HOME_NET은 보호 대상 네트워크다.
NAT Instance 구조에서는 Private Subnet CIDR을 지정해야 한다.

# grep -n "HOME_NET" /etc/suricata/suricata.yaml | head

직접 편집하여 다음과 같이 수정한다.

vars:
  address-groups:
    HOME_NET: "[10.0.1.0/24]"
    EXTERNAL_NET: "!$HOME_NET"

주의사항:

• NAT Instance의 퍼블릭 대역을 넣으면 안 된다
• 실제 보호 대상은 Private Subnet 내부 서버다
• HOME_NET을 잘못 잡으면 룰은 동작해도 의미 없는 탐지가 된다

---

2.2 eve.json 활성화 확인

Suricata 이벤트 로그는 eve.json으로 기록된다.
기본으로 활성화돼 있는 경우가 많지만 반드시 확인한다.

# grep -n "eve-log" /etc/suricata/suricata.yaml | head -n 40

실제 예시는 다음과 같다.

이 설정이 있어야 다음 파일이 생성된다.

/var/log/suricata/eve.json

이 로그는 이후 OpenSearch / Kibana 연동의 핵심 데이터가 된다.

---

3. Suricata 실행

3.1 systemd 실행 전 테스트 런

설정 적용 전에 반드시 테스트한다.

# suricata -T -c /etc/suricata/suricata.yaml

이 단계에서 다음을 검증한다.

• YAML 문법 오류
• 룰 파싱 오류
• 설정 충돌

아래와 같이 나오면 정상이다.

여기서 에러가 나면 데몬 실행 시 바로 장애로 이어진다.

---

3.2 기존 데몬 종료 (충돌 방지)

패키지 설치 시 systemd 서비스가 떠 있을 수 있다.
NFQUEUE 인라인 실행과 충돌을 막기 위해 먼저 종료한다.

# systemctl stop suricata 
# systemctl disable suricata

---

4. NFQUEUE 기반 인라인 실행

4.1 Suricata 실행

# suricata -c /etc/suricata/suricata.yaml -q 0 -D

여기서 -q 0은 매우 중요하다.

---

4.2 -q 0 : NFQUEUE 0번 사용 의미

-q 0 (또는 iptables의 --queue-num 0)은
리눅스 커널과 Suricata가 패킷을 주고받기 위해 약속한 큐 번호다.

1) 비유: 은행 창구

• iptables (청원경찰)
  → “이 패킷은 0번 창구로 가서 검사받으세요”
• Queue 0 (대기열)
  → 검사 대기 중인 패킷 공간
• Suricata (은행원)
  → “나는 0번 창구만 맡는다” (-q 0)

핵심은 이것이다.

iptables는 0번으로 보내는데
Suricata가 1번 창구(-q 1)를 보고 있으면
패킷은 처리되지 않고 트래픽이 멈춘다
큐 번호는 반드시 일치해야 한다

---

2) 기술적 의미 (User Space Packet Queuing)

• 원래 패킷 처리는 커널 영역에서 이뤄진다
• NFQUEUE는 패킷을 **유저 공간(Suricata)**으로 전달한다

동작 흐름:

1. 커널 → NFQUEUE 0번으로 패킷 전달
2. Suricata가 Queue 0을 감시
3. 패킷 검사 수행
4. 결과를 커널에 반환
   • ACCEPT
   • DROP

---

3) 왜 0번을 쓰는가

특별한 의미는 없다.
관습적인 기본값이다.

고성능 환경에서는 다음과 같이 확장한다.

# iptables --queue-balance 0:3

# suricata -q 0 -q 1 -q 2 -q 3

멀티 큐 + 멀티 코어 처리용이다.
이번 실습에서는 사용하지 않는다.

---

(3) 현재 큐 구성 상태

• iptables → NFQUEUE 0번
• Suricata → -q 0 리스닝
• 큐 번호 일치
• 인라인 처리 정상

---

5. 로그 확인

Suricata 동작 여부를 로그로 확인한다.

# tail -f /var/log/suricata/suricata.log

# tail -f /var/log/suricata/eve.json

• 트래픽이 흐르면 eve.json에 이벤트가 기록된다
• alert 룰 매칭 시 로그가 누적된다

---

6. 결론

현재 상태는 다음과 같다.

• NFQUEUE 기반 인라인 처리 중
• 모든 패킷이 Suricata를 통과
• 룰 액션은 alert 위주
• 실제 차단(drop)은 발생하지 않음

즉,

인라인 IDS 상태

차단은 룰 액션이 drop일 때만 발생한다.
운영 환경에서는 이 상태로 충분히 관찰한 뒤
오탐을 제거하고 필요한 룰만 drop으로 전환한다.

🛠 마지막 수정일: 2025.12.23