Suricata: 기본적으로 JSON을 사용하는 멀티스레드 네트워크 엔진

핵심 내용

1. 아키텍처별 멀티스레딩: 패킷 캡처(Linux의 AF_PACKET, 높은 처리량을 위한 AF_XDP)는 코어 전반에 걸쳐 작업자 파이프라인을 공급하므로 엔진은 1세대 IDS의 단일 대기열 병목 현상 없이 최신 하드웨어에서 확장됩니다. 크기 조정은 대역폭뿐만 아니라 CPU와 RAM/패킷을 합친 것입니다.
2. EVE JSON은 데이터 모델의 차이입니다. 모든 경고, 흐름 및 프로토콜 메타데이터 레코드는 사용자 지정 구문 분석 없이 Elastic/OpenSearch 파이프라인에 직접 전달되는 구조화된 JSON(http.uri, tls.sni, dns.name과 같은 필드)으로 제공됩니다. 이 하나의 디자인 선택이 Suricata가 대부분의 SOC 스택 투표에서 승리한 이유입니다.
3. 프로토콜 인식은 서명 그 이상입니다. 엔진은 TLS 핸드셰이크 메타데이터(JA3 클래스 해시, SNI, 인증서 필드), HTTP 헤드, DNS 쿼리 및 SMB/파일 추적을 기록하므로 센서는 네트워크 메타데이터 수집의 두 배가 됩니다. 많은 팀은 경고가 발생하기 전부터 이를 위해 주로 Suricata를 실행합니다.
4. 규칙 호환성은 운영상 마음의 평화입니다. Snort 형식 규칙은 대부분 중복되어 로드되므로(ET 규칙 세트는 두 가지 모두에 대해 게시됨), 위협 정보 구독은 적절한 구문 추가를 통해 Snort 백그라운드 전송의 엔진과 기술 전반에 걸쳐 확장됩니다(Suricata는 app-layer-events와 같은 자체 키워드를 추가합니다).
5. IPS 모드는 실제입니다. 삭제 규칙이 있는 NFQUEUE 또는 AF_PACKET을 통해 인라인이지만 자세에는 HA 친구와 신중한 정책이 필요합니다. 대부분의 자산은 Suricata를 탐지로 수동적으로 유지하고 예방을 위해 방화벽 규칙을 사용하며 자산이 장애 폐쇄 위험을 정당화하는 경우에만 인라인으로 업그레이드합니다.
6. 보안 도구 컬렉션의 위치: Snort와 함께 서명 IDS의 최신 기본값입니다. 더욱 풍부한 메타데이터 출력으로 인해 Zeek급 NSM 다음으로 첫 번째 SOC 스택의 센서 구성 요소로 적합합니다. Trivy/openvas는 취약성을 다루고 Wazuh는 엔드포인트 집계를 담당합니다.

현장 노트

클라이언트를 설득한 Suricata 배포는 알림이 아니라 메타데이터였습니다. EVE JSON이 Elastic 스택에 도착했고, 첫 번째 헌트 쿼리가 미스터리 중단을 TLS 갱신 기간에 몇 분 만에 조정했습니다. 센서는 사고 사이에 랙 공간을 확보합니다.

자주 묻는 질문