발생 가능한 사이버 위협에 대한 대처 능력을 강화하는 실전적 훈련을 위한 사이버 훈련 시스템은 실제의 사이버 환경을 가상화 기술을 이용하여 동적으로 생성한 유사한 가상운용환경을 지원한다. 훈련은 공격을 담당하는 레드팀, 방어를 담당하는 블루팀, 훈련에 대한 모니터링을 수행하는 화이트팀으로 구성되어 운용되며 시스템 구축 예로는 이스라엘의 사이버짐^[3]과 미국 DARPA의 국가 사이버전 시험장(NCR, National Cyber Range)^[2] 등이, 국내 예로는 KISA의 시큐리티짐(Security-Gym)이 2017년 11월부터 공식 운영을 시작한 바 있다. 또한 이러한 사이버전 훈련 시스템에서 블루팀이 훈련자로 구성될 때 레드팀 역할을 맡아 시나리오에 의해 설정된 공격을 자동적으로 수행하는 에이전트에 대한 개발이 진행된 바 있다^[4].

트래픽 발생기는 일반적으로 시스템의 네트워크 부하 시험과 사이버 위협 대처 능력을 보기 위한 목적으로 개발되며 소프트웨어, 하드웨어로 구현된다. 이 중 사이버 위협 트래픽을 제외한 L4(OSI(Open System Interconnection) 7 계층 구조 중 Transport Layer) – L7 (OSI 7계층 구조 중 Application Layer) 단의 트래픽 발생을 위한 도구에는 T-Rex, Pktgen, MoonGen, Ostinato 등이 존재한다^[5]. T-Rex는 CISCO에서 개발한 DPDK (Data Plan Development Kit: 고속 패킷 처리를 위한 데이터 플레인 라이브러리와 네트워크 인터페이스 컨트롤러 드라이버 집합) 기반의 상태 저장 및 상태 비저장 트래픽 생성기로서 실제 트래픽 템플릿을 재생하거나 L4-L7 트래픽을 생성할 수 있다. 그러나 실행을 위한 별도의 하드웨어가 필요하다. pktgen은 리눅스 운영체제에서 제공하는 네트워크 부하 시험용 packet sender로서 고속으로 패킷을 생성하고 유통 통계 정보를 얻을 수 있는 특징을 가진다. MoonGen은 pktgen와 같이 네트워크 부하 시험용 packet sender로서 고속 패킷 생성, 유통 결과 통계 정보 제공의 기능을 가지며 Intel 계열의 NIC에 의존적인 특성을 가진다. Ostinato 는 네트워크 가상화 에뮬레이터인 eve-ng에서 지원하는 오픈소스 트래픽 생성기로서 네트워크 상에 위치하는 drone(에이전트)이 제어 시스템의 설정값을 받아서 실제 패킷을 생성하는 시스템이다.

트래픽 발생 도구들은 트래픽 부하 측정에 목적을 두고 있으며 훈련을 위한 목적으로 개발되지 않아 실제 시스템에서의 사용자의 트래픽 양상을 재현하거나 L7 payload의 내용이 재현 상황에 적합한가는 고려하지 않는다. 본 논문에서 제안하는 상태 저장 트래픽 발생 Architecture는 훈련을 위한 적합한 트래픽을 생성하는 것에 초점을 맞추었다는 점에서 기존 트래픽 발생기들과 차별화된다.

사이버전 훈련을 위해 제공되는 배경 트래픽은 훈련의 대상이 되는 위협 트래픽을 숨기기 위한 목적을 가진다. 만약 배경 트래픽이 없을 경우, 훈련자는 트래픽 자체만을 감시하다 트래픽이 생길 경우 이를 차단하기만 하면 되기 때문이다. 이러한 목적의 배경 트래픽을 좀 더 실제와 유사하게 제공하기 위해서는 훈련의 목적이 되는 실환경에서 트래픽을 캡처하여 데이터셋(PCAP: Packet CAPtrue, 패킷 캡처) 형태로 제 공하는 방법을 채택하였다. 본 절에서는 실환경에서 캡처된 트래픽을 훈련용 가상환경에서 상태 저장 방식으로 유통시키기 위해 수집된 실 트래픽 데이터셋을 가공하여 상태 저장 트래픽 데이터셋으로 변환하는 방법에 대해 설명한다.

가공 시 고려해야 할 요소는 다음과 같다.

