Netflow 와 sflow

이미지 출처: https://www.thinknts.com/managed-services/system-and-network-monitoring/

 

학교나 회사에 꼭 하나씩은 있는 전산팀, 그곳에서는 우리가 인터넷 상에서 언제, 어디로 접속하는지를 뭘 보고 어떻게 분석하는 걸까요?

 

본 포스트에서는 네트워크 모니터링에서 빼 놓을 수 없는 기술 NetFlowsFlow를 소개드리려 합니다.

 

1. NetFlow



NetFlowIP 트래픽의 흐름을 기록하고 분석하는 프로토콜입니다. IT 인프라에 배치되어 있는 각종 라우터, 스위치, 그리고 여러 호스트 사이에서 오가는 패킷들의 메타 정보들이 NetFlow를 통해 가시화될 수 있습니다. 여기에는 트래픽의 순간 발생량, 주요 경로, 패킷 손실률 등과 같은 유용한 정보들이 포함됩니다. 이러한 정보들은 궁극적으로 DDoS와 같은 사이버 공격을 탐지하거나 QoS (Quality of Service) 등을 도입하여 네트워크를 효율적으로 운영하는 데 도움을 줍니다.

 

보통 Wireshark와 같은 도구들은 단말 호스트에서 유입되는 트래픽을 분석하는 데 목적을 두는데, NetFlow는 이와는 다르게 네트워크 전반에 걸쳐 패킷 데이터를 모니터링하는 데 의의가 있습니다.

 

NetFlow를 개발한 곳은 다름아닌 Cisco라는 네트워크 장비 공급업체입니다. NetFlow가 나오기 이전에는 SNMP(Simple Network Management Protocol)이 현장에서 사용되었지만, NetFlow에 비하면 제공할 수 있는 정보의 디테일이 다소 부족한 편입니다. 실제로 SNMP는 각 네트워크 경유지의 트래픽 양을 확인할 수는 있어도, 어떤 호스트 또는 서버가 트래픽을 발생 시키는지라던가 또는 그중에서 대역폭을 많이 잡아먹는 대상이 누군지 알 수 없습니다.

 

이미지 출처: https://www.firewall.cx/networking-topics/protocols/netflow/1273-netflow-vs-snmp-network-monitoring.html

 

시간이 지나면서 NetFlow가 복잡하고 트래픽이 많이 발생하는 환경에서 네트워크 상태를 파악하는 데 효과적임이 알려졌고, 이어 다른 네트워크 플랫폼에서도 이를 모니터링에 도입하거나 벤치마킹하기 시작했습니다. 그 결과 NetFlow는 어느새 해당 분야에서 업계 표준의 위치로 우뚝 올라섰습니다.

 

2. NetFlow의 동작

 

NetFlow를 제일 처음 소개할 때 NetFlow를 프로토콜이라고 설명하였습니다. 프로토콜이라 함은 자체적인 패킷 구조와 이를 파싱하는 규칙이 존재한다는 것을 의미합니다. 그래서 NetFlow 패킷만을 따로 분석하는 장비나 시스템이 따로 존재합니다.

 

NetFlow 모니터링 시스템은 크게 3가지 요소로 구성됩니다.

  • Flow exporter: NetFlow를 지원하는 라우터나 방화벽을 의미하며, 해당 장치에서 집계한 패킷 흐름 정보(=NetFlow 레코드)는 Flow collector에게 정기적으로 전송됩니다.
  • Flow collector: 앞서 Flow exporter가 전달한 NetFlow 레코드의 전처리와 저장을 담당합니다.
  • Flow analyzer: 저장된 NetFlow 레코드로부터 대역폭 사용량, 트래픽 패턴, 애플리케이션 별 트래픽 비중, 보안 이슈 등을 분석하고 관련 플랫폼이나 GUI를 통해 분석 내용을 시각화합니다.

 

Flow exporterNetFlow 레코드를 생성할 때, 수집한 패킷들을 특정한 기준으로 그룹화하고 그룹화된 패킷 리스트를 '흐름(Flow)'이라는 용어로 분간합니다. 패킷들이 아래의 요소들에 대하여 공통된 값을 가지면 같은 Flow로 그룹화됩니다.

  • 출발지 IP 주소
  • 도착지 IP 주소
  • 출발지 port 번호
  • 도착지 port 번호
  • Layer 3 프로토콜 유형
  • TOS (Type of Service)
  • 라우터/스위치의 인터페이스

 

