🕸️ [클래식] Bro — 공격 '서명'이 아니라 네트워크의 '사건'을 정의한 최초의 실시간 침입 탐지기

논문 정보

한 줄 요약 — "공격 이름을 미리 나열하면, 목록에 없는 공격은 못 잡는다"

1998년의 상용 침입 탐지 제품은 대개 공격 시그니처 라이브러리를 앞세웠다. Vern Paxson은 그 반대에서 출발한다. 네트워크에서 실제로 일어난 일을 사건(event)으로 정규화해 올려보내는 이벤트 엔진과, 그 사건을 어떻게 해석하고 대응할지를 적는 정책 스크립트 인터프리터를 분리했다. 엔진은 "무엇이 일어났는가"만 알고, "무엇이 문제인가"는 사이트의 스크립트가 결정한다.

이 분리가 단순한 설계 취향이 아니었던 이유는 성능과 확장성이다. Bro는 1996년부터 LBNL의 100 Mbps FDDI 링(하루 약 20 GB)을 상시 감시했고, 바쁜 시간대에 초당 8,800 패킷(25 Mbps)·피크 15,000 pps를 처리하면서 패킷을 거의 떨어뜨리지 않았다. 정책을 바꾸려고 C++ 22,000줄을 다시 컴파일하는 대신, 스크립트 1,900줄을 고치면 됐다.

"Bro is divided into an 'event engine' that reduces a kernel-filtered network traffic stream into a series of higher-level events, and a 'policy script interpreter' that interprets event handlers written in a specialized language used to express a site's security policy." — 초록

배경 — 1996년, 왜 '수동 모니터'였나

• 문제의 크기: LBNL은 수천 대의 이기종·분산 관리 호스트를 운영했다. 호스트마다 에이전트를 심는 방식은 현실적이지 않았고, 인터넷으로 나가는 DMZ 링크 하나를 수동으로 감시하면 가장 큰 공격 유입 지점을 경제적으로 볼 수 있었다.
• 속도가 곧 요구사항: 그 링크는 FDDI 링이라 최대 100 Mbps, 하루 약 20 GB가 흐른다. 패킷 필터가 트래픽을 따라가지 못해 패킷을 버리면, 버려진 패킷에 정확히 침입의 증거가 들어 있을 수 있다. "공격 중에 트래픽 폭주가 겹치지는 않겠지"라는 가정은, 공격자가 모니터 자체를 공격할 수 있다는 점에서 즉시 무너진다.
• 기존 제품과의 차이: 논문은 상용 제품들이 더 정교한 UI와 관리 도구, 더 큰 시그니처 라이브러리를 갖췄다고 인정하면서도, "모니터를 어떻게 만드는가"에 대한 상세한 기술 문헌은 없다고 지적한다. Bro는 제품이 아니라 시스템 논문이다.
• 이름의 유래: Bro는 조지 오웰의 1984에 나오는 감시자를 연상시키는 이름으로, 저자 스스로 "감시에는 프라이버시 침해의 가능성이 함께 온다"는 오웰식 경고라고 밝힌다. 2018년 프로젝트가 Zeek으로 개명한 배경에도 이런 이름의 부담이 있었다.

핵심 1 — 두 개의 상자: 이벤트 엔진과 정책 인터프리터

• 아래층(메커니즘): 커널 BPF 필터가 SYN/FIN/RST 제어 비트 위주로 트래픽을 추리고, 스냅샷 길이를 패킷 전체로 잡는다(내용 분석을 위해). 이벤트 엔진은 헤더 정합성을 검사하고, (출발지·목적지 IP, 포트) 튜플로 연결 상태를 찾고, TCP 바이트 스트림을 순서대로 재조립하고, 타이머 큐를 관리한 뒤 고수준 사건을 만든다.
• 위층(정책): 정책 스크립트 인터프리터가 사건 핸들러를 실행한다. 핸들러는 상태를 갱신하고, 새로운 사건을 합성하고, 로그를 디스크에 남기고, syslog로 실시간 통지를 보낼 수 있다. 즉 탐지 로직이 패킷 파서와 분리되어 있다.
• 구현 규모: C++ 약 22,000줄 + Bro 정책 스크립트 1,900줄(그중 약 1,650줄은 사이트 특화가 아닌 공통 보일러플레이트). 단일 스레드 설계이며 Digital Unix, FreeBSD, IRIX, SunOS, Solaris에서 동작했다.
• 왜 굳이 분리했나: 트래픽이 많은 환경에서는 "무엇을 필터링하고, 얼마나 들여다보고, 어떻게 대응할지"를 상황에 따라 계속 조절해야 한다. 이 결정을 C++에 하드코딩하면 정책 하나 바꿀 때마다 시스템을 다시 만들어야 한다. 분리는 단순성뿐 아니라 현장에서의 변경 가능성을 사는 거래였다.

