I. 서론

네트워크 대역폭 소모위주의 DDoS(Distributed Denial of Service) 공격은 수십 년간 끊임없이 발생해왔으나. 최근에는 세션 고갈 형 공격, GET Flooding 등을 통한 시스템의 자원을 고갈시키는 공격이 많이 발생하고 있다. 세션 고갈 형 공격으로는 부하 분산 및 서버 보호 목적의 L4 스위치, 방화벽 등 해당 장비의 세션 관리 능력의 유한성을 악용하여 SYN Flooding, Slowloris 등이 있으며, Get Flooding 등 서버 자원 고갈 형 공격으로 서버 자원의 트랜잭션 처리 한계를 악용하여 정상적 접속 후 대량의 요청을 발생 시켜 네트워크 모니터링으로 파악이 불가능한 공격으로 7.7 대란의 Cache Control attack0] 해당된다.

특히, 최근 발생하는 GET Flooding 공격은 각각의 좀비PC가 최소한의 HTTP 트래픽을 발생시키면서, 대량의 좀비 PC를 동원하여 시스템을 마비시키는 형태의 공격이 주를 이루고 있다. CC Attack 같은 경우도 일반적인 웹 접속 시에는 1회 요청하는 페이지를 한대의 좀비 pc에서 초당 6〜10여회를 요청하는 패턴을 보였으며 지속적으로 웹 서버에 부하를 발생시킨다. 그러나, 주요 DDoS 대응장비에서는 HTTP PPS (Packet Per Second : 초당 발생한 패킷 수) , CPS(Character Per Second : 초당 발생량 량트래픽 량)에 대한 Threshold 기반 대응방법을 적용하고 있는데, 이는 좀비 PC당 소규모 트래픽을 발생시키는 최근 DDoS 공격 동향을 비추어 볼 때, 효과적으로 동작하지 못한다. 본 논문에서는 발생 가능한 Get Flooding의 모든 공격유형을 도시하고, 간단하면서도 강력한 대응 메커니즘을 제안한다. 2장에서는 상용환경에서 사용하고 있는 Volume 기반 대응 메커니즘의 한계점을 웹서비스 특징에 비추어 분석 및 개선방안을 제시하고, 3장에서는 웹 서비스에 대한 다양한 통계를 기반으로 3개의 DDoS 공격 대응 메커니즘을 제안한다. 4장에서는 DDoS 공격대응시스템 구축을 통해 제안한 메커니즘을 성능분석 결과를 제시하고, 5 장에서는 성능분석 결과를 토대로 본 대응 메커니즘이 가지는 의미를 분석하고 결론을 제시한다.

Ⅱ. 관련 연구

응용계층 DDoS 공격에 대한 여러 가지 연구가 진행되고 있다〔1, 2, 3〕. 웹 서비스 특성상 이용자 IP 리스트는 flat하게 분포하지 않고 기존에 들어왔던 이들이 계속 들어오는 특징을 이용하여, 그 비율을 이용한 DDoS 공격 탐지방안〔4〕, 웹 서비스 이용패턴 정보를 분석하여 공격자로 의심스러운 Source IP 들을 대상으로 Greylist로 분류하고, 이들에 대해 적은 리소스를 할당하는 방법에 대한 연구〔5〕, 각 URL page hit distribution 등을 통계적 방식에 기반하여 학습한 후, 일시적인 request 폭주와 DDoS 공격을 구별하는 방법〔6〕, 웹 서비스 사용자 page 이동경로에 따른 분석〔7〕, 허용된 사용자에 한해 웹 서비스 접속을 허용하는 Admission Control을 통해 대응하는 방법 등이 제안되어 있다〔8〕. 위 연구 동향 중 URL page hit distribution은 많은 연산량을 필요로 하며 웹서비스에 올라가는 컨텐츠 및 시기에 따라 크게 변하여 Threshold 설정이 어려운 단점이 있고, Admission Control 기법은 out of path 방식으로는 동작할 수 없고, 인라인으로 동작해야 하는데 세션 관리가 필요한 단점이 있다. 본 논문에서는 상용 환경에 바로 적용할 수 있는 대응기술을 제안하고자 하므로, 상용 DDoS 공격 대응 장비에서 사용하고 있는 HTTP PPS 트래픽에 대한 Threshold 기반 대응 방법의 문제점을 기반으로 간단하면서도 강력한 대응 메커니즘을 제시하고자 한다. HTTP PPS 트래픽에 대한 Threshold는 초 단위로 트래픽을 수집하고, HTTP 전체에 대한 Threshold를 설정하는데 다음의 문제점이 있다.

