실시간 120만개의 패킷분석 - OpenSOC 프로젝트

올해 들어서 블로그에 글 쓰기가 힘들어 졌는데, 오랜만에 포스팅을 해 보려고 합니다.  오늘의 주제는 오픈소스 기반의 시큐리티 분석 프레임웍인 OpenSOC 입니다. OpenSOC 는 여러 보안 문제의 이슈를 빅데이터라는 관점에서 접근해 볼 수 있어, 보안 침해 사고에 대한 조사, Anonmaly 탐지 등 이용범위는 사용방법에 따라 다양해 질 수 있습니다.  오픈소스 기반인 만큼 여러가지 오픈소스를 이용하고 있는데요 Storm, Kafka, Elasticsearch 와 같은 하둡의 에코시스템 MySQL 등을 사용하고 있습니다.  이를 통해 패킷캡쳐 인덱스, 저장, 데이터 스트리밍 처리, 배치 처리, 실시간 검색, 집계등을 이용할 수 있게 됩니다. 

프레임웍에서 제공하는 주요 기능은 아래와 같습니다.

• Extensible spouts and parsers for attaching OpenSOC to monitor any telemetry source
• Extensible enrichment framework for any telemetry stream
• Anomaly detection and real-time rules-based alerts for any telemetry stream
• Hadoop-backed storage for telemetry stream with a customizable retention time
• Automated real-time indexin for telemetry streams backed by Elastic Search
• Telemetry correlation and SQL query capability for data stored in Hadoop backed by Hive
• ODBC/JDBC compatibility and integration with existing analytics tools

OpenSOC 를 사용하기 위해서 필요한 것은 다음과 같습니다.

• 2 개의 네트워크 패킷 캡쳐 카드 (Napatech 사의 NT20E2-CAP 추천)
• 아파치 Flume 1.4.0 +
• 아파치 Kafka 0.8.1+
• 아파치 Storm 0.9+
• 아파치 하둡 2.X 
• 아파치 하이브 12+ (13 권장)
• 아파치 Hbase 0.94+
• Elastic Search 1.1+
• MySQL 5.6+

OpenSOC 컴포넌트는 크게 데이터처리를 위한 스트리밍 쪽과 실제 분석을 하기위한 UI 화면으로 나뉘어져 있습니다.  OpenSOC 를 구현하기 위해 테스트된 환경은 시스코에서 제공한 것으로 14개의 데이터 노드와 3개의 클러스트 제어 노드, 2개의 ESX 호스트, 라우터, 스위치등이 있습니다. 

과거에 제가 진행해 보았던 패킷 분석 프로젝트와 비슷한 개념이 되기도 하는데, 더욱 큰 관점에서 프레임웍이 만들어져 있다는 점에서 매력이 있습니다. 오픈소스로 공개되어 있는 만큼 사용도 자유롭고 실시간으로 120 만개의 패킷을 처리할 수 있다는 것은 성능면에서도 만족스러워 보입니다.  관련 프로젝트를 진행해 보신 분들은 아시겠지만 패킷분석 처리가 만만치는 않은 작업입니다. 제대로 구현하면 얻어낼 수 있는 데이터도 많지만 이 엄청난 패킷 데이터를 저장하고 처리하고 의미있는 데이터로 얻어내기까지는 상당히 많은 작업들이 필요합니다. 

이걸 오픈소스로 이용할 수 있다는 측면에서는 아주 매력적이죠. 물론, 다양한 오픈소스를 사용해야 하기 때문에 어느정도의 경험이 필요로 할듯 해 보입니다.  

더 상세한 정보는 다음 사이트에서 얻을 수 있습니다.

http://opensoc.github.io/

혹시 OpenSOC 로 구현을 진행하였거나 진행할 계획이 있으신 분들은 알려주세요~ 

//Rigel   

[긴급] OpenSSL Heartbleed 버그 취약점, 주의 필요

