Bro

https://www.bro.org/

 Bro를 잠시 리뷰해 보았다. "Bro는 침입탑지 시스템중 하나이다."라고 단순하게 말하기에는 많은 변화가 있었다. 여러 가지 장점이 생겼는데, 개인적으로 높이 평가하고 싶은 사항은 클러스터링, 스크립트 언어, 로드밸런싱 메카니즘 등 이다. 본연의 기능 및 성능과 확장성을 고려한 발전이 두드러진다고 생각한다.  

Bro는 네트워크 패킷을 읽어 유해한 내용을 탐지하는 일종의 Network IDS(Intrusion detection system)라는 포인트 솔루션에서 출발하여, 발전에 발전을 거듭해서, 이제는(2014) 다양한 탐지를 수행하고 클러스터링과 스케일러빌리티를 갖추는 등 하나의 보안 프레임워크로써 자리잡게 되었다.

 내가 Bro는 처음 보았을 때, 대략 10여년 전이었던, 2004년 경으로 기억된다. 당시에 snort가 침입탐지 시스템의 대부격으로 자리잡고 있었다.(지금도 snort는 여전히 강력한 도구다.) 그때, Bro는 1Gbps 네트워크 탐지 성능을 갖추는 것을 목표로 코드를 전부 새로 만들던 것으로 기억한다. 지금은 10 Gbps 망이 실전 배치된 상황이지만, 당시에는 1Gbps 망이 진보된 망이었다. 

Bro의 발전 히스토리.

대부분의 IDS, IPS가 다수 rule(signature) 환경에서 성능 문제을 가지고 있었던 시기고, 이를 극복하고자 하는 노력이 당시  IDS, IPS 분야 보안업계의 주된 이슈였다.

Bro의 발전을 얘기하기에 앞서 snort를 먼저 알아볼 필요가 있다. snort(당시 2.0 버전)는 성능 및 확장성을 고려하지 못한 코드로 작성되어 있었다. 쓰레드(thread)를 통한 병렬성이나, 프로세스를 통한 병렬성(process parallelism) 등을 고려하지 않은 코드였다. 또한 룰도 주먹구구식으로 만들어져 있었고, 적절히 분류되지 않아서 관리 및 병렬성(data parallelism)을 확보하는데는 부족함이 많았다. 그러나, 당시 네트워크 패킷 분석 도구중에서는 가장 유명하고 넓은 사용자 층을 확보하고 있었던 것이 사실이다. 

이러한 snort가 안고 있던 문제점은 새로운 시스템의 탄생를 유발했다. Bro, Suricata와 snort 3.0의 소프트웨어 내부 구조 재설계였다. 필자도, 당시 snort rule을 XML Schema를 만들어 XML형식으로 변환하고, 분류하였고, 병렬엔진구조로 변경하여 고성능 스노트를 개발했던 기억이 있다.

아래는 Bro 홈페이지의 내용을 일부 발췌하여 기술한 것이다.

----------------

Bro는 다음과 같은 아키텍쳐로 동작한다.

Bro의 내부 구조

Features

Bro는 자체의 스크립팅 언어를 통해 광역의 분석을 지원한다. 커스터마이징을 하지 않아도, 브로는 이미 강력은 특장점의 집합이다.

• 배포(Deployment)

  • Linux, FreeBSD, MacOS등 표준 유닉스 스타일 시스템이 운영되는 통상적인 하드웨어 상에서 동작.
  • 네트워크 탭 또는 모니터링 포트를 통해 완전한 패시브 트래픽 분석을 수행.
  • 패킷을 수집할 때 표준 libpcap 인터페이스 사용
  • 실시간(Real-time) 및 오프라인 분석(offline analysis).
  • 거대-스케일의 디플로이먼트를 위해 클러스터 지원.
  • 독자 실행 및 클러스터 셋업을 위한 단일화된 관리 프레임워크
  • BSD 라이센스를 가지며 오픈소스 임.

• 분석(Analysis)

  • 오프라인 분석과 포렌직을 위해 활동에 대한 포괄적인 로깅 .
  • 응용 레이어 프로토콜에 대해 포트에 독립적인 분석 
  • 다양한 응용 프로토콜 지원(DNS, FTP, HTTP, IRC, SMTP, SSH, SSL 등).
  • 응용 프로토콜에서 교환된 파일 컨텐츠 분석, 핑거프린트를 계산하기 위한 MD5/SHA1 연산.
  • 포괄적인 IPv6 지원.
  • 터널 탐지 및 분석(Ayiya, Teredo, GTPv1 등). Bro 터널의 암호화를 풀고, 만약, 터널이 없으며, 그 컨텐츠 분석을 계속한다.
  • 프로토콜을 분석하는 동안 광범위하게 동작의 정확성을 검사(Extensive sanity checks).
  • IDS-스타일 패턴 매칭 지원.