2.1 1초 단위의 Volume 기반 탐지

웹서비스에서 사용되는 HTTP 트래픽은 일정한 특징을 가지고 있다. 정상 사용자의 경우, 대부분의 시간은 트래픽이 발생하지 않는 상태로 있다가 웹 브라우저를 실행하거나 메뉴, 링크 클릭을 통한 웹서핑 , refresh 등을 통해 어떤 행위를 하게 되면, HTTP Request가 발생하는데 한 번의 행위는 수십에서 수백 개의 HTTP Request를 한순간에 발생시킨다. 즉, 정상 사용자의 웹서핑에서도 평소에는 트래픽 발생량이 매우 저조하지만, 특정 순간에는 대량의 HTTP Request가 발생하게 된다. 따라서 1초 단위의 Volume 기반 탐지 방법은 해당 클라이언트의 비정상행위 여부를 탐지하는데 한계를 가지게 된다.〔그림 1〕은 정상 사용자의 1초 단위의 HTTP PPS와 10초 단위의 HTTP PPS를 나타낸다. 정상 사용자의 웹서핑 시, 1초 단위로 트래픽을 보면 사용자의 행위가 발생한 시점에서 대량으로 발생하여 보통 초당 Thre­ shold 로 설정하는 50을 넘어서지만, 그 외의 시점에서는 트래픽 발생량이 미미하디、즉, 정상 사용자조차 트래픽 발생량의 변화가 극심하므로, 1초 단위의 Volume 기반 탐지기법은 한계가 존재한다. 그러나, 10초 단위로 트래픽을 보면 사용자가 행위를 어느 정도 했는지 판단할 수 있다. 10초 단위 분석기법의 효과에 대해서는 3장에서 상세히 기술한다.

(그림 1) 정상 사용자의 1초, 10초 단위의 HTTP 트래픽분포

2.2 HTTP 트래픽 전체에 대한 Threshold

앞서 기술한 대로, 웹 서비스 특성상 정상 사용자의 단 한번의 행위가 적게는 수십, 많게는 수백개의 HTTP Request를 발생시키게 된다. 따라서, 정상 사용자를 공격자로 오 탐지하지 않도록 하기 위해, Threshold는 보통 매우 큰 값으로 사용하게 되어 다수의 미탐지가 발생한다. 특히, 다수 좀비 PC를 사용하고 각 좀비 PC 당 소규모의 트래픽을 발생시키는 최근 DDoS 공격추세에 비추어보면 더욱 二렇다. 여기서 HTTP Request■들을 분석하면 사용자가 웹브라우저 상에서 어떤 행위를 했을 때 발생되는 HTTP Request 와 이에 수반하여 발생하는 HTTP Request로 구분됨을 알 수 있다. 예를 들어, 특정 페이지 요청 시 200 OK로 해당 페이지에 대한 정보를 받고, 웹브라우저에 해당 페이지를 도시하기 위한 여러 iframe, jpg, gif 등 다양한 HTTP Request가 발생하게 된다〔9, 1이. 여기서, 처음 발생한 HTTP Request는 사용자의 행위에 의해 발생했지만, 그 뒤에 수반되는 Request는 해당 페이지 도시를 위한 수반되는 Request들이다. 만일. 수많은 HTTP Re­ quest 중에서, 사용자 행위에 의한 발생한 HTTP Request를 식별하고, 그들에 대해 Threshold를 설정할 수 있다면 DDoS 공격에 효과적인 대응이 가능하다. 왜냐하면 실제 사용자의 행위는 예를 들어 10초에 30번 이상 발생하는 것은 웹브리우저 상에서 사실상 불가능하기 때문에, 10초당 사용자 행위에 대한 Threshold를 30으로 설정하면 효과적으로 대응할 수 있다.

지금까지 주요 DDoS 전용 장비에 적용되어 있는 HTTP에 대한 Threshold 기반 대응 메커니즘의 한계점과 개선하기 위한 접근방안을 제시하였다. 1초 단위 트래픽 분석 이외에 10초 단위의 트래픽 분석이 필요하며, HTTP 전체에 대한 Threshold 기반 대응 외에 사용자의 실제 행위에 대한 Threshold를 통해 정교한 대응이 가능하다. 이러한 접근방안을 토대로, 3장에서는 본 논문에서 제안하는 3가지 대응 메커니즘을 제안한다.

