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 공격 대응 기능을 제공한다. @


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.




eth1에 추가 IP를 셋팅한다.

cat << EOF > /etc/sysconfig/network-scripts/ifcfg-eth1:1

DEVICE=eth1:1

GATEWAY=169.56.100.1

IPADDR=169.56.100.100

NETMASK=255.255.255.0

ONBOOT=yes

EOF


#Full NAT 설정

systemctl start firewalld

systemctl enable firewalld

systemctl restart NetworkManager


echo "net.ipv4.ip_forward = 1" > /etc/sysctl.d/ip_forward.conf

sysctl -p /etc/sysctl.d/ip_forward.conf



#Full NAT Setting

function fullnat() {

  local LOCAL_DEV=$1

  local LOCAL_IP=$2

  local DEST_DEV=$3

  local DEST_IP=$4

  firewall-cmd --direct --permanent --add-rule ipv4 nat PREROUTING 1 -i ${LOCAL_DEV} -d ${LOCAL_IP} -j DNAT --to-destination ${DEST_IP}

  firewall-cmd --direct --permanent --add-rule ipv4 nat POSTROUTING 0 -o ${DEST_DEV} -s ${DEST_IP} -j SNAT --to-source ${LOCAL_IP}

  firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -s ${LOCAL_IP} -j ACCEPT

  firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -d ${DEST_IP} -j ACCEPT

}


#Public -> Private

fullnat eth1 169.56.100.100 eth0 10.10.5.5

#Public -> Public 

fullnat eth1 169.56.100.100 eth1 13.125.100.100

#Private -> Private

fullnat eth0 10.100.10.10 eth0 10.10.5.5

#Private -> Public

fullnat eth0 10.10.5.5 eth1 169.56.100.100


#Bonded Private -> Private

fullnat bond0 10.100.10.10 bond0 10.10.5.5



'OS > Linux' 카테고리의 다른 글

CentOS 7 Full NAT 설정, Secondary IP 추가  (0) 2018.11.05
pdnsd로 DNS Proxy 설정하기  (0) 2018.11.05
firewalld 설정  (0) 2018.11.04
SAMBA 설치 at CentOS 7  (0) 2018.08.29
vimdiff 사용법  (0) 2018.04.21
Linux 에서 IP 추출  (0) 2018.04.21


가끔 외부에서 Cloud의 내부 DNS를 써야 할 경우가 있다.

그럴 경우 NGINX에서 TCP 53/UDP 53을 Reversy Proxy 해도 되고,

보다 편하게 할려면 Proxy DNS를 쓰면 된다. (DNS 캐싱 기능도 있음)


# 설치

wget http://members.home.nl/p.a.rombouts/pdnsd/releases/pdnsd-1.2.9a-par_sl6.x86_64.rpm

yum localinstall pdnsd-1.2.9a-par_sl6.x86_64.rpm


#/etc/pdnsd.conf를 열어서 해당 서버의 IP와 DNS IP를 설정한다.

vi /etc/pdnsd.conf

global {

        server_ip = 169.56.100.100; #해당 서버의 Public IP로 바꾼다.

}


server {

        ip = 10.0.80.11; #Cloud의 내부 DNS 주소를 적는다. (Softlayer: 10.0.80.11)

#AWS의 내부 DNS 주소는 링크 참고, https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/VPC_DHCP_Options.html#AmazonDNS

}


systemctl restart pdnsd

systemctl enable pdnsd



#방화벽에서 특정 IP만 열고 싶다면

firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4"  source address="1.2.3.4/32"  port protocol="tcp" port="53" accept"

firewall-cmd --permanent --zone=public --add-rich-rule="rule family="ipv4"  source address="1.2.3.4/32"  port protocol="udp" port="53" accept"

#전체를 열려면

firewall-cmd --permanent --zone=public --add-service=dns


'OS > Linux' 카테고리의 다른 글

CentOS 7 Full NAT 설정, Secondary IP 추가  (0) 2018.11.05
pdnsd로 DNS Proxy 설정하기  (0) 2018.11.05
firewalld 설정  (0) 2018.11.04
SAMBA 설치 at CentOS 7  (0) 2018.08.29
vimdiff 사용법  (0) 2018.04.21
Linux 에서 IP 추출  (0) 2018.04.21

안쓰면 자꾸 까먹는다...


잘정리 해두신 분꺼 스크랩, 출처: https://www.lesstif.com/pages/viewpage.action?pageId=22053128


firewalld 란


Linux 커널 2.2 까지는 ipchains 이라는 패킷 필터링/방화벽 프레임워크가 구현되어 있었고 2.4부터는 더 유연하고 다양한 기능을 가진 netfilter 로 프레임워크가 교체 되었습니다.

iptables 은 netfilter 프레임워크의 최상단에 위치하는 사용자 레벨의 프로그램으로 시스템 관리자는 iptables 명령어로 리눅스 서버로 들어오고 나가는 패킷을 필터링하거나 포트 포워딩을 설정할 수 있으며 방화벽으로도 사용할 수 있습니다.

iptables 는 숙련된 관리자가 아니면 사용이 어려운 단점이 있었는데 이런 문제를 해결하고자 RHEL/CentOS 7 부터는 방화벽을 firewalld 라는 데몬으로 교체하였고 이에 따라 사용자 레벨의 프로그램은 iptables 명령어 대신 명령행에서는 firewall-cmd , GUI 환경에서는 firewall-config 를 사용하게 되었습니다.

이 절에서는 firewall-cmd 명령을 사용하여 firewalld 데몬을 통해 방화벽 정책을 구성하고 수정하는 것을 학습하게 됩니다.

firewall 스택


영구적 규칙과 정책 재구동

기본적으로 firewall-cmd 로 방화벽 정책을 변경했을 경우 현재 구동되고 있는 firewalld 에 즉시 적용되지만 정책은 지속성이 없이 임시로 적용되며 정책을 재구동하는 명령어인 firewall-cmd --reload 를 실행하거나 시스템을 재부팅하면 예전 정책으로 다시 초기화 되며 이로 인해 서비스의 장애가 발생할 수 있습니다.


이때문에 방화벽 정책을 영구적으로 유지하기 위해서는 --permanent 옵션을 추가해서 실행하면 되지만 이는 즉시 적용되지 않고 firewall-cmd --reload 명령어로 방화벽 정책을 재구동하거나 재부팅을 하기 전에는 변경한 방화벽 설정이 적용되지 않습니다.


firewalld 를 처음에 사용할 때 이 때문에 혼란을 겪고 정책 설정을 잘못한 걸로 오해하는 사용자가 많으므로 아래 표를 보고 방화벽 정책의 즉시 적용 여부와 지속성 여부를 꼭 익혀 두어야 합니다.



firewall-cmd
firewall-cmd --permanent
즉시 적용(firewall-cmd --reload 불필요)아니요
재부팅시 정책의 지속 여부아니오
방화벽 정책 적용 여부