위의 사항을 고려할 때, L7 payload, 물리 interface인 Ethernet Header를 제외하고 패킷 구분 field와 sequence field를 지정할 수 있는 패킷 field는 IP header와 TCP/ UDP header 부분이 해당된다. 그리고 상태 저장 데이터셋이라는 특성 상, 패킷의 순서를 준수해야하기 때문에 TCP protocol을 활용한다고 가정하고 데이터셋 변환을 수행한다.

패킷 구분 field는 훈련자 행위에 의한 패킷과 상태 저장 트래픽 발생에 의한 패킷의 구분을 위한 field와 배경 트래픽 간의 데이터셋 구분을 위한 field(이후 group id)를 별개로 간주하여 진행한다. 전자의 경우, IP header 중 패킷이 얼마나 빨리 처리되어야 하는가에 대한 정보를 담는 Type of Service(TOS) field에 특정값(0×40)을 지정하는 방식으로 수행한다. Group id는 하나의 PCAP file로 만들어지는 상태 저장 트래픽을 다른 PCAP 상태 저장 트래픽과 구분하기 위한 목적으로 TCP header의 window field(16 bits)를 활용하여 unique 한 id를 부여한다. 또한 데이터셋 내부의 패킷들의 순서를 확인하기 위한 field는 URG 플래그가 설정되지 않으면 사용되지 않는 field인 Urgent pointer(16 bit) 부분을 활용한다. 이를 통해 만들어지는 packet의 header 는 Fig. 2의 형태를 가지며 bit 단위로 정리한 표가 Table 1이다.

모니터링 서버는 훈련용 가상환경의 네트워크 맵 정 보를 받아 트래픽 에이전트가 실행될 VM의 IP 정보를 추출하고 위에서 설명한 field 값을 함께 실환경 PCAP file에 적용하여 트래픽 에이전트가 실행할 PCAP 데이 터셋을 생성한다.

트래픽 에이전트는 3.1절에서 설명한 상태 저장 트 래픽 데이터셋을 순서에 맞게 발생시키는 것을 목적으 로 한다. 이를 위해 트래픽 에이전트는 설정된 데이터 셋을 기반으로 Ethernet layer를 통과한 패킷을 interrupt 하여 데이터셋에 의해 발생한 패킷인지 검사한 후, 아 닐 경우, 원래 처리되어야 하는 Network layer에서 처 리할 수 있도록 하는 내부 private firewall 개념을 적용 하였다.

내부 private firewall에 의해 tos field가 0×40인 패킷 을 식별하여 에이전트 처리 대상 패킷임을 인식한 후 에는 Group ID에 의한 구분 및 sequence를 비교한 후, 데이터셋에 의해 다음에 보내야할 packet을 송신한다. 이 과정은 Group id field인 Window size 값에 의해 내부에서 관리하는 Packet Queue에 저장하는 과정과 Queue에 저장된 packet을 그 시점에서 받아야하는 순 서의 패킷인지를 비교하여 다음 패킷을 발생시키는 과정으로 분리하여 비동기적으로 처리한다. 이 동작 매커니즘을 Fig. 3로 나타낼 수 있다.

트래픽 에이전트는 Ethernet layer 레벨에서 packet을 처리하기 때문에 TCP layer에 의한 재전송 메커니즘을 활용하지 않는다. 동시에 상태 저장 방식으로 트래픽을 발생시키기 때문에 만약 네트워크 환경에서 소실되는 패킷이 생길 경우, 다음 패킷으로 진행할 수 없게 된다. 이를 처리하기 위해 별도의 재전송 protocol을 정의하여 패킷 손실에 대한 대응 작업을 수행할 필요가 있다. 본 논문에서는 이를 위한 재전송 protocol로 다음과 같은 절차를 제안한다.

이에 대한 예시를 Fig. 4로 나타내었다.

A는 packet 1을 송신하고 packet 2에 대한 재전송 timer를 설정된 timeout으로 작동시킨다. B는 트래픽 데이터셋 발생 시작 시각부터 packet 1에 대한 재전송 timer를 작동시킨 상태에서 받아야 하는 packet 1을 받고 packet 2를 A로 송신한다. 그러나 packet 2가 네트워크 상황에 의해 소실되어 A에 전달되지 못하는 경우, A는 packet 1 송신 후, 작동된 재전송 timeout이 지난 후 2번 packet을 못 받은 상태를 인식하고 2번 packet에 대한 재전송 요청 패킷을 B로 송신하게 된다. B는 2번 packet 재전송 요청 패킷을 받은 시점에서 3번 packet에 대한 재전송 timer를 중지하고 2번 packet 을 재전송하게 된다. 그리고 다시 3번 packet에 대한 재전송 요청 timer를 작동시킨다.