Ⅲ. DDoS 공격 대응 메커니즘

〔그림 2〕는 본 논문에서 제안하는 동작 메커니즘을나타낸디.. Source IP들로부터의 HTTP Request 발생 시, 2개의 Behavior 기반 DDoS 공격대응 메커니즘을 통해 정상 Source IP와 의심스러운 Source IP로 분류하고, 의심스러운 행위를 하는 Source IP에 대해 Challenge 기반 DDoS 공격 대응 메커니즘을 적용하여 악성 행위를 하는 Source IP 를 blacklist 처리한다.

(그림 2] DDoS 공격 대응 메커니즘

3.1 Direct Request에 대한 URL 별 Threshold 기반 대응 메커니즘

3.1.1 Direct Request, URL 별 Request 수와의 상관관계

사용자 행위에 기반한 HTTP Request 구분을 위해 다음과 같이 용어를 정의한다.

- Direct Request : 웹브라우저 실행, 특정 메뉴 클릭 . refresh 등 사용지가 직접 어떤 행위를 했을 때, 발생하는 HTTP Request

- Indirect Request : Direct Request에 의해 발생하게 되는 image, iframe 등에 대한 HTTP Request

HTTP 트래픽 분석 결과, 사용자가 한 번의 행위 (메뉴 클릭 , 웹브라우저 실행 등)를 했을 때. 발생하는 수많은 HTTP Request 중에서 동일한 URL (Uni- form Resource Locator) 을 요청하는 경우는 거의 없다(하나의 웹 페이지에 배너 등에서 같은 이미지가 중복 사용될 수도 있으나 이는 관리자가 파악할 수 있는 내용이므로, 예외로 함). 예를 들어, 한번의 Direct Request가 100개의 Indirect Request 를 발생시킨다면, 100개의 Indirect Request는 각각 다른 URL을 요청한다' 즉, 1개의 Direct Request에 대해 발생하는 Indirect Request가 n 개라면(魇/es知 : R巳que就长는 糸번째 URL을 요청한 Request 횟수, k= 1...H), max {Inquest v Beqiiest^ ....Bequestn)< l^H m개의 Direct Request/} 발섕할 경우, max(/翊眼s知屉q“es&.…贤/冬 m이 된다. 따라서, 각 URL 별 Request 수는 Direct Request, 수 이상으로 존재할 수 없다.〔그림 3〕 은특정 포털사이트를 대상으로 1。초간 발생한 Direct Request의 수가 3과 10일 때, 각 URL별 Request 수를 큰 순서대로 정렬한 분포를 나타낸다. X축은 hit이 발생한 URL들을 나타내는데, 편의상 숫자로 표시하였다.

(그림 3) Direct Request 횟수 3, 에서의 URL별 HTTP Reqyest 분포

(그림 4) Direct Request와 URL 별 최대 Request 수와의 상관관계

관측 결과, 각 URL 별 Request 수는 Direct Request 수인 3과 10을 초과하여 존재하지 않는다’ 이를 검증하기 위해 국내 주요 포털사이트 5개를 대상으로 10초간 각 사이트별로 웹브라우저 실행 , 메뉴 클릭, refresh 등 Direct Request 수를 1부터 10 까지 증가시킬 때, URL 별 Request 수 중 최대 값을 도식화하였다. 각각의 점은 100번의 실험 데이터 평균값이다.〔그림 4〕는 10초간의 Direct Request 수와 최대 URL Request 수와의 상관관계를 나타낸다.

관측 결과, 사용자의 실제 행위 횟수를 나타내는 Direct Request 수와 각 URL 별 Request 수는 유사한 값을 나타낸다. 그러므로, 사용자의 실제 행위 횟수에 대한 Threshold가 5라면, 각 URL별 Request 수에 대한 Threshold를 S로 설정하여 이상 트래픽을 탐지 및 대응할 수 있다.〔그림 4〕에서 Direct Request 수를 벗어난 일부 사례들 및 동일한 배너 이미지 사용 등의 경우가 존재하므로, 이상 트래픽으로 탐지한 경우 Challenge 기반 대응 메커니즘 등을 통해 DDoS 공격 발생 여부를 최종 판단한다.

3.1.2 Direct Request에 대한 Threshold

