Akamai Diversity

Akamai 블로그

SLOW DOS 공격의 증가

이 글은 객원 저자인 시니어 엔터프라이즈 아키텍트 David Senecal과 시니어 솔루션 아키텍트 Aseem Ahmed가 작성했습니다.

슬로우 HTTP DoS 공격이라 불리는 새로운 레이어 7 공격이 증가하고 있습니다. 새로운 공격처럼 들리지 않을 수도 있지만, 보안 분야에서는 '자주 언급되지 않는 공격'이 곧 새로운 공격이 될 수 있습니다.

제 경험에 비추어 봤을 때 DoS 공격에 대해 우리가 갖고 있는 일반적인 개념은 빠르게 발생하는 증폭 공격입니다. 기존의 DoS 또는 DDoS 공격은 증폭 공격이었고 지리적으로 분산된 수많은 클라이언트가 필요했습니다. 하지만 공격자가 최소한의 리소스 및 대역폭만 사용하는 슬로우 공격 역시 웹 서버를 다운시킬 수 있습니다.

저희 연구소 환경에서 취약한 아파치(apache) 서버를 대상으로 slowhttptest를 사용한 결과입니다. 아래의 스니펫은 서버와의 새로운 접속이 매우 빠르게 이루어질 때 사용된 툴을 보여줍니다. 공격을 시작하고 5초 후에 웹서버는 다운됐습니다.

SlowPost 1.png

아래의 HTML 스크린샷은 동일한 테스트 결과를 보여줍니다. 이 툴은 초당 200개씩, 1000개의 접속을 오픈했는데 해당 서버는 동시에 351개의 접속만 처리할 수 있었고 649개의 접속은 보류(pending) 상태로 남아 있습니다.

SlowPost 2.png


이런 공격이 문제가 되는 이유

  • 이런 접속은 정상 사용자가 요청한 것처럼 보입니다.
  • 기존의 전송률 탐지 기법을 우회합니다.
  • 시그니처에 기반한 기존의 IPS/IDS 솔루션은 보통 이런 접속을 인지하지 못합니다.
  • 공격을 실행하기 위해 필요한 리소스와 대역폭이 매우 작습니다.
  • 하드웨어 능력에 상관 없이 웹 서버를 다운시킬 수 있습니다.


공격이 작동하는 방식

슬로우 HTTP DoS 공격은 웹 서버가 클라이언트의 요청을 성실하게 처리한다는 점을 이용합니다. 공격자는 정상처럼 보이는 요청을 보내서 웹 리소스가 이런 요청을 최대한 오랫동안 분주하게 처리하도록 만듭니다. 공격자가 지속적으로 이런 요청을 보내면 서버의 리소스는 빠른 속도로 고갈될 수 있습니다.

슬로우 HTTP DoS 공격은 여러 가지 종류가 있습니다. 자세한 설명에 앞서 먼저 일반적인 HTTP 구조와 흐름에 대해 살펴보겠습니다.

 

요청

Headers

POST /account/login HTTP/1.1 CRLF