재전송 요청 packet을 수신 측에서 식별하기 위해서는 재전송 요청 패킷임을 나타내는 flag를 별도의 field 에 설정할 필요가 있다. 이를 위해 3.1절에서 제시한 Window size 혹은 Urgent Pointer field를 사용할 수 있다. 다른 field를 활용할 수도 있으나 하나의 packet을 처리하기 위해 접근해야하는 field의 종류를 늘리는 것은 불필요한 IO를 발생시킬 수 있으므로 위의 두 field를 재활용하는 방안으로 접근하였다. 또한 재전송 packet은 Group ID 식별 후, sequence를 비교하기 위한 프로세스를 처리해야할 필요가 없으므로 Group ID를 저장하는 window size field의 reserved bit를 활용하여 재전송 요청 packet임을 표시하고 Urgent Point에 재전송 요청 packet의 sequence number를 저장하는 방식으로 재전송 packet을 새로 생성하여 송신하도록 한다. 이를 위해 추가된 field를 포함한 상태 저장 트래픽 패킷의 TCP Header는 Table 2와 같다.

트래픽 에이전트는 설정된 상태 저장 트래픽 데이터셋 발생 시에 packet이 소실되는 경우가 발생할 경우, Windows size field 12번째 bit를 자체적으로 변경하여 재전송 요청 packet을 전송하게 된다.

모니터링 서버는 상태 저장 트래픽 데이터셋을 생성하고 이를 훈련용 가상 환경에 설치된 상태 저장 트래픽 에이전트에 배포하여 트래픽 발생을 할 수 있도록 제어하는 역할을 담당한다. 기능적인 부분으로 살펴보면 트래픽 데이터셋 생성과 트래픽 에이전트 제어 부분으로 크게 나눌 수 있다.

트래픽 데이터셋 생성은 훈련용 가상환경의 네트워크 토폴로지와 실환경 트래픽 캡처 데이터를 입력으로 받아 트래픽 에이전트에서 처리 가능한 형태의 데이터셋으로 변환하는 기능이다.

훈련용 가상환경은 외부 시스템에 의해 정의되는 환경으로서 상태 저장 트래픽 발생 Architecture는 네트워크 토폴로지를 구성하는 가상 머신의 정보와 네트워크 링크 정보를 외부 입력 데이터로서 받게 된다. 훈련용 가상환경에서 배경 트래픽을 송/수신할 가상 머신을 선택한 후, 가상 머신에서 발생할 트래픽을 실환경 캡처 트래픽 중에서 선택하면 3.1절에서 설명한 상태 저장 트래픽 데이터셋을 생성하게 된다. 각각의 외부 데이터를 어떻게 활용하는지를 Fig. 5로 나타내었다.

트래픽 에이전트 제어 기능은 훈련용 가상환경에 분산된 상태 저장 트래픽 에이전트들을 통합하여 관리하기 위한 기능이다. 분산된 에이전트를 관리하기 위해서는 기능적 요구사항과 함께 고려되어야 할 비기능적 요구사항, 즉 품질 속성^[6]으로서 Table 3과 같은 항목이 존재한다.

첫 번째 품질 요소인 확장성은 상태 저장 트래픽 발생 Architecture의 적용 대상이 훈련용 가상환경이라는 점에서 도출된다. 훈련용 가상환경은 외부 시스템에 의해 네트워크 토폴로지가 저작되고 가상환경(ex: VMware[1]) 상에 생성되며 훈련의 목적과 대상에 따라 다양한 형태의 네트워크 환경을 가지게 된다. 이러한 다양한 네트워크 토폴로지에서는 트래픽 에이전트 가 설치될 가상 머신의 설치 대수가 가변적일 수 밖에 없으며 각 머신이 가지는 IP 주소 역시 가변적인 요소가 된다. 이에 대해 모니터링 서버가 각각의 모든 트래픽 에이전트에 session을 유지하며 제어 명령을 전달하는 것은 불필요한 성능적 부하로 작용할 수 있으므로 제어 메시지는 publish/subscribe 구조^[6]로 모니터링 서버와 트래픽 에이전트 간의 직접적인 연결 없이 전달될 수 있는 형태로 설계하였다.