• 스크립팅 언어(Scripting Language)

  • 임의 분석 작업 기술을 위한 튜링 머신에 준하는 언어(Turing-complete language).
  • 이벤트 기반 프로그래밍 모델.
  • IP 주소, 포트 번호, 그리고 타이머와 같은 도메인에 특정된 데이터 타입, IPv4와 IPv6에 대한 투명한 핸들링.
  • 네트워크 상태를 전사적으로 트래킹하고 관리하는 확장성 있는 지원.

• 인터페이스(Interfacing)

  • 정교하게 구조화된 아스키 로그를 기본 출력(well-structured ASCII logs).
  • ElasticSearch와 DataSeries를 위한 백엔드 차선책. 진보된 데이터베이스 인터페이스가 (준비 중임).
  • 외부 입력을 분석을 위해 실시간 통합. 실시간 데이터베이스 입력이 준비중.
  • 외부 프로그램들과 Bro 이벤트를 교환하는 외부 C 라이브러리. Perl, Python,  Ruby 바인딩 지원.
  • 스크립트 언어 내에서 임의 개수의 외부 프로세스들에게 트리거할 수 있는 기능 .

Bro Cluster Architecture

Bro는 멀티쓰레드가 아니다. 그래서, 일단, 싱클 프로세서 코어의 한계가 있고, 현재 이를 위한 선택사항으로 부하를 다수 코어에 분배하는 것을 고려할 수 있다. 또는 다수 대의 컴퓨터에게 말이다. Bro의 클러스터 배포 시나리오는 거대한 Bro 시스템을 만드는 현재 솔루션이다. 도구들과 스크립트들은 많은 Bro 프로세스들을 쉽게 관리하고 패킷을 검사하고 활동을 상관분석 하는 단일로 보게하고 엔터티를 화합하게 하는 구조를 제공한다.  이 문서는 Bro 클러스터 구조에 대해 기술한다. Bro 클러스터를 구성하는 방법에 대한 정보를 원하면 다음 링크 문서 보도록 한다(BroControl).

Architecture

아래 그림은 Bro 클러스터의 주 구성요소를 보이고 있다.

Tap

탭(tap)은 감청을 위해 패킷 스트림의 복사본을 만드는 메커니즘이다. 예를 들어, 스위치에 있는 모니터링 포트, 또는, 광 네트워크상에 있는 광 분배기(optical splitter)가 있을 수 있다. 

Frontend

프론트엔드(frontend)는 이산 하드웨어 장치 또는 트래픽을 많은 스트림 또는 플로우들로 나누는 호스트 상의 기술이다. Bro 바이너리는 이 작업을 하지 않는다. 프론트엔드 역할을 수행하는 많은 방법이 있고, 몇몇 방법은 아래 프론트엔드 옵션 부분을 보기 바란다. 

Manager

매니저는 2개의 프라이머리 작업을 갖는 Bro 프로세스이다. 먼저, 로그 메시지들을 받고, Bro 통신 프로토콜을 사용하여 클러스터 내의 노드들의 나머지를 주의한다. 결과는 나중에 후처리를 위해 조합해야 할 많은 이산 로그가 아닌 단일 로그이다. 

 매니저는 노티스(notices)들의 중복을 제거(de-duplicate)할 경우가 있고, 그렇게 함으로써 notice를 위한 요충지(choke point)로써 동작하고 있는것과  어떻게 notices들이 액션으로 처리되는지 역할할 수 있다. 예를 들어, 이메일, 문자, 블록킹등이다.

매니저 프로세스는 초기 BroControl에 의해 시작되고, 지정된 포트를 열고 연결이 들어 오기를 대기한다. 또한, 클러스터의 나머지에 대해 임의의 연결을 초기화하기 않는다. 일단 워커가 시작되고 매니저에게 연결하면, 로그와 notice는 워커들로 부터 매니저 프로세스로 도착하기 시작한다.  

Proxy

프록시는 Bro 프로세스중 하나인데, 동기화 상태를 관리한다. 변수들(Variables)은 연결된 Bro 프로세스들 사이에서 자동으로 동기화될 수 있다. 프록시들은 모든 워커가 서로에게 직접 연결해야할 필요성을 완화하는 역할을 하여 워커를 돕는다.

 Examples of synchronized state from the scripts that ship with Bro include the full list of “known” hosts and services (which are hosts or services identified as performing full TCP handshakes) or an analyzed protocol has been found on the connection. If worker A detects host 1.2.3.4 as an active host, it would be beneficial for worker B to know that as well. So worker A shares that information as an insertion to a set which travels to the cluster’s proxy and the proxy sends that same set insertion to worker B. The result is that worker A and worker B have shared knowledge about host and services that are active on the network being monitored.

