- 전체
- 보안뉴스
- 제로데이취약점
- 해킹프로그래밍
- 웹해킹
- 해킹기법
- 정보보호
- 정보보안기사 - 국가기술자격
- 악성코드분석_리버싱
- 시큐어코딩_개발보안진단원
- CISSP
- CISA
- 모의해킹_penetration-test
- deepweb / tor network
- Kali Linux
웹페이지 과다 호출 방식의 DDoS공격 사례 및 대처
2023.07.28 23:04
웹페이지 과다 호출 방식의 DDoS공격 사례 및 대처
제 목 : 웹페이지 과다 호출 방식의 DDoS공격 사례 및 대처
작성자 : 좋은진호(truefeel)
작성일 : 2008.1.22(화)
수정일 : 2009.6.28(일) 웹서버에서 HTTP GET Flooding 완화하기위한 설정 추가
다양한 DDoS 공격이 있지만, 이 글에서는 웹페이지를 과다하게 요청하는 방식의 DDoS을 살펴본다. 'DDoS는 막을 수 있다. 없다'에 대해서는 얘기하지 않는다. 오직 웹서버의 로그를 통해서 DDoS 공격 사례만을 살펴봤다.
입수한 몇 가지 로그 중 날짜와 시간대와 IP일부는 ??으로 변경 표시하였다.
1. 사례 1
218.93.???.10 - - [??/Oct/2007:??:19:44 +0900] "GET /index.asp?id=1 HTTP/1.1" 403 219 "www.google.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 5.1)" 59.53.???.126 - - [??/Oct/2007:??:19:44 +0900] "GET /index.asp?id=1 HTTP/1.1" 403 219 "www.google.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 5.1)" 125.118.???.133 - - [??/Oct/2007:??:19:44 +0900] "GET /index.asp?id=1 HTTP/1.1" 403 219 "www.google.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 5.1)" |
1) URI : /index.asp?id=1
의미 없어 보이는 URI같지만, 이 URI가 아이템베이(Windows기반+asp)에서 사용하는 URI로 보인다. 전혀 무관한 사이트에도 아이템베이의 URI로 공격이 들어온 것이다.
2) referer : www.google.com
레퍼러는 클라이언트(공격자)가 임의로 지정이 가능하지만, 이건 너무나도 허술하게 해놨다. 쓰윽 살펴보면, 구글통해서 들어왔구나 착각할 수도 있을 것이다. 그러나 정상적인 레퍼러라면 http:// 로 시작할 것이며, http:// 있더라도 구글 검색결과 페이지에서는 들어올 수 있겠지만 구글 메인에서 들어올 수는 없다.
3) 위의 로그에는 남지 않았지만, 공격대상을 도메인으로 요청하는 경우도 있을 것이고, IP로 요청할 수도 있을 것이다.
IP로 요청(즉, http://1.2.3.4/index.asp?id=1 처럼)했다면, 서비스 IP 변경으로 정상화가 될 수도 있을 것이다. 그러나 도메인으로 공격한 경우면, IP 변경시 바로 lookup이 되어 또 다시 공격이 들어올 것이다.
2. 사례 2
83.11.???.5 - - [??/Oct/2007:??:40:51 +0900] "GET /selling_information.html?tb=sell_pa&id=?????????? HTTP/1.1" 403 234 "www.google.com" |
1) URI : /selling_information.html?tb=sell_pa&id=??????????
이 URI은 아이템매니아에서 사용하는 URI이다. 이 또한 아이템 사이트가 공격을 심하게 당할 시기에 전혀 무관한 사이트에도 이들의 URI로 공격이 들어온 것이다.
3. 사례 3
위의 2개의 사례와는 다르게 해당 사이트에 존재하는 URI를 호출할 때도 있다. 이 때는 웹페이지가 정상적으로 실행이 될 것이고, 과다하게 요청이 이뤄지니 서버의 load는 감당할 수 없을 정도로 높아질 수 있다.
이 때는 웹로그를 살펴보고 위의 "www.google.com" 처럼 이상하게 된 레퍼러는 없는지, 브라우저명이 이상하지는 않는지 살펴보고, 그에 따라 대처해야 할 것이다.
URI 요청시에 엉뚱한 경우도 있다. 공격 대상이 a.com일 때 URI에 /http://a.com:80/ 이라고 표시된 경우도 있다고 한다. 즉, 브라우저로 봤을 때는 http://a.com/http://a.com:80/ 이런 형태로 요청한 꼴이다. 아마 툴을 이용해서 공격한 것 같은데, URI입력하라는 항목에 URL을 잘 못 입력한 것으로 보인다.
4. 사례 4 (트래픽 과다 발생을 위한 웹페이지 요청)
82.46.???.85 - - [??/???/2007:??:37:40 +0900] "GET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^&&%$%$^%$#^&**(*((&*^%$##$%^&*(*&^%$%^&*.htmGET ^*%%RTG*(&^%FTGYHJIJ%^&*()*&*^&%RDFG(JKJH.aspGET *(&*^TGH*JIHG^&*(&^%*(*)OK)(*&^%$EDRGF%&^.htmlGET 생략 ... " 414 271 "-" "-" |
KISA에서 발표한 '아이템 거래사이트 대상 DDoS 공격사례 분석'(http://www.krcert.or.kr/technicalDocList.do 에서 2007년 12월 31일 발표 자료)에서도 볼 수 있다. 열려있는 TCP 80포트를 통해 과다한 트래픽을 발생하는 형태이다.
1) GET ^&&%$%$^%$#^&** ... 생략 ...
GET method로 요청한 값은 의미 없는 값이며, 하나의 요청당 로그에는 8192bytes가 남아있다. 로그에는 8192만 남는 제한이 있기때문에, 실제로는 하나의 요청당 더 큰 bytes로 요청했을 것이다.
의미없는 값으로 GET mothod를 호출한 경우는 아이템 사이트 공격이 많았던 시기(9~10월) 이전에도 있었다.
2) 상태 코드 414
'Request-URI Too Long'을 의미한다.
5. 웹서버에서 HTTP GET Flooding 완화하기 위한 설정
이 부분은 얼마전 질문받아서 내용을 추가한다.
HTTP GET Flooding나 CC Attack 등의 DDoS 공격은 앞단에 DDoS방어 장비(장비 종류와 공격량에 따라 다르지만)나 L7 스위치 등이 있으면 막을 수 있는 공격 유형이다. 그러나 이러한 장비가 없다면 웹서버에서 처리를 해야하는데, 다음 2가지 시스템 구성에 따라서 적용 효과가 달라진다.
- 웹서버 한두대로 운영한다면 해결이 쉽지않다. 그래도 설정을 해두는게 좋다.
- 웹서버가 몇십대 등 대수가 많을수록 효과를 볼 수 있다.
1) apache의 로그 설정
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %T %{Host}i %{Accept-Language}i" combined2 |
CustomLog 설정에 로그포맷을 combined2 으로 지정한다. 이렇게 함으로써 실행시간(%T), 요청호스트명, 문자셋 등 좀 더 자세한 로그를 남길 수 있다. CustomLog 설정시에 로그를 일단위, 또는 시간단위로 로테이션하여 저장하는게 좋다. 이에 대해서는 '6. 참고할만한 자료'에 적어둔 글을 참고한다.
위처럼 로그를 남기는데도, 공격유형의 요청과 정상적인 요청간의 차이를 느끼지 못한다면 HTTP Request 헤더 패킷을 살펴봐야 한다. tcpdump, ngrep, ethereal(wireshark) 등의 툴을 사용하여 공격유형 요청과의 차이점을 찾아내야 한다.
2) 원하는 공격 패턴일 경우 403 Forbidden되도록 설정 (샘플)
SetEnvIf Referer "^http://www.google.com$" notaccept SetEnvIf Referer "^www.google.com$" notaccept SetEnvIfNoCase User-Agent "Hackeroo" notaccept # SetEnvIf Accept-Language "zh-cn" notaccept <Location "/"> Order allow,deny Allow from all Deny from env=notaccept </Location> |
위 예처럼 Referer나 User-Agent명이 이상한 경우 Deny되도록 설정할 수 있다. 또한 공격자의 문자셋이 다른 정상적인 것과 다르게 zh-cn로 표시된다면 추가할 수 있다. 이렇게 공격유형의 차이점을 파악하여 SetEnvIf로 변수 설정해주면 된다.
3) iptables와 스크립트
앞에서 설명한 apache 설정만으로 막기는 무리다. 앞의 설정과 접목하여 iptables로 IP차단까지 함께해야 조금이라도 효과를 볼 수 있다.
웹페이지 요청이 IP에서 동시 30개 이상이면(수치는 자신의 환경에 맞게 튜닝할 것) 차단하는 iptables 설정 예이다. iptables connlimit 모듈이 있어야 한다.
iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 30 -j DROP |
만약 C-class IP대역(255개 IP 전체)에서 동시 30개 이상 요청이 오는 것을 막고 싶다면 --connlimit-mask 24 옵션을 추가한다.
위처럼 limit기능을 이용하지 않고, 웹로그를 보고 특정 IP를 차단할 수 있다. 개인적으로는 connlimit보다는 이 방법을 더 선호한다. 로그를 보고 판단하므로 connlimit의 임계치 튜닝필요없이 정확히 해당 IP만 차단할 수 있기 때문이다.
주기적으로 웹로그를 파악하는 스크립트를 만든다. 그리고, 이 스크립트는 비정상적인 요청(로그를 자세히 남겨야 함) IP는 자동으로 iptables로 막도록 추가한다.
4) 기타
ModSecurity는 HTTP 패턴 매칭 방법 또는 특정 IP에서 과다하게 요청되는 것 등을 막을 수 있는 아파치 모듈이다. 이에 대해서는 'ModSecurity를 이용한 HTTP DDoS/flood 공격 완화'(글 EcusE, http://free4u.wo.tc/weblog/12023)글이 도움이 될 것 같다.
6. 참고할만한 자료
1) DDoS 정보 관련
* 정부의 DDoS 대응체계 구축 의지는 있는건가 (2008.1.21)
http://coffeenix.net/bbs/viewtopic.php?p=4309#4309
* 아이템베이와 아이템매니아 등의 DDoS공격 관련 (2007.10.11)
http://coffeenix.net/bbs/viewtopic.php?t=2631
* com & .net 도메인 수수료 인상과 Titan 프로젝트 (2007.4.9, 타이탄 프로젝트는 Verisign의 인프라확충 프로젝트임)
http://coffeenix.net/bbs/viewtopic.php?t=2092
* 전세계 봇 감염 대수 = 투사부일체 관객수 (2007.3.28)
http://coffeenix.net/bbs/viewtopic.php?t=2063
* 어떤 root DNS서버가 공격당했나? (2007.2.9)
http://coffeenix.net/bbs/viewtopic.php?t=1900
* DDoS공격 언론보도와 찾아본 사례들 (2007.2.8)
http://coffeenix.net/bbs/viewtopic.php?t=1892
* 해킹(DDoS 공격) 점점 노골적 (2007.1.13)
http://coffeenix.net/bbs/viewtopic.php?t=1785
2) 설정 관련
* cronolog 툴로 개선된 형태로 log rotation하기 (2000년대 초, 글 좋은진호)
http://coffeenix.net/board_view.php?bd_code=16
* 아파치 모듈 mod_setenvif
http://httpd.apache.org/docs/2.2/ko/mod/mod_setenvif.html
* iptables connlimit match 등
http://www.netfilter.org/projects/patch-o-matic/pom-external.html#pom-external-connlimit
* ModSecurity
http://www.modsecurity.org/
[출처] http://coffeenix.net/board_view.php?bd_code=1567
광고 클릭에서 발생하는 수익금은 모두 웹사이트 서버의 유지 및 관리, 그리고 기술 콘텐츠 향상을 위해 쓰여집니다.
