[1~2주차] github 오픈소스 자료조사 (Suricata)

 

[오픈소스 분석을 위해 GPT에게 질문]

 

[선택한 OSS]

https://github.com/OISF/suricata

GitHub - OISF/suricata: Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monit

 

[개요] Suricata 는 실시간 네트워크 모니터링을 통해 악성 트래픽을 탐지&차단하는 IDS/IPS 시스템

[언어] C언어

[목표] 멀티스레딩, 성능 최적화에 중점을 두었음

 

 

 

[Suricata의 핵심 주요 모듈]

Packet Capture

 

• 주요 파일:
  • source-af-packet.c 및 source-pfring.c: 각각 AF_PACKET, PF_RING 방식에 관한 코드가 포함
  • source-pcap.c: PCAP 기반 패킷 캡처가 구현
  • suricata.yaml: 각 패킷 캡처 방식의 설정을 관리하는 곳이며, 모듈이 실행될 방식을 정의
• 분석 방법:
  • 각 캡처 방식의 source-*.c 파일을 통해 패킷이 Suricata로 전달되는 과정을 확인
  • 예를 들어, Decode 및 Thread에 관련된 함수들은 패킷이 네트워크 인터페이스에서 읽힌 뒤, 스레드 간에 어떻게 분배되고 처리되는지 보여줌

 

 

Detection Engine

 

• 주요 파일:
  • detect-engine.c: Detection Engine의 주요 로직이 포함된 파일. 여기서 패킷의 흐름과 상태를 유지하며, 각 규칙과 비교하는 작업을 수행
  • detect.c: 패턴 매칭 및 규칙 적용 로직을 관리
  • flow.c 및 flow-manager.c: 플로우 기반 트래픽 처리에 필요한 기능을 담당하며, 플로우 테이블을 통해 상태를 관리
• 분석 방법:
  • detect-engine.c에서 엔진의 초기화와 규칙 매칭의 전체적인 흐름을 확인
  • detect.c와 함께 sigmatch.c를 확인해, 매칭 프로세스와 트래픽이 규칙을 만족하는지 확인하는 과정을 파악

 

 

두 모듈 모두 다중 스레드 구조와 부하 분산이 중요한 역할을 함

패킷 캡처와 감지 엔진은 각각 스레드를 활용하여 부하를 나누고 병렬로 처리할 수 있도록 설계되어 있음

이 구조 덕분에 Suricata는 많은 트래픽을 동시에 처리 가능

• 이점: 다중 큐와 부하 분산을 통해 각 스레드가 독립적으로 작업을 수행하며, 패킷 캡처에서 감지 엔진으로의 데이터 흐름을 원활하게 유지
• 한계: 다중 스레드 환경에서 플로우가 올바르게 관리되지 않으면 패킷 순서가 뒤바뀔 수 있으며, 이는 잘못된 탐지 결과를 초래할 수 있음

 

 

 

📁suricata/.clusterfuzzlite

-> Fuzzing(코드의 잠재적 취약성 테스트) 설정 및 빌드 환경 정의

1. Dockerfile

• 기능: Suricata의 Fuzzing 환경을 구성하는 Docker 이미지를 정의
• 주요 설정:
  • 기본 이미지: gcr.io/oss-fuzz-base/base-builder-rust을 기반으로 하여 Rust 언어와 필요한 도구를 설치.
  • 패키지 설치: build-essential, libtool, tshark 등 Suricata 빌드 및 Fuzzing에 필요한 라이브러리를 설치.
  • 추가 소스: pcre2, libpcap, jansson, libyaml, lz4 등 Suricata에 필요한 외부 라이브러리를 다운로드하고, Git 리포지토리에서 libhtp, fuzzpcap 같은 라이브러리를 클론
  • Rust 설정: Fuzzing에 필요한 Rust 툴체인(nightly)과 cbindgen을 설치해 Rust 코드와 C 코드를 연동.

2. build.sh

• 기능: Docker 컨테이너 내부에서 Suricata를 빌드하고 Fuzzing 테스트를 설정하는 스크립트
• 주요 단계:
  • 의존성 빌드: Fuzzing 옵션에 맞게 의존성을 정적으로 컴파일(zlib, pcre2, jansson, libpcap, libyaml 등).
  • 라이브러리 설치: libhtp, fuzzpcap, lz4 등 필요 라이브러리들을 설치하여 Suricata 빌드 환경을 구성.
  • Fuzzing 관련 설정: SANITIZER 옵션에 따라 Rust와 C 코드에 Fuzzing 관련 옵션을 적용하고, oss-fuzz-configure.sh 스크립트를 사용해 Suricata의 Fuzzing 환경을 초기화.
  • Seed Corpus 설정: Google의 OSS-Fuzz 저장소에서 seed corpus를 다운로드하여 Fuzzing의 초기 데이터를 준비하고, 각 Fuzzing 바이너리 및 딕셔너리를 설정

