http://www.itworld.co.kr/techlibrary/114957


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

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

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

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

상기 링크에서 다운.

https://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?seq=17002


[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 기능을 내장한 방화벽
B. IPS
    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 공격 대응 기능을 제공한다. @


'ETC.' 카테고리의 다른 글

MacBook 터치바 오류 해결  (0) 2020.03.22
PM, RFI, RFP, WBS, SOW, POC, BMT  (0) 2019.09.18
애자일 소프트웨어 개발 선언,  (0) 2018.08.12
TCP 튜닝  (0) 2018.03.30
Let's Encrypt Wildcard 인증서 발급하기  (0) 2018.03.29

Firecracker는 Serverless 컴퓨팅을 위한 안전하고 빠른 microVM을 위한 AWS에서 만든 KVM기반의 새로운 hypervisor 이다.

Lambda와 Fargate등 컨테이너를 써야 하지만 공유 보안이 문제가 되는 곳에  컨테이너 수준의 빠른 실행을 보장하는 hypervisor이다.

이는 AWS 뿐만 아니라 OnPremise이든 IBM의 Baremetal이든 다 올릴 수 있다. 물론 PC에서도 가능하다.  (vagrant에 쓰면 좋겠는데?)


원문 : https://aws.amazon.com/ko/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/


가상화 기술의 새로운 과제

오늘날 고객은 서버리스 컴퓨팅을 사용하여 인프라의 구축 또는 관리에 대한 걱정없이 애플리케이션을 구축 할 수 있습니다. 개발자는 코드를 AWS Fargate를 사용하여 서버리스 컨테이너를 사용하거나 AWS Lambda를 사용하여 서버리스 함수들을 사용 할 수 있습니다. 고객들은 서버리스의 낮은 운영 오버 헤드를 너무 좋아합니다. 우리 또한 서버리스가 향후 컴퓨팅에서 중추적 인 역할을 계속할 것으로 믿습니다.

고객이 서버리스를 점점 더 많이 채택함에 따라 기존의 가상화 기술은 이벤트 중심 또는 짧은 수명의 특성이 있는 이러한 유형의 워크로드의 특성에 최적화되지 않았음을 알게 되었습니다. 우리는 서버리스 컴퓨팅을 위해 특별히 설계된 가상화 기술을 구축 할 필요성을 확인했습니다. 가상 시스템의 하드웨어 가상화 기반 보안 경계를 제공하면서도 컨테이너 크기와 기능의 민첩성을 유지하면서 크기를 유지할 수있는 방법이 필요했습니다.


Firecracker Technology

Meet Firecracker, an open source virtual machine monitor (VMM) that uses the Linux Kernel-based Virtual Machine (KVM). Firecracker allows you to create micro Virtual Machines or microVMs. Firecracker is minimalist by design – it includes only what you need to run secure and lightweight VMs. At every step of the design process, we optimized Firecracker for security, speed, and efficiency. For example, we can only boot relatively recent Linux kernels, and only when they are compiled with a specific set of configuration options (there are 1000+ kernel compile config options). Also, there is no support for graphics or accelerators of any kind, no support for hardware passthrough, and no support for (most) legacy devices.

Firecracker boots a minimal kernel config without relying on an emulated bios and without a complete device model. The only devices are virtio net and virtio block, as well as a one-button keyboard (the reset pin helps when there’s no power management device). This minimal device model not only enables faster startup times (< 125 ms on an i3.metal with the default microVM size), but also reduces the attack surface, for increased security. Read more details about Firecracker’s promise to enable minimal-overhead execution of container and serverless workloads.

In the fall of 2017, we decided to write Firecracker in Rust, a modern programming language that guarantees thread and memory safety and prevents buffer overflows and many other types of memory safety errors that can lead to security vulnerabilities. Read more details about the features and architecture of the Firecracker VMM at Firecracker Design.

Firecracker microVMs improve efficiency and utilization with a low memory overhead of < 5 MiB per microVMs. This means that you can pack thousands of microVMs onto a single machine. You can use an in-process rate limiter to control, with fine granularity, how network and storage resources are shared, even across thousands of microVMs. All hardware compute resources can be safely oversubscribed, to maximize the number of workloads that can run on a host.

We developed Firecracker with the following guiding tenets (unless you know better ones) for the open source project:

  • Built-In Security: We provide compute security barriers that enable multitenant workloads, and cannot be mistakenly disabled by customers. Customer workloads are simultaneously considered sacred (shall not be touched) and malicious (shall be defended against).
  • Light-Weight Virtualization: We focus on transient or stateless workloads over long-running or persistent workloads. Firecracker’s hardware resources overhead is known and guaranteed.
  • Minimalist in Features: If it’s not clearly required for our mission, we won’t build it. We maintain a single implementation per capability.
  • Compute Oversubscription: All of the hardware compute resources exposed by Firecracker to guests can be securely oversubscribed.

We open sourced this foundational technology because we believe that our mission to build the next generation of virtualization for serverless computing has just begun.

Firecracker Usage

AWS Lambda uses Firecracker as the foundation for provisioning and running sandboxes upon which we execute customer code. Because Firecracker provides a secure microVM which can be rapidly provisioned with a minimal footprint, it enables performance without sacrificing security. This lets us drive high utilization on physical hardware, as we can now optimize how we distribute and run workloads for Lambda, mixing workloads based on factors like active/idle periods, and memory utilization.

Previously, Fargate Tasks consisted of one or more Docker containers running inside a dedicated EC2 VM to ensure isolation across Tasks. These Tasks now execute on Firecracker microVMs, which allows us to provision the Fargate runtime layer faster and more efficiently on EC2 bare metal instances, and improve density without compromising kernel-level isolation of Tasks. Over time, this will allow us to continue to innovate at the runtime layer, giving our customers even better performance while maintaining our high security bar, and lowering the overall cost of running serverless container architectures.

Firecracker runs on Intel processors today, with support for AMD and ARM coming in 2019.

You can run Firecracker on AWS .metal instances, as well as on any other bare-metal server, including on-premises environments and developer laptops.

Firecracker will also enable popular container runtimes such as containerd to manage containers as microVMs. This allows Docker and container orchestration frameworks such as Kubernetes to use Firecracker. We have built a prototype that enables containerd to manage containers as Firecracker microVMs and would like to with with community to take it further.

Getting Started with Firecracker

Getting Started with Firecracker provides detailed instructions on how to download the Firecracker binary, start Firecracker with different options, build from the source, and run integration tests. You can run Firecracker in production using the Firecracker Jailer.

Let’s take a look at how to get started with using Firecracker on AWS Cloud (these steps can be used on any bare metal machine):

Create an i3.metal instance using Ubuntu 18.04.1.

Firecracker is built on top of KVM and needs read/write access to /dev/kvm. Log in to the host in one terminal and set up that access:

sudo setfacl -m u:${USER}:rw /dev/kvm

Download and start the Firecracker binary:

curl -L https://github.com/firecracker-microvm/firecracker/releases/download/v0.11.0/firecracker-v0.11.0
./firecracker-v0.11.0 --api-sock /tmp/firecracker.sock

Each microVM can be accessed using a REST API. In another terminal, query the microVM:

curl --unix-socket /tmp/firecracker.sock "http://localhost/machine-config"

This returns a response:

{ "vcpu_count": 1, "mem_size_mib": 128,  "ht_enabled": false,  "cpu_template": "Uninitialized" }

This starts a VMM process and waits for the microVM configuration. By default, one vCPU and 128 MiB memory are assigned to each microVM. Now this microVM needs to be configured with an uncompressed Linux kernel binary and an ext4 file system image to be used as root filesystem.

Download a sample kernel and rootfs:

curl -fsSL -o hello-vmlinux.bin https://s3.amazonaws.com/spec.ccfc.min/img/hello/kernel/hello-vmlinux.bin
curl -fsSL -o hello-rootfs.ext4 https://s3.amazonaws.com/spec.ccfc.min/img/hello/fsfiles/hello-rootfs.ext4

Set up the guest kernel:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/boot-source'   \
    -H 'Accept: application/json'           \
    -H 'Content-Type: application/json'     \
    -d '{        "kernel_image_path": "./hello-vmlinux.bin", "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"    }'

Set up the root filesystem:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/drives/rootfs' \
    -H 'Accept: application/json'           \
    -H 'Content-Type: application/json'     \
    -d '{        "drive_id": "rootfs",        "path_on_host": "./hello-rootfs.ext4",        "is_root_device": true,        "is_read_only": false    }'

Once the kernel and root filesystem are configured, the guest machine can be started:

curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT 'http://localhost/actions'       \
    -H  'Accept: application/json'          \
    -H  'Content-Type: application/json'    \
    -d '{        "action_type": "InstanceStart"     }'

The first terminal now shows a serial TTY prompting you to log in to the guest machine:

Welcome to Alpine Linux 3.8
Kernel 4.14.55-84.37.amzn2.x86_64 on an x86_64 (ttyS0)
localhost login:

Log in as root with password root to see the terminal of the guest machine:

localhost login: root
Password:
Welcome to Alpine! 

The Alpine Wiki contains a large amount of how-to guides and general information about administrating Alpine systems. 

See <http://wiki.alpinelinux.org>. 

You can setup the system with the command: setup-alpine 

You may change this message by editing /etc/motd.

login[979]: root login on 'ttyS0' 
localhost:~#

You can see the filesystem usingls /

localhost:~# ls /
bin         home        media       root        srv         usr
dev         lib         mnt         run         sys         var
etc         lost+found  proc        sbin        tmp

Terminate the microVM using the reboot command. Firecracker currently does not implement guest power management, as a tradeoff for efficiency. Instead, the reboot command issues a keyboard reset action which is then used as a shutdown switch.

Once the basic microVM is created, you can add network interfaces, add more drives, and continue to configure the microVM.

Want to create thousands of microVMs on your bare metal instance?

for ((i=0; i<1000; i++)); do
    ./firecracker-v0.10.1 --api-sock /tmp/firecracker-$i.sock &
done

Multiple microVMs may be configured with a single shared root file system, and each microVM can then be assigned its own read/write share.

Firecracker and Open Source

It is our mission to innovate on behalf of and for our customers, and we will continue to invest deeply in serverless computing at all three critical layers of the stack: the application, virtualization, and hardware layers. We want to offer our customers their choice of compute, whether instances or serverless, with no compromises on security, scalability, or performance. Firecracker is a fundamental building block for providing that experience.

Investing deeply in foundational technologies is one of the key ways that we at AWS approach innovation – not for tomorrow, but for the next decade and beyond. Sharing this technology with the community goes hand-in-hand with this innovation. Firecracker is licensed under Apache 2.0. Please visit the Firecracker GitHub repo to learn more and contribute to Firecracker.

By open sourcing Firecracker, we not only invite you to a deeper examination of the foundational technologies that we are building to underpin the future of serverless computing, but we also hope that you will join us in strengthening and improving Firecracker. See the Firecracker issues list and the Firecracker roadmap for more information.



+ Recent posts