기준이 다소 복잡할 수 있지만, TCP 통신을 예를 들면 단순하게 한 서버와 클라이언트 쌍이 3-way Handshaking하고나서부터 데이터 교환이 끝날때까지를 (TCP 플래그 FIN, RST가 발생하는 시점까지) 하나의 Flow라고 구분짓는다고 생각하시면 됩니다.

 

그룹별로 분리된 패킷 정보는 UDP 데이터그램 형태로, Flow exporter를 출발해 Flow collector에게 도달합니다. 이후 Flow collector 내부의 NetFlow CacheFlow별로 여러 통계 수치값(ex., 패킷 수, bytes/packet)들이 보관됩니다.

 

3. NetFlow의 한계, 그리고 sFlow 

 

Netflow가 네트워크 분석에 유용한 건 사실이나, 몇가지 문제점들도 안고 있습니다. 가장 큰 이슈는 처리 성능으로, 네트워크 상의 모든 패킷 데이터를 추적해야하다보니 Netflow 장치에 부담을 상당히 끼칩니다. 고작 수백개의 호스트로 구성된 네트워크일지라도 이들이 만들어내는 패킷의 양은 상상 이상으로 크기 때문입니다.

 

성능 이슈를 풀기 위한 대안: sFlow

 

이미지 출처: https://blogs.cisco.com/networking/miercom-report-secured-network-infrastructure

 

이러한 성능 문제를 해소하기 위해서 sFlow라는 대안이 도입되었는데요. sFlow는 "sampled NetFlow"의 약어로, 모든 패킷이 아니라 랜덤한 일부 패킷을 뽑아 통계를 생성하는 NetFlow 파생 버전입니다. 샘플링 비율(적을 때는 패킷 1,000개당 1개씩 뽑기도 한다네요)에 따라서 분석 가능한 범위가 좁아질 수 있긴 합니다. 한 때 이 샘플링 비율을 정하는 알고리즘을 잘 설계하는 것이 네트워크 연구 분야에서 뜨거운 주제였습니다.

 

그럼에도 여전히 풀기 어려운 문제들

 

NetFlow에서 수집하는 데이터만으로는 분석하지 못하는 것들이 여러 있습니다. 일부 통신 노드들은 NetFlow만으로 식별하기가 어렵습니다. 당연한 이야기겠지만 NAT(Network Address Translation) 또는 VPN을 사용하는 단말의 경우, 사용자와 단말의 유형 등의 정보를 정확히 파악하는데는 무리가 있습니다.



그리고 NetFlow에서 수집하는 정보들은 주로 TCP/IP 계층의 헤더 정보들로, 실질적인 애플리케이션 데이터가 포함된 페이로드를 수집하지는 않습니다. 페이로드를 포함하여 Flow 데이터를 정밀 분석하는 기술로 흔히 DPI(Deep Packet Inspection)라는 기술이 있으나, 이런 프로세스를 NetFlow에서 다루지는 않습니다. 

 

 

예전에는 고유한 수신지/도착지 port를 사용하는 애플리케이션들이 다수였지만, 요즘 같이 대부분 온라인 서비스들이 웹과 HTTPS 기반으로 대체된 상황에서 Flow가 정확히 어떤 애플리케이션 유형의 데이터인지를 판단 내리기 힘듭니다.



NetFlow 하나만으로는 완벽한 네트워크 모니터링을 제공할 수 없는 건 사실입니다. 그럼에도 방대한 네트워크를 분석하고 운영하는 데에 NetFlow만큼 효과적인 도구를 찾기도 어렵습니다. 많은 네트워크 운영/보안 회사에서 NetFlow 모니터링 시스템과 대시보드를 서비스화하고 있고, 실제 여러 현장에서 도입되어 왔다는 점 역시 사실이니까요.

ManageEngine Inc. 의 NetFlow 모니터링 대시보드

반응형