Accept: */* CRLF

Content-type:  application/x-www-form-urlencoded CRLF

Content-Lenngth: 60 CRLF

Connection: keep-alive CRLF

Host: www.customer.com CRLF

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 CRLF

Body

email=customer%40account.com&password=mypasswrd


응답 

Headers

HTTP/1.1 200 OK CRLF

Server: Apache/2.2.22 (Ubuntu) CRLF

Content-Type: Text/html CRLF

Content-Length: 200 CRLF

Date: Fri, 12 Jul 2013 05:31:32 GMT CRLF

Connection: Keep-Alive CRLF

Body

<html>

   <head>

   .....

  </head>

</html>



요청 플로우의 각 단계에서 다양한 종류의 슬로우 공격이 발생할 수 있습니다.

  • Slow HTTP Headers (Slowloris): 공격자가 HTTP 헤더의 일부분만 매우 낮은 속도(서버의 접속 대기상태 타임아웃 값보다 낮음)로 전송하는데 결코 요청을 완료하지는 않습니다. 소켓을 열어놓기 위해 정기적으로 헤더를 전송하고 서버 리소스를 계속 사용합니다. 아래의 이미지는 이런 공격이 어떻게 이루어지는지 보여줍니다.
    SlowPost 3.png



  • Slow HTTP Post (RUDY): 이름이 말해주는 것처럼 천천히 데이터를 POST해서 항목을 채우는 공격입니다. 요청은 모든 헤더를 포함하고 있고 콘텐츠 길이 헤더 역시 정상(일반적으로 높은 값)이기 때문에 서버는 데이터 양을 예상할 수 있습니다. 공격자는 매우 낮은 속도로 Form에 데이터를 주입하고 서버는 데이터가 더 많이 올 것이라고 예상하기 때문에 계속 리소스를 사용할 수밖에 없습니다. 결국 서버의 리소스가 고갈되게 됩니다. 아래 이미지는 이 공격의 진행 과정을 보여줍니다.  
    SlowPost 4.png



  • Slow Read Attack: 클라이언트가 완전한 요청을 보내면 서버가 응답할 때 응답 데이터를 받기 위해 아주 작은 TCP 윈도우를 전파합니다. 서버는 소켓을 오픈한 상태로 클라이언트에게 천천히 데이터를 전송합니다. 서버는 응답 윈도우 사이즈를 확인하기 위해 클라이언트를 검사하고 클라이언트는 트랜스퍼 속도를 늦추기 위해 항상 작은 윈도우 사이즈를 전파합니다. 파일 사이즈가 클수록 연결을 완료하는데 더 오랜 시간이 걸립니다. 대용량 파일을 여러 번 요청하면 DoS 공격이 서버를 빠르게 다운시킬 수도 있습니다.
    SlowPost 5.png


Akamai
Professional Service팀이 이런 공격을 방어하는 방법

  • SlowLoris: Akamai 플랫폼은 본질적으로 이 공격을 방어하도록 설계되었습니다. Akamai 엣지 서버는 요청을 오리진 웹 서버로 포워드하기 전에 클라이언트가 전체 헤더를 보낼 때까지 기다립니다. 따라서 공격은 엣지 서버에서 차단되고 오리진 웹 서버에는 아무런 영향을 끼치지 않습니다.
  • Slow POST (Rudy) 공격: Kona Site Defender에 포함된 Slow POST 보안 기능은 클라이언트로부터 데이터를 수신하는 속도를 확인해 공격을 탐지합니다. 엣지 서버가 클라이언트 속도가 너무 느리거나 공격을 시도할 것 같다고 결정하기 전까지 기다리는 최소 비트레이트와 인터벌 횟수(인터벌당 5초)를 정의할 수 있습니다. 예를 들어, 클라이언트가 POST body를 6번 이상(30초 이상) 10bps보다 낮은 속도로 전송한다면 알림을 트리거하고 해당 클라이언트와의 연결이 중단됩니다. 엣지 서버가 해당 클라이언트와의 연결을 중단할 때 오리진으로 향하는 데이터 스크림 역시 차단됩니다.  
  • Slow Read 공격: Akamai 플랫폼은 클라이언트와 오리진 웹 서버 사이에서 프록시 역할을 하기 때문에 Akamai 플랫폼과 오리진 웹 서버 사이의 TCP 연결은 동일한 slow 특성을 갖고 있지 않습니다. Akamai 엣지 서버와 오리진 웹 서버 사이의 TCP 연결은 Akamai 엣지 서버와 클라이언트 사이의 연결과 분리되어 있습니다. Akamai는 Slow Read 공격에 대한 가시성을 강화하기 위해 Slow POST 보안 기능과 유사한 기능을 개발하고 있습니다. 클라이언트의 read 바이트를 모니터링해서 슬로우 클라이언트와의 연결을 탐지 및 종료시킬 수 있는 기능입니다.  


Slow Dos 공격에 대한 준비가 필요하다면, korea-marketing@akamai.com 으로 문의해 보세요.