여기서는: Direct Request에 대한 Threshold# 어떻게 설정할 것인지 분석한다. 이를 위해, 주요 포털 사이트 5개에 대해 정상적인 웹 서비스를 이용할 때 10초당 Direct Request가 몇 번이나 되는지 관측하고, Direct Re이빘est 수별 분포 비율로 나타냈다, 〔그림 5〕는 10초 단위의 정상 사용자의 Direct Request에 대한 분포와 이 분포에 대한 Cheby­ shev's [眼quality를 나타낸다.

(그림 5) 정상 사용자의 Direct Request 분포 및 Chebyshev's Inequality

〔그림 5〕와 같이, 10초 동안 정상 사용자의 Direct Request 수는 2 이하가 89.4%, 4 이하가 95, 5%를 차지한다. 예상했던 대로, 대부분 Direct Request^} 4 이하에서 존재한}다] Chebyshev's Inequality에 따르면, 분포 모양에 상관없이(1一丄) krX 100(%)의 데이터는 적어도 我 t 由 age—用 와 如wage + 畝「 사이에 위치흐卜다. 본 분포에 대해 Cheby아!©v's Inequality에 따라 /가 6인 경우, 10초 동안의 Direct Request 수 중 10.505 이하에 최소 97.22%의 데이터가 존재한다. 그러므로. Direct Request에 대한 Threshold# 10으로 설정하면, 오탐지율 최대값은 2.78% 이종!. 가 된다. Thwe아ioid 를 초과하는 Sour源 IP에 대해서도 무조건 필터링 처리하는 것이 아니라 약 5초~ 10초 정도 필터링 처리하고, 반복될 경우 DDoS 공격이 발생한 것으로 간주하는 등 DDoS 공격징후를 토대로 다양한 DDoS 공격대응정책을 적용하여 오 탐지율 문제를 해결할 수 있다.

3.1.3 대응 알고리즘

Direct Request에 대한 Threshold 기반 대응 메커니즘 알고리즘을 나타낸다.

(표 1) Direct Request에 대한 Threshold 기반 대응 알고리즘

- 如/ : 특정 시간 구간 t, IP S 어서 彿째 URL에 대한 HTTP PPS

- : 전체 시간 구간 7에서의 의 합

- n : 전체 시간 구간 7종 안 요청이 발생한 URL 개수

- threshold : 如人姦에 대한 Thr©나M)ld

3.2 URL 당 평균 HTTP에 대한 Threshold 기반대응 메커니즘

3.2.1 발생 가능한 DDoS 공격유형

앞서 기술한 Direct Request0)] 대한 Thre^ shold는 기존 대응기법보다 정교한 대응을 할 수 있으나, 이를 우회할 수 있는 DDoS 공격형태가 발생할 수 있다.〔그림 6〕은 DDo$ 공격이 발생할 수 있는 유형을 나타낸다.

[그림 6) 정상 사용자의 URL 별 HTTP 분포 및 발생 가능한 DDoS 공격

〔그림 6〕은 주요 포털 사이트 5개를 대상으로 100 초간 30번, 70번의 Direct Request를 발생시켰을 때. URL별 hit 수를 높은 순으로 정렬한 결과를 나타낸다. X축은 hit이 발생한 각각의 URL을 나타내며, 편의상 숫자로 표기하였다. 정상 사용자의 웹 서비스 이용패턴에서 100초간 30번의 Direct Re- quest를 발생시키기는 쉽지 읺-으1瓦 70번은 지속적으로 F5를 눌러서 refresh 할 때나 가능한 수준이다. 앞서, 10초 단위에서 Direct Request 기준이 10이므로 Threshold 10통계 결과를로 통계결과를 보면, Direct Request 30의 경우 9.66% 영역만 차지하고 있어 DDoS 공격 이상 징후로 탐지되지 않으면서 지금 발생한 트래픽 대비 최대 1, 035%의 트래픽을 더 발생시킬 수 있고, Direct Request 70의 경우 15.2% 영역만 차지하고 있어 지금 발생한 트래픽 대비 최대 658%의 트래픽을 더 발생시킬 수 있다. 이와 같은 DDoS 공격을 탐지 및 대응하기 위해서는 HTTP 트래픽 패턴을 세부적으로 분석해야 한다.

3.2.2 정상 사용자의 HTTP 트래픽 패턴 분석

