The Amazon i3 Family

Amazon has recently released to general availability the i3.metal instance, which allows us to do some things which we could not do before in the Amazon cloud, such as running an unmodified hypervisor. We were able to run more than six thousand KVM virtual machines on one of these instances, far beyond our pessimistic guess of around two thousand. In the remainder of this post we will discuss what makes these platforms important and unique, how we ran KVM virtual machines on the platform using Amazon’s own Linux distribution, and how we measured its performance and capacity using kprobes and the extended Berkeley Packetcpu Filter eBPF .

Read on for details!

i3.metal and the Nitro System

The i3 family platforms include two improvements from what Amazon has historically offered to AWS customers. The first is the combination of the Annapurna ASIC and the Nitro PCI cardwhich together integrate security, storage, and network I/O within custom silicon. The second improvement is the Nitrohypervisor, which replaces Xen for all new EC2 instance types. Together, we refer to the Nitro card, Annapurna ASIC, and Nitro hypervisor as the Nitro System. (See the EC2 FAQs entry for the Nitro Hypervisor for some additional details.)

Although Amazon has not released much information about the Nitro system there are important technical insights in Brendan Gregg’s blog and in two videos ( here and here ) from the November 2017 AWS re:Invent conference. From these presentations, it is clear that the Nitro firmware includes a stripped-down version of the KVM hypervisor that forgoes the QEMU emulator and passes hardware directly to the running instance. In this sense, Nitro is more properly viewed as partitioning firmware that uses hardware self-virtualization features, including support for nested virtualization on the i3.metal instances.

Nitro protects the Annapurna ASIC and the multi-root PCI hardware from being reprogrammed for the i3.metal systems, but nothing else (this invisible presence is to protect against the use of unauthorized elastic block stores or network access.) For example, while Nitro has no hardware emulation (which is the role of QEMU in a conventional KVM hypervisor), Nitro does enable self-virtualizing hardware (pdf). Importantly, Nitro on the i3.metal system exposes hardware virtualization features to the running kernel, which can be a hypervisor. Thus, a hypervisor such as KVM, Xen, or VMWare can be run directly in an i3.metal instance partitioned by the Nitro firmware.

Image above: Amazon’s i3 platform includes the Annapurna ASIC, the Nitro PCI Card, and the Nitro Firmware. See

Key Virtualization Features Exploited by the Nitro Firmware

Below is a brief, incomplete summary of virtualization features exploited by the Nitro system—particularly in the bare metal instances.

VMCS Shadowing

Virtual Machine Control Structure (VMCS) Shadowing provides hardware-nested virtualization on Intel Processors. The VMCS is a set of registers that controls access to hardware features by a virtual machine (pdf). The first-level hypervisor—in this case the Nitro system—keeps a copy of the second to nth level VMCS and only investigates registers that are different from the cached version. Not every register in the VMCS requires the first level hypervisor to monitor. The Nitro firmware thus provides nested virtualization with no material effect on performance (consuming only a small amount of additional processor resources). If the instance hypervisor does not violate the boundaries established by Nitro, there is no intervention and no effect upon performance.

Most significantly, VMCS shadowing registers are freely available to the kernel running on the bare-metal instance, which is unique for EC2  instances.

Extended Page Tables

Once the hypervisor has established memory boundaries for the virtual machine, Extended Page Tables (EPT) are a hardware feature that allows a virtual machine to manage its own page tables. Enabling this hardware feature produced a two order magnitude of improvement in virtual machine performance on x86 hardware.

Like VMCS shadowing, EPT works especially well with nested hypervisors. The Nitro firmware establishes a page table for the bare-metal workload (Linux, KVM, or another hypervisor.) The bare-metal workload manages its own page tables.

As long as it does not violate the boundaries established by the Nitro firmware, Nitro does not effect the performance or functionality of the bare-metal workload. Nitro’s role on i3.metal workloads prevents the workload from gaining the ability to re-configure the Annapurna ASIC or the Nitro card and violating the limits set for the instance.

Posted Interrupts

The multi-root virtualization capability (pptx) in the i3 instances virtualizes the Amazon Enhanced Networking and Elastic Block Storage (EBS) using PCI hardware devices (Annapurna ASIC and the Nitro card) assigned by the Nitro firmware to specific bare-metal workloads.

Posted interrupts (pdf) allow system firmware to deliver hardware interrupts directly to a virtual machine, when that virtual machine is assigned a PCI function. The Nitro system uses posted interrupts to allow the bare-metal workload to process hardware interrupts generated by the Nitro hardware without any intervention from the Nitro System.

That is, the Annapurna ASIC and Nitro PCI card can interrupt the bare-metal workload directly, while remaining protected from re-configuration by the bare metal workload. There are no detrimental effects on performance as long as the Nitro System does not over-provision CPUs, which it does not do. (The bare-metal workload may, even if it is a hypervisor, as we will see below in the limited testing we did)

Loading KVM on a Bare Metal Instance

On an EC2 Bare Metal system (i3.metal in the screen grab above), Nitro is hardware partitioning firmware. The Nitro firmware is based on KVM and does not use hardware emulation software (such as QEMU). It does initialize the custom Amazon hardware and pass-through hardware to the running instance: networking, storage, processors, PCI trees, and memory. It then jumps into the bare-metal instance kernel, which in our testing was Amazon Linux. (Amazon also supports the VMware Hypervisor as a bare-metal instance)