3. project.yaml

• 기능: Fuzzing 프로젝트의 메타 정보를 설정
• 주요 설정:
  • 기본 정보: Suricata의 홈페이지 URL과 언어(Rust), 주 연락 담당자와 추가 연락자 정보.
  • Sanitizers: address, memory, undefined와 같은 다양한 Sanitizer를 설정하여 Fuzzing 시 잠재적 메모리 오류나 정의되지 않은 동작을 감지.
  • Fuzzing 엔진: afl, honggfuzz, libfuzzer와 같은 Fuzzing 엔진을 사용하여 Suricata의 코드에 다양한 방식의 Fuzzing을 적용
  • 주 리포지토리: 프로젝트의 주 리포지토리 링크를 지정하여 Suricata의 최신 소스 코드를 참조.

 

[성능 & 기능]

📁suricata/.src 

 

• 패킷 캡처 및 인터페이스 모듈
  • Suricata는 네트워크 트래픽을 수집하기 위해 다양한 인터페이스(예: AF_PACKET, PCAP, PF_RING)를 지원
  • source-*.c 파일들: 다양한 캡처 소스의 구현체로, 각 파일은 특정 캡처 방법을 정의
  • capture.c: Suricata가 사용할 캡처 인터페이스와 방식을 관리하고 제어
• 패킷 디코딩 모듈
  • 패킷을 수집한 후 각 프로토콜(IP, TCP, UDP 등)로 구분하여 해석하는 기능을 담당
  • decode.c 및 decode-*.c: 패킷을 각 레이어별로 분류하고 분석할 수 있도록 해석하는 파일
  • 디코더는 레이어별로 분리하여 트래픽이 어디서 발생했는지를 추적할 수 있게 합니다.
• Detection Engine (탐지 엔진)
  • 패킷에서 발생하는 이벤트와 규칙을 대조하여 보안 위협을 탐지하는 엔진
  • detect-engine.c 및 detect.c: 규칙 기반 탐지 로직을 수행하여 패킷이 규칙 조건에 맞는지 여부를 확인
  • app-layer-protocol.c 파일: 애플리케이션 계층에서 발생하는 특정 이벤트나 이상 패턴을 감지하는 데 사용
• 플로우 및 세션 관리
  • Suricata는 연결 기반 분석을 위해 플로우(Flow) 관리 기능을 가짐.
  • --> 이는 연결 상태와 세션 정보를 추적하여 정확한 탐지를 가능하게 함
  • flow.c, flow-manager.c: 네트워크 연결 상태를 추적하여 양방향 트래픽을 올바르게 관리
  • stream-tcp.c 및 stream.c: TCP 스트림의 흐름을 관리하고, 비정상적인 스트림이나 세션을 탐지하는 데 사용
• 로깅 및 출력 모듈
  • 탐지된 보안 이벤트와 패킷 정보를 다양한 형식으로 기록하여 보안 로그를 생성
  • output-json.c: JSON 형식으로 탐지 결과를 기록하는 파일로, Suricata가 다양한 외부 시스템과 통합
  • output.c 및 기타 로깅 관련 파일들: 탐지 결과를 다양한 형식으로 출력하며, 로그 저장 방식도 설정
• 구성 파일 및 초기화:
  • Suricata의 설정 파일(suricata.yaml)을 읽고 이를 통해 각 모듈을 초기화
  • conf.c: 설정 파일의 내용을 Suricata 모듈들이 사용할 수 있도록 구성
• 기타 유틸리티 및 도구:
  • Suricata의 다양한 기능을 보조하는 유틸리티와 도구들
  • util-*: 메모리 관리, 문자열 처리 등 Suricata의 전반적인 기능을 지원

 

📁suricata/ rules  -> 네트워크 탐지 규칙들

{주요 프로토콜 관련 파일들}

 

📄 suricata / rules / http-events.rules 

HTTP 프로토콜 이상 감지를 목적으로 하는 규칙들 정의 / 고유한 sid를 가지고 오류 감지