OpenSSL 라이브러리에서 중대한 보안 취약점이 발견되었습니다.  이 버그는 Heartbleed 로 불리고 있는데요, 이 취약점으로 인해 누구나 OpenSSL 취약점을 내포하고 있는 버전의 시스템으로부터 메모리 정보를 읽어들일 수 있습니다. 이 메모리 정보는 64K바이트 청크 형태로 읽어볼 수 있으며 이 정보로 부터 비밀키도 얻어낼 수 있습니다. 이 뜻은 이 비밀키를 이용하면 암호화된 정보를 볼 수 있다는 것이며 서비스와 사용자 사이에서 모든 정보를 엿볼수가 있게 됩니다.  공식적으로 이 버그는 CVE-2014-0160 입니다.

이번 취약점이 SSL/TLS 프로토콜상의 구조적인 문제는 아닙니다. OpenSSL 라이브러리의 취약점이며 다음과 같은 버전이 영향을 받습니다 :

- OpenSSL 1.0.1 - 1.0.1f 사이의 버전은 취약합니다.
- OpenSSL 1.0.1g 는 취약하지 않습니다.
- OpenSSL 1.0.0 관련 버전은 취약하지 않습니다.
- OpenSSL 0.9.8 관련 버전은 취약하지 않습니다.

현재 많은 버전들이 취약한 버전으로 이용되고 있는 것으로 판단되는 만큼 OpenSSL 을 사용중인 사용자라면 바로 버전 정보를 확인하여 패치하기를 권장합니다. 만약 지금 시점에서 새로운 버전으로 적용이 힘든경우라면 기존 버전을 다음 옵션으로 재 컴파일 해 사용하여 문제를 일시적으로 해결할 수 있습니다.

-DOPENSSL_NO_HEARTBEATS

또한 이 취약점의 또 다른 문제점은 로그상으로 어떤 추적할 만한 정보를 하나도 남기지 않습니다. 즉, 해당 취약점을 통해 악용되었는지 알기 힘들다는 점입니다.

현 시점에서 이 취약점을 이용한 공격이 많이 퍼지고 있는지는 확인하기 어렵지만 OpenSSL 사용자는 빠른 시일내에 패치할 것을 강력히 권고 합니다.

이 취약점의 세부정보는 다음 사이트에서 더 자세히 얻을 수 있습니다.

http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt

중요한 문제이다 보니 급하게 포스팅을 남깁니다.

[참고] OpenSSL 버전 확인 방법
version 옵션을 사용하면 현재 설치되어 있는 OpenSSL 의 버전을 쉽게 확인할 수 있습니다.
# openssl version
OpenSSL 0.9.8y-fips 5 Feb 2013

from Rigel

스노트(Snort)에서 발표한 OpenAppID - 애플리케이션 인지

정말 오랜만에 써 보는 포스팅입니다. 개인적인 이유로 너무 정신없이 지내다 보니 블로그에 포스팅할 시간이 없었는데, 오늘은 스노트에 관련한 글을 잠깐 적어볼까 합니다. 최근에 (정확히 말하면 한달전이 되겠네요) 스노트에서 OpenAppID 라는 것을 발표했습니다. 이름에서 알 수 있는 것과 같이 애플리케이션을 인지하기 위한 기술입니다. 

스노트 사이트에서는 해당 기능이 반영된 스노트를 다운로드 받을 수 있습니다.

http://snort.org/snort-downloads

Snort 2.9.7.0 알파 버전부터 해당 기능을 제공하고 있고 이 기능은 스노트에서 전처리기 형태로 제공되는 기능으로 Snort 를 컴파일시에 --enable-oepn-appid 와 같이 build 할때 기능을 제공하도록 설정되어야 사용할 수 있습니다.

주요기능은 다음과 같습니다.

- 네트워크 상에서 어플리케이션 탐지
- 애플리케이션의 사용 트래픽 보고 기능 
- 정책에 의한 애플리케이션 차단
- 스노트 룰 언어의 확장판으로 OpenAppID 사용 
- IPS 이벤트에서 어플리케이션 이름으로 보고 가능 