The Nitro firmware only activates if the bare-metal kernel violates established partitioning. The fact that the Nitro firmware is actually Linux and KVM is not new: Linux has been used as BIOS for many years for complex systems that consolidate networked or shared resources for hardware platforms.

Passing-through the VMX flag and Running Nested Virtualization

The Bare Metal kernel sees the vmx flag when it inspects /proc/cpuinfo:

This flag is necessary in order to load KVM. It indicates that the Virtual Machine Control Structure (VMCS) is programmable by the Linux-KVM kernel. VMCS Shadowing makes this possible; it uses copy-on-write methods and register caching in the processor itself to run each layer in the stack (Nitro, KVM, and the Virtual Machine) directly on the processor hardware. Each layer is controlled by the layer beneath it.

The i3.metal systems use register caching and snooping to provide hardware-virtualized processors to each layer in the system, beginning with the Nitro System, up to virtual machines being run by the bare-metal instance (KVM in this case).

The Nitro firmware does not use QEMU because it does not emulate any hardware. In our testing, we did use QEMU hardware emulation in the upper layer virtual machines. This resulted in the picture below, where the Nitro firmware is running beneath the i3 instance kernel. We then loaded KVM, and used QEMU to provide hardware emulation to the virtual machines:

When running a hypervisor such as KVM on the i3.metal systems, each layer has direct access to the processor through VMCS Shadowing, which provides each layer with the Virtual Machine Control registers.

Installing KVM on an Amazon Linux Image

The Amazon Linux distribution is derived from Fedora Linux with KVM available as two loadable modules. (KVM is maintained and supported by Amazon as a standard feature of the bare metal instance.)

Some components need to be installed, for example QEMU:

Libvirt is not part of the Amazon Linux distribution, which saves cost . We do not need Libvirt, and it would get in the way of later testing.

Libvirt is an adequate collection of software, but qemu-kvm is not aware of it, meaning the virtual machine state information stored by Libvirt may be out of sync with qemu-kvm . Libvirt also provides an additional attack vector to KVM while providing little additional functionality over what is provided by standard Linux utilities and kernel features, with  qemu-kvm.

Built-in Processor Support for KVM

The i3.metal instance has 72 threads running on 36 physical cores that support KVM and posted interrupts. This information may be read in /proc/cpuinfo: 

Loading KVM on the Nitro system is most easily done by   modprobe’ing the KVM modules:

The irqbypass  module provides posted interrupts to KVM virtual machines, reminding us again that we may pass PCI devices present on the bare-metal host through to KVM virtual machines.

Built-in virtio virtual I/O at the Linux Kernel Level

virtio  is a Linux kernel i/o virtualization feature: it is maintained and supported by Amazon and that it works with qemu-kvm  to provide isolated (not shared as in Xen’s dom0  netback and blockback) virtual i/o devices for virtual machines that do not need direct access to a hardware PCI device. Each virtio  device is a unique and private virtual PCI device with separation provided by the Linux kernel.

The Amazon Linux kernel supports virtio devices, as shown by this excerpt of the Amazon Linux configuration file:

Kernel Shared Memory (KSM)

KSM is a Linux kernel feature that scans memory pages, merges duplicates, marks those pages as read-only, and copies the pages when they are written (COW).  KSM provides a kernel-level mechanism for over-provisioning memory. KSM is automatic, built in, and does not require an external module as Xen does, for example, with its Dom0 balloon driver.

KSM is documented in the Linux kernel documentation directory.

The Amazon Linux kernel is configured with KSM:

Running a KVM virtual machine with copy-on-write memory is straightforward, by starting the virtual machine with the mem-merge feature turned on: 

Using the -machine mem-merge=on  command upon virtual machine startup causes QEMU to execute anmadvise system call with the MADV_MERGEABLE parameter for the virtual machine memory, marking the VM memory as merge-able.

To disable merging for a virtual machine upon startup, use the same command but substitute  mem-merge=off . 

Running the KVM Virtual Machine

We created a virtual machine using a minimal Linux distribution: TTY Linux. It has an image built specifically to run with KVM using virtio  network and block devices.

We ran KVM Linux virtual machines using this command line:

Only three steps are required to create the virtual machine:

  1. Download the TTY Linux distribution and unzip to an iso image:
  1. Create the qcow disk image for the virtual machine:
  1. Run the virtual machine:

We were struck by how easy it was to run KVM virtual machines on these Nitro systems, configured as they are with Amazon Linux. Each virtual machine in our testing had 1G of memory and 1G of writeable storage.

numactl and other Linux Process Control

A benefit of  KVM on i3.metal is the ability to use standard Linux system calls to control virtual machine resources. A good example is using the Linux numactl  command to allocate CPU cores for a kvm virtual machine: 

The above command uses numactl utility to bind the KVM virtual machine to Core #1.  It demonstrates how integrated KVM is with the Linux kernel and how simple it is to allocate memory and cores to specific virtual machines.

Integration with the Linux Kernel: cgroups, nice, numactl, taskset