핵심 2 — 정책 언어가 '시그니처 목록'을 대체한다

• 상태를 가진 탐지: 핸들러가 상태를 유지할 수 있으므로 판단 단위가 "패킷 한 개"가 아니라 "연결의 역사"가 된다. 대표 예가 FTP bounce다. FTP 클라이언트가 PORT 명령으로 데이터 연결을 자기 자신이 아닌 제3의 피해 사이트로 돌리면, 서버를 이용해 임의 서비스로 업로드하거나 포트 스캔을 할 수 있다. Bro는 PORT 요청의 리다이렉션을 플래그했다. 논문은 "쉬워서 넣었는데, 몇 달 뒤 실제 FTP bounce 공격을 관측했다"고 적는다.
• NUL 바이트에 강한 문자열: Bro 문자열은 C처럼 NUL로 끝나는 배열이 아니라 (길이, 바이트 벡터)다. 공격자가 USER nice\0USER root처럼 NUL을 끼워 모니터가 보는 사용자명과 서버가 해석하는 사용자명을 다르게 만드는 subterfuge를 원천 차단한다.
• 포트가 아니라 프로토콜로 식별: Finger, FTP, Portmapper, Telnet 네 개의 애플리케이션 분석기를 내장했다. 표준 포트를 쓰지 않는 FTP 데이터 연결도 PORT/PASV 문법을 파싱해 ftp-data로 식별한다. 이는 "포트 21이면 FTP"라는 시그니처적 사고와 정반대다.
• 정책 중립성: 엔진은 사건을 만들 뿐 유죄를 선고하지 않는다. 같은 사건 스트림 위에서 사이트마다 다른 정책을 쓸 수 있고, 새 공격이 나타나도 엔진을 고치지 않고 스크립트만 추가하면 된다.

핵심 3 — 모니터 자신이 공격 표적이다

• 과부하 공격(overload): 트래픽을 폭주시켜 패킷 필터 버퍼를 고갈시키면, 모니터는 정확히 공격 관련 패킷을 놓친다. Bro는 net stats 사건으로 수신·필터 드롭·커널 드롭 수치를 주기적으로 정책에 알려, 스크립트가 "지금 내가 눈이 먼 상태인가"를 판단하게 한다.
• 크래시 공격(crash): 자원 고갈이나 구현 버그로 모니터를 멈추게 하는 공격. Bro는 Unix alarm 기반의 워치독 타이머를 두어, 이벤트 엔진이 T초 전에 처리하던 패킷을 아직 끝내지 못했으면 정체 상태로 간주하고 복구 절차를 밟는다.
• 기만 공격(subterfuge): 모니터와 실제 호스트가 같은 트래픽을 다르게 해석하도록 만드는 공격 — IP 단편, 겹치는 TCP 재전송, NUL 삽입, 비표준 포트 등. 방어의 원칙은 매 단계에서 암묵적 가정을 명시화하고, 가정이 깨지면 사건을 발생시키는 것이다. 겹치는 재전송의 내용이 원본과 다르면 알람을 올리고, IP 단편은 재조립하며, 애플리케이션 계층까지 파싱한다.
• 1998년의 연결: 같은 해 USENIX Security에서 Ptacek와 Newsham이 발표한 Insertion, Evasion, and Denial of Service는 상용 IDS 4종을 이 세 가지 기법으로 무력화했다. Bro의 5장은 같은 문제를 설계 단계에서 다룬 셈이다 — "탐지 시스템도 공격받는 시스템이다"라는 명제를 아키텍처에 새긴 것.

숫자로 본 운영 결과 (1998년 논문 기준)

• 정직한 각주: 온라인 판 논문은 인쇄본 7장이 FDDI 링의 트래픽 수준을 2배 과장했다고 밝히며 수치를 정정한다. 1998년의 25 Mbps는 당시로선 결코 가벼운 부하가 아니었다.
• 한계도 숫자로 드러난다: "interesting networks" 필터를 끄고 30분간 돌린 스트레스 테스트에서 평균 640 pps(피크 800 pps)를 받아들이면서 364개 패킷을 드롭했다. 저자는 사용한 하드웨어가 이미 최신이 아니었다고 덧붙인다 — 고속화는 끝이 없는 문제임을 스스로 인정한 셈이다.