예로 fireall-cmd 로 정책을 추가했을 경우 즉시 반영되지만 만약 잘못된 설정이었을 경우에 firewall-cmd --reload 명령어를 실행하면 예전 정책으로 복구됩니다.


하지만 firewall-cmd --permanent  로 정책을 추가했을 경우 firewall-cmd --reload 명령어를 실행해야 변경한 정책이 적용되며 예전 정책으로 복구하려면 새로 추가한 정책을 삭제하고 다시 방화벽을 구동해야 합니다.

만약 방화벽 정책 변경시 즉시 반영하고 재부팅시에도 유지되도록 하고 싶으면 firewall-cmd 를 두 번 호출하면 되며 한 번은 --permanet 옵션을 주고 한 번은 옵션을 빼면 됩니다.


Network Zone

firewalld 의 특징중 하나는 이 장의 서두에서 설명한 네트워크 구성과 영역을 기본 설정으로 포함시켰다는 것입니다. 이에 따라 서버가 어떤 zone에 포함될 지만 정의하면 상대적으로 설정해야 하는 부분이 대폭 간소화 되었습니다.


먼저 기본 설정된 zone 의 목록을 확인하려면 firewall-cmd 명령에 --get-zones 옵션을 주고 실행하면 됩니다.

$ sudo firewall-cmd  --get-zones
 
 
work drop internal external trusted home dmz public block
사전 정의된 zone 목록

표시된 목록은 사전 정의된  zone 으로 이제 서버의 용도에 맞게 zone 을 할당하면 되며 해당 zone 이 어떤 정책을 갖고 있는지 확인하려면 --list-all-zones 옵션으로 사전 정의된 zone 에 대한 자세한 정보를 볼 수 있습니다.

$ sudo firewall-cmd  --list-all-zones
 
 
dmz
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:
 
 
internal
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:
zone 에 대한 자세한 정보 출력

각 zone 별 services 항목을 보면 해당 zone 에서 기본적으로 허용하는 서비스 포트를 확인할 수 있으며 dmz 는 ssh 를, internal 은 dhcpv6-client, mdns 등을 허용하는 것을 알수 있습니다.


현재 활성화된 zone 을 확인하려면 --get-active-zone 옵션을 실행하면 되며 현재 활성화된 zone 은 public 인 것을 알수 있습니다.

$ sudo firewall-cmd --get-active-zone
 
 
public
  interfaces: eth0
public
  interfaces: eth1
현재 활성화된 zone 출력


존 설정 정보 보기(--list-all)

현재 활성화된 존 정보를 확인하려면 --list-all  옵션을 사용하면 됩니다. 아래는 현재 활성화된 존이 dmz 이고 10022 등의 port 가 열려 있음을 표시합니다.