We can turn the Linux kernel into a hypervisor by loading the KVM modules and starting a virtual machine, but the Linux personality is still there. We can control the virtual machine using standard Linux resource and process control tools such as cgroups, nice, numactl, and taskset :

All cgroup  commands work naturally with KVM virtual machines. As far as cgroups is concerned, each KVM virtual machine is a normal Linux process (although KVM runs that process at the highest privilege level in VMX guest mode (pptx), which provides hardware virtualization support directly to the virtual machine). There are two utilities to bind a KVM virtual machine to a specific processor, NUMA node, or memory zone:taskset  and numactl .

In summary, the Linux command set along with qemu-kvm  allows us native control over processors, memory zones, and other platform properties for to running KVM virtual machines. Libvirt, on the other hand, is a layer over these native control interfaces that tends to obscure what is really going on at the hardware level.

Testing the Limits of  Bare-Metal AWS Hypervisor Performance

To more securely run virtual-machine workloads on cloud services, we accessed a bare-metal instance for project research during the preview period. We wanted to first verify that KVM can be used as a hypervisor on EC2 bare-metal instances, and second, get a read on stability and performance. We had limited time for this portion of the research.

To measure system response, we decided to use the BPF Compiler Collection (BCC) (building and using this toolset may be the subject of another blog post).

BCC uses the extended Berkeley Packet Filter, an amazing piece of technology in recent Linux Kernels that runs user-space byte code within kernel space. BCC compiles byte code that uses dynamic kernel probes to instrument kernel behavior.

To test CPU load, we added a simple shell script to each VM’s init process:

This ensured that each virtual machine would be consuming all the CPU cycles allowed to it by KVM.

Next, we used a simple shell script to start KVM virtual machines into oblivion:

Then we ran the BCC program, which measures how much time processes are spending on the scheduler’s run queue – a measure of system load and stability. The histogram below shows the system when running 6417 virtual machines.

The histogram above demonstrates how long, within a range, each sampled process waited on the KVM scheduler’s run queue before it was actually placed on the processor and run. The wait time in usecs shows how long a process that is runnable (not sleeping or waiting for any resources or events to occur) waited in order to run. There are three things to look for in this histogram:

  1. How closely grouped are the sampled wait times? Most processes should be waiting approximately the same time. This histogram shows this is the case, with close to half samples waiting between 4 and 15 microseconds.
  2. How low are the wait times? On a system that is under-utilized, the wait times should be mostly immaterial (just a few microseconds or less on this hardware). This system is over-utilized, and yet the wait times for most of the samples are fewer than 15 microseconds.
  3. How scattered are the samples in terms of wait times? In this histogram there are two groups: the larger group with wait times less than 511 microseconds, and the smaller group with wait times between 1024 and 32767 microseconds. The second group consists of only roughly 7% of samples. We would expect a distressed system to show several different groups clustered around longer wait times, with outliers comprising more than 7% of all samples.

Upon reaching 6417 virtual machines, the system was unable to start any new VMs, due to memory exhaustion. However we were able to  ssh to running VMs; when we stopped a VM, KVM started a new one. This system appeared to be capable of running indefinitely with this extreme load placed upon the CPU resources.

CPU and Memory Over-provisioning

When fully loaded with virtual machines, CPUs were overloaded 10:1 virtual cycles to physical cycles. There were more than thirty thousand processes running on the system, and it was actively reclaiming memory using KSM (discussed above). Before running the tests, the consensus among our team was that perhaps we could run 2K virtual machines before the system fell apart. This guess (that’s all it was) proved to be overly pessimistic. (However, we did not test I/O capacity in any significant way.)

Beyond proving that we could run a hell of a lot of virtual machines on the i3.metal platform, and that CPU over provisioning was wickedly efficient, we didn’t accomplish much else; for example, we can conclude nothing about the I/O performance of the system. But these are rich grounds for further performance and limit testing using the BCC toolkit, which we hope to discuss in a later blog post.

"컨테이너 관리의 정석" 쿠버네티스의 이해와 활용 - IDG DeepDive

‘쿠버네티스(Kubenetes)’가 거침없이 질주하고 있다. 쿠버네티스는 컨테이너 일정 관리부터 컨테이너 간 서비스 검색, 시스템의 부하 분산, 롤링 업데이트/롤백, 고가용성 등을 지원하는 오케스트레이션 툴이다. 컨테이너 원천 기술을 가진 도커의 ‘스웜(Swarm)’ 을 가볍게 제압하고, 이제는 기업의 60%가 사용하는 사실상의 표준 컨테이너 툴이 됐다. 340억 달러, 우리 돈 38조 원에 달하는 IBM의 레드햇 인수도 그 이면에는 쿠버네티스가 자리 잡고 있다. 

오늘날 기업 IT 인프라에서 쿠버네티스가 중요한 이유와 구축 방법을 살펴본다. 관리와 보안을 도와줄 유용한 툴과 주요 클라우드 업체의 쿠버네티스 서비스도 심층 분석한다.