왜 지금도 읽는가 — 30년 뒤 Zeek이 된 설계

• 인용 2,423회의 무게: 1990년대 후반 "실시간 + 고속 + 정책 언어"를 한 시스템에서 보여준 사례는 드물었다. 이후 네트워크 보안 모니터링(NSM) 연구와 제품 설계의 공통 기준점이 됐다.
• Zeek의 탄생: Bro 프로젝트는 2018년 Zeek으로 이름을 바꿨다. 오늘의 Zeek는 ⭐8,116, C++ 코드베이스, 2026년 8월 v9.0.0을 내놓았고 2026년 10월에도 활발히 푸시되고 있다. 방화벽·SIEM과 함께 SOC의 네트워크 사실(fact) 계층을 담당한다.
• "시그니처 IDS가 아니다": Zeek의 설명 문구는 여전히 "전형적인 IDS와는 매우 다른 네트워크 분석 프레임워크"라고 말한다. 탐지 룰을 나열하는 대신 연결·DNS·HTTP·TLS·파일 전송 같은 사건과 로그를 만들고, 그 위에 정책을 얹는다. 이 철학이 1998년 논문의 두 상자 구조 그대로다.
• 현대 탐지 엔지니어링의 원형: 오늘날의 "탐지 로직과 데이터 수집 파이프라인을 분리하라", "행위 기반 탐지", "탐지 코드도 공격 표면이다"라는 원칙은 이 논문이 훨씬 앞서 실증한 것이다. 공격 서명이 아니라 관측 가능한 사건 모델을 먼저 설계하라는 조언은 LLM·클라우드 시대에도 유효하다.

한계와 오늘의 관점

• 하드웨어 시대의 제약: 100 Mbps FDDI, 단일 스레드, 인터프리터 기반 정책 실행. 오늘날의 10/40/100 Gbps 링크와 암호화된 트래픽(TLS 1.3, QUIC)에는 그대로 적용할 수 없다. Zeek가 별도 진화한 이유다.
• 탐지 범위는 정책 작성자에게 달려 있다: 내장 분석기는 네 개뿐이고 공격 시그니처 라이브러리도 없다. "무엇이 문제인지"를 정의하는 일은 여전히 사람의 몫이며, 이는 장점이자 부담이다.
• 전체 패킷 캡처의 비용: 내용 기반 분석은 저장·성능·프라이버시 비용을 동반한다. 저자가 이름부터 오웰식 경고로 삼은 이유이기도 하다. 오늘날에는 최소 수집·보존 기간·접근 통제가 설계 요구사항이 됐다.
• 그래도 남는 교훈: ① 메커니즘과 정책을 분리하라. ② 탐지 시스템도 공격받는다고 가정하라. ③ "패킷을 다 본다"는 착각 위에 탐지를 세우지 말고, 해석의 차이를 먼저 고려하라. 이 세 문장은 1998년과 2026년에 똑같이 유효하다.

출처

• 논문: Vern Paxson, Bro: A System for Detecting Network Intruders in Real-Time, 7th USENIX Security Symposium (1998-01-26–29) — PDF
• 확장판: Computer Networks 31(23–24), 1999 — DOI (OpenAlex 인용 2,423회)
• 현재 구현체: Zeek 프로젝트 · 문서 · GitHub (⭐8,116, v9.0.0)
• 함께 읽기:
  • 2026-10-02 Insertion, Evasion, and Denial of Service: 상용 IDS 4종을 무력화한 1998년의 자매 논문. Bro 5장이 설계로 답한 문제를 공격자 관점에서 정면으로 다룬다.
  • 2026-09-14 Security Problems in the TCP/IP Protocol Suite: 같은 시대, "인터넷의 신뢰 가정"을 처음 체계적으로 의심한 고전. Bro의 재조립·정합성 검사가 왜 필요한지 보여준다.
  • 2026-10-12 Tor: The Second-Generation Onion Router: 대규모 수동 감시가 일상이 된 세계에 대한 반대편 설계. Bro의 이름이 던진 프라이버시 경고와 함께 읽으면 균형이 잡힌다.