정상 시, 용자가 어떤 행위를 했을 때 발생하는 HTTP Request가 S개, 그때까지 시간이 7라.면, 최초 행위 발생 후 7' 이내인에서 신규 행위가 발생하게 되면. 그때까지 발생한 HTTP 개수 및 요청 T 한 URL 개수는 S X 号이며, 신규 행위 발생시점인4이 7보다 클 경우에는 HTTP 개수 및 요청 URL 개수는 S가 된다. 정상 사용자의 행위횟수가 많아지게 되면, <이 점 차 작은 값을 가지게 됨에 따라, S X 에 해당하는 HTTP Request 개수도 크게 증가하지 않는다. 따라서, URL 당 평균 HTTP 개수는 정상 사용자의 경우. 일정치 이상으로 증가하기 어렵다. 〔그림 7〕은 10초간 사용자의 Direct, Request가 증가함에 따라, 전체 HTTP 개수와 URL 당 HTTP 개수를 비교하여 나타낸다.

〔그림 7〕은 10초간 Direct Request 수를 1부터 W까지 증가시킬 때, 발생한 트래픽에 대해 좌측은 HTTP PPS, 우측은 URL 당 평균 HTTP 개수를 나타낸다. 여기서 발생한 트래픽은 정상 사용자가 웹브라우저를 통해 사용자의 행위 횟수를 증가시킬 때의 데이터 임에도 불구하고 10초당 850개가 넘는 HTTP 가 발생하게 되어, 정상과 공격 트래픽을 구분하기 어렵다. 그러나, URL 당 평균 HTTP 개수를 보면, 10 초간 10번의 Direct Request 발생, 즉 1초마다 계속 페이지 refresh를 할 때조차도 URL 당 HTTP 개수는 3.11 이상으로 증가하지 않는 것을 확인할 수 있다.

(그림 7) HTTP 개수와 URL 당 평균 HTTP 개수 상관관계

3.2.3 대응 알고리즘

URL 당 평균 HTTP에 대한 Threshold 기반 대응 알고리즘을 나타낸다.

- : 특정 시간 구간 t, IP S에서의 HTTP PPS

- wrs : 전체 시간 구간 7에서의 叫u의 합

- n : 전체 시간 구간 7동 안 요청이 발생한 URL 개수

-httKr, . t ' wt, s division to n for time interval T

-threshold^ : threshold of http此"T

3.3 Challenge 기반 DDoS 공격 대응 메커니즘

앞서, 웹서비스 트래픽 패턴에 기반한 DDoS 공격 대응 메커니즘을 제안하였다. 여기서는 의심스러운 트래픽을 발생시키는 Source IP를 대상으로 DDoS 공격 여부를 판단할 수 있는 Challenge 기반 대응 메커니즘을 제안한다. Netbot Attacker, Black­ energy, DosHTTP, 7.7 DDoS 등 지금까지 발생했던 응용계층에 대한 모든 DDoS 공격은 대량의 HTTP Request 를 발생시키거나 TCP Con nection을 고갈시키는 형태로 발생했으나, 이들은 웹서버로부터의 Response는 모두 무시한다〔11.12). 그러나, 정상 웹브라우저의 경우 HTTP Request 후, 웹서버로부터 받은 HTTP Response를 토대로 Indirect Request가 발생한다. 띠라서, 본 논문에서 제시하는 메커니즘은 HTTP Response 에 Challenge를 삽입하고, 이후 발생하는 Request에 Challenge에 대한 적절한 Response 여부에 따라 정상 사용자의 트래픽과 좀비:PC에 의한 트래픽을 구별한다. 〔그림 8〕은 Challenge 기반 DDoS 공격 대응 절차를 나타낸다.

(표 2) URL 당 평균 HTTP에 대한 Threshold 기반 대응 알고리즘

(그림 8) Challenge 기반 DDoS 공격 대응 절차

위 그림과 같이, 웹브라우저를 통한 정상 사용자의 HTTP Request를 수신한 웹서버는 Response의 payload에 Challenge 값을 클라이언트에게 보내고, 웹브라우저는 수신한 payload 내용을 해석하는 과정에서 Challenge에 대한 Authentication Key 를 계산하고 HTTP Cookie에 삽입하여 redi­ rection 형태로 HTTP Request를 다시 발생시키게 된다, 웹서버는 HTTP Cooki은에 포함된 Authen­ tication Key를 검증하여 DDoS 공격 발생 여부를 탐지하게 된다. 지금까지 발생한 DDoS 공격도 구는 웹서버의 Response를 무시하므로, 이후 발생하는 HTTP Request는 Authentication Key를 포함하고 있지 않게 되므. 로, 웹서버는 이를 탐지하고 해당 Source IP를 Blacklist 처리한다. 아래 표는 java script 중 Challenge 코드의 핵심 부분을 나타낸디.

