HTTP Traffic Flooding 공격(GET Flooding)

: TCP 세션 연결 이후 발생하는 일반적인 공격 형태

: 공격자는 동일한 URL을 반복 요청하여 웹서버가 URL에 해당되는 데이터를 클라이언트에게 회신하기 위해 서버 자원을 사용하도록 하는 공격

 

 공격자(클라이언트) ---- 동일한 URL에 대한 요청*10000 ---> 피해자(웹서버)

 공격자(클라이언트) <--- 요청한 URL에 대한 응답 ----  피해자(웹서버)

 공격자(클라이언트) <--- 요청한 URL에 대한 응답 ----  피해자(웹서버)

 공격자(클라이언트) <--- 요청한 URL에 대한 응답 ----  피해자(웹서버)

 공격자(클라이언트) <--- 요청한 URL에 대한 응답 ----  피해자(웹서버)

                                             .

                                             .

                                             .

                                         과부화

 

=> DoS 상태에 빠짐 (웹서버는 한정된 HTTP 처리 Connection 용량을 갖고있기 때문)

 

with Cache-Control (CC Attack)

웹서버의 부하를 감소시키기 위해 캐싱 서버를 운영

-> 동일한 URL에 대한 요청이 많을 때 캐싱 서버를 통해 응답

 

-> 이때 공격자는 HTTP 캐시 옵션(Cache-Control)을 조작하여 캐싱서버가 아닌 웹서버가 직접 처리하도록 유도

=> 웹서버 자원 소진 (DoS공격)

 

HOW??

[캐싱서버가 아닌 웹서버가 직접 처리]

- no-store(캐시저장금지) : 클라이언트로부터 요청받은 데이터를 캐싱서버에 저장하는 것을 방지

- must-revalidate(캐시검증) : 웹서버와 별도로 캐싱 서버를 운영 -> 검증요구

 

[캐싱 서버 운영 모델]

- Fowarding(포워딩)

  PC - 캐싱 서버 - 웹서버 - DB

  캐싱서버가 요청정보를 먼저 처리하는 경우

  <공격>

  PC와 캐싱서버간 패킷에서 Cache-Control 값이 no-store로 설정

  캐싱 서버와 웹서버가 별도로 운영되는 경우, 값을 must-revalidate 로 설정

 

- Hosting(호스팅)

   PC - (웹서버 <-> 캐싱서버) - DB

   웹서버가 요청정보를 분석한 후 캐싱서버를 이용하는 경우

   <공격>

   PC와 웹서버간 패킷에서 Cache-Control 값이 no-store로 설정 

   웹서버와 캐싱서버가 별도로 운영되는 경우, 값을 must-revalidate 로 설정