<주요 내용>
Tech Trend
- 미안, 리눅스! 이제 주인공은 ‘쿠버네티스’야
- “최신 1.12부터 구버전까지” 쿠버네티스 컨테이너 버전별 변천사
- “배포판부터 예제까지” 올바른 쿠버네티스 시작 가이드
- 컨테이너 혁명 이끄는 주요 쿠버네티스 배포판 12가지
Tech Solution
- 쿠버네티스 ‘관리 지옥’에서 탈출하는 필수 툴 15가지
- “쿠버네티스를 더 안전하게” 필수 컨테이너 보안 툴 7종
AWS vs. 애저 vs. 구글 클라우드 … 관리형 쿠버네티스 3종 심층 비교
- 쿠버네티스, 고통은 쓰지만 열매는 ‘너무’ 달다
- “서버 비용 80% 절감” 영국 파이낸셜 타임스의 쿠버네티스 도입기

상기 링크에서 다운.

[Product Issue] TG DPX, 인라인 vs. 아웃오브패스 대결의 종결자

  • 안철수연구소
  • 2010-11-19

2006년도 하반기부터 시작된 국내 DDoS 시장에서 DDoS 공격 대응 제품은 여러 형태나 분류로 나눌 수 있다. 그 중 구성 방식에 따라 인라인(Inline) 방식의 제품과 아웃오브패스(Out-of-Path) 방식의 제품으로 구분하는 것이 가장 대표적이다. 이러한 두 가지 형태의 구성 방식은 사실 네트워크 담당자가 아니라면 생소하게 느껴질 수 밖에 없는 용어다. 
이 글에서는 인라인 구성 방식과 아웃오브패스 구성 방식에 대해 쉽고 명확하게 이해를 할 수 있도록 소개하고자 한다.

구성 방식에 따른 분류

인라인 방식과 아웃오브패스 방식은 해당 장비가 네트워크 구간 내에 어디에 위치하느냐에 따라 구분된다. 인라인 방식은 네트워크 구간 내에 위치하게 되며, 빠른 대응이 가장 큰 장점이다. 반면, 아웃오브패스 방식은 네트워크 외부에 위치하며, 네트워크 안정성이 높다는 것이 장점이다. 인라인 방식과 아웃오브패스 방식, 각각의 특성은 [표 1]과 같다.



Inline 구성 방식

Out-of-Path 구성 방식

구성의 특징

네트워크 구간 내에 위치

네트워크 외부에 위치

트래픽 기준

양방향 트래픽

단뱡향 트래픽

(일부 양방향 트래픽)

보안 적용의 장점

빠른 대응

네트워크 안정성 뛰어남

대규모 트래픽 구간에 설치 적합

구성의 단점

평상시 네트워크에 관여

Inline 대비 느린 대응

양방향 트래픽 구성 시 구성 복잡

적용 제품

방화벽, IPS, 웹 방화벽,

L2/L3/L4/L7 Switch

DDoS, 웹 방화벽, L4/L7 Switch, Proxy

이제 본격적으로 인라인 방식과 아웃오브패스 방식에 대해 자세히 알아보기로 하자.

Inline 구성 방식이란?

1. 구성 방식의 설명
인라인 방식은 라우터, 스위치 등과 같은 네트워크 장비 및 방화벽, IPS와 같은 보안 장비들의 구성 방식처럼 트래픽 소통 구간에 설치되는 방식을 의미한다(그림 1).


[그림 1]  Inline 구성 방식의 예

이 방식의 경우 네트워크 구간 사이에 위치하기 때문에 해당 장비의 설치 시 실시간 네트워크 트래픽의 단절 현상이 있으며, 회선 구성 등의 변경도 불가피하게 일어날 수 밖에 없다. 특히 인라인 방식의 제품이 IP 어드레스(Address)를 설정하는 구성 방식인 L3 (Routed) 인라인일 경우에는 설치되는 네트워크 구간 상단 및 하단 장비의 네트워크 IP 설정도 변경이 되어야 하는 부분이 있다. 이로 인해 최근에는 인라인 구성 방식으로 설치 시에는 IP 어드레스가 필요없는 L2 (Transparent) 모드를 선호하며, 대부분의 인라인 제품은 해당 구성 방식을 지원하고 있다.

2. 인라인 제품이 관여하게 되는 네트워크 트래픽의 특징
인라인 방식의 제품은 [그림 1]과 같이 트래픽이 소통되는 네트워크 구간 내에 설치가 되기 때문에, 내부로 들어오는 인바운드(Inbound) 트래픽과 외부로 나가는 아웃바운드(Outbound) 트래픽 등 양 양방향 트래픽 모두 해당 제품을 거치게 된다. 
모든 고객에게 있어서 설치된 인라인 제품의 장애나 트래픽 전송 지연 문제에 대해서는 매우 민감한 사안일 수 밖에 없다. 이로 인해 기본적으로 인라인 제품은 최소한의 전송 지연 시간 (Latency Time)이나 장애 시 트래픽 바이패스(Traffic Bypass) 기능 등의 대비책을 제공하고 있다.

3. 보안적인 측면에서 인라인 방식은 인바운드

