https://www.ahnlab.com/kr/site/securityinfo/secunews/secuNewsView.do?seq=17002
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 |