. - § : Server의 현재시간

“ T : Server가 Challenge 값을 보낼 때의 시간

- [ABd[r : 비교하고자 하는 자리 수侦 = 2일 경우, 하위 2자리 (32bit)만 비교)

一 %艸 '■ Seivei측이 보유한 비밀 키

- H{T.!!\SkEy)'- * &y를 hash 한 값

현재 DDoS 공격 방어기술 중 SYN Cookie 기법이 널리 사용되고 있는데, 이는 IP Spoofing을 통해 SYN Flooding 공격 등을 발생시키는 공격에 대응할 수 있다, 그러나, 위와 같이 정상적인 TCP 세션을 맺고, 발생하는 GET Flooding 공격에 대응할 수 없는 반면. ChaHen既 기반 대응 메커니즘은 대응 가능하다. 또한, HTTP Pwxy를 사용하는 경우, 웹 방화벽 등 보안 기능을 제공하지만, 정상 사용자와 동일한 inquest에 대해 탐지 및 대응할 수 없지만, Challenge 방식은 대응 가능하다. Challenge 기반대응 메커니즘은 모든 Source IP 대상 트래픽에 적용되는 것이 아니라, 앞서 Behavior 기반 대응 메커니즘에 의해 의심스러운 HTTP 트래픽 패턴을 보이는 Source IP에 한정하여 적용한다. 의심스러운 Source IP로부터 HTTP Request를 수신한 웹서버는 Challenge 기반 DDoS 대응 메커니즘을 시작한다. 이와 깉, 이, 적용대상을 한정하여 성능 문제를 해결할 수 있다.

(표 3) ChaHenge 기반 DDoS 공격 대응 알고리즘

IV. 성능 분석

4.1 Implementation

대응 메커니즘 검증을 위해 DDoS 공격대응 시스템을 개발하였다. 네트워크 인터페이스 카드(NIC) 를 통해 들어오는 패킷은 NIC 드라이버를 거쳐 NDIS(Network Driver Interface Specific cation)로 오게 된다’ DDoS 공격 대응을 위해 개발한 NDIS Intermediate 드라이버를 통해 패킷을 후킹 하며 Packet Pool로 넘기고, 각 패킷에 대한 포인터는 NDIS Driver API Helper 로 넘긴다. Packetshield Main Engine에서는 이 정보들을 토대로 패킷을 Layer 3. 4, 7에서 파싱하고, 필터링 처리한다. 실제 트래픽에 대한 제어는 Packetshield Main Engine에서 이루어진다.〔그림 9〕는 DDoS 공격대응시스템 아키텍쳐 및 패킷 파싱, 필터링 구조를 나타낸다.

(그림 9) DDoS 공격 대응 시스템 아키텍쳐

4.2 Behavior 기반 대응 메커니즘 성능시험 결과

4.2.1 기존 DDoS 공격 도구에 따른 성능평가

주요 DDoS 공격도구인 Netbot Attacker와 Blackenergy를 통한 GET Flooding 공격 발생 시, Behavior 기반 메커니즘을 적용했을 때와 적용하지 않았을 때의 CPU 이용률. 네트워크 이용률, 웹서버의 lifetime을 분석하였다. 이를 위해, 좀비PC 및 C&C 서버, 웹서버 등으로 구성된 테스트베드 환경을 구축하였다. [그림 10〕은 Netbot Attacker는 좀비 PC당 Thread를 5개, Blackenergy는 Thread 를 10개로 설정하고. HTTP GET Flooding을 발생시키는 좀비PC의 수를 점차 증가시킬 때의 성능분석 결과를 나타낸다.

(그림 10) Netbot Attacker, 이"k^nsgy룰 통한 DDoS 공격 발생 시, 성능평가

a), b), c)는 Netbot Attacker, d), e), f)t Black- energy를 통한 DDoS 공격 발생 시, CPU, 네트워크 대역폭, 웹서버 lifetime을 나타낸다. Netbot Attacker의 경우, 대응 메커니즘이 동작하지 않을 때 , CPU의 경우 좀비 PC 4〜5대면 100%에 이르고 (a), 네트워크 대역폭 역시 좀비 PC 5~6대면 100%를 이르고(b). 좀비 PC가 7대의 경우 웹서버는 50여초 이상을 버티지 못한다(c). 그러나, Behavior 기반 DDoS 공격 대응 메커니즘 적용 시, 안정적으로 동작함을 확인할 수 있다’