약 1,000 여개 이상의 어플리케이션 탐지를 제공한다고 합니다. 참고로 스노트에서 룰에 적용하여 사용하기 위해서는 다음과 같은 형태로 사용됩니다.

사용예:

    alert tcp any any -> any any  (msg:"test for app HTTP";     appid: http;     sid:18759; rev:4; )
    alert tcp any any -> any any  (msg:"test for app FTP";      appid: ftp;      sid:18760; rev:4; )
    alert tcp any any -> any any  (msg:"test for app FTP Data"; appid: ftp-data; sid:18761; rev:4; )
    alert tcp any any -> any any  (msg:"test for app CNN zappos"; appid: cnn.com zappos;  sid:18762; rev:4; )

기존 스노트룰에 appid 라는 태그를 사용하여 쉽게 사용이 가능합니다.

다만 어플리케이션 탐지 모듈은 기본적으로 Lua 로 만들어져 있습니다. Lua 는 많은 분들에게 생소한 언어이기도 한데요, 이로 인해서 어플리케이션 모듈을 만드는 것이 스노트 룰 만드는것만큼 쉽지는 않을것같습니다. 

하지만, OpenAppID 가 활성화되어 많은 모듈들이 만들어지면 Snort 를 통해서도 쉽게 어플리케이션 인지를 할 수 있어 상당히 유용해 집니다. 저도 이러한 부분에 동참하고자 OpenAppID 관련한 글을 지속적으로 적어볼까 합니다. 오늘은 오랜만에 쓰는 글이다 보니 가볍게만 적어보고 다음번을 기대해 볼께요 

패킷 저장시 용량을 줄이기 위한 고민

패킷 저장시 늘어만 가는 크기에 고민을 해본적이 있을것입니다. 무작정 큰 파일로 저장하기에도 용량 측면에서 문제가 있고 해당 파일을 열어보기에도 쉽지가 않습니다. 그러므로 패킷을 덤프하는 경우 그 이유가 명확해야 범위를 결정지을 수 있고, 얼마나 덤프를 해야하고 용량은 어느정도 까지 해야 하는지 대략 산출이 됩니다.

무조건 많이 패킷을 저장한다고 해서 얻을 수 있는 것이 많아진다고도 볼 수 없습니다.  패킷을 덤프하는 범위와 목적 그리고 환경적 요인에 따라 이것은 다 달라지기 때문에 어떻게 하시라고 딱 정해드리기는 어렵습니다.  다만 다음과 같은 부분을 고려한다면 패킷파일의 크기를 줄일 수 있으리라 생각됩니다.

1. 패킷 파일 저장시 범위를 명확히 하기

특정IP , 포트번호와 같이 무엇인가 범위를 잡을 수 있는 것이 있다면 범위 지정이 필요합니다.

2. 얼마나 오랜시간동안 저장할 것인가?

패킷 분석 목적에 따라서 달라지지만 얼마동안 저장하느냐에 따라 패킷크기가 크게 달라집니다.  무조건 오래하는 것이 좋은것은 아닙니다. 우선 짧은 시간 패킷을 저장해 보고 대략 패킷파일이 늘어나는 속도와 그 내용을 한번 보고서 시간을 결정하는 것도 좋습니다.  패킷덤프할 시간이 결정되면 파일의 적정크기도 판단하셔서 특정 크기 이상이 되면 다른 파일로 저장되도록 하는 것이 분석시에 편리합니다. 물론 하나의 파일로 모으는 경우가 필요할 경우도 있을것 같습니다. 만약 파일을 저장시에 분할한다면 와이어샤크에서는 패킷 덤프시 옵션을 지정할 수 가 있고, 큰 패킷로 저장을 하였다면 추후에 Split 를 하여 적정 크기로 만들어 분석을 할 수 있습니다. 패킷 분할과 관련해서는 블로그에서 검색해 보시면 몇 가지 방법들이 나옵니다.

