실제 DDoS 스토리들: SSL 커넥션 플러드

Adapted from David Holmes' "True DDoS Stories: SSL Connection Flood"

서버에서의 SSL 터미네이션

어떤 유명기업의 중요 사이트가 매우 심각한 DDoS 공격을 받아 수 주 동안 다운되는 사태가 발생했는데, 아래 그림은 그 기업의 네트워크 레이아웃을 나타낸 것이다.

경쟁업체들과는 다르게 이 기업은 SSL 트래픽이 그대로 데이터센터 내부에까지 도달해, 애플리케이션 서버에서 터미네이트 되는 구조를 가지고 있었다. 우리는 SSL 트래픽이 ADC에서 터미네이트 되도록 해야지 안전하고 바람직하다는 점을 누차 계속해서 주장해왔지만 여기서는 그 점에 대해서는 다시 설명하지 않겠다. 이 사이트의 경우, 클라이언트(고객)에 의해 발생된 SSL 연결은 사라지기 전에 (timeout 과정에 들어가기 전에) 일정 시간 동안 액티브(active) 상태로 남아 있어야 한다는 것이 서비스 제공업체와의 서비스계약에 명시되어 있었다.

공격

공격자의 신원은 아직도 밝혀지지 않았지만, 공격을 당한 이 기업은 어나니머스 (Anonymous)를 범인으로 의심하고 있다. 공격자가 누구든 간에 이들은 수 천 개의 합법적인 SSL 연결을 열면서 공격을 시작했다. 이 연결들은 DDoS 방지 시스템을 통과해 로드밸런서에 도달했고, 그리고 방화벽과 IPS를 통과해 애플리케이션 서버들에 도달한 후, 세션을 설정하고 그제서야 (길게 설정된) 타임아웃 과정이 시작되었다. 이 SSL 세션들은 그 안에 Payload (실제 화물, 여기서는 연결 세션 안에 포함된 정보 비트들을 의미함)를 포함하지 않고 있었으며, 클라이언트 사이드에서 종료되지 않았다. 이것은 커넥션 플러드 공격의 전형인데, 단지 합법적으로 구축된 SSL 세션 내에서 발생했다는 점이 다를 뿐이다.

애플리케이션 서버군은 부하를 충분히 감당할 수 있도록 구축되어 있었기에, 속이 빈 SSL 세션의 수는 수백만 개까지 늘어났다. SSL이 뒷 단의 애플리케이션 서버에서 터미네이트 되는 구조이기 때문에, 앞 단의 디바이스들 중에서 동시에 처리할 수 있는 접속의 개수가 가장 적은 디바이스가 먼저 다운될 것이고, 이 경우에는 로드밸런서가 그런 디바이스였다. (참고로 F5의 경쟁업체 중 하나가 제공한 제품인데, 여기서 그 경쟁업체의 이름은 밝히지 않겠다.) 다른 많은 디바이스들처럼 이 로드밸런서는 자신이 처리할 수 있는 동시 연결의 최대치에 도달하자 완전히 작동을 멈추고 트래픽 처리를 중지했다.

보통의 경우 로드밸런서는 공격하는 트래픽 부하를 액티브 서버들에 나누어 분산을 하기 때문에 DDoS 공격을 완화시키는 기능을 하지만, 그것은 규모가 작은 공격일 경우의 얘기이고 이 경우에는 로드밸런서가 가장 약한 부위가 되어버린 것이다. 대개의 경우는 방화벽이 가장 먼저 문제를 일으키는 것이 보통이다.

공격은 수 주일간 계속되었고 이 DDoS 공격이 멈추기 전까지 서비스는 재개되지 못했다.

바람직하지 못한 방어전략 #1 – (한 지점만 해결하는) 포인트 솔루션들

Arbor, Prolexic, 그리고 (이제는 단종된) 예전의 Cisco Guard 제품 등 DDoS 방어 솔루션을 제공한다고 주장하는 업체들이 몇몇 있다. 위 고객이 어떤 업체의 솔루션을 사용하고 있었는지 밝히지는 않겠지만, 어쨌거나 중요한 점은 도움이 되지 못했다는 것이다. 위에서 말한 어떤 솔루션도 SSL을 터미네이트 하지 않기 때문에 SSL 커넥션 플러드 공격에는 장님이나 마찬가지이다. SSL을 애플리케이션 서버에서 터미네이트하는 아키텍처를 고집하겠다면, 한 시간당 6,000 달러를 서비스제공업체에 지불하고 클라우드-기반 스크러빙을 이용할 수 있지만 도움이 되지 않을 것이다. 설혹 클라우드-기반 서비스가 SSL을 터미네이트 하더라도 금융기관들은 이 서비스를 사용할 수 없는데, 이 방법은 암호화되지 않은 트래픽을 다른 회사의 클라우드로 전송하는 것을 의미하기 때문이다. 대부분의 금융회사들은 이런 것을 금지하는 내부정책을 가지고 있다.