4.2.2 Behavior 기반 대응 메커니즘에 의한 성능평가 저하

여기서는 Behavior 기반 대응 메커니즘을 적용할 때와 적용하지 않을 때의 성능 저하가 얼마큼 발생하는지 분석한다. 이를 위해, Behavior 기반 대응 메커니즘은 모든 연산을 수행하지만. blacklist로 도출된 IP를 필터링하지 않을 때(모니터링 모드)에서의 성능 저하 여부를 측정하였다. X축은 어플리케이션 성능측정 전문장비인 Avalanche 2900 장비를 통해 초당 발생시킨 Transaction 수를 나타내고, Y축은 Behavior 기반 대응 모듈 Enable, Disable 상황에서 초당 처리한 Transaction 수를 나타낸다.

(그림 11] Behavior 기반 대응 모듈 En&bl#Di$able에서이 TPS 처리성능

Behavior 기반 대응 모듈을 동작하더라도 8, 000 TPS (Transaction Per Second)까지 비 슷하게 동작하며, Disable의 경우 최대 10, 043 TPS까지 처리 가능한 반면' Enabled 경우 최대 7, 848 TPS까지 처리 가능하다. 즉, 최대 Transaction 처리 성능대비 78.14% 선에서 운영할 수 있다. 이는 모니터링 모드로 운영했을 때의 성능 저하를 나타내므로. DDoS 공격정보에 대해 필터링 모드로 동작하게 되면 더욱 좋은 결과를 나타낼 것이다.

(표 7) Internet Explorer 7에서의 r에 따른 Response Time

4.2.3 Challenge 기반 대응 메커니즘 성능시험 결과

Challenge 기반 DDoS 공격 대응 메커니즘은 모든 Source IP에 대해 적용하지 않고 DDoS 공격으로 의심스러운 Source IP에 한정하여 적용함으로써, Challenge 공격대응 모듈에 따른 부하를 줄일 수 있다. Challenge 기반 대응 모듈이 적용되는 Source IP는 Chalkmge에 따른 Authentication Key를 계산해야 하는데, 클라이언트가 받게 되는 부하는 r 값을 통해 정책적으로 조정할 수 있다.〔표 7〕은 Internet Explorer 7에서 r 값에 따른 클라이언트의 Response Time을 나타낸다.

분석 결과, r 값이 2, 3인 경우 각각 평균 3.16ms, 6’45ms이지만, r 값이 4가 될 경우 평균 242.67ms 가 되는 등 기하급수적으로 증가함을 확인할 수 있다, 따라서, r 값을 3 이하로 운영하면 정상 사용자의 성능저종} 없이 운영할 수 있다. 또한, Response Time은 다양한 클라이언트 PC 성능에 따라 달라질 수 있다. 〔그림 12〕는 고사양 PCdntel Core2 Duo CPU 3.0GHz, 3.37GB RAM)와 저사양 PC(Intel Core2 CPU 1.86GHz. 1.0GB RAM)에서 측정한 Response Time을 나타낸다.

(그림 12) PC 성능에 따른 Response Time

분석 결과, PC의 사양과 관계없이 3 이하의 r 값을 운영할 때 효과적으로 동작하는 반면, r 값 4에서는고사양 PC와 저사양 PC에서 차이가 발생한다. 따라서 , Challenge 기반 DDoS 공격 대응 메커니즘 적용 시, r 값은 2〜3 정도로 조정하여 사용하면, PC 성능과 상관없이 성능 부하를 최소화하면서 좀비PC에 의한 DDoS 공격 트래픽을 차단할 수 있다.

V. 결론

지금까지 웹서비스를 대상으로 발생하는 응용계층 DDoS 공격에 대한 Direct Request 기반 Thre­ shold, URL 당 평균 HTTP 기반 Threshold, Challenge 기반 대응 메커니즘을 제안하고. 성능분석 결과를 제시하였다.〔그림 13〕은 DDoS 공격유형 및 본 논문에서 제안된 메커니즘을 통해 대응 가능한 영역을 나타낸다.

(그림 13) DDoS 공격유형 및 대응 가능 영역