3. 패킷저장 포맷 - Pcap vs Pcap-ng

오랜시간동안 패킷을 저장한다면 저장 포맷도 고려해볼 필요가 있습니다. 와이어샤크 최근 버전에서는 기본 포맷이 pcap 에서 pcap-ng 로 변경이 되었습니다. 비교적 최신 버전의 와이어샤크를 사용하신다면 본인도 모르게 패킷파일이 pcap-ng 로 저장되고 있는 것입니다. 가끔 전달받는 패킷의 포맷을 보면 과거보다 확실히 pcap-ng 포맷이 증가된걸 느낄 수 있습니다. pcap-ng 포맷은 pcap 보다 포맷구조가 더 유연해 졌으며 저장되는 내용도 더 많습니다.  최근 포스팅한 pcap-ng 포맷 구조 글을 참고해 보시면 이유를 아실 수 있습니다. 이러한 이유로 부가적인 정보가 더 기록이 되기 때문에 특별히 pcap-ng 포맷이 필요하지 않다면 용량적인 측면에서도 pcap 포맷으로 저장하는 것이 더 유리합니다.

다음의 경우를 한번 살펴보겠습니다. test.pcap 파일은 pcap-ng 포맷파일입니다.
$ file test.pcap
test.pcap: pcap-ng capture file - version 1.0

이 test.pcap 파일은 대략 크기가 2.6 기가 정도가 되는데 pcap 포맷으로 변경하여 한번 비교해 보도록 하겠습니다.

$ editcap -F libpcap -T ether  test.pcap convert.pcap

아래와 같이 pcap 포맷으로 변경하여 보면 약 300 메가 정도의 차이를 보입니다.

-rwxr-xr-x 1 root    root    2.6G Dec 12 16:09 test.pcap
-rw-rw-r-- 1 root     root    2.3G Dec 20 18:00 convert.pcap

만약 여러분이 상당히 오랜시간 패킷파일을 저장한다면 저장되는 패킷 포맷 방식에 따라 파일 크기가 커질 수 있다는 점입니다.

4. 패킷을 다 들여다 볼 것인가?

보통 패킷 덤프시 큰 용량을 차지하는 부분이 패킷의 페이로드 부분입니다. 헤더만 놓고 본다면 그 자체는 크지 않지만 데이터가 들어가면 이게 큰 부분을 차지합니다.  전체 패킷을 다 볼 필요가 없고 일부만 저장해도 된다고 할 경우에는 snaplen 크기를 지정하여 제한할 수가 있습니다. tcpdump 를 사용한다면 -s 를 통해 이 크기를 제한할 수 있습니다. 만약 -s 100 이 된다고 가정하면 패킷당 100 바이트 까지만 저장이 된다는 것이죠. 그렇다면 헤더 정보와 일부 페이로드만이 약간 포함될 것입니다. 물론 데이터를 전체 못 본다는 것은 있지만 여러분들의 필요에 따라 제한하여 저장해도 괜챦다면 이 방법은 패킷파일 크기를 줄이는데 큰 도움을 줄 것입니다.

와이어샤크에서는 캡쳐옵션에서 Limit each packet to "xxx" bytes 옵션을 통해 조정할 수 있습니다.

5. 압축으로 크기를 줄이자

패킷파일은 압축을 할 경우 용량 절약을 크게 볼 수 있는 경우가 많습니다. 저장해서 일정기간 동안 보관해야 하는 경우라면 압축을 해서 보관하는 것이 좋습니다. 물론, 패킷파일이 큰 경우에는 압축을 하고 해제하는데 많은 시간이 소요될 수 있다는 점도 알아두세요!

이상으로 패킷파일 크기를 줄이기 위한 몇 가지 방법을 적어 보았습니다.  패킷파일 저장시 한번쯤 참고해 보셨으면 합니다.

From Rigel