보안적인 측면에서 인라인 방식은 인바운드 트래픽에 대한 보안 설정과 함께 아웃바운드 트래픽에 대한 보안 설정을 할 수 있다는 이점을 가지고 있다. 
특히 TCP 프로토콜(Protocol)의 경우에는 세션기반 프로토콜(Session Oriented Protocol)로서, 클라이언트와 서버 간의 양방향 통신을 유지해야만 하는 특징이 있다. 따라서, 일반적인 인라인 구성 방식의 방화벽이나 IPS 에서는 TCP 프로토콜에 대해 양방향 세션이 정상적으로 통신이 되고 있는지와 함께, TCP 프로토콜의 규약에 맞는 양방향 통신이 되고 있는지에 대해서도 점검하여 비정상적인 세션을 차단할 수 있는 보안 기능을 제공한다. 이 기능이 바로 잘 알려진 ‘스테이트풀 인스펙션(Stateful Inspection)’이다.
또한, 네트워크 구간 내에서 동작을 하고 있으므로, 보안 위협에 대한 탐지에 대해 즉시 차단 명령을 내리면 실시간으로 보안 정책이 적용될 수 있는 것이 가장 큰 특징이다. 물론, 최근에는 네트워크 구성이 매우 복잡하고 고도화되고 있어 네트워크 구간 내의 회선이 2중화 이상으로 구성이 되는 경우가 비일비재하다. 이러한 구성 방식을 대응하기 위하여 인라인 방식 제품은 하나의 장비에서 여러 회선을 수용할 수 있는 구성 방식과 함께 2대 이상의 인라인 방식 제품이 서로 실시간 TCP 세션을 공유할 수 있도록 하는 액티브-액티브(Active-Active) HA 구성 방식도 지원하는 제품도 있다.

4. 적용 제품의 예
A. 방화벽
    A. L3 (Routed) Mode 구성 방식의 방화벽
    B. L2 (Transparent) Mode 구성 방식의 방화벽
    C. L2 (Transparent) Mode 구성 방식의 Bypass 기능을 내장한 방화벽
    A. L2 (Transparent) Mode 구성 방식의 Bypass 기능을 내장한 IPS
C. Router/Switch
    A. L3 기반의 Routing 처리(Static & Dynamic Routing Protocol)
    B. L2 기반의 Swtching 처리

Out-of-Path 구성 방식이란?

1. 구성 방식의 설명
아웃오브패스 방식은 ‘Out-of-Path’라는 단어에서 의미하는 바와 같이 설치되는 장비가 트래픽의 소통 구간에서 외부로 빠져 나와있는 구성 방식을 의미한다. 이를 도식화하면 [그림 2]와 같다.

[그림 2] Out-of-Path 구성 방식의 예

특히, 아웃오브패스 방식은 인라인 방식과는 다르게 네트워크 구간 외부에 설치되어 전체 트래픽 중 특정한 트래픽만 통과하거나, 평상시에는 전혀 트래픽이 통과하지 않는 구성으로 이용이 가능하다. 이로 인해 제품이 설치가 되더라도 기존의 네트워크 트래픽 흐름에는 영향을 주지 않는 장점을 가지고 있다. 즉, 인라인 방식의 약점인 전송 지연, 또는 장애 등의 문제로부터 좀 더 자유로울 수 있다는 것이다.

2. 아웃오브패스 방식이 관여하는 네트워크 트래픽의 방향성
아웃오브패스 방식을 통과하는 트래픽의 유형은 크게 ‘특정 서비스 트래픽의 양방향 트래픽’이나 ‘특정 서비스 트래픽의 단방향 트래픽’의 두 가지 형태로 분류할 수 있다.


[그림 3] Out-of-Path 구성 양방향 트래픽  [그림 4] Out-of-Path 단방향 트래픽

먼저, 여기서 언급한 ‘특정 서비스 트래픽’이란 전체 네트워크 트래픽 아웃오브패스 방식의 제품만을 통과하는 서비스 트래픽을 의미하는 것이다. 예를 들어 대외 서비스를 하는 서버가 웹 서버, DNS 서버, 메일 서버가 있다고 가정하자. 이 경우, 아웃오브패스 방식 제품에서는 DNS 서버와 메일 서버의 트래픽을 제외한 웹 서버만을 통과시킨다. 즉, DNS 서버와 메일 서버의 트래픽은 아웃오브패스 방식의 제품이 관여하지 않는다는 것이다. 이로 인하여 기존의 DNS 서버와 메일 서버의 트래픽은 기존의 네트워크 경로를 그대로 이용하게 되므로, 서비스에 영향을 받지 않는다.
만약 양방향 트래픽을 이용할 경우에는 위에서 예를 든 웹 서버의 경우와 같이 클라이언트에서 서버로 요청하는 트래픽(Inbound Traffic)이 아웃오브패스 방식 제품으로 유입되고, 서버에서 클라이언트로 응답하는 트래픽(Outbound Traffic) 또한 아웃오브패스 방식의 제품으로 유입되는 구성 방식을 의미한다.