• 이상 감지 유형: 규칙들은 알려지지 않은 HTTP 오류, 누락된 헤더, 잘못된 전송 인코딩, 과도하거나 부족한 필드 등 다양한 HTTP 프로토콜 오류를 포착
• 규칙 구조: 각 규칙은 흐름 방향, 조건(예: 누락된 헤더), 이벤트 타입(app-layer-event), 카운터 증가(flowint:http.anomaly.count,+,1) 등을 정의
• 목적: HTTP 기반의 잠재적인 공격이나 비정상적 행위를 탐지하여 보안 모니터링에 기여

📄 suricata / rules / dns-events.rules 

DNS 프로토콜에 관한 비정상적인 동작을 감지하는 규칙 정의

• Malformed Data: 요청 또는 응답 데이터의 형식이 잘못된 경우를 감지 (sid:2240002, sid:2240003).
• 잘못된 요청/응답 플래그: 요청 플래그가 잘못 설정된 경우 (sid:2240004), 응답 플래그가 잘못 설정된 경우 (sid:2240005).
• Z Flag: 예약된 Z 플래그가 0이 아닐 때 감지 (sid:2240006).
• Invalid Opcode: 잘못된 Opcode가 있을 경우 감지 (sid:2240007).

📄 suricata / rules / dns-events.rules 

TLS 프로토콜의 비정상적인 동작을 감지하기 위한 규칙 정의

1. TLS 헤더/레코드 유효성 검사:
   • 잘못된 SSLv2/TLS 헤더, 레코드 버전, 레코드 유형 등을 감지하여 비정상적인 세션을 탐지 (sid:2230000, sid:2230001, sid:2230002, sid:2230015 등).
2. 인증서 검증:
   • 유효하지 않은 인증서와 관련된 오류를 감지하여 인증서 위조를 탐지할 수 있습니다. 예: 잘못된 인증서 길이, 날짜, 발행자 (sid:2230004, sid:2230021~sid:2230030).
3. Heartbeat 공격 탐지:
   • Heartbleed 취약점 관련 오버플로우 또는 데이터 유출 탐지를 통해 취약점 공격을 방어 (sid:2230012~sid:2230014).
4. SNI 확장 오류:
   • 잘못된 Server Name Indication(SNI) 정보 감지 (sid:2230016, sid:2230017, sid:2230018).

 

{인프라 관련 파일들}

📄 suricata / rules / ssh-events.rules 

SSH 프로토콜과 관련된 비정상적인 이벤트 감지하는 규칙 정의

• 잘못된 배너 탐지:
  • SSH 연결 중 수신된 배너가 잘못되었거나 비정상적인 경우 감지 (sid:2228000)
• 너무 긴 배너:
  • SSH 배너가 허용된 길이보다 긴 경우 감지하여 비정상적인 연결 시도를 파악 (sid:2228001)
• 잘못된 레코드:
  • SSH 레코드가 예상 형식과 일치하지 않는 경우 감지하여 데이터 손상이나 공격을 방지 (sid:2228002)

📄 suricata / rules / smtp-events.rules 

SMTP에서 발생할 수 있는 비정상적이거나 의심스러운 행동을 감지하는 규칙 설정

• 비정상 응답 및 매칭 오류:
  • SMTP 응답이 비정상적이거나 요청과 일치하지 않는 경우 탐지
• 명령 및 응답 길이 초과:
  • 너무 긴 명령 또는 응답 라인을 탐지하여 비정상적인 데이터 전송을 감지
• TLS 거부 및 데이터 명령 거부:
  • TLS 또는 데이터 명령이 거부된 경우 감지하여 보안 이벤트를 추적
• MIME 관련 경고:
  • MIME 파싱 오류, 잘못된 Base64 인코딩, 긴 MIME 헤더 등의 비정상적인 MIME 형식을 탐지
• 중복 필드 및 구문 오류:
  • SMTP 메시지에 중복 필드가 포함되거나 구문 분석이 불가능한 콘텐츠가 발견될 때 경고를 생성
• 파일 이름 및 경계 초과:
  • 파일 이름이 너무 길거나 MIME 경계 길이가 초과된 경우 탐지

📄 suricata / rules / ftp-events.rules 

FTP 프로토콜에서 발생할 수 있는 비정상적 상황을 감지하는 규칙들 정의

• 요청 명령 길이 초과 (sid:2232000):
  • 클라이언트에서 서버로 전송되는 FTP 요청 명령이 너무 길 때 경고를 생성. 이는 비정상적이거나 악의적인 FTP 활동의 징후일 수 있음
• 응답 명령 길이 초과 (sid:2232001):
  • 서버에서 클라이언트로 전송되는 응답 명령이 너무 길 때 경고를 발생시킴. 이 역시 비정상적인 활동을 탐지할 수 있는 규칙

 

 