$ sudo firewall-cmd --list-all
 
 
dmz (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp5s0f0 enp5s0f1
  sources:
  services: ssh http https
  ports: 10022/tcp 2120-2121/tcp 20/tcp 2120-2142/tcp 10000/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:


특정 존의 정보를 볼 경우 --zone 옵션뒤에 존 이름을 기술합니다. 아래는 work 존 설정을 표시합니다.

$ sudo firewall-cmd --list-all --zone work



기본 존 바꾸기

기본 존을 변경하려면  --set-default-zone=ZONE 옵션을 사용하여 변경해 주면 되며 다음은 dmz 로 변경하는 예제입니다. 

$ sudo firewall-cmd  --set-default-zone=dmz
기본 존 변경


서버의 경우 여러 개의 NIC(Network Interface Card) 가 있을 수 있고 NIC 마다 다른 zone 을 설정해야 할 수 있습니다. NIC 가 eth0 eth1 두 개가 있을 경우 --change-interface=[ETH] 명령으로 인터페이스마다 사용할 zone 을 지정할 수 있습니다.


다음은 eth0는 dmz , eth1은 private 로 변경하는 예제입니다.

$ sudo firewall-cmd --zone=dmz --change-interface=eth0
$ sudo firewall-cmd --zone=dmz --change-interface=eth1
NIC 마다 zone 지정


존 만들기

만약 firewalld 에 내장된 zone 설정이 현재 서비스에 딱 들어 맞지 않는다면 --new-zone 옵션을 사용하여 새로 zone 을 만들면 됩니다. 아래는 webserver 라는 이름의 새로운 존을 만드는 예제입니다.

$ sudo firewall-cmd --permanent --new-zone=webserver
새로운 zone 생성


생성한 존은 바로 반영되지 않으므로 방화벽 정책을 다시 읽어 들여야 합니다. --reload 을 주어서 변경된 내역을 firewalld에 반영할 수 있습니다.


$ sudo firewall-cmd --reload
변경된 정책 반영


이제 방화벽 정책을 반영했으니 새로 생성한 존이 보이는지 확인을 위해 --get-zones 옵션을 주고 실행하면 목록에 추가된 것을 확인할 수 있습니다.

$ sudo firewall-cmd --get-zones
 
block dmz drop external home internal public trusted webserver work
존 생성 여부 확인

TODO webserver 진하게 표시


사전 정의 서비스

사전 정의된 서비스 확인

firewalld 에는 방화벽 정책 변경시 용이하도록 많이 사용하는 서비스를 사전에 정의해 놓고 있으며 --get-services 옵션으로 전체 목록을 확인할 수 있습니다. 

$ sudo firewall-cmd --get-services
 
 
RH-Satellite-6 amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability http https imaps ipp ipp-client ipsec iscsi-target kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind rsyncd samba samba-client smtp ssh telnet tftp tftp-client transmission-client vdsm vnc-server wbem-https
사전 정의 서비스 목록


서비스 추가

웹 서버는 http(80), https(443) 으로 접근을 허용해야 하므로 --add-service=SERVICENAME 구문으로 서비스를 추가해 줍니다. --add-service 는 여러 개의 서비스를 동시에  기술할 수 없으므로 http와 https 를 따로 기술해 줍니다.

$ sudo firewall-cmd --permanent --zone=webserver --add-service=http
$ sudo firewall-cmd --permanent --zone=webserver --add-service=https
http 서비스 추가


서비스 삭제

서비스 삭제는 --remove-service=SERVICENAME 구문을 사용합니다. 아래는 http/https 서비스를 삭제합니다.


$ sudo firewall-cmd --permanent --zone=webserver --remove-service=http
$ sudo firewall-cmd --permanent --zone=webserver --remove-service=https
http 포트 추가



포트 추가

만약 사전 정의된 서비스가 아닌 다른 포트를 사용하는 경우 --add-port=포트번호:프로토콜  형식으로  등록할 수 있습니다. 포트 번호가 범위일 경우 - 를 구분자로 등록할 수 있습니다.


아래는 9090에서 9100 까지 TCP 포트를 허용하는 방화벽 설정 예제입니다.

$ sudo firewall-cmd --permanent --zone=webserver --add-port=9090-9100/tcp
포트 번호로 추가


포트 삭제

포트 삭제는 --remove-port=포트번호:프로토콜 형식으로 사용하면 되며 add 와 마찬가지로 범위일 경우 - 를 구분자로 사용합니다.

아래 명령은 webserver 존에 추가한 9090 에서 9100 포트 오픈 정책을 삭제합니다.


$ sudo firewall-cmd --permanent --zone=webserver --remove-port=9090-9100/tcp
포트 번호로 삭제




포트 추가/변경, IP 추가/변경은 --reload 옵션으로 firewalld 를 재실행해야 반영됩니다.



인터페이스 변경 및 ssh 서비스 추가

이제 웹 서버 존은 eth0 이더넷을 사용하도록 설정하고 eth1 이더넷은 내부 망에서 ssh로 연결 가능하도록 dmz 존으로 만들기 위해 각 존이 사용하는 NIC를 --change-interface 옵션으로 변경해 봅시다.

internal 이나 home 은 기본적으로 samba 나 printing 서버등이 열려 있으므로 웹 서버같이 DMZ에 위치할 서버에 할당하지 않는 게 좋습니다.

$ sudo firewall-cmd --permanent --zone=webserver --change-interface=eth0
$ sudo firewall-cmd --permanent --zone=dmz --change-interface=eth1
NIC 마다 zone 지정



웹 서버이므로 어떤 클라이언트 IP 라도 80, 443 포트에 연결하면 허용하도록 설정했지만 IP 에 따라 접근 제어를 실행해야 하는 서비스도 있습니다.


예로 웹서버를 원격에서 관리할 수 있도록 ssh 서비스를 등록할 경우 일반적으로는 정해진 IP에서만 접근을 허용해야 합니다.


이럴 경우 --add-source=<source range>/netmask 옵션을 사용하여 허용할 IP 를 추가해 줄 수 있습니다. 


이제 dmz 에 ssh 서비스를 추가하고 내부 망(192.168.10.0/24) 에서만 ssh 가 연결 가능하도록 설정하고 webserver 존은 --remove-service 명령어로 ssh 서비스를 삭제합니다.


$ sudo firewall-cmd --permanent --zone=dmz --add-service=ssh
$ sudo firewall-cmd --permanent --zone=dmz --add-source=192.168.10.0/24
$ sudo firewall-cmd --permanent --zone=webserver --remove-service=ssh
NIC 마다 zone 지정


이제 방화벽 구성이 완료되었으니 firewall-cmd --reload 명령을 사용하여 방화벽 정책을 반영합니다.


rich rule

만약 설정하고자 하는 방화벽 정책이 복잡하고 firewall-cmd 에서 적절한 옵션을 제공하지 않을 경우 rich-rule 을 사용하여 복잡한 규칙을 설정할 수 있습니다.

rich rule 은 별도의 문법을 갖고 있으며 iptables 의 어려운 옵션을 알지 않아도 세밀하게 원본 주소, 목적지 주소에 따른 접근 제어, 로깅, 세밀한 액션 설정등 복잡한 방화벽 규칙을 작성할 수 있는 특성이 있으며 아래와 같은 형식으로 새로운 규칙을 추가해 줄 수 있습니다.

$ sudo firewall-cmd [--zone=zone] --add-rich-rule='rule' [--timeout=timeval]
rich 룰 문법

[ ] 안에 있는 옵션은 생략 가능하며 예로 --zone 옵션을 생략하면 기본 존에 반영이 됩니다. --timeout 옵션이 주어질 경우 해당 시간동안만 방화벽 규칙이 적용되고 그 시간이 지나면 자동으로 예전 규칙으로 돌아가며 기본 시간값은 s(초)이나 m(분) , h(시간) 을 붙여서 시간 단위를 지정할 수 있습니다.


규칙 삭제 및 확인

규칙을 삭제할 경우 아래와 같이 --remove-rich-rule 명령으로 삭제하면 됩니다.

$ sudo firewall-cmd [--zone=zone] --remove-rich-rule='rule'
rich 규칙 삭제


규칙이 있는지 확인하려면 --query-rich-rule 명령을 사용하며 실행 결과로 콘솔에 yes 가 표시되면 해당 규칙이 존재하는 것이고 no 일 경우 규칙이 없는 경우입니다.

$ sudo firewall-cmd [--zone=zone] --query-rich-rule='rule'
 
 
yes
rich 규칙 검증


rich 규칙 문법

리치 규칙은 아래와 같은 구조를 갖고 있으며 마찬가지로 대괄호([ ]) 안의 옵션은 생략 가능하며 전체 규칙은 한줄에 기술해야 합니다.

rule
  [family="rule family"]
  [source]
  [destination]
  service|port|protocol|icmp-block|icmp-type|masquerade|forward-port|source-port
  [log]
  [audit]
  [accept|reject|drop|mark]
리치 규칙 문법


family

TCP 프로토콜 패밀리를 지정하며 ipv4 또는 ipv6 를 설정하면 되며 생략할 경우 ipv4, ipv6 를 모두 허용합니다.  만약 규칙에서 source 나 destination 주소를 사용하는 경우 family 가 ipv4  인지 ipv6 인지 명시적으로 기술해야 합니다.


출발지(source)

source [not] address="address[/mask]"|mac="mac-address"|ipset="ipset"

출발지 주소를 지정해서 IP 기반으로 접근 제어를 실행할 수 있으며 IP 주소 또는 CIDR(Classless Inter-Domain Routing) 방식으로 지정하면 되며 NOT 을 사용하여 반대의 의미로 사용할 수 있습니다.


예로 아래의 예제는 192.168.10.0 의 모든 대역을 지정합니다.

source address="192.168.10.0/24"
CIDP 로 소스 IP 지정


아래의 예제는 192.168.10.5 가 아닌 모든 IP 를 지정합니다.

source not address="192.168.10.5"
특정 IP 가 아닌 경우 지정



destination

목적지 주소도 원본 주소와 마찬가지로 아래와 같은 구문으로 사용하면 됩니다.

destition [not] address="address[/mask]"|mac="mac-address"|ipset="ipset"


element

요소는 service, port, protocol, masquerade, icmp-block, forward-port와 source-port 중에 하나가 될 수 있으며 각 요소의 의미는 다음과 같습니다.


service

서비스 요소의 사용법은 아래와 같이 name=service_name 형식으로 사용하면 됩니다.

service name=https

service 요소는 firewalld 에서 사전에 정의한 서비스 목록이며 well known 서비스일 경우 포트보다 서비스 이름(예: 443 대신 https)으로 지정하는 게 편리하며 firewall-cmd --get-services 로  전체 서비스 목록을 얻을 수 있습니다.

서비스 요소 사용시 목적지 주소를 제공하면 규칙의 목적지 주소와 충돌하게되고 오류가 발생하므로  멀티 캐스트를 사용하는 서비스외에는 일반적으로는 사용하면 안 됩니다.


port

port port=number_or_range protocol=protocol

포트는 단일 포트 번호 또는 포트 범위를 지정(예: 8080-8100) 할 수 있으며 tcp/udp 로 프로토콜을 구분해 주어야 합니다.


아래는 tcp 의 8080에서 8100 까지 포트 범위를 지정하는 예제입니다.

port port=8080-8100 protocol=tcp



protocol

프로토콜 항목은 id 또는 이름으로 지정할 수 있으며 사전에 정의된 프로토콜은 /etc/protocols 에 있으며 아래와 같은 형식으로 사용하면 됩니다.

protocol value=protocol_name_or_ID

다음은 IP(Internet Protocol) 암호화 버전인 IPSec(Internet Protocol Security) 에서 사용하는 인증 헤더(ah; Authentication Header) 를 지정하는 예제입니다.

protocol value="ah"
IPSec의 AH 헤더


icmp-block

하나 이상의 ICMP(Internet Control Message Protocol) 를 차단할 경우 사용하며 아래와 같이 차단하려면 ICMP 유형을 지정하면 됩니다.

icmp-block name=icmptype_name


전체 ICMP 의 목록을 얻으려면 아래 명령을 사용하면 됩니다.


log

커널 로깅(예 : syslog)을 사용하여 방화벽 규칙에 대한 새로운 연결 시도를 기록할수 있으며 로그의 구분을 위해 로그 메시지에 추가될 접두어 문자열을 정의 할 수 있습니다.

로그 수준은 emerg, alert, crit, error, warning, notice, info 또는 debug 중 하나이며 로그 사용은 선택 사항입니다.

log [prefix=prefix text] [level=log level] limit value=rate/duration


로깅 사용은 limit 키워드를 사용하여 제한할 수 있으며 rate 는 1이상의 양의 자연수이며 duration 은 s(second), m(minute), h(hour), d(day) 를 지정할 수 있습니다.

최대 제한은 1/d 이며 이는 하루에 최대 1번만 로깅을 하겠다는 의미입니다.


다음은 ftp 프로토콜을 자세히 로깅하기 위해 로그 파일에 ftp 라는 접두사를 붙이고 debug 레벨로 30초마다 로깅하겠다는 설정입니다.

log prefix=ftp level=debug limit value=30/s
log 예제



audit

감사(audit) 은 log 대신 방화벽을 로깅할 수 있는 설정으로 syslog 등의 로그 장치로 보내지 않고 auditd 감사 데몬으로 감사 레코드를 전송합니다.


audit 명령은 파라미터가 없지만 선택적으로 limit 키워드를 사용하여 감사 수집을 제한 할 수 있습니다. audit 사용은 선택 사항입니다.

audit [limit value="rate/duration"]


action

action 키워드로 규칙에 맞는 패킷에 대한 동작을 정의할 수 있으며 action은 허용(accept), 거부(reject), 파기(drop) 또는 표시(mark) 중 하나를 설정하면 됩니다.

규칙에는 element 또는 출발지만 포함될 수 있으며 규칙에 element가 포함되어 있으면 일치하는 새 연결이 작업과 함께 처리됩니다. 규칙에 원본이 포함되어 있으면 원본 주소의 모든 내용이 지정된 작업으로 처리됩니다.

accept | reject [type=reject type] | drop | mark set="mark[/mask]"


accept를 사용하면 모든 새로운 연결 시도를 허용하며 reject 를 설정하면 거부되며 출발지  주소에 거부 메시지를 전하며 거부 유형은 다른 값을 사용하도록 설정할 수 있습니다.

drop을 설정하면 모든 패킷이 즉시 파기되고 어떤 정보도 출발지 주소로 전송하지 않으므로 기본 방화벽의 동작으로 권장합니다. mark를 사용하면 모든 패킷에 주어진 표시와 선택 사항 마스크가 표시됩니다.

rich rule 적용 예제

이제 firewall-cmd 의 rich rule 을 사용하여 세밀하게 방화벽 정책을 수립하는 예제를 살펴봅시다.

예제에서는 --zone=dmz 명령으로 적용할 zone 을 지정했지만 하나의 zone 만 있다면 지정할 필요가 없으며 --permanent 옵션을 제외해서 즉시 반영되지만 방화벽 정책 재구동이나 시스템 재부팅시 정책이 유지되지 않으므로 지속해야 할 정책이라면 --permanent옵션을 주어서 정책을 만들고 --reload 옵션으로 정책을 지속적으로 반영하는 것이 필요합니다.


IPSec 의 ah 프로토콜 허용

IPSec 의 authentication 헤더를 허용하며 family 를 지정하지 않았으므로 ipv4, ipv6 모두 허용됩니다.

$ sudo firewall-cmd --add-rich-rule='rule protocol value="ah" accept'
authentication header 허용

만약 정책을 삭제하려면 위 명령어를 복사한 후에 --add  --remove 로 변경하면 되며 아래는 위 rich 규칙을 삭제하는 예제입니다.

$ sudo firewall-cmd --remove-rich-rule='rule protocol value="ah" accept'
authentication header 허용 삭제


ftp 허용

192.168.10.0 대역의 모든 서버에서 ipv4 를 사용하여 ftp 연결을 허용하며 30초마다 로깅을 audit 을 사용하여 기록합니다.

$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" service name="ftp" source address="192.168.10.0/24" log limit value="30/s" prefix="ftp" audit accept'
ftp 허용


베스천 호스트에서만 SSH 접속 허용

중요한 서비스인 SSH 를 보호하기 위해 베스천 호스트(예: 192.168.58.2) 에서만 ipv4 를 사용하여 SSH 연결을 허용합니다.

$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="192.168.58.2" service name="ssh" accept'
베스천 호스트에서만 ssh 허용



white list 허용

화이트 리스트인 192.168.20.2 에서 public 존에 대한 모든 연결을 허용합니다.

$ sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.20.2" accept'
화이트 리스트 허용


black list 연결 거부

블랙 리스트인 192.168.58.10 에서 모든 연결을 거부하고 "icmp-net-prohibited"  ICMP 메시지를 전송합니다.

$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="192.168.58.10" reject type="icmp-net-prohibited"'
블랙 리스트 거부


black list 연결 차단(drop)

블랙 리스트인 192.168.58.11 에서 모든 연결을 drop 합니다.

$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="192.168.58.11" drop'
ftp 허용


IP 위장 방어

공격자는 공격지를 들키지 않기 위해 패킷의 출발지 IP 주소를 위장할 수 있으며 특히 사설 IP 주소가 설정된 패킷이 인터넷상의 서버에 도착한다면 주의가 필요합니다. 사설 IP 주소의 범위를 클래스 별로 CIDR(Classless Inter-Domain Routing 방식으로 기술해 보면 다음과 같습니다.

  • 10.0.0.0/8(10.0.0.0 ~ 10.255.255.255)
  • 172.16.0.0/12(172.16.0.0 ~ 172.16.255.255)
  • 192.168.0.0/16(192.168.0.0 ~ 192.168.255.255)


그리고 다음과 같은 특별한 IP 주소도 사용하지 않는다면 서버에서 거부하도록 설정하는 것이 좋습니다.

  • 169.254.0.0/16 - DHCP 가 없는 환경에서 네트워크 구성을 위한 zeroconf route 주소
  • 192.0.2.0/24 - TEST NET
  • 224.0.0.0/4 - Multicast 용
  • 240.0.0.0/5 - 미래를 위해 예약


$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="10.0.0.0/8" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="172.16.0.0/12" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="192.168.0.0/16" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="169.254.0.0" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="224.0.0.0/4" drop'
$ sudo firewall-cmd --zone=dmz --add-rich-rule='rule family="ipv4" source address="240.0.0.0/5" drop'
IP 위장 방어


이중에서 사설 IP 대역과 멀티캐스트를 위해 예약된 224.0.0.0 대역은 회사의 네트워크 구성 여부에 따라 사용할 수 있지만 인터넷 상의 서버에 도착한 패킷이 사설 IP 로 왔을 경우에만 차단해야 하므로 --zone 옵션으로 명시적으로 사설 IP 를 차단할 존을 기술하는 게 좋습니다.

특히 멀티캐스트는 tomcat 의 세션 클러스터링(기본 설정:  228.0.0.4)시 기본 설정이므로 내부 망과 연결된 존에서는 차단하지 말아야 하며 톰캣 클러스터링이 제대로 동작하는지 확인해 보아야 합니다.


Smurf 공격 방어

스머프 공격은 DOS(Denial of Service) 공격의 일종으로서 공격 대상인 서버의 IP 로 위장한 ICMP 패킷을 전체 네트워크에 브로드캐스팅하는 공격으로 다음과 같은 절차에 따라 공격을 수행합니다.


smurf 공격
  1. 공격자는 출발지 IP를 공격 대상의 IP로 변조(10.0.0.1)한 ICMP echo request 패킷을 목적지 네트워크의 브로드캐스트 주소(192.168.0.255) 로 전송
  2. 브로드캐스트이므로 네트워크내의 모든 서버는 해당 패킷을 수신한 후에 출발지 IP 주소인 10.0.0.1 에 ICMP Echo Reply 패킷을 전송
  3. 공격 대상 서버(10.0.0.1) 는 ICMP 패킷을 대량으로 수신하여 서비스 불능 상태에 빠짐

이에 대한 대책은 브로드캐스트로 요청된 ICMP 패킷을 파기하도록 방화벽 정책을 설정하면 됩니다.

$ sudo firewall-cmd --add-rich-rule='rule family=ipv4 destination address="0.0.0.0/8" drop'
$ sudo firewall-cmd --add-rich-rule='rule family=ipv4 destination address="255.255.255.255" drop'
Smurf 공격 방어

정상적으로 방화벽 정책이 반영되고 정상 동작 여부를 확인했다면 영구적으로 방화벽 정책을 적용하기 위해  --permanent 옵션을 추가해서 한 번 더 실행해 주면 됩니다.

즉 위의 smurf 방지 대책은 아래와 같이 한 번 더 실행해 주면 됩니다.


$ sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 destination address="0.0.0.0/8" drop'
$ sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 destination address="255.255.255.255" drop'
Smurf 공격 방어


위와 같이 CentOS 7 에 포함된  firewalld 를 사용하면 사전에 정의된 규칙에 따라 손쉽게 방화벽 정책을 수립할 수 있으며 고급 정책이 필요할 경우 rich 규칙을 사용하여 더 세밀한 방화벽 정책을 수립할 수 있습니다.

Ref


'OS > Linux' 카테고리의 다른 글

CentOS 7 Full NAT 설정, Secondary IP 추가  (0) 2018.11.05
pdnsd로 DNS Proxy 설정하기  (0) 2018.11.05
firewalld 설정  (0) 2018.11.04
SAMBA 설치 at CentOS 7  (0) 2018.08.29
vimdiff 사용법  (0) 2018.04.21
Linux 에서 IP 추출  (0) 2018.04.21

AWS 비용 계산기가 새로 나왔습니다.

UI도 깔끔해졌고, 여러 리전을 그룹으로 지정해서 같이 계산도 가능합니다.

Edit Group으로 원하는 리전을 먼저 그룹으로 만들고 시작하세요.

https://calculator.aws/

EFS, nfs

cpio를 이런데 쓸줄이야. (사실 검색해보기 전까지는 backup용으로 쓰이던걸 몰랐다. Android fs 빼낼때나 썻지...)

fpart + cpio + GNU Parallel 은 참신하다. Amazon EFS 외에도 잘 써먹을 수 있겠다.

참고 : https://github.com/aws-samples/amazon-efs-tutorial

원문 : https://s3.amazonaws.com/aws-us-east-1/demo/efs-parallel-file-transfer-test.html


Amazon EFS Parallel File Transfer Test

AWS Storage Days | New York | September 6-8, 2017

Version 1.0


© 2017 Amazon Web Services, Inc. and its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited.

Errors or corrections? Email us at darrylo@amazon.com.


Step-by-step Guide

Launch this environment to evaluate how the different instances types, I/O size, and thread count effects throughput to an Amazon EFS file system.

AWS CloudFormation template will launch:

  • Three Auto Scaling groups
  • Recommend using default instance types for each Auto Scaling group
    • t2.micro for Auto Scaling group 0
    • m4.large for Auto Scaling group 1
    • c4.xlarge for Auto Scaling group 2
  • Minimum and desired size for each Auto Scaling group is 1 (maximum 4)
  • Each Auto Scaling group instance will auto mount the identified Amazon EFS file system, generate 5GB of 1MB files & 5GB of 10MB files using smallfile, and install the following applications:
    • nload - is a console application which monitors network traffic and bandwidth usage in real time
    • smallfile - https://github.com/bengland2/smallfile - used to generate test data; Developer: Ben England
    • GNU Parallel - https://www.gnu.org/software/parallel/ - used to parallelize single-threaded commands; O. Tange (2011): GNU Parallel - The Command-Line Power Tool, ;login: The USENIX Magazine, February 2011:42-47
    • Mutil mcp - https://github.com/pkolano/mutil - multi-threaded drop-in replacement of cp; Author Paul Kolano (NASA)
    • fpart - https://github.com/martymac/fpart - sorts file trees and packs them into partitions; Author Ganaël Laplanche
    • fpsync - wraps fpart + rsync - included in the tools/ directory of fpart

NOTICE!! Amazon Web Services does NOT endorse specific 3rd party applications. These software packages are used for demonstration purposes only. Follow all expressed or implied license agreements associated with these 3rd party software products.

WARNING!! If you build the above mentioned environment, this will exceed your free-usage tier. You will incur charges as a result of creating this environment and running these scripts in your AWS account. If you run this environment for 1 hour, you may incur a charge of ~$1.18.

You can launch this CloudFormation stack, using your account, in the following AWS Regions:

AWS Region CodeNameLaunch
us-east-1US East (N. Virginia)cloudformation-launch-stack
us-east-2US East (Ohio)cloudformation-launch-stack
us-west-2US West (Oregon)cloudformation-launch-stack
eu-west-1EU (Ireland)cloudformation-launch-stack
eu-central-1EU (Frankfurt)cloudformation-launch-stack
ap-southeast-2AP (Sydney)cloudformation-launch-stack

SSH to all three EC2 instances

Not all EC2 instances are created equal

Run this command against t2.micro

1. Write 17GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/17G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=17408 conv=fsync &
nload -u M
While this is running, continue and run Step 2 in a separate terminal session.

Run this command against m4.large

2. Write 5GB to EFS w/ 1MB block size

time dd if=/dev/zero of=/efs/dd/5G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=5120 conv=fsync &
nload -u M

Maximize throughput using larger I/O size

Run the remaining commands against c4.xlarge

3. Write 2GB to EBS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

4. Write 2GB to EFS w/ 1MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress conv=fsync
Record run time.

5. Write 2GB to EBS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

6. Write 2GB to EFS w/ 8MB block size - ‘sync’ once at the end

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress conv=fsync
Record run time.

Sample run times

Step & CommandDuration
3. Write 2GB to EBS w/ 1MB block size - ‘sync’ once at the end22 seconds
4. Write 2GB to EFS w/ 1MB block size - ‘sync’ once at the end12 seconds
5. Write 2GB to EBS w/ 8MB block size - ‘sync’ once at the end22 seconds
6. Write 2GB to EFS w/ 8MB block size - ‘sync’ once at the end12 seconds
7. Write 2GB to EBS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

8. Write 2GB to EFS w/ 1MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=1M count=2048 status=progress oflag=sync
Record run time.

9. Write 2GB to EBS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

10. Write 2GB to EFS w/ 8MB block size - ‘sync’ after each block is written

time dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N).img bs=8M count=256 status=progress oflag=sync
Record run time.

Sample run times

Step & CommandDuration
7. Write 2GB to EBS w/ 1MB block size - ‘sync’ after each block is written22 seconds
8. Write 2GB to EFS w/ 1MB block size - ‘sync’ after each block is written1 minute 43 seconds
9. Write 2GB to EBS w/ 8MB block size - ‘sync’ after each block is written22 seconds
10. Write 2GB to EFS w/ 8MB block size - ‘sync’ after each block is written48 seconds

Maximize throughput using parallel, multi-threaded access

Run the remaining commands against c4.xlarge

11. Write 2GB to EBS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

12. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 oflag=sync'
Record run time.

13. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 3 | parallel --will-cite -j 4 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=512 conv=fsync'
Record run time.

14. Write 2GB to EBS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/ebs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

15. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 oflag=sync'
Record run time.

16. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ once at the end

time seq 0 7 | parallel --will-cite -j 8 'dd if=/dev/zero of=/efs/dd/2G-dd-$(date +%Y%m%d%H%M%S.%3N)-{}.img bs=1M count=256 conv=fsync'
Record run time.

Sample run times

Step & CommandDurationThroughput
11. Write 2GB to EBS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written22 seconds~90 MB/s
12. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ after each block is written26 seconds~77 MB/s
13. Write 2GB to EFS (4 threads of 512MB each) w/ 1MB block size - ‘sync’ once at the end12 seconds~167 MB/s
14. Write 2GB to EBS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written22 seconds~90 MB/s
15. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ after each block is written14 seconds~143 MB/s
16. Write 2GB to EFS (8 threads of 256MB each) w/ 1MB block size - ‘sync’ once at the end12 seconds~167 MB/s

Maximize throughput - EFS parallel file transfer test

Run the remaining commands against c4.xlarge

Identify size of data set to be transferred.

du -csh /ebs/data-1m/
find /ebs/data-1m/. -type f | wc -l

Set variable

instanceid=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)