3. 보안 제품의 구성 제약 및 적용의 범위
아웃오브패스 방식에서 양방향 트래픽을 구성할 경우에는 네트워크 상에서의 트래픽 라우팅의 고려가 매우 중요하다. 일반적으로 네트워크 트래픽 라우팅은 목적지 IP 기반의 라우팅 정책을 적용하게 된다. 예를 들어 ‘웹 서버로 향하는 트래픽을 아웃오브패스 방식 제품으로 보내겠다’라고 하는 형태로 구성이 된다. 하지만 웹 서버가 랜덤한 출발지 IP로의 응답 트래픽을 아웃오브패스 방식 제품으로 보내고자 하는 라우팅은 목적지 IP 기반의 라우팅 정책으로는 적용이 불가능하다. 이로 인하여 PBR (Policy Based Routing) 등의 기법을 이용하여 출발지 IP 기반의 라우팅 기법을 적용해야만 웹 서버의 아웃바운드 트래픽도 아웃오브패스 방식 제품으로 트래픽을 유입시킬 수 있다.

양방향 트래픽 기준의 아웃오브패스 방식 제품은 이러한 문제점을 해결하기 위해 트래픽 통신을 중계시켜 주는 ‘프록시 IP’를 설정하여 운영하게 된다. 예를 들어 클라이언트가 웹 서버로 요청할 때에는 아웃오브패스 방식 제품에 설정된 웹 서버의 대표 IP로 요청을 하게 되고, 아웃오브패스 방식 제품은 설정된 프록시 IP를 이용해 서버로 트래픽을 중계하게 된다. 이후 서버의 응답 트래픽은 프록시 IP로 전달되고, 이 응답을 아웃오브패스 방식 제품이 클라이언트에게 전달하는 복잡한 구조로 대응한다.

하지만 대부분 가장 효율적인 방법으로 랜덤한 클라이언트의 요청 트래픽인 인바운드 트래픽에 대해서만 관심을 가지고 아웃바운드 트래픽에 대해서는 적용하지 않는 단방향 기준의 보안 정책도 많이 사용하고 있다. 이에 대한 대표적인 예가 DDoS 공격 방어의 경우이다. 
예를 들어, 웹 서비스의 보안 영역 중 DDoS 공격의 경우에는 외부로부터 웹 서버로 유입되는 대규모의 DDoS 트래픽에 관한 보안 정책이 필요하고, 그 반대인 웹 서버가 외부의 불특정 대상에게 DDoS 공격을 감행하는 사례는 매우 적다고 판단할 수 있다. 이때에는 DDoS 공격 방어를 위해서는 아웃바운드 트래픽에는 관여할 필요 없이 인바운드 트래픽 만을 대상으로 DDoS 공격 방어를 수행하면 된다. 한가지 예를 더 들자면, L4/L7 스위치의 경우에도 클라이언트의 웹 서비스에 대한 요청 트래픽만 처리하고, 웹 서비스의 응답 트래픽은 L4/L7 스위치를 거치지 않고 직접 클라이언트에게 전달되는 DSR(Direct Server Response) 방식을 들 수 있다.

특히 대규모 웹 서비스의 트래픽 특성을 살펴보면, 웹 서비스를 요청하는 클라이언트로부터의 인바운드 트래픽은 양이 작으며, 서비스에 응답을 하고 웹 페이지를 전달하는 아웃바운드 트래픽은 상대적으로 양이 많다. 이 경우 인바운드 트래픽만을 기준으로 보안을 구축할 때에는 대규모 서비스 망이라고 하더라도 상대적으로 적은 인바운드 트래픽 기준으로 보안 제품을 선택할 수 있으므로, 제품의 활용 효과 면에서도 이점을 가질 수 있다.

4. 적용 제품의 예
특정 서비스의 트래픽 중 양방향 트래픽을 사용하는 제품은 Transparent Mode의 L4/L7 스위치나 프록시 기반의 방화벽, 웹 방화벽 기반이 될 수 있다.
특정 서비스의 트래픽 중 단방향 트래픽을 사용하는 제품은 DSR(Direct Server Response) 모드의 L4/L7 스위치나 DDoS 공격 방어 제품이 있다.

지금까지 인라인 구성 방식과 아웃오브패스 구성 방식에 대해 간단히 기술적으로 비교해 보았다. 이 중 가장 많은 이야기를 이어나갈 수 있는 DDoS 공격 대응 제품에서의 인라인 구성 방식과 아웃오브패스 구성 방식에 대해서 이야기를 하고자 한다.

DDoS 공격 대응 제품, 인라인 vs. 아웃오브패스 전격 비교

DDoS 공격 대응 제품에 있어서 인라인 방식과 아웃오브패스 방식의 대결 구도는 어제 오늘의 일이 아니다. 고객은 DDoS 공격 대응 제품의 도입부터 이 두 가지 방식을 고려해야만 했다. 또한 벤더사는 자신의 제품이 채택한 방식의 강점을 부각시키기 위해 노력해왔다.

DDoS 공격 대응 제품의 구성 방식에 대한 이해

