본문 바로가기

Hack The Packet/@ 2012 CODEGATE

[CODEGATE 2012 PREQUEAL] 정상트래픽과 DoS 공격트래픽을 어떻게 구분할 수 있을까?


DoS (Dinal of Service) 공격은 정상적으로 운영되는 서비스를 더이상 이용할 수 없게 하는 공격이다. 취약점을 이용한 방법과 네트워크 트래픽을 과도하게 보내는 Flooding 형태로 나누어 생각해 볼 수 있다.

 트래픽을 분석하는 것은 서버를 운영하는 사람의 입장과 악성코드에 감염된 PC의 사용자의 관점에서 다르게 생각해 볼 수 있을것이다. 같은 공격기법을 왜 다르게 판단해야 할까.
 서버입장에서는 가장 쉽게 한 페이지나 서비스에 과도하게 트래픽이 몰리는 경우, DoS 로 판단해 볼 수 있을것이다. 하지만 DDoS 에 악용되는 악성코드에 감염된 PC의 사용자(좀비 PC)에게는 오히려 과도한 트래픽을 찾는것은 쉬우나 간헐적으로 나타나는것은 모래 사장속에서 바늘찾기와 같을 것이다. 또한 단순히 트래픽이 많다고 해서 공격 트래픽이라고 판단하기도 어려울 것이다. 

# CODEGATE2012 Network 200 문제 풀어보기.

사용한 툴 ::  WireShark , NetworkMiner

DoS 공격으로 추정되는 상위 4개의 목적지 주소와 국가 정보를 구하는 문제이다. 



STEP1 파일의 기본 정보 파악하기

WireShark >> Statistics >>  Summary >>  

 12,566KB 사이즈의 패킷 파일에 약 5분동안 73,992개의 패킷이 들어있다. 초당 패킷량은 247개정도이며 데이터사이즈는 39K 정도이다. 이 기본정보로는 네트워크가 많다 적다를 판단하기는 힘들다. 기본 정보로 판단이 가능한 경우는 평소 자신이 사용하는 네트워크의 양을 계산한 기준으로 판단할 수는 있을것이다.



STEP2 필터링 with WireShark

 많은 패킷들을 잘 분류하는것이 중요하다 :)

1. 불필요한 정보를 제거
2. 확신이 드는 패킷 분리

일단, 퀵하게 본다면 IP Spoofing 같은 것은 한눈에 의심이 간다고 판단이 된다.

Wire Shark FILTER :: ip.dst == 111.221.70.11
 

필터링 결과, 전체 패킷의 71% (52,620 / 73,992 ) 이다. 또한 위 요약정보에서 초당 패킷이 247개인것에 비해 965개로 트래픽이 상당한것으로 보인다. 당연히 악성으로 판단되므로 ip.dst != 111.221.70.11 제외하도록 한다. 이를 다시 새로 저장 (File >> Save as >> 하단 Packet Range 에서 Displayed 선택 후 저장 )하여 새로 분석을 시작~!

Wire Shark FILTER :: ip.addr eq 74.125.71.1/24 and http.request

상단에 있는 74.125.71 대역은 구글의 IP이다. 이것이 공격지인지 본다면 http 요청으로 아래와 같이 볼 수 있을 것이다. 이런경우라면 정상으로 판단되므로 제외하도록 한다.
 



Wire Shark FILTER ::  ip.src != 74.125.71.0/24 and ip.dst != 74.125.71.0/24 

정상이라고 판단되는것은 제외하는 작업을 거치다 보면  악성을 판별하는것이 좀 더 수월해 진다. 
또하나의 다수를 차지하는 (ip.addr eq 109.123.118.42) 를 필터링해보면, 42% (8285/19543) 를 차지하는것을 알 수 있다. 또한 트래픽을 보면 동일한 요청이 연속적으로 반복되는것을 볼 수 있고 80포트로 udp, icmp 패킷이 나가는 것으로 보아 전형적인 DoS 라고 판단할 수 있다.