X축은 Source IP별 10초간 요청한 URL 개수를 나타내고, Y축은 해당 시간 동안 발생한 HTTP 개수를 나타낸다. 따라서. Source IP별 10초 단위마다 정상 및 DDoS 공격의 모든 트래픽 패턴은 하나의 점으로 표현된다. X축은 요청한 URL 개수를 나타내므로 Y<X 영역에는 데이터가 존재할 수 없다. 기존 HTTP에 대한 Threshold 기반 대응 메커니즘은 URL 개수는 고려하지 않으므로, ①+②+③ 영역의 트래픽 유형에 대해서는 DDoS 공격으로 탐지 및 차단할 수 있다. 이를 우회할 수 있는 트래픽은 ④+⑤ + ⑥ 영역에 존재할 수 있는데, 본 논문에서 제안한 Direct Request 기반 Threshold 대응기법은 ④ 영역을 대응할 수 있고, URL 당 평균 HTTP Request에 대한 대응기법은 ④+⑤ 영역을 탐지 및 대응할 수 있다. Challenge 기반 대응기법은 의심스러운 트래픽 패턴을 보이는 ④+⑤ 영역 뿐 아니라. 정상 사용자 패턴에 해당하는 ® 영역에서도 DDoS 공격발생 여부를 탐지할 수 있다. a는 4으로 URL 당 평균 HTTP Request 수를 의미하므로’ 각 URL 별 HTTP Request들 중 a 이상의 Request 수를 기록한 경우가 존재한다. 따라서, Direct Request 에 대한 Threshold가 a라면. SsaX에 해당하는 최소한 ①+④ 영역은 DDoS 공격으로 탐지 및 대응할 수 있다. 앞서, 웹서비스 이용 패턴 분석 결과, 앞서 기술한 바와 같이 Threshold를 10으로 설정할 경우 PM10X 영역에 대해 대응할 수 있다. 0 역시 URL 당 평균 HTTP Request 수를 의미하므로 ₀₌ 錦盟霊幕_{이며' 空麻에 해당하는 ①+②} + ④+⑤ 영역은 DDoS 공격으로 탐지 및 대응할 수 있다. 앞서, 웹서비스 이용 패턴 분석 결과, URL 당 평균 HTTP에 대한 Threshold를 3으로 설정할 수있으므로, FM3X 영역에 대해 대응할 수 있다. 일반적인 웹서핑 사용자 대부분의 트래픽은 10초당 Direct Request 개수가 2 이하인 경우가 89.4%이므로 〜 YWL5X 사이에 존재하게 되며 , 웹브라우저 refresh 등을 통해 고의적으로 트래픽을 많이 발생시킬 경우, Y>2X 〜 FW3X 영역에 위치하게 된다.

최근까지 큰 피해를 발생시킨 Netbot Attacker, Blackenergy, 풍운, DoSHTTP 등의 DDoS 공격 도구는 특정 URL에 대해 Get Flooding을 발생시키므로. 주로 ①영역에 위치하며, 7.7 DDoS 공격의 20 PPS 이하로 특정 URL을 대상으로 발생하므로, ④영역에 위치한다. Netbot Attacker 5.5 버전 이상에 존재하는 Circle CC Attack의 경우, 사전에 설정된 URL들을 대상으로 DDoS 공격이 발생하므로, ③영역에 해당하여 탐지 및 대응이 가능하다. 응용계층에 대한 DDoS 공격은 점차 정상 사용자와 유사한 패턴으로 발전하고 있으므로, 향후 DDoS 공격은 ①台④⑤习⑥영역으로 발전할 것으로 예상된다. 본 논문에서 제안한 메커니즘은 ④, ⑤ 영역을 탐지 및 대응할 수 있고, ⑥ 패턴에 해당되더라도 Challenge 기반 대응 메커니즘을 통해 대응할 수 있다. 본 논문에서 제안한 메커니즘은 간단하면서도 강력한 성능을 내므로, 상용 환경에 바로 적용할 수 있을 것으로 예상된다. 최근, DDoS 공격은 점차 정상 사용자의 유사한 형태로 발전하고 있으므로, 본 논문에서 제안한 메커니즘을 더욱 발전 시켜 정교한 DDoS 공격에 대응할 수 있어야 할 것이며, 본 논문에서 다루지 않은 TCP Cormection을 고갈시키는 DDoS 공격유형에 대한 분석이 추후 연구되어야 한다.

* 본 연구는 지식경제부 및 한국산업기술평가관리원의 IT산 업원천기술 개발사업의 일횐〃으로 수행되었음、