DDoS (분산 서비스 거부), Http 웹 공격으로 인한 서비스 지연

다음은, 실제 Http 웹 공격 사례 입니다. 이러한 공격 패턴은 기존의 트래픽을 밀어 넣는 방식과는 다르게 특정 웹사이트의 서비스를 지연 또는 장애를 일으킬 목적이 큽니다.



<Http Connections 갯수는 챠트상으로는 2440 근처이지만 그 지점에서 웹프로세스가 바로 장애가 발생하면서 더 올라가지 않았지만,..>



<과연 120Mbps 가까운 트래픽은 도대체 어디로 향하는지....;;>



<공격후의 시점에서의 Ping loss 율은 50~70% 선...>


공격은,. 오후 8시 20분 경부터 시작이 되었는데요..

모니터링후 실제 임시 조치를 하기까지 약 1시간 정도 소요가 되었습니다. 이 소요시간은 해당 웹서버의 자체 서비스로도 초기에는 충분 처리가 가능하였으나 그 이후 워커 프로세스에서 장애가 계속해서 장애가 발생하여 그 다음 대처 과정 이었습니다.

이 공격 패턴은, 공격지에서 특정 도메인에 대한 웹연결후 바로 끊어 버리는 방법입니다. 웹서버로의 요청이 포트만 오픈하는게 아니라 GET 요청 처리까지 입니다.

2008-05-04 12:34:20 GET /default.asp - - 124.53.201.50 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 121.175.170.91 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 211.212.153.39 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 211.109.18.29 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 211.237.213.84 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 124.54.173.45 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 61.252.201.187 - - 200 0 0
2008-05-04 12:34:20 GET /default.asp - - 220.72.182.154 - - 200 0 0

하지만 실제 공격지에서는 서버측에서 리턴되는 데이터를 수신하지 않습니다.
공격자가 프로그램에서 그런것까지 구현을 해놓을 이유가 전혀 없기 때문이지요..;;

해당 사이트 인스턴스의 기본 페이지가 default.asp 입니다. 말하자면 도메인 쿼리만 해서 접속 요청을 한다는 것입니다.

default.asp 파일에는 해당 웹사이트의 정상적인 운영을 위해서 여러가지 코드가 작성되어 있습니다.

이러한 코드는 예상되는 정상적인 범위내에서 안정적인 운영이 가능하도록 작성이 되어 있지만 DDoS 공격이 발생할 경우 큐갯수(2만개)를 훨씬 초과하는 요청이 들어오기 때문에 웹서버는 default.asp 코도 처리 때문에 CPU 로드가 100% 유발하게 됩니다.

이때 해당 서버의 상황은,. 큐갯수초과 뿐만 아니라 CPU로드 100%, 네트워크 세션의 엄청난 연결로 인해서 서비스 장애가 발생하게 됩니다.

물론 IPS 하단으로 옮겨서 차단하는 방법도 있겠으나,. 코드상 약간의 처리만으로도 리소스 사용율을 낮출수가 있습니다.

위 로그를 보면,. IP 주소외에는 어떠한 컬럼의 값도 없습니다.
말하자면,. 일반적은 브라우져 형태가 아닌 소켓으로 직접 요청하는 방법이겠지요.;;

<%
  if Request.ServerVariables("http_user_agent") = "" then
    Response.Redirect "http://192.168.1.1/"   
  else
    Response.Redirect "default2.asp"
  end if
%>

기존의 인덱스 페이지를 default2.asp 로 변경하고 default.asp 는 위처럼 코드를 변경하였습니다. 일반적인 브라우져에서 넘겨주는 user agent 값을 체크하는 것인데요.,.

상단의 Http 연결과 CPU 로드 차트를 보면,. 꾀나 효과적인 처리인것 같습니다.
물론 CPU로드는 위의 간단한 코드 처리만으로도 30~40% 가 나올만큼 요청이 계속 되었습니다.

서버 자체에서 더 좋은 처리 방법이라고 한다면,.
WebKnight 나 UrlScan 같은 ISAPI 필터를 이용했다면 default.asp 코드를 처리하지 않아도 되기 때문에 훨씬 깔끔한 방어가 될것 같습니다.

위와 같은 방법은,.
어디까지나 서버자체에서 처리가능한 한계내에서의 방법이고 되도록이면 IPS 하단에서 서비스를 하는게 가장 좋은 선택 입니다.


05-ddos-mrtg-http-day.gif
05-ddos-mrtg-traffic-day.gif
05-ddos-mrtg-cpu-day.gif