The proxy model extends to having multiple proxies when necessary for performance reasons. It only adds one additional step for the Bro processes. Each proxy connects to another proxy in a ring and the workers are shared between them as evenly as possible. When a proxy receives some new bit of state it will share that with its proxy, which is then shared around the ring of proxies, and down to all of the workers. From a practical standpoint, there are no rules of thumb established for the number of proxies necessary for the number of workers they are serving. It is best to start with a single proxy and add more if communication performance problems are found.

Bro processes acting as proxies don’t tend to be extremely hard on CPU or memory and users frequently run proxy processes on the same physical host as the manager.

Worker

워커는 Bro 프로세스 중 하나인데, 네트워크 트래픽을 스니핑하고, 유사한/닮은 트래픽 스트림에 대해 프로토콜 분석을 한다. 액티브 클러스터에 주된 일은 워커에서 일어난다. 워커는 전형적으로 클러스터에서 실행하는 Bro process들의 벌크를 표현한다. 모든 프로토콜에 대한 파싱과 분석이 여기에서 일어나므로, 워커용으로 당신이 제공할 수 있는 가장 빠른 메모리와 CPU코어 스피드가  권고된다. 워커에서 디스크에 대한 특별한 요구는 없다. 이는 대부분의 모든 로깅은 원격지 매니저에서 하기 때문이다. 그리고, 보통, 매우 작은것 만이 디스크에 쓰여진다.

The rule of thumb we have followed recently is to allocate approximately 1 core for every 80Mbps of traffic that is being analyzed. However, this estimate could be extremely traffic mix-specific. It has generally worked for mixed traffic with many users and servers. For example, if your traffic peaks around 2Gbps (combined) and you want to handle traffic at peak load, you may want to have 26 cores available (2048 / 80 == 25.6). If the 80Mbps estimate works for your traffic, this could be handled by 3 physical hosts dedicated to being workers with each one containing dual 6-core processors.

Once a flow-based load balancer is put into place this model is extremely easy to scale. It is recommended that you estimate the amount of hardware you will need to fully analyze your traffic. If more is needed it’s relatively easy to increase the size of the cluster in most cases.

프론트엔드 옵션(Frontend Options)

There are many options for setting up a frontend flow distributor를 셋팅하는 많은 방법/옵션이 있다. 많은 경우, 네트워크와  호스트 상에서 플로우 분배를 다수 스테이지로 수행하도록 하는 이점이 있다.

Discrete hardware flow balancers

cPacket

만일 당신이 10G 이상의 물리 인터페이스를 모니터링한다면, 권고되는 솔루션이 cPacket사의 제품인 cFlow 또는 cVu 장치를 사용하는 것이다. 이 장치들은 많은 사이트에서 성공리에 사용되었다. 이 장치들은 목적지 이더넷 MAC 어드레스를 다시 쓰는 방식으로 레이어-2 로드 밸런싱을 수행한다. 이는 각 패킷을 연계하여, 특정 플로우가 동일한 목적지 MAC을 가지게 한다. 패킷은 모니터링 호스트, 즉,워커에게 직접 전달될 수 있다. 각 워커는 BPF 필터로 플로우의 스트림의 가시성을 제한하거나, 통상적인 스위치를 사용하여 1G인터페이스로 트래픽을 분배할 수 있다. 이는 워커를 1G 인터페이스에서 동작하도록 하게 하여, 비용을 훌륭하게 줄여준다. 

OpenFlow Switches

우리는 요즘 OpenFlow 기반 스위치를 찾아 보고 있는데, 플로우 기반 로드밸런싱을 스위치에서 자동으로 하기 위함이다.이는 많은 사용자를 위한 프론트엔드를 장만하는데 드는 비용을 혁신적으로 낮추어 준다. 이 문서는 보다 많은 정보 습득시 갱신될 수 있다.

On host flow balancing

PF_RING

리눅스에서 PF_RING 소프트웨어는 "클러스터링" 특장점을 갖는다. 이는 동일 인터페이스를 스니핑하는 다수 프로세스들 사이에서 플로우기반 로드밸런싱 수행한다. 이는 당신이 쉽게 한대의 물리 호스트에서 다중 코어의 이점을 취하게 해준다. 왜냐하면 Bro의 메인 이벤트 루프는 단일 쓰레드 방식이고, 다중 코어를 핸들링할 방법을 자체적으로 가지고 있지 않기 때문이다. 만일 당신이 PF_RING을 사용하고자 한다면,  how to configure Bro with PF_RING 문서를 보도록 하기 바란다.

Netmap

FreeBSD는 Netmap이라는 프로젝트를 진행중에 있다. 이 프로젝트는 플로우 기반 로드밸런싱을 할 수 있다. 만일 이 프로젝트가 성공적으로 사용할 수 있게 되면 이 문서를 업데이트하도록 하겠다.

Click! Software Router

Click! 는 간단한 구성으로 플로우기반 로드밸런싱을 사용하도록 할 수 있다. 이 솔루션은 리눅스 상에서는 권고되지 않는다.