바람직하지 못한 방어전략 #2 – 더 많은 수의 약한 링크들

고객들과 통합된 보안솔루션에 대해 얘기를 해보면, 종종 듣는 공통된 반론 중 하나가 “우리는 모든 달걀을 한 바구니에 담기를 원치 않기 때문에 단일 벤더를 신뢰할 수 없다”는 것이다. 이 논리야말로 이 전략이 가지고 있는 위험성을 잘 보여주는 예이다. 문제는 모든 달걀이 한 바구니에 담겨있다는 점이 아니고, “어디가 가장 약한 링크인가?”이다. 수많은 달걀 중에 하나가 부서지는 것은 그리 큰 문제가 아니나 길게 연결된 사슬에서 고리 하나가 부러지면 사슬 전체가 소용없게 되어버린다는 것이 문제이다. 아키텍처 상의 이점으로 디바이스들이 널리 퍼져 있는 형태를 원한다면, 이 사슬 상에 있는 모든 디바이스들이 공격을 견뎌낼 수 있도록 확실히 해야만 한다. 더 많은 수의 디바이스가 있다는 것은 더 많은 수의 취약한 링크가 있다는 것과 동일한 것이다.

적절한 방어전략 – 풀-프록시 (Full Proxy)

만약 위 회사가 유휴 연결을 제거하는 Dynamic Reaping 기능을 가진 풀-프록시 아키텍처를 채용하고 있었다면 이런 공격을 충분히 방어할 수 있었다. SSL 터미네이션 기능이 있는 지능적인 풀-프록시 ADC는 (대개의 경우 HTTP 데이터인) 애플리케이션 페이로드(payload - 부하, 정보 비트)를 기다렸다가 이것이 도착한 후에야 백엔드 서버에 연결을 설정한다. 그 이유는 로드-밸런싱을 위한 쿠키나 기타 다른 HTTP 헤더들을 삽입하기 위한 것이다. ADC 연결 테이블이 가득 차면 다이내믹 리핑이 현재 사용 중이 아닌 (non-active) 연결들을 종료해서 진정한 SSL 연결들을 위한 새로운 연결자원을 만들어낸다.

풀-프록시 ADC (Application Delivery Controller)에서 SSL을 종료시키면 또 다른 이점들이 있다. 어떤 회사들은 SSL을 풀-프록시 ADC에서 종료시키고, 그 후에 그 뒤 단에서 DDoS 스크러빙 서비스를 시작하는데, 그 이유는 이런 서비스들이 이제는 암호화가 풀린 페이로드를 볼 수 있기 때문이다. 그러나 금융기관들에서는 종종 트래픽이 ADC를 떠날 때 다시 암호화를 하도록 요구되는데, 이런 곳에서는 ADC야말로 SSL 공격에 대응할 수 있는 ‘유일한’ 디바이스이다. 끝으로, ADC는 하드웨어로 보호된 FIPS 140 레벨 3 주요 서비스들의 위치를 찾아내기에 이상적인 디바이스이다. 이런 기능을 하는 디바이스들은 대체로 매우 비싸므로, 수십 대의 서버로부터 오는 이 서비스들을 한두 대의 ADC에 통합시키는 것은 매우 합리적인 선택이다.

고객들을 만나러 다니다 보면 공격을 받았을 때 방화벽이 실패했다는 얘기를 매우 자주 듣게 된다. 자신의 인프라를 보호하기 위해 방화벽을 구매, 설치하는데 막상 공격을 받았을 때는 방화벽이 바로 가장 취약한 링크가 된다는 것은 매우 아이러니컬 하다. SSL 공격을 받았을 때 SSL 인프라가 제 기능을 못하게 되는 것도 이와 마찬가지이다. SSL은 선의의 데이터를 보호하기 위한 기술이고 보호를 할 것으로 기대가 되는 기술이지만, 잘못된 방식으로 구축이 되면 해를 입도록 만드는 요소가 될 수 있다는 점을 명심해야 한다.