[그림 1]과 같이 인라인 구성 방식의 경우 네트워크 구간 내에 위치하게 되며, 단일 제품 또는 2대 이상의 다수의 제품으로 구성된다. 이 경우 DDoS 공격 대응 제품은 실시간으로 트래픽을 모니터링하며 차단할 수 있다.
반면 아웃오브패스 구성 방식의 경우에는 앞에서 설명한 바와 같이 네트워크 구간 외부에 위치하여 평상시에는 동작하지 않는 특징을 가지고 있다. 이로 인하여 DDoS 공격 발생 시 동작할 수 있도록 항시 모니터링하는 ‘탐지 전용’ 제품과 DDoS 공격을 실제적으로 차단하게 되는 ‘차단 전용’ 제품으로 역할이 나누어지게 된다. 물론, 대규모 트래픽을 처리할 수 있도록 탐지 장비와 차단 장비는 2대 이상의 다수의 제품으로 구성되는 클러스터(Cluster) 구성 방식도 있다.

DDoS 공격 방어 대상 트래픽: 양방향 Vs. 단방향

일부 네트워크 구성의 특성에 따라 인바운드 DDoS 공격과 아웃바운드 DDoS 공격 두 가지를 모두 고려하는 경우가 있다. 이러한 사례를 생각해보면 DDoS 공격 대응 제품이 보호하는 대상이 서버뿐만 아니라 클라이언트까지 포함된 네트워크 구간일 경우가 여기에 해당된다. 특히 서버가 외부 IDC에 있는 것이 아닌 자체 망의 DMZ 구간 내에 포함이 되어 있는 경우이다. 이 경우 DDoS 공격 대응 제품은 DMZ 네트워크와 내부 네트워크의 트래픽 단일 유입 구간에 설치가 될 경우에는 인바운드 DDoS 공격에 대해 DMZ 네트워크의 서버에 대한 DDoS 공격 방어를 수행한다. 그리고, 내부 네트워크 구간의 클라이언트 PC가 아웃바운드 DDoS 공격을 할 경우에도 방어를 수행하는 경우가 있다. 이 때에는 양방향 트래픽의 방향성에 적합한 인라인 구성 방식의 DDoS 공격 대응 제품이 적합하다.

하지만, 일반적으로 DDoS 공격은 외부에서 내부 서비스로의 대규모 트래픽을 유발하여 외부의 정상적인 사용자들이 서비스로 접근을 하지 못하게 하는 특징을 가지고 있다. 따라서 일반적으로 DDoS 공격 대응 제품은 인바운드 트래픽 관점에서의 방어를 원칙으로 한다.

따라서, 대외 서비스를 수행하는 서버에 대한 DDoS 공격 방어를 하기 위해서는 인라인 구성방식의 DDoS 공격 대응 제품에서 인바운드 DDoS 공격만을 관여하도록 하거나, 또는 대규모 트래픽이 발생하는 IDC 구간일 경우에는 아웃오브패스 구성 방식의 DDoS 공격 대응 제품이 적합하다.

DDoS 공격 방어 동작 시간의 적합성: 인라인 vs. 아웃오브패스

DDoS 공격은 공격이 발생하면 즉시 서비스가 마비되는 현상을 초래하므로 이에 대한 대응 시간이 매우 중요하다. 
인라인 구성의 경우 앞서 설명한 바와 같이 양방향, 또는 단방향 트래픽에 대해 실시간으로 탐지/차단을 수행하기 때문에 DDoS 공격 발생 시 즉시 설정되어 있는 정책에 의해 공격을 차단할 수 있다. 이 경우 최소 1초 이내의 DDoS 공격 탐지/차단 동작이 수행될 수 있는 장점이 있다.

반면, 아웃오브패스 구성의 경우에는 평상시 DDoS 공격을 차단하는 제품은 동작하지 않고, 이를 동작시키기 위해 상시 모니터링을 하는 DDoS 공격 탐지 장비가 별도로 구성이 된다. 이 경우 DDoS 공격이 발생이 되면 먼저 DDoS 공격 탐지 장비가 DDoS 공격을 인지하여 DDoS 공격 차단 장비로 동작 명령을 전달하여, 차단 장비가 DDoS 트래픽에 대해 차단을 처리하게 된다. 이로 인하여 아웃오브패스 구성 방식의 DDoS 공격 대응 제품은 인라인 구성 방식의 제품보다는 대응 시간이 느리다는 구조적 한계가 분명히 존재한다.

이를 보완하기 위하여 아웃오브패스 구성 방식에서 빠르게 동작할 수 있는 여러 가지 기술들이 개발되고 있다. 예를 들어, 기존의 사용되었던 스위치/라우터에서 수집되는 트래픽 플로우 정보가 아닌 실시간 트래픽 기준으로 탐지할 수 있는 기술이 적용되고 있다. 아울러 인바운드 트래픽만을 기준으로 하여 실시간 트래픽을 모니터링해 효율성을 극대화하는 기술도 현재 이용되고 있다. 

DDoS 공격 방어 기능: 인라인 vs. 아웃오브패스/양방향 vs. 단방향/클러스터링

지금까지 인라인 구성 방식과 아웃오브패스 구성 방식, 그리고 트래픽의 방향성에 대해 설명을 하였다. 하지만, 가장 중요한 것은 각 구성 환경과 트래픽 특성에 따라 DDoS 공격을 어떻게 방어할 수 있는지에 대한 DDoS 공격 방어 기능이다. 단순히 네트워크 구성만 지원한다고 해서 DDoS 공격을 대응할 수 있는 것은 아니므로, 본연의 기능인 DDoS 공격 방어 기능에 다시 초점을 맞추어야 한다.