{이벤트 & 오류 모니터링}

📄 suricata / rules / stream-events.rules 

TCP 스트림에서 발생하는 다양한 비정상 상황을 탐지하는 규칙들로 구성됨

• 3-Way 및 4-Way 핸드셰이크 오류: 잘못된 순서나 ACK(확인 응답) 문제, 잘못된 SYN/ACK 패킷 등 TCP 핸드셰이크 과정에서 발생하는 문제를 감지
• FIN, CLOSEWAIT 및 TIMEWAIT 상태의 비정상 패킷: 정상적인 연결 종료 프로세스 중 비정상적인 ACK 또는 FIN 시퀀스를 탐지
• 재전송 이벤트: 중복 데이터 전송이나 초과된 재전송이 감지되면 이를 경고하여 네트워크 혼잡이나 공격을 추적
• 기타 비정상 이벤트: 잘못된 타임스탬프, 잘못된 TCP 윈도우 업데이트 등 여러 특이사항을 모니터링

 

📄 suricata / rules / decoder-events.rules 

디코더 관련 규칙 정의 -> 네트워크 패킷 구조 & 프로토콜 준수 여부 감시

• IPv4/IPv6 패킷 이상: 패킷의 크기가 너무 작거나 헤더 길이가 잘못된 경우, 잘못된 옵션 사용 등이 탐지
• ICMP, TCP, UDP 문제: 패킷 크기 오류, 잘못된 헤더 길이, 허용되지 않은 코드 등을 감시
• MPLS, VLAN, GRE 등 다양한 프로토콜: 지원되지 않는 타입이나 잘못된 필드 값에 대한 경고를 제공
• 중복 레이어 및 기타 문제: 패킷 레이어가 너무 많거나 예기치 않은 데이터가 포함된 경우 탐지

 

 

[문서 및 설정 파일]

📁 suricata / README.md  -> Suricata의 목적 & 보안 개선사항

1. 프로젝트 개요

• Suricata는 네트워크 침입 탐지 시스템(IDS), 침입 방지 시스템(IPS), 그리고 네트워크 보안 모니터링(NSM) 엔진. 이는 OISF(Open Information Security Foundation)와 Suricata 커뮤니티에 의해 개발되었음
• 네트워크 보안을 위해 주로 사용되며, 신뢰할 수 없는 데이터를 다루므로 입력 처리 오류가 발생할 경우 심각한 보안 위협이 될 수 있음

2. QA(품질 보증) 프로세스

• Suricata는 코드 품질과 보안을 보장하기 위해 다단계의 품질 보증 과정을 거침
• GitHub-CI 체크: PR(Pull Request)이 생성되면 자동으로 실행됨
• 개발자 및 커뮤니티 리뷰: 코드 리뷰를 통해 코드 품질과 보안성을 평가함
• 프라이빗 QA 환경에서의 테스트: 다양한 운영 체제와 컴파일러, 최적화 설정, 정적 및 동적 코드 분석, 패킷 기반 Fuzzing 테스트 등 다양한 QA 테스트를 수행하여 기존 기능을 검증함
• 수동 테스트: 변경 사항에 따라 추가로 수행할 수 있는 수동 테스트로는 트래픽 재생 테스트, 대용량 패킷 처리, 성능 테스트 등이 있음
• Coverity Scan: 코드 병합 후, Coverity Scan을 통해 코드 분석을 수행하여 추가적인 문제를 찾음

3. 기여 및 PR 프로세스

• PR을 기여할 때 QA 절차를 통과해야 하며, GitHub-CI 실패가 있으면 수정을 요구
• 코드 품질이 낮거나 커뮤니티 및 팀에서 해당 기능이 불필요하다고 판단되면 PR이 거부될 수 있음
• Contributing 절차에서는 PR이 QA 실패 시 자동으로 닫히며, 코드의 품질이나 성능 문제가 있을 경우 개선을 요구

4. 자주 묻는 질문(FAQ)

• PR 승인 여부, 병합 시기, PR이 닫히는 이유에 대한 설명이 포함됨
• QA 과정에서 발생하는 경고나 오류는 자동화 도구에서 감지되며, 가능한 경우 Suppression(억제)을 추가하거나 코드 리팩터링을 통해 오류를 수정해야 한다는 방침이 있음

 

📁suricata / doc  -> Suricata의 기능 & 설정 방법

📁 suricata / doc /doxygen

[📄.gitignore]