트래픽 에이전트는 가상머신에서 동작 시, 제어 메시지 통신을 위한 별도의 네트워크 어댑터 모듈을 추가하여 해당 어댑터에서만 제어 메시지를 처리하도록 한다. 이를 그림으로 나타내면 Fig. 6과 같다.

두 번째 품질 속성인 정확성은 시간 동기화에 대한 제약을 부여하는 항목으로 3.2절에 설명한 트래픽 에이전트의 재전송 protocol에 의해 주어진 품질 속성이다. 트래픽 데이터셋에 의해 송/수신하기로 설정된 트래픽 에이전트 간의 local time이 상호 간에 타이머 이상 차이가 난다면 주어진 트래픽 발생 시각을 local time이 빠른 쪽이 먼저 시작하게 되어 송신 혹은 수신되어야 할 packet이 timeout 시간까지 처리되지 않아 필수적으로 재전송 요청 packet이 발생하기 때문이다. 네트워크 환경 상의 문제가 아닌 상황에서 재전송 요청 packet을 발생시키지 않게 하기 위해 각 가상머신의 local clock을 기준 global clock을 정해 동기화시킬 필요가 있다. 모니터링 서버의 시각을 global clock으로 설정하고 트래픽 에이전트의 초기화 시에 반드시 동기화를 수행하도록 하는 방식으로 2번 품질 속성을 만족시킬 수 있다. 이러한 시간 동기화를 위한 방법으로는 네트워크 타임 프로토콜(Network Time Protocol: NTP)을 일반적으로 사용하며 인터넷에 연결되어 있을 경우에는 time.google.com 등 공용 NTP 서버와의 동기화를 수행할 수 있다. 그러나 훈련 시스템은 대부분의 경우 외부와의 연결이 없는 폐쇄망이므로 모니터링 서버를 내부 NTP 서버로 설정하고 각각의 훈련용 가상환경 내의 가상 머신들이 모니터링 서버를 기준으로 동기화하도록 시스템 설정을 수행해야 한다.

마지막 품질 속성인 시간반응성은 첫 번째 품질 속성에 의한 설계와 두 번째 품질 속성에 의한 설계에 따라 파생된 속성이다. 확장성을 만족하기 위해 채용한 publish/subscribe 구조에서는 메시지 소비자가 메시지를 polling해가는 시점이 달라 명령 처리에 대한 시간 동기화를 수행할 수 없다는 점과 트래픽 에이전트가 같은 트래픽 데이터셋을 송/수신하기 위해서는 재전송 타이머 시간 범위 내에서 시간 동기화를 이루어야 한다는 점이 충돌하는 것이다. 이를 해결하기 위해서 트래픽 에이전트가 메시지를 소비하는 시점과 실제로 제어 명령을 수행하는 시점을 분리하는 방식으로 설계하여 적용하였다. 이는 제어 명령 내부 정보에 제어 명령을 수행할 시각을 함께 주어 모든 트래픽 에이전트가 global clock 동기화를 수행한 local clock의 특정 시점에 제어 명령을 수행하도록 하는 것이다.

상태 저장 트래픽 발생기의 모니터링 서버와 트래픽 에이전트가 설계 의도와 동일하게 동작하는지를 검증하기 위하여 Fig. 10의 시스템 구성도로 가상 머신 네트워크를 구성하여 실험을 수행하였다. 이 가상 운용환경은 총 28개의 가상 머신으로 이루어져 있으며 각각의 가상 머신은 가상 스위치와 라우터를 이용하여 연결되어 있는 구조이다.

트래픽 에이전트는 총 28개의 가상 머신(OS: Ubuntu 16.04, Windows 10)에서 동시에 트래픽을 발생하여 트래픽 데이터셋의 송/수신 노드에 따라 패킷 송/수신을 수행하였다. 이 중 하나의 가상 머신에서 wireshark를 사용해 가상 머신의 송/수신 packet을 capture한 결과는 Fig. 11과 같다.

Fig. 11의 설명과 같이 상단 데이터셋 트래픽의 양상과 하단 실유통 캡처 트래픽이 패킷 별로 대조하였을 때 동일한 순서와 형태로 나타난 것을 확인하여 데이터셋 트래픽 유통 및 트래픽 에이전트 제어가 설계한 대로 동작함을 확인할 수 있었다.