우선, 인라인 구성 방식에서의 양방향 트래픽 관점에서의 DDoS 공격 방어 기능을 살펴보자. 이 경우에는 외부로부터 유입되는 인바운드 DDoS 공격에 대해 탐지/차단할 수 있는 기능이 기본적으로 제공이 되어야 한다. 특히 단순한 임계치(Threshold) 기반의 DDoS 공격 탐지/차단은 해당 정책에 의해 탐지/차단 되는 트래픽이 실제로 정상적인 패킷(Packet)인지 아닌지에 대해 명확히 판단할 근거가 없다. 따라서, 이러한 임계치 기반의 DDoS 공격 탐지/차단 동작 방식 이전에 해당 패킷이 정상적인 패킷 인지를 검증해 줄 수 있는 ‘인증 기반’의 DDoS 공격 탐지/차단 방식이 필요하다. 아울러 아웃바운드 DDoS 공격에 대해서는 내부 클라이언트/서버의 IP는 알고 있으므로, 이와 다른 IP 에서 발생할 경우에는 즉시 차단하고, 정상적인 응답 트래픽 특성이 아닌 경우에는 인증 기반 및 임계치 기반으로 탐지/차단 할 수 있는 기술이 필요하다.

두 번째로, 인라인 구성의 단방향 트래픽 관점과 아웃오브패스 구성의 단방향 트래픽 관점에서의 DDoS 공격 방어 기능에 대해 살펴보자. 앞서 언급한 바와 같이 인바운드 DDoS 공격에 대해 정확히 방어하기 위하여 ‘인증 기반’의 패킷 검증 방식과 ‘임계치(Threshold) 기반’의 정책 기반의 DDoS 탐지/차단 방식이 동시에 지원되어야 한다. 하지만 ‘인증 기반’의 경우에는 해당 구성에서는 단방향 트래픽만을 가지고 ‘인증 기반’을 사용해야 하므로, 인라인 구성 방식에서 사용하는 인증 기반 기술과는 다른 단방향 트래픽을 기준으로 한 독특한 기술이 필요하다. 또한 단순히 아웃오브패스 DDoS 탐지 장비에서 보여지는 양방향 트래픽 기준의 정상/비정상 연결(Connection) 여부만을 가지고 판단하는 것이 아닌, DDoS 공격 발생 시 아웃오브패스 DDoS 차단 장비에서의 실시간 인증 기반 검증이 제대로 된 DDoS 공격을 방어할 수 있는 기술이다.

마지막으로, 단방향 트래픽 기준의 인라인 및 아웃오브패스 구성 방식을 고려할 때 가장 큰 강점은 바로 여러 대의 DDoS 제품을 하나의 DDoS 제품처럼 클러스터링하는 것이다. 이 경우에도 앞서 설명한 바와 같이 ‘인증 기반’과 ‘임계치 기반’ 두 가지 방식이 지원되어야 하는 것이 매우 중요하다. 이와 더불어 다중 장비의 정책을 동시에 동기화 할 수 있는 관리 방안과 함께 ‘인증 기반’의 검증의 경우에는 다중 장비의 ‘인증’ 동작 정보가 실시간으로 공유가 되어야 여러 대의 DDoS 제품이 하나의 DDoS 공격 대응 솔루션으로 사용될 수 있다. 

[그림 5] Inline Cluster 구성의 예              [그림 6] Out-of-Path Cluster 구성의 예


AhnLab TrusGuard DPX, 
Inline / Out-of-Path / Clustering 구성이 지원되는 DDoS 공격 대응 제품

AhnLab TrusGuard DPX(이하 TG DPX) 는 업계 최초로 라이선스(License) 변경만으로도 동일 제품에서 인라인 구성 방식과 아웃오브패스 구성 방식, 그리고 클러스터링 구성까지 지원하는 제품이다. 
특히, 다단계 필터 구조를 통하여 기본적으로 제공되는 자동 학습 기반의 임계치 기준의 DDoS 탐지/차단 방식을 지원할 뿐만 아니라 실시간 인증 기반을 통하여 DDoS 공격 발생 시 유입되는 트래픽이 정상적인지 비정상적인지를 확인할 수 있는 기능을 제공한다.

[그림 7] AhnLab TrusGuard DPX 구성 방식의 예

TG DPX는 단방향 트래픽만을 기준으로 하여 아웃오브패스에서의 DDoS 공격 탐지를 할 수 있으며, 공격 차단을 공격 대상의 트래픽만을 기준으로 하여 인증 기반과 임계치 기반의 DDoS 공격 방어를 처리할 수 있는 독특한 기술을 제공하고 있다. 또한 DDoS 공격 차단을 수행하는 다중 장비간의 인증 정보를 실시간으로 공유함으로써, 단방향 트래픽 기준의 인라인 및 아웃오브패스 클러스터링 구성 방식까지 지원하고 있다.
이를 통하여 TG DPX는 기존 DDoS 공격 방어 시 임계치 기반 방식의 DDoS 공격 차단 처리 방식과 대비 정확하고 오탐이 최소화된 DDoS 공격 대응 기능을 제공한다. @

+ Recent posts