doxygen 폴더 안의 모든 파일, 폴더를 무시하되, .gitignore 파일만 Git에서 추적하도록 하기 위함

Doxygen 문서를 자동으로 생성하는 스크립트 사용 시 설정됨

📁 suricata / yamal.in  -> Suricata의 설정 파일 & IDS/IPS 성능에 영향을 미치는 설정 옵션

1. 기본 정보와 네트워크 구성 (vars 섹션)

• HOME_NET과 EXTERNAL_NET: IDS/IPS가 모니터링할 내부 네트워크와 외부 네트워크를 설정
• 다양한 서비스 서버(HTTP, SMTP, SQL 등)에 대해 네트워크 그룹을 지정하여 트래픽을 필터링하고 모니터링 가능

2. 출력 설정 (outputs 섹션)

• fast.log: 간단한 로그 파일로, 경고를 기록
• eve.json: JSON 형식의 다목적 로그 파일로, Suricata의 이벤트와 경고를 세부적으로 기록. Redis 서버로 전송하거나 JSON을 멀티스레딩으로 관리하는 옵션도 제공
• pcap-log: 패킷을 pcap 형식으로 기록해 패킷 캡처를 제공

3. 애플리케이션 계층 프로토콜 설정 (app-layer 섹션)

• HTTP, DNS, TLS 등 주요 애플리케이션 계층 프로토콜을 위한 탐지 옵션을 설정
• 예를 들어, tls 설정에서는 JA3 지문 생성, 세션 복원 및 암호화 처리 방식 등을 지정

4. 캡처 옵션 (af-packet, pcap, dpdk 등)

• AF-Packet: 네트워크 인터페이스와 직접 통신하여 고속 패킷 캡처를 지원하며, 클러스터링과 메모리 맵 옵션을 통해 성능을 최적화
• PCAP: libpcap 기반 패킷 캡처로, 네트워크 트래픽을 파일에서 읽을 수 있는 옵션을 제공
• DPDK: 고속 패킷 캡처를 위한 DPDK 설정으로, RX/TX 큐와 메모리 풀 크기를 조정

5. 탐지 엔진 설정 (detect 섹션)

• 프로파일: 서명 그룹의 메모리 사용량과 성능을 최적화하기 위해 탐지 엔진의 프로파일을 low, medium, high로 조정
• MPM (Multi-Pattern Matching) 알고리즘: 여러 패턴을 동시에 탐지하는 알고리즘을 지정해 성능을 최적화. 예를 들어 ac(Aho-Corasick)나 hs(Hyperscan)가 있음

6. 플로우 설정 (flow 섹션)

• 메모리 사용량과 해시 크기 등을 설정해 플로우(Flow) 추적 효율을 높이고, 메모리 초과 상황에서 긴급 복구를 위한 매개변수를 정의

7. 프로파일링 설정 (profiling 섹션)

• 규칙 프로파일링: 규칙 실행 성능을 기록하여 최적화의 기초 자료로 활용
• 키워드 및 패킷 프로파일링: 각 키워드와 패킷의 성능을 분석해 Suricata의 작동 효율성을 진단

 

📁 suricata / threshold.config  -> Suricata의 설정 파일 & IDS/IPS 성능에 영향을 미치는 설정 옵션

주요 명령어 및 옵션

1. Thresholding 명령어:
   • threshold와 event_filter 구문으로 특정 경고의 발생 빈도를 제한
   • 예시: threshold gen_id 0, sig_id 0, type limit, track by_src, count 10, seconds 10는 같은 소스 IP에서 10초 내 최대 10개의 경고만 기록하도록 제한
2. Suppress 명령어:
   • 특정 조건에서 경고를 완전히 억제합니다.
   • 예시: suppress gen_id 1, sig_id 2009557, track by_src, ip 217.110.97.128/25는 해당 IP 주소 범위에서 발생하는 특정 경고를 억제하여 기록하지 않음

주요 옵션

• gen_id와 sig_id: Suricata 규칙의 고유 식별자로, 특정 경고를 타겟팅할 수 있음
• type: 제한 방식 지정 (limit, threshold, both 중 선택).
• track: IP 기준 경고 추적 방법 (by_src는 소스 IP별 추적, by_dst는 대상 IP별 추적).
• count와 seconds: 경고 횟수와 시간 간격을 설정하여 경고 빈도를 조정

적용 예시

• 특정 IP 범위에서 발생하는 잦은 경고를 억제하여 불필요한 로그가 쌓이지 않도록 하고, 특정 경고는 빈도를 제한해 과도한 이벤트 발생을 방지