17. Transfer files from EBS to EFS using rsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time rsync -r /ebs/data-1m/ /efs/rsync/${instanceid} &
nload -u M
Record throughput.

18. Transfer files from EBS to EFS using cp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time cp -r /ebs/data-1m/* /efs/cp/${instanceid} &
nload -u M
Record throughput.

Set variable

Set the threads variable to 4 threads per vcpu.
threads=$(($(nproc --all) * 4))

19. Transfer files from EBS to EFS using fpsync

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /usr/local/bin/fpsync -n ${threads} -v /ebs/data-1m/ /efs/fpsync/${instanceid} &
nload -u M
Record throughput.

20. Transfer files from EBS to EFS using mcp

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time mcp -r --threads=${threads} /ebs/data-1m/* /efs/mcp/${instanceid} &
nload -u M
Record throughput.

21. Transfer files from EBS to EFS using efscp script (cp + GNU Parallel)

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /home/ec2-user/efscp.sh /ebs/data-1m/ /efs/efscp ${threads} &
nload -u M
Record throughput.

22. Transfer files from EBS to EFS using fpart + cpio + GNU Parallel

Drop caches.
sudo su
sync && echo 3 > /proc/sys/vm/drop_caches
exit
time /usr/local/bin/fpart -Z -n 1 -o /home/ec2-user/fpart-files-to-transfer /ebs/data-1m
time parallel --will-cite -j ${threads} --pipepart --round-robin --block 1M -a /home/ec2-user/fpart-files-to-transfer.0 'sudo cpio -pdm {} /efs/parallelcpio/${instanceid}/' &
nload -u M
Record throughput.

Sample run times

Step & CommandDurationThroughput
17. Transfer 5000 ~1MB files from EBS to EFS using rsync10 minutes 3 seconds~8.3 MB/s
18. Transfer 5000 ~1MB files from EBS to EFS using cp7 minutes 55 seconds~10.5 MB/s
19. Transfer 5000 ~1MB files from EBS to EFS using fpsync4 minutes 38 seconds~18.6 MB/s
20. Transfer 5000 ~1MB files from EBS to EFS using mcp1 minute 40 seconds~50.0 MB/s
21. Transfer 5000 ~1MB files from EBS to EFS using cp + GNU Parallel1 minute 27 seconds~57.5 MB/s
22. Transfer 5000 ~1MB files from EBS to EFS using fpart + cpio + GNU Parallel1 minute 4 seconds~78.0 MB/s

Re-run steps 17-22, changing the source path from /ebs/data-1m to /ebs/data-10m to compare the throughput differences between small and large I/O size.

Cleanup

Delete all files on the EFS file system that were created using these scripts and delete the CloudFormation stack, so you don’t continue to incur additional charges for these resources.

Conclusion

The distributed nature of Amazon EFS enables high levels of availability, durability, and scalability. This distributed architecture results in a small latency overhead for each file operation. Due to this per-operation latency, overall throughput generally increases as the average I/O size increases, because the overhead is amortized over a larger amount of data. Amazon EFS supports highly parallelized workloads (for example, using concurrent operations from multiple threads and multiple Amazon EC2 instances), which enables high levels of aggregate throughput and operations per second.

For feedback, suggestions, or corrections, please email me at darrylo@amazon.com.

마이크로서비스로만 가면 만능일것 같은 시대에 한번 쯤 읽고 고민해 볼만한 글이다.


"마이크로서비스는 답이 아니었다"··· 세그먼트가 모놀리틱으로 돌아온 이유

Tamlin Magee | Computerworld UK


원문보기: http://www.ciokorea.com/news/39258

다른 많은 기업과 마찬가지로, 데이터 스타트업 세그먼트(Segment) 역시 오래된 인프라스트럭처로 인한 문제 때문에 마이크로서비스(microservice)로 눈을 돌렸다. 하지만 곧 단일 구조(monolithic) 아키텍처로 돌아오지 않으면 해결할 수 없는 복잡한 문제가 있다는 것을 깨달았다.

세그먼트의 주 고객은 타임(Time), IBM, 리바이스(Levi’s) 등이다. 이들 기업의 모든 고객 데이터를 세일즈, 애널리틱스, 헬프데스크 등에 피딩하기 전에 한 지점에 모아 볼 수 있는 서비스를 제공한다.

세그먼트의 CTO이자 공동창립자인 캘빈 프렌치-오웬은 “처음에는 단일 API와 라이브러리를 제공하고 그들이 데이터를 보내오는 식의 개발자 우선 방식을 택했다. 우리가 데이터를 모아 구성한 후 이를 적절한 스키마로 정렬하고, 고객사가 사용하는 200여 가지 이상의 툴에 이 데이터를 보냈다. 여기서 툴이란 세일즈포스 같은 세일즈 툴 일수도 있고, 젠데스크(Zendesk) 같은 고객 관련 툴, 혹은 레드시프트(Redshift)나 빅쿼리(BigQuery)같은 데이터 웨어하우스 일수도 있다”라고 말했다.

세그먼트사는 전적으로 AWS에 의존하고 있으며, ECS(Elastic Container Service)가 관리하는 1만 6000개 컨테이너가 250여 가지 마이크로서비스를 제공한다.

세그먼트는 원래 단일 구조 아키텍처를 사용했다. API가 데이터를 처리해 싱글 큐(queue)에 포워딩하면 직원이 데이터를 읽고 이벤트를 모든 서버측 ‘목적지’, 그러니까 파트너 API에 선형 체인을 통해 전송했다. 그러나 이런 방식은 이내 문제를 발생시켰다. 툴에서 서버 에러를 반송할 때의 재시도가 큐와 만나 다른 이벤트와 뒤섞이는 것이다. 이로 인해 파이프가 막히고 성능 장애로 이어졌다.

세그먼트의 소프트웨어 엔지니어 알렉스 누난은 “단일 구조에서 탈피해 마이크로서비스로 전환한 것도 이 때문이었다. 우리에게는 데이터를 수집하는 API와 라우터가 있고, 라우터는 이벤트를 목적지별 큐와 서비스로 라우팅했다. 이벤트가 발생하면 라우터가 ‘좋아, 이 이벤트는 구글 애널리틱스와 맥스 패널로 보내야겠어’라고 판단을 내리고 해당 이벤트의 카피를 2개 생성해 각각의 큐로 이를 보내는 식이었다”라고 말했다.


바람 잘 날 없었던 “마이크로서비스”의 세계

마이크로서비스 방식은 한동안 잘 돌아 가는 것처럼 보였다. 그러나 역시 문제가 발생했다. 누난의 표현을 빌리면 '마이크로서비스 세계의 더 깊숙한 곳에서 개별 파트너의 API 목적지와 서비스에 대한 새로운 타입의 큐가 형성됨'에 따라 발생했다. 결국 개발자는 모든 업데이트를 수동으로 처리해야 했고 어떤 업데이트 버전이 어디의 어느 리포(repo)에 있는지를 일일이 기억하는 것이 한계에 다다랐다.

누난은 “시간이 갈수록 개발자의 생산성이 급격히 저하됐다. 모든 것이 각기 다른 별개의 큐와 별개의 서비스, 그리고 자체적인 리포에 있었기 때문이다. 우리는 통합을 유지, 생성하기 위해 공유 라이브러리를 만들었지만 이것을 전개할 좋은 방법도, 또 제대로 테스팅할 여건도 안됐다. 공유 라이브러리를 업데이트하기에는 시간도 자원도 부족했다. 결국 구글 애널리틱스 버전만 업데이트하는 식이 됐다. 모든 라이브러리가 서로 다른 업데이트 버전을 갖게 됐다"라고 말했다.

세그먼트 팀은 파트너 API가 각각 어느 라이브러리 버전에서 구동되는지 추적하고, 그 버전 간의 차이도 기억해야 했다. 누난은 “라이브러리 관리 업무 만으로도 개발자에게 너무 큰 부담이 됐다. 꾹 참고 서비스마다 하나하나 변경할 수도 있지만 그러려면 수 일이 걸렸고, 특히 서비스 하나 하나를 테스트하고 전개하는데 여러 명의 개발자가 필요하게 됐다. 이것이 너무 큰 부담으로 작용한 끝에 결국 꼭 필요한 변경사항조차도 적용하지 않게 되는 일까지 발생했다. 모든 서비스에 아주 작은 변경사항만 적용하기 위해서도 팀 전체가 달려 들어 일주일 이상 소모해야만 했다”라고 말했다.

세그먼트의 직원은 이러한 큐를 처리하기 위해 수면 부족에 시달리는 것도 모자라, 성능 이슈에도 직면했다. 예를 들어 구글 애널리틱스와 같은 대규모 목적지의 경우 초당 수천 건에 달하는 이벤트를 처리하는 반면 하루에 수 건 이내의 이벤트만을 처리하는 곳도 있었다. 세그먼트 팀은 오토-스케일링 룰을 적용해 이러한 서비스의 수동 커스터마이징을 최소화 했지만 서비스마다 고유의 CPU 및 메모리 로드 패턴이 있었기 때문에 모든 통합에 같은 룰을 적용할 수는 없었다.

누난은 “하루에도 수십 번씩 쉴 새 없이 호출이 왔고, 직원이 일일이 개입해 이러한 서비스를 처리해야 했다. 이런 식으로 2년 넘게 마이크로서비스 방식을 이용한 결과 큐와 리포에 140여 가지 서비스를 갖게 됐지만 시스템 장애를 막는 데에만 모든 에너지를 쏟아도 역부족이었기에 그보다 더 건설적이거나 선제적인 어떤 노력도 할 수 없는 상황이었다. 이쯤 되자 한걸음 물러나 생각해 보지 않을 수 없었다. ‘대체 이 상황을 해결하려면 어떻게 해야 하지?’ 결국 인력을 추가해야 한다는 결론이 나왔지만, 그런 식으로 문제를 해결하고 싶지는 않았다”라고 말했다.

그러나 결국 세그먼트는 마이크로서비스 아키텍처가 지속 불가능하다는 결론에 다다랐다. 목적지를 추가할수록 성능 저하가 눈에 띄게 증가했고 이것은 ‘상당히 뚜렷한 경고 신호’였다. 누난은 “한창 마이크로서비스로 인한 광기가 극에 달했을 때 내가 세그먼트에 합류했다. 당시 이미 어떻게 하면 이 문제를 해결할 것인가에 대한 논의가 이루어지고 있었다”라고 말했다.



단일 구조로 돌아가다

세그먼트 팀은 마이크로서비스를 어떻게 다시 하나의 거대한 시스템으로 재설계할 것인지 방법을 찾아야 했다. 이른바 ‘신(新) 단일구조’로의 이행이었다. 결국 당시 세그먼트가 진행 중이던 ‘센트리퓨즈(Centrifuge)’ 인프라스트럭처 프로젝트를 통해 새로운 단일 구조로 이행하기로 결정됐다. 센트리퓨즈는 세그먼트 비즈니스의 핵심이라 할 수 있는 단일 이벤트 딜리버리 시스템이다.

프렌치-오웬은 “센트리퓨즈는 큐를 생성하고 실패가 발생했을 때 트래픽을 흡수하기 위한 시스템이다. 이 시스템 덕분에 우리는 여러 코드를 한 장소에 통합하고, 이를 통해 두 마리 토끼를 잡는 전략을 취하기로 했다"라고 말했다.

이를 위해 먼저 모든 목적지 코드를 하나의 리포로 통합했다. 하나의 리포에 모든 종속 항목과 테스트를 합병하는 것이었다. 서비스가 하나뿐이므로 논리적으로 당연했다. 그러나 이 과정이 대단히 복잡하고 머리 아픈 과정이었다. 누난은 "120개가 넘는 고유의 종속 항목들 각각에 대해 우리는 모든 목적지에 대한 하나의 버전을 만드는 데 집중했다. 또한 목적지를 이동하면서 사용 중인 종속 항목을 확인하고 이들을 최신 버전으로 업데이트했다. 또 목적지의 새로운 버전에서 생긴 부분을 바로 바로 수정했다"라고 말했다.

이렇게 일관성을 확보한 결과 코드베이스를 어지럽히던 혼란이 상당 부분 해소되었다. 세그먼트 팀은 또한 빠르고 쉽게 모든 목적지 테스트를 한 번에 진행할 수 있는 테스트 스위트는 개발했다. 지나치게 길고 복잡한 테스트 과정 역시 업데이트를 방해하던 주요 요소 중 하나였기 때문이다.

이처럼 목적지 코드를 단일 리포로 이동시켜 단일 서비스로 통합하자 곧바로 개발자 생산성 증대라는 성과로 이어졌다. 서비스 전개 시간도 수 분 이내로 단축됐다. 누난은 “인프라스트럭처의 가장 큰 부분을 재설계해야 했기 때문에 단일 구조로의 전환에는 상당한 시간이 걸렸다. 당연한 일이었다. 하지만 적어도 예전처럼 계속해서 고객 지원 요청이 들어오거나 하는 일은 없다. 모두가 수면 부족에 시달리지 않을 수 있게 됐다. 모든 것을 하나의 리포로 통합하고 나니 관리도 쉬워졌다”라고 말했다.

이어 "이제 공유 라이브러리에 업데이트를 생성하고 싶을 때, 엔지니어 1명이 한 시간만 투자해 테스트하고 전개할 수 있다. 우리에게는 정말 획기적인 변화였다. 처음 마이크로서비스를 채택했을 때 당시 그런 선택을 할 만한 사정이 있었다고 생각한다. 당시 팀이 처한 상황이나 겪고 있던 성능 이슈를 고려하면 최고의 선택이었다. 그러나 시간이 지날수록 마이크로서비스의 장점은 사라지고 생산성과 성능만 잡아먹게 됐다. 그래서 다시 단일 구조로 돌아온 것이다"라고 말했다.

세그먼트 사가 다른 기업에 비해 처리하는 데이터 양에서 압도적으로 많긴 하지만 비슷한 불편을 겪는 다른 기업 역시 단일 구조로 돌아오는 것이 하나의 대안이 될 수 있다. 누난도 "그런 선택을 한다고 해도 전혀 놀라운 일이 아니다"라고 말했다.

단일 구조로 돌아온 후 나아진 건 세그먼트 사 직원의 워크-라이프 밸런스 뿐 만이 아니다. 고객 역시 훨씬 일관되고 안정적인 서비스를 누릴 수 있게 됐다. 프렌치-오웬은 “모든 서비스가 한 장소에, 단일 리포에 통합됨에 따라 추가된 변경 사항이 다음 번에도 모든 서비스에 똑같이 전개될 것이라는 확신을 가질 수 있게 됐다. 덕분에 고객 역시 서비스 별로 각기 다른 버전으로 인해 발생하는 혼란이나 비일관성을 더 이상 겪지 않아도 됐다"라고 말했다. 

ciokr@idg.co.kr 


Transient로 Windows Server 2016 를 띄운후 Language 설치 메뉴에서 한국어를 추가해도

추가되었다고만 뜨고 실제 한국어 랭귀지 팩이 설치가 안된다.

일반 셋업때는 잘된다. 2012는 일반 셋업 때도 안되었던걸로 기억한다.


이른 윈도업데이트서버가 Softlayer 내부것으로 지정이되어있고 (WSUS) 인터넷업데이트는 막아 놓았다.

거기에서 막혀 있거나 해당 랭귀지팩을 제공해주지 않기 때문이다? (이런 !@(*&&(*$@(*&)(*)

어째든 WSUS 를 잠깐 끄고 한국어 설치옵션에 가면 이전과 다른 다운로드 옵션이 보인다.

덤? 으로 윈도 업데이트도 몇개 더 된다.

하지만, 아무래도 윈도 업데이트 정책은 벤더것을 따라가는게 편하기 때문에 다시 WSUS를 켜주자.


WSUS를 끄는법 regedit 실행 (실행->regedit) 후 아래 경로에서 DoNotConnectToWindowsUpdateInternetLocations를 1에서 0으로 바꾼다.

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]

"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000000




+ Recent posts