이쯤되서. Network Miner 를 이용하여 분석을 시작해보자. (파일 사이즈가 큰 경우, 속도가 느리기 때문에 앞선 작업처럼 필터과정을 거친 뒤 시작하는것이 좋다. )

 
 STEP3 필터링 with WireShark, Network Miner


 네트워크 마이너 툴을 이용하면 호스트 리스트를 한눈에 볼 수 있고, 파일이나 이미지 목록을 바로 받아볼 수 있는 장점이 있다. 하지만 와이어샤크를 이용할때처럼 필터를 자유롭게 걸 수 없다는 단점이 있다.
 두가지 툴을 적절히 활용하면 분석에 매우 용이하다.
 네트워크 마이너에서 "Sort Hosts On" 로 IP주소, 보낸 패킷 바이트 크기별 등으로 정렬할 수 있다. 하지만 여러 방향으로 정렬해 보아도 어떤것이 DoS 공격과 관련된 패킷인지 한눈에 보기는 어렵다. 




  이 정보를 어떻게 활용할 수 있을까? 각 도메인별 IP대역을 얻을 수 있으니 이를 이용하여 한번에 필터를 걸어 도메인 단위로 분석해 볼 수 있다. 특히 페이스북, 구글, 다음 등과 같은 웹 사이트들은 워낙 송/수신 하는 데이터들이 많으니 이렇게 구분해서 보는 것이 꽤 도움이 될 것이다.

필터에 계속 타이핑을 하는것보다 아래와 같이 필터를 걸수도 있을것이다 :)
 



 이렇게 검증해 나가다보면, 위처럼 확연히 이상증세가 나타나는 것이 아니라면 정상패킷을 걸러내는것만으로도 매우 지겨운 작업이 될것이다. 이럴때 축소화된 패킷을 가지고 DoS  공격에 대해 다시 생각해 볼 필요가 있다.

 STEP4 필터링된 패킷을 가지고 DoS 공격 걸러내기

 어느정도 패킷을 정제한 다음에 DoS 공격을 걸러내기 위해선 아래와 같은 필터를 이용할 수 있다.
  

ICMP flood icmp

SYN flood, slowloris tcp.flags == 0x02

R-U-Dead-Yet?  
  http.request.method == POST  or 
tcp.data contains 50:4f:53:54 or data.len == 1 

- tcp.flags == 0x02

일반적인 웹 트래픽에도 SYN 트래픽은 다량 발생할 수 있다.
이 중 의심스러운 [TCP Port numbers reused] 패킷들을 자세히 살펴보면 출발지 포트와 목적지 포트가 80으로 같은것을 알 수 있다.  대게 프로그래밍 오류로 볼 수도 있으며 일반적인 웹 요청은 아니라고 판단된다. 



http.request.method == POST  or tcp.data contains 50:4f:53:54 or data.len == 1  

RUDY는 HTTP POST 공격으로 요청헤더에 CONTENT-LENGTH를 매우 크게 잡고 실제 데이터는 소수만 보내는 공격이다. 서버는 요청 헤더에 있는 사이즈만큼 데이터가 올때까지 기다리게 되므로 오랜시간 자원이 낭비되게 된다. POST로 보내지는 요청이 있는 경우 데이터 사이즈가 작은경우를 필터링해서 찾아 낼 수 있다.



기타 DoS Attack )

Teardrop attacks (TCP/IP 재조합 버그였고, 2009년 SMB2 레이어 공격이었음) 
Low-rate Denial-of-Service attacks

Peer-to-peer attacks

Asymmetry of resource utilization in starvation attacks

Permanent denial-of-service attacks

Application-level floods

Nuke

Distributed attack

Reflected / Spoofed attack

Degradation-of-service attacks

Unintentional denial of service

Denial-of-Service Level II 

 따라서, DoS 공격이라고 추정되는 공격지들의 패킷량이 많은 순서대로
 IP, 국가 정보는 다음과 같다.


111.221.70.11, Singapore  => 52620 packets
109.123.118.42, United Kingdom => 8285 packets
199.7.48.190, United States => 615 packets
66.150.14.48, United States => 149 packets

 이 문제는 서버입장이 아닌 클라이언트 입장에서 악성코드에 감염되었을 때, 네트워크 특징만으로도 감염증상을 찾을 수 있는지를 판단하는 분석이 필요하다. DoS는 무조건 패킷수가 많은 경우라고 생각하여 단순히 모든 패킷들의 수를 세었거나 정상과 비정상적인것을 구별할 수 없었다면 상당히 어려운 문제가 되었을 것이다. 하지만 문제의 요지를 잘 파악했다면 오히려 굉장히 쉽게 풀리지 않았을까 생각된다 :)

'Hack The Packet > @ 2012 CODEGATE' 카테고리의 다른 글

[CODEGATE 2012 QUAL] Conficker  (0) 2012.04.01