2012년 1월 3일 화요일

10.26 선거방해 사건의 분석.

Intro. 이번 블로깅은 지금까지 제가 가지고 있던 의문점들에 대하여 최대한 객관적이고 기술적으로 접근하여 얻은 추론임을 서두에 밝힙니다. 글을 읽는 모든 분들 또한 객관적 시각에서 바라봐 주시길 바랍니다. 
이 글에 대한 기술적 토론은 댓글을 통해 해주시길 바라며, 그 어떠한 정치적, 인격비하적 발언도 불가을 알려 드립니다. (발견시 주기적으로 삭제할 예정입니다) 
이 글은 많은 기술적 부분을 내포하고 있음으로 읽는 분들의 직종에 따라 상당히 난해한 부분이 나타날 수 있습니다. 해당직종의 종사자가 아닐 경우 "Chapter4 -쉬운설명"부터 읽어 나가시기를 권해 드립니다.







Chapter 1. 선관위의 서버구성

 우선 이번 사건에서 먼저 알고 넘어가야 하는 부분입니다. 선관위는 국가 주요기관으로 최대한 합리적이고 안정적인 서버 운영이 필요한 기관입니다. 선관위 서버가 공격등의 위험에 노출되거나 적절한 대응을 하지 못하였을 시에는 선거 결과에 대한 공신력이 저하될 수 있음을 인지하여야 합니다. 


 객관적으로 이번 사건을 보기위해 선과위 서버 구성을 조사하던 중, 선관위 서버가 Sub Domain마다 다른 IP Address를 가진다는 사실을 알게 되었습니다. 만약 서브도메인 마다 다른 서버를 사용할 경우 선관위 서버는 Load Balancing을 하지 않을 확률이 높아지게 됨으로 이번 증상에 많은 영향을 끼칠 수 있습니다. 
 조사결과 선관위 메인 페이지를 기준으로 nec.go.kr을 공유하는 서브도메인 6개(www, info, m, minfo, law, ok)와 별도의 도메인 2개를 발견할 수 있었습니다. 이중에 중요한 것은 서브 도메인 6개 입니다. 정확성을 위해 제가 사용할 수 있는 회선 (SK Broadband와 KT, KT Wibro) 3개와 주변의 지인분들, 그리고 이 포스팅이 가능하도록 조언을 해 주신 모든 분들께 IP조회를 의뢰한 결과 모두 동일한 결과값을 얻을 수 있었습니다.(IP 조회는 국내뿐 아니라 해외에서도 이루어 졌습니다)






IP만 가지고는 확신을 할 수 없었기에 각 서브도메인 별 Header Response를 살펴보기로 합니다.(이미지를 클릭 하시면 확대보기를 하실 수 있습니다)

http://www.nec.go.kr


http://info.nec.go.kr


http://m.nec.go.kr


http://minfo.nec.go.kr


http://law.nec.go.kr


http://ok.nec.go.kr

각 서버별로 상이한 Header Response를 확일 할 수 있으며 심지어는 Charset값 마저 다름을 알 수 있습니다. 이러한 서버 설정은 상당히 비효율적이라 할 수 있습니다. 개인적인 소견으로는 하청을 주는 과정에서 벌어진 웃지못할 비극이 아닐까 하는 생각을 해봅니다. 혹자는 "Virtual Host 셋팅으로 위와같은 결과물을 만들 수 있다"고 주장할 수 있으나, 그러한 세팅을 해야할 목적을 찾을 수 없음으로 가능성은 아주 낮다고 봅니다. 또한 위 결과물을 토대로 선관위 서버는 Tomcat을 기반으로 JSP를 서비스를 하고 있으며, Unix/BSD,Linux기반의 Apache 서버를 사용할 확률이 높다있다는것을 알 수 있습니다.
(추가12.01.10: 또는 많은 비용을 들여 WebLogic의 사용도 가능성이 있습니다.)

위 결과물과 여러 정황들을 토대로 선관위의 서버 구성도를 그려보았습니다. 선관위 서버 구성과 차이가 있을 수 있으나 logic은 대동소이 할 것입니다. 따라서 이번 현상을 설명하는데는 충분할것 입니다.(포토샵에서 발로 만들었음을 미리 밝히는 바입니다. 이미지를 클릭하시면 확대화면을 보실 수 있습니다.)



KT에서 공개한 MRTG가 2개인 점을 감안하여 두군데의 ISP에서 모두 Pubnet으로 유입이 될 것이라는 전제를 두었습니다. Database Server는 개표정보 수집과 각 방송과 언론 기자들의 조회, 일반인의 조회를 충분히 버텨낼 수 있어야 함으로 최소 2대이상의 병렬구조로 이루어져 있을 것입니다. 각 서브도메인 마다 1대의 서버를 사용할 수도 있지만 아래와 같이 L7 Switch혹은 L4 Switch의 순차적 구성을 사용하여 아래와 같이 여러대로 구성할 수도 있습니다.(이러한 경우에는 로드벨런싱을 하더라도 동일 IP를 보일 수 있습니다)


하단에서 이정도 구성을 할 수 있었다면 상단 구성 또한 로드벨런싱을 했어야 하며, 1대의 구성보다는 훨씬 더 많은 양의 요구를 처리할 수 있습니다. 또한 Chapter2에서 언급할 DDoS공격의 효율성 부분을 더욱 낮게 만드는 요인이 됩니다.


이쯤에서 6기 이상의 서브도메인 서버 또는 서버군을 이미 로드벨런싱으로 묶었어야 하는것 아니냐는 의문을 제기하시는 분이 있을 것입니다. 저도 그 부분은 이해하기가 쉽지 않습니다. 정리하자면 선관위의 서버 구성은 6개 이상, 웹서비스를 목적으로 하는 독립적인 서버(군)으로 이루어져 있으며 각 서버(군)별 서비스 내용은 아래와 같습니다.

  1. www : Domain Root에 관련된 서비스를 하며 다른 서브도메인 으로의 링크를 제공합니다.
  2. info : 투표소 조회와 투/개표율 조회 등의 선거관련 정보를 제공합니다.
  3. m : Mobile Service Page 의 Domain Root를 제공합니다.
  4. minfo : info 서버와 동일한 정보를 Mobile을 통해 제공합니다.
  5. law : 선거와 관련된 법제정보를 제공합니다.
  6. ok : 재외선거와 관련된 정보를 제공합니다.

이쯤되면 전체적인 시나리오가 예상되는 분들이 있으실 겁니다. 앞으로 이야기할 서버는 이 6개의 서버(군)중 www, info, m, minfo 4개의 서버(군) 입니다.






Chapter 2. 경찰 발표내용의 신뢰성과
기술적 논쟁들.

 경찰 발표에 의하면 "200대의 좀비 PC를 가지고 RCMP,UDP,TCP,CC 등의 총합 2Gb의 공격으로 정상적 서비스를 할 수 없는 상태로 만들었다" 가 주된 내용 입니다. 뭐 누가 술을 먹고 마약을 하고 누군가에게 사주를 하였다는 부분기술적인 부분이 아님으로 생략하겠습니다.



 가. 공격의 효율성 부분 입니다. 경찰 발표에 따르면 "RCMP,UDP,TCP,CC 등의 공격이 이루어 졌다"라고 했습니다. 지금부터 Chapter1 에서 다뤘던 서버의 구성을 가지고 이 공격들의 효율성이 어떠한가 보도록 하겠습니다. LG엔시스에서는 DDoS장비는 정상작동했다고 발표했습니다.


RCMP(ICMP) : 가장 당혹스러웠던 공격 기법이었습니다. "구글신"에게 물어보아도 알려주지 않았던 신종 기법이었기 때문이지요. 정확히 말씀드리자면 ICMP의 오타입니다. 이러한 오타를 검증없이 복사해 나른 언론사분들 덕분에 상당히 많은 기사에서 이 단어를 목격하게 됩니다. ICMP 공격의 경우 공격받을 서버가 위치한 네트워크 상의 다른 서버에 공격대상을 수취인으로 하는 ICMP요청을 보내는 방식의 공격입니다. 요청을 받은 네트워크 상의 최소 255대의 서버가 수취인에게 ICMP를 전달하고 공격이 성공하면 상당한 효율을 보장할 수 있습니다. 하지만 대부분 네트워크 장비에들이 막아낼 수 있도록 설계되어 있으며 Chapter1 에서 다루었던 DDoS 방어장비라면 일정량 이상의 ICMP를 거부해 손쉽게 막아낼 수 있는 공격입니다. 심지어 서버세팅시 ipTable설정 만으로도 방어가 가능한 공격이 되겠습니다.
UDP : 별도의 검증없이 양방향으로 데이터를 가장 빠르게 전달하는 통신방법입니다. 보통 동영상이나 음악 스트리밍 서비스에 사용합니다. 방어 방법은 UDP로 들어오는 모든 요청에 대해 Null(정보없음)을 반환해 주는 방식으로 방어가 이루어집니다. 서버나 DDoS 방어 장비에서 이러한 방어를 할 경우 상위 네트워크(스위치 장비나 백본 등)에 부하가 몰리게 되어 서비스 제공 업체에서 인지하고 대응할 수 있으며 마찬가지로 Chapter1의 DDoS 방어장비라면 충분히 방어할 수 있는 공격 입니다. 
TCP,CC : 두가지 모두 다른 공격 방법이나 하나로 묶어 쓰는 이유는 두가지 공격 모두가 "정상인척" 하는 공격으로서 대용량의 공격이 불가능 하다는 이유가 있습니다. 정상 이상의 패턴을 보이면 DDoS 방어장비가 탐색할 가능성이 높습니다. 위 공격들은 많은수의 좀비를 확보했을 때 비로소 공격의 효과가 나타나며 200대의 좀비로는 큰 효과를 볼 수 없는 공격방식 입니다. DDoS 방어 장비는 이러한 "정상인척 하는 비정상 신호"를 막아내는 역할을 하며 서버설정으로 방어 할 수 있는 방법을 인터넷 검색만으로 쉽게 찾을 수 있습니다. 
섞어찌개(?) : 경찰 발표에 의하면 200대의 한정된 공격 자원을 이용하여 최대한의 공격을 해야 효율성을 보장받을 수 있습니다. DDoS 공격에 있어 200대는 적은 자원이고 이를 활용해 공격할 수 있는 최선의 방법은 ICMP나 UDP공격이지만 Web Server Web Server Software(Apache등)와 방화벽 기본 세팅은 TCP/80, TCP/433을 제외하고 Deny all입니다. (이 설정이 들어있지 않다면 선관위 서버 관계자들은 전부 옷을 벗어야 합니다) 앞서 설명드린대로 UDP를 제외하면 200대로 2Gbps의 공격을 하는 것은 현실적으로 불가능하기 때문에 전송량 부분 또한 충족할 수 없으며, 2Gbps 이하의 공격을 여러가지 공격방식으로 분할하는 것 또한 효율성면에서 최악의 선택입니다. 따라서 DDoS공격으로 선관위 서버를 무력화 시키는 것에는 실패했을 확률이 높다고 할 수 있습니다.


 나. 기술적 논쟁 부분 입니다. "나꼼수"에서 처음 이 사건을 이야기 하면서 "DB서버를 끊었다" 라는 표현을 사용합니다. 그리고 자칭 보안전문가 이신 "이길환"님이 방송 매체와의 인터뷰를 통해 "특정 페이지를 공격해 DB를 무력화할 수 있는 신종 DDoS다"라는 이야기를 하면서 전문가들 사이에 기술적 논쟁이 시작됩니다. 그리고 저를 이 논쟁에 들어오게한 "박현철"님의 트윗 내용은 첫번째 블로그를 통해 공개를 했습니다.
 이번 기술적 논쟁에서 가장 중요한 부분은 Chapter1 에서 다루었던 서버의 구성 입니다. 제 예상이 틀리지 않다면 현재의 선관위 서버는 그 어떠한 효율도 기대할 수 없는 구성으로 이루어져 있으며, 앞서 이야기한분들 주장에 가능성이 생깁니다. 하지만 확실히 집고 넘어가야 할 부분은 특정페이지를 공격하던, 메인 페이지를 공격하던 "DDoS공격으로 죽일 수 있는것은 웹서비스를 하는 프로그램이지 특정 페이지만 죽지는 않는다"는 것입니다.

 그리고 사과드릴 부분이 있습니다. 제 두번째 블로그의 내용으로 현재 선관위의 조회페이지에서 봤을때는 55가지의 질의(Query)만으로도 충분한 서비스를 할 수 있으나 당일 선관위의 조회페이지는 지금과 다르다는 것을 간과한 내용입니다. 충분한 조사를 하지 않고 제 짧은 식견으로만 포스팅을 한 점에 대하여 글을 읽어주신 분들께 사과를 드립니다.

 이 기술적인 논쟁을 하기 위하여 한가지 더 필요한 사항이 있다면 바로 선거당일 이용자들이 격었던 장애증상에 대한 레포트 입니다. 선관위 서버에서 일어났던 일들을 종합적으로 정리해봐야 할 필요성이 있었습니다. 이번 맥락 에서는 선관위 서버에서 나타난 증상만을 기술하고 자세한 내용은 Chapter3에서 제보와 증상을 중심으로 사건을 재구성 하면서 이야기 하도록 하겠습니다.

  1. DB서버에서의 Caching은 일어나지 않았을 확률이 높다. 시/도,구/군 외 사용자 이름과 주민등록 번호, 읍/면/동을 입력받았다.
  2. DDoS 공격은 있었다. 하지만 200대의 좀비로 2G의 공격은 불가능하며 공격의 효율성 부분을 보장할 수 없다.
  3. 6시 부터 9시 사이에는 자신의 투표소 찾기가 불가능 했다. 심지어 투표율 조회 또한 되지않았다.
  4. 8시 부터 9시 사이에는 http://www.nec.go.kr (메인페이지)도 접속 장애를 겪었다.
  5. DDoS 공격을 받을 수 있는 것은 "특정 페이지를 소유하는 1기의 서버(군)"이다.
  6. info와 minfo 서버(군)에서 동시간대에 같은 증상이 나타났다.
  7. 경찰발표에서 선관위가 공격을 인지한 시각은 5시50분이다.






Chapter 3. 제보와 증상을 바탕으로 
당일 사건의 재구성 



 먼저 11월 16일 KT 이상용 상무가 방송통신위원회가 주최한 해킹방지워크샵 에서 공개한 MRTG를 보면서 이야기를 풀어가도록 하겠습니다.


위 MRTG는 11월16일 오전  KT 이상용 상무가 공개한 그래프에 가시성을 위해 시간표시를 추가했음을 알려 드립니다. 

 Chapter1 에서 말씀드린대로 ISP유입은 KT+Dacom을 보는것이 맞을 것입니다. 그러므로 두 그래프를 합친 값이 Pubnet으로 유입된 전체 트래픽 양이 되겠습니다. 여기서 Pubnet이라 함은은 초고속 국가망을 구축하는 사업으로서 선관위가 들어있는 KRNIC : KT Pubnet 을 가르킵니다. KT Pubnet 안에는 선관위의 서버만이 있는 것은 아닙니다. 하지만 전개의 편의성을 위해 다른 서버로 유입되는 트래픽은 무시하도록 하겠습니다.

 유입량을 보면 양 그래프 모두다 7시경 부터 유입량이 증가하며 피크는 8시 입니다. 6시 이전의 유입량은 상당히 적으며 당일 당선확정 뉴스가 나간 20시 30분경 이후로 유입량이 상당히 줄어듭니다. 아래 기사는 MK뉴스에서 당일 9:50에 발표한 뉴스 입니다.


 뉴스에서는 06:15분 부터 08:32분 까지 선관위 서버에 장애가 나타났다고 이야기 하고 있습니다. 


 시간대별로 유입량(피크 기준)을 보면.

  1. [00:00 ~ 06:00] 무의미할 정도의 적은 양만이 유입되고 있습니다.
  2. [06:00 ~ 07:00] KT로 1G 가량의 트래픽이 유입됩니다. Dacom은 200M 이하의 유입을 보입니다.(합산 1.2G 정도의 트래픽으로 DDoS공격+ 일반트래픽량 입니다. 2G 공격은 보이지 않으며, 공격이 있었다 하더라도 몸풀기 수준일 것으로 예상됩니다)
  3. [07:00 ~ 08:00] KT로 4G->6G Dacom으로 1G->2G 의 트래픽이 유입됩니다. 합산하면 5G->8G의 트래픽이 유입됨을 알 수 있습니다.(선관위가 발표한 11G의 유입은 없었던 것으로 보입니다)
  4. [08:00 ~ 09:00] 양쪽 그래프 모두 30분 경까지 급속도로 유입이 줄어들다 09:00경  KT는 1G, Dacom은 2G의 유입을 보입니다.
  5. [09:00~ ] KT는 1G대 Dacom은 2G 이하(합산 평균 3G)의 유입을 꾸준히 유지 합니다.

위 상황을 종합하여 보면 선관위 서버 장애가 발생할 수 있는 시간대는 07:00 ~ 08:30 이며 06:00 ~ 07:00 사이에는 장애가 발생할 확률이 낮다는 것을 알 수 있습니다. 다음은 제보를 통한 사건의 분석을 해 보겠습니다.



위 트윗 내용은 제가 트위터를 통하여 선관위서비스의 장애를 수집한 내용 입니다.

 먼저 그동안의 제보요청을 꾸준히 리트윗 해 주신 모든 분들께 이번글을 빌어 감사의 뜻을 전합니다. 이글이 포스팅 된 후에도 제보는 꾸준히 받을 생각이며 제보를 하실 분들은 @iMaZiNe80 으로 멘션 주시기 바랍니다.

 제보를 주신 분들의 장애증상을 분석해 본 결과 시간대별 장애증상이 다르게 나타나고 있음을 알 수 있었습니다. 증상과 시간대는 크게 2가지로 나뉠 수 있습니다.(멘션 내용의 공개는 조금 더 심사숙고 후 결정하도록 하겠습니다)

  1. [06:00 ~ 07:40] 선관위 메인 페이지(www.nec.go.kr, m.nec.go.kr)투표소 찾기 페이지(info.nec.go.kr, minfo.nec.go.kr)까지는 정상적으로 접근이 가능했으나 검색결과 페이지가 나오지 않음.
  2. [07:40 ~ 09:00] 선관위 메인 페이지 접속시에도 장애를 격었으며 투표소 찾기 페이지 접근 도 어려웠음. 
  3. 위 증상은 일반접속과 모바일 접속에서도 동일하게 나타남.

 Chapter1에서 언급했던대로 선관위의 서버는 서브도메인 별로 독립적으로 구성되어 있습니다. DDoS가 특정 페이지를 공격했다는 경찰의 발표에 따르면 www, info, m, minfo 4가지의 서버(군)중 하나만이 영향권에 있다 할 수 있습니다. (만약 4개의 서버 모두를 공격했다면 Chapter2 에서 다루었던 공격의 효율성 자체가 소멸되어 버립니다) 또한 DDoS가 성공적으로 서버를 공격했다 할지라도 나머지 3개의 서버는 정상적인 서비스를 하고 있어야 합니다. 하지만 제보를 바탕으로 보면 선관위 서버는 2개의 서버(군)[info.nec.go.kr, minfo.nec.go.kr]이 같은 증상(검색 결과 페이지가 나오지 않음)을 보입니다.


 7시 40분 이후의 접속장애 증상은 MRTG를 기준으로 보았을 때 정상적인 접속 폭주에 의한 서비스 장애일 것으로 보입니다. 대부분 메인 페이지를 기준으로 나타나며 증상으로는 접속이 불가 하거나, 느리거나, 늦게라도 접속이 가능했다 입니다. 물론 접속후 검색 결과 페이지는 나오지 않습니다.


DDoS 공격이 아닌 정상적인 유입은 4가지로 나눌 수 있습니다.
  1. www.nec.go.kr로 접속 -> 팝업링크를 따라 info.nec.go.kr의 검색페이지로 이동.
  2. 다른 블로그나 뉴스의 링크를 따라 info.nec.go.kr의 검색페이지로 바로 접속.
  3. 모바일 기기를 통해 m.nec.go.kr로 접속 -> minfo.nec.go.kr의 검색페이지로 이동.
  4. 트위터나 뉴스의 모바일 링크를 통해 minfo.nec.go.kr 의 검색페이지로 이동.

 종합해 보면 Database의 무력화 나 검색결과 페이지의 오류/부재 가 아닐경우 위 증상(2대의 서버군에 동일증상)이 일어나기 힘듬을 알 수 있으며 가능성 또한 0%에 수렴합니다. 전문가분들 중에 DDoS를 통해 JDBC 의 DB Connection Pool 초과로 DB Blind 상태가 되었을 수도 있다는 의견을 제시하십니다. 하지만 이러한 증상 또한 Chapter2의 내용에 근거하여 하나의 서버(군)에서만 일어날 수 있으며 트래픽 발생이 시작되는 6시부터 증상이 발생하기는 힘들 것으로 보입니다. DB Connection Pool 이 있었다 함은 WAS(JEUS등)를 사용했거나 DB가 Oracle 이라는 이야기도 됩니다. 이는 하단의 DDoS로 DB를 무력화 시킬 수 있는 가능성을 많이 낮추어 줍니다.
  그렇다면 DDoS로 Database가 무력화 될 가능성을 볼 필요가 있습니다. 먼저 이번 선거에서만 유일하게 투표소 조회에서 주민등록 번호와 이름을 입력받았다는 사실을 알 수 있었습니다. 기존의 시/도, 구/군, 읍/면/동의 입력 방식에서 주민등록 번호와 이름의 Unique한 값이 질의(Query)에 들어가게 되면 일단 DB단이나 WAS에서의 Caching은 힘들어 지며 Heavy Query를 만들어 낼 것 같은 착각을 불러 일으킬 수 있습니다. 하지만 주민등록번호 와 같은 Unique한 INT값은 Primary Key로 사용이 가능하며 Index를 탈 수 있는 최적의 조건을 만들어 줍니다. 또한 DATA의 구성상 주민등록 번호는 이름과 주소지를 내포하고 있음으로 필요없는 중복값을 입력받았을 뿐 그 어떠한 Heavy Query도 생성할 수 없음을 알 수 있습니다. 오히려 주소지별로 구성된 Table을 검색하기 위한 주소지 입력 값이거나. 주민등록 번호의 검증을 위한 이름을 입력받았을 확률이 더욱 높습니다. 게다가 매 공격마다 주민등록 번호와 이름을 생성해야 하며 대부분의 웹프로그래머 들은 DB에 질의를 던지기 전에 주민등록번호의 유효성을 확인합니다. 결론적으로 200대의 좀비+일반접속(6시 대의 적은 양 [MRTG참조]) 으로 DB를 무력화 시키는 상당히 힘든 일이 됩니다.
 검색페이지의 폴다운 메뉴나 프론트페이지의 공지사항이 멀쩡히 보였다는 상황 또한 Database의 정상 작동을 뒷받침해 줄 수 있는 증거가 될 수 있습니다.


 이제 남은 가능성은 검색결과 페이지의 오류(또는 부재)입니다. 지금까지의 모든 상황을 종합해 볼 때 가장 높은 가능성을 보이며 DDoS 공격으로는 일어날 수 없는 상황입니다. 마지막으로 열어놓을 수 있는 가능성이 있다면 info와 minfo 두개의 서버(군) 또는 Database 서버군에 해커가 침입하거나, 접근 가능한 사람이 결과 페이지를 변경 또는 삭제 하거나, Database 에서 조회해야 하는 table의 이름을 바꾸거나 삭제하는것 입니다.







Chapter 4. 쉬운설명

 위 챕터들을 최대한 이해하기 쉽도록 재구성 합니다. 이번 챕터는 기술적 내용을 배제함으로 논리적 반론을 받지 않겠습니다. 먼저 그림을 보시겠습니다.(이번에도 포토샵에서 발로 만들었음을 미리 알려드립니다)


노란색은 웹서버, 연두색은 DB서버 입니다. 
DATA는 창고라고 보시면 이해가 편합니다.

DATA안에 있는 DB서버라는 녀석들은 웹서버 말고는 접근이 불가능합니다. 간혹 가능한 경우가 있는데 미션임파서블에 나오는 특수요원쯤 되는 해커라는 녀석이 나타나야 가능합니다.

 자 여기 선관위라는 회사가 있습니다. 일반적인 구성일 경우 노란 녀석들은 모든 업무처리가 가능합니다. 하지만 선관위는 www와 m이 안내역할을 하고 info와 minfo가 투표소 조회 업무를 합니다. m과 minfo는 모바일로 들어오는 고객만을 받습니다.

 경쟁 회사에서 DDoS라는 고객을 위장한 악당을 선관위에 투입합니다. 하지만 선관위는 4명의 직원이 모두 다른 업무를 함으로 괴롭힐 수 있는 직원이 1명 뿐입니다. 경찰발표에 따르면 5시50분 부터 괴롭힘이 시작 되었고 info라는 직원이 몰빵을 당했다고 합니다.

 그런데 info와 minfo 두녀석 모두 자신의 업무를 똑바로 하지 않습니다. 고객의 투표소위치자료 요청을 모르쇠로 일관합니다. 괴롭힘을 받은 직원은 분명히 1명 입니다. 또한 CCTV를 조사해 본 결과 6시 부터 7시 사이에는 DDoS를 포함한 정상적 고객이 그리 많이 오지도 않았습니다.(고객이 몰려온 시간은 7시 45분 이후 입니다)

 고객들의 불만 내용을 수집해 봅니다. 고객들은 6시부터 7시 사이에도 info와 minfo모두 투표소 위치자료를 내놓지 않았다고 합니다. 8시이후 고객들은 4명의 직원이 모두 업무를 할 수 없을 정도로 지쳐 있었고 투표소 위치자료 또한 받지 못했다고합니다.

 위 사건이 일어날 가능성은 몇가지로 압축이 됩니다. info와 minfo가 DB서버라는 직원이 준 자료를 무시했던지, 아니면 애초에 요청을 하지 않았던지, 그것또한 아니라면 DB서버직원 중 투표소 위치자료를 관리하는 직원이 돌연 휴가를 가던가 투표소 위치자료 자체가 증발해야 합니다. 혹은 해커라는 녀석이 원거리 사격으로 DB서버를 저격해서 죽였어야 합니다.

 하지만 경찰은 계속 info가 집단괴롭힘을 받아 일어난 일이라고 하고 DDoS라는 녀석만 잡아갑니다. 고객들은 경찰의 발표를 이해할 수 없다고 하지만 경찰또한 모르쇠로 일관합니다.






Chapter 5. 개인적 소견 및 예상반응

 상위 챕터의 기술적 분석을 토대로 개인적인 소견을 발표하겠습니다. 100% 개인적인 소견임으로 그 어떠한 태클도 사양하며 책임이 많은 순으로 나열합니다. 




90%의 책임1 - 선거관리위원회 입니다. 
  1. 글의 서두에서도 말씀드렸지만 선관위의 서버는 그 어떠한 통신적 지연 및 손실에도 정확한 정보를 수집 및 제공할 수 있는 시스템을 운영해야 합니다. 그렇지 못할 경우 투표결과 와 선거 자체의 공신력을 회손하게 됩니다. 그럼에도 불구하고 방만한 서버관리와 운영으로 2G의 DDoS공격에도 서버에 장애가 발생했다고 자랑스럽게 말하고 있습니다. 또한 그 공격 자체의 의구심을 풀어낼 어떠한 증거도 제시하지 않고 있습니다. (내부관련자나 해킹없이 이번 현상이 나타날 수 있음을 기술적으로 증명해야 합니다.)
  2. 위 현상들을 기준으로 보면 대략 4G이상의 트래픽에서 장애가 발생하는 서버의 구성 입니다. 보궐선거에서 이정도의 트래픽이 발생했다면 총선이나 대선같은 전국구 선거에서는 몇배 이상의 트래픽이 발생할 수 있음은 자명한 일입니다. 이에 따른 서버의 대비책을 말하기는 커녕 "우리는 피해자 입니다" 라고 뒷짐을 지고 있습니다.
  3. 경찰 발표에 따르면 선거관리위원회가 공격을 인지한 시점은 5시 50분 입니다. 작은규모의 사이트라도 운영해본 분이라면 알 수 있겠지만 서버에 문제가 발생하였을 경우 가장 먼저 찾게되는 것은 "사이트 개발자"와 "서버 관리자" 이며 선거당일 이라는 비상 사태에 대비하여 모니터링을 하고 있어야 함은 당연한 상황입니다. 그린존 대피의 문제 뿐 아니라 그 어떠한 대처도 가능했어야 하고, 만약의 경우 해킹이 발생했더라도 이 두직분이 존재했다면 대응시간은 30분이 넘지 않았을 것입니다. 또한 제 예상을 뛰어넘는 그 어떠한 서버 설정적 문제점이 발견 된다면 책임을 피해갈 수 없어야 합니다.
  4. 이유없이 투표소를 대거 이동 하였음에도 공지가 허술하여 많은 사람들로 하여금 투표에 지장을 초래하였습니다. 이는 그 어떠한 책임도 피해갈 수 없는 사항이며 선관위의 존재 이유를 부정하는 행위 입니다.


 8%의 책임2 - 대한민국 정부여/야를 막론한 국회의원 입니다.
  1. 앞서 말씀드린대로 현재의 선관위는 방만한 운영으로 공신력을 잃었습니다. 이러한 상태에서 치루어지는 그 어떠한 선거도 공정하게 이루어 질 수 없다는 인식을 하지 못한 채 DDoS에만 매달려 있습니다. 이번 사건에서 가장 중요한 부분은 DDoS 범인이 아니라 선관위의 상태 입니다.
  2. 특검이 모든것을 해결할 수 있다는 생각을 한다면 큰 오산입니다. 제가 보아온 지금까지  특검은 면죄부를 배포하는 일 이외의 그 어떠한 업적도 남긴 사례가 없었습니다.
  3. 선관위 서버는 당신들의 웃는 얼굴이나 대문짝 만하게 나오고 접속자도 가뭄에 콩나듯 들어오는 개인 홈페이지가 아니라는 것을 인식하지 못했다는 점입니다. 돈주고 하청주면 해결된다는 생각부터 뜯어고치지 않으면 이 문제의 해답은 영원히 보이지 않을 것 입니다.
  4. 기술적,인문적 전문가가 배양될 수 없는 토양을 만들어준 대가 이기도 합니다. 그러한 전문가들이야 말로 사람이 자원인 대한민국의 기둥이라는 사실을 인지하지 않으면 이러한 사태는 반복될 뿐입니다.  


1%의 책임3 - 누가 시켰는지 확실치는 않지만 DDoS공격을 한 사람들 입니다. 뭐 국가기관을 상대로 범죄를 저질렀으니 죄를 부정할 수는 없습니다.


1%의 책임4 - 저를 포함한 이 글을 읽고있는 여러분 입니다.
  1. 지지난 서울시장 선거때도 서울 시내에서 5시간 이상을 돌아 개표소에 도착한 투표함에 대하여 어떠한 반응을 보였었나요?
  2. 나꼼수 여의도 공연에는 "그리드 측정법"을 기준으로 10만여 명이 모였습니다. 그 이후의 어떠한 집회 현장에서도 그만한 인원을 볼 수는 없었습니다.(물론 저도 모두 나가지는 않았습니다)



이 글이 기술적으로 틀리지 않았을 때의 예상 반응입니다.(웃자고 하는 이야기 입니다) 기술적으로 문제가 있다면 댓글을 통해 해결이 될 것입니다. 웃자고 하는 이야기에 죽자고 달려들지는 않아 주었으면 합니다.

  1. 검찰이 갑자기 숨겨진 해커를 찾아냅니다.(하지만 해킹공격은 30분 내에 해결 가능하다 말씀 드렸습니다)
  2. 갑자기 존재하지도 않았던 이상한 MRTG나 로그가 공개됩니다.(이미 했었어야 하지만 이후에 공개되는 자료의 신빙성은 어찌하실런지...)
  3. 알바를 동원해 댓글을 쓰레기 장으로 만듭니다.(그래서 기술적 논의 외의 댓글은 전부 삭제 하겠다 서두에 밝혔습니다)
  4. 이도저도 안되면 글 하나 하나의 꼬투리를 잡아, 여러가지 이유로 잡아갑니다(저는 할일이 많기 때문에 잡혀가기 싫습니다, 뭐 잘못한게 있어야 잡혀가던지..., 저는 그러한 삶을 살아오지 않았습니다!!)
  5. 아니라면 바로 이 화면을 보시게 될 것입니다.




그럼으로 이번 포스팅은 원작자(출처)를 기재하는 한 그 어떠한 캡춰나 불펌을 마구 허용합니다.







Chapter 6. 이글의 목적과 바램 


 이 글을 통해 그 어떠한 부귀영화를 원하지 않습니다. 그저 믿을 수 있는 상태에서 나의 한표를 행사하고 싶을 뿐입니다. 객관적인 선에서 제시할 수 있는 모든 의문이 풀린다면 제가 많은 시간을 투자하여 이러한 글을 써야할 이유나 근거도 없어집니다. 아마 저를 포함한 많은 분들이 저와 같은 생각을 하시리라 생각합니다. 이 글을 읽으시는 모든 분들께 하고싶은 말은 "제발 부탁이니 선관위를 믿을 수 있는 상태로 만들어 주세요" 입니다. 이것이 이글의 목적이고 바램입니다.

개인적인 바램을 더하자면 이 블로그의 주제에 맞는 제 이념과, 그 이념을 사진으로 풀어 나가는 이야기를 포스팅 하고 싶습니다. 이후의 블로깅 내용중에 이번 사건과 관련한 그 어떠한 글도 다시 포스팅 하지 않게 되기를 바라는 바입니다.



다시한번 그동안의 제보요청을 꾸준히 리트윗 해 주신 모든 분들께, 이번글을 빌어 감사의 뜻을 전합니다. 이 글이 포스팅된 후에도 제보는 꾸준히 받을 생각이며 제보를 하실 분들은 @iMaZiNe80 으로 멘션주시기 바랍니다.


댓글 27개:

  1. 후륭하십니다 저같은 일반인도 숙지할수 있게 해 주셔서 너무 감사합니다 앞으로도 더 많은 정보 들려 주세요 꾸벅!!

    답글삭제
  2. 수고 하셨습니다,
    잘 앍고 갑니다,

    답글삭제
  3. 한틀, 봤냐? 이런게 리포트다.

    답글삭제
  4. 대단하시네요.. 이런 기술적인글을 보고싶었던 1인 입니다. 갑사히 잘 보고 갑니다.

    답글삭제
    답글
    1. 제가 아는 그 매버릭님 맞나요? 읽어주셔서 감사합니다.

      삭제
  5. 잘 읽었습니다. 수고가 많으십니다. 다음에도 좋은 정보와 글 기대하겠습니다.

    답글삭제
  6. 여러 반박 좀 해보겠습니다. 1번의 선관위 서버 구성도와 4번의 선관위 서버 구성도가 다르구요. 차라리 4번의 윗쪽 구성도가 1번하고 맞는거 같은데요?

    그리고 DDos로 DB 무력화 시키는 것도 가능합니다. DB 요청 보내는 페이지에 지속적인 요청을 보내면 캐싱이 안 되어 있다면 웹서버가 먼저 죽을수도 있고 웹서버의 요청에 비례하게 요청을 받는 DB서버가 죽을 수도 있는건데 사실 처리하는건 DB쪽이 훨씬 많잖아요 DB는 수 많은 요청에도 무적일거라 생각하고 쓴 글이신지요

    그로인해 DB서버가 죽었다면 info, minfo 모두에서 같은 db서버를 사용할거라 말씀하셨고 그럴거기 때문에 둘다에서 안 나오는게 가능합니다

    2Gbps의 요청도 2G bits per second입니다. 그럼 초당 250MB/s의 요청인데 1대당 초당 1.25MB/s 의 요청이 불가능한가요? HTTP / Torrent 도 다 TCP로 작동 되는 것인데요

    Torrent 는 TCP를 사용한다고 봤지만 전송부분은 UDP를 사용하는지 잘 모르겠네요 하지만 HTTP는 TCP를 사용하는데 업 다운 다 5메가 이상 뜨는걸 봤네요

    위에건 삭제하고 '1대당' 이란 말을 추가했습니다.

    답글삭제
  7. DB만 죽이는 방법이 DB를 직접 공격하는 것만 생각하신 것 같은데 DB를 직접 공격 안하고 웹 서버 거쳐서 많은 요청을 보내면 DB가 죽죠

    답글삭제
  8. Heavy Query가 없다고 서비스가 무조건 지속이 잘 된다면 누가 서버를 증설하나요? 일반적인 Query 요청이 많아도 다운 될 수 있을 것이고요

    또 프로그래머가 1번 요청시 이전 이름과 주민등록번호를 무시하는 로직을 짜지 않는 한 매번 요청마다 새로운 이름과 주민등록번호를 생성할 필요도 없을 거구요.. 일반 사용자가 1번만 조회 할 수 있다는건 말이 안되지 않습니까

    그리고 메인 공지사항, 메뉴부분을 캐싱 하고 투표소 조회 페이지에서만 캐싱을 안 했다면 공지와 메뉴가 나오는 것도 가능합니다.

    답글삭제
  9. 위에서 메인 공지사항, 메뉴부분 캐싱은 웹서버에서 캐싱을 말한 겁니다

    답글삭제
  10. 다른 글에서 본건데 투개표망하고 홈페이지망은 분명히 분리되있을겁니다.

    "솔직히 이정도 상태라면 어떻게 답변을 드려야 할지...
    2개 이상의 망을 분리해 하나의 서비스로 연계할 수 있는 기술력의 선관위 서버가 2Gb의 DDoS 공격에 맹렬히 싸우다 DB 서버만 장렬히 전사하는 웃지 못할 참사가 벌어진 겁니다. 제 상상력의 한계는 이미 넘어가셨다고 볼 수 있습니다."

    같다고 생각하시냐는 질문에 이런 답변은 본인이 동문서답 하신 것 같네요.

    답글삭제
    답글
    1. 자..,. 승호님

      Chapter4의 서버구성도는 일반인의 이해를 위해 쉽게 풀어쓴 것임으로 논쟁에서 제외한다 기술하였습니다. Logic기준으로 다르지 않습니다.

      대당 1.25MB(12.5Mbps)의 http request를(송출 아닙니다) 정상으로 보시나요?
      Chapter2를 한번 더 읽어보세요.

      주민번호의 유효성을 검증한다 하였습니다. 생성하여야 하는것은 올바른 주민번호 입니다. DDoS툴에 주민번호 생성하는 로직이 있을지는 의문입니다.
      같은 번호의 무한반복을 초당 1.2MB HTTP Request... 정상 신호로 보여지기 어렵구요.

      Chapter3를 다시 읽어보시길 권합니다. 트래픽이 발생하는 시점부터 서비스가 불가능 했습니다. DDoS의 눈빛만으로 DB가 죽어야 합니다. DB가 죽으면 캐싱도 의미가 없습니다. Connection 자체가 없으니까요.

      다른글의 의문점 까지 들고 오셨는데 망을 분리 한다는 말이 라우터 하단에 있는 연결이 2개다 라는 말로 이해하신다면 설명드리기가 힘들 것 같습니다. 2개 이상의 망을 가지고 한가지의 서비스 한다면 어떠한 기술이 필요할지 생각해 보시기 바랍니다.

      Chapter 1,2,3은 독립된 기술이 아닙니다. 연계하여 보셔야 이해가 쉽습니다.

      이런 의문이 나타날 수 있다는건 제 글실력이 부족해서라고 생각하겠습니다.
      글에 있는 내용을 다시 물어보셔야 할 정도로 제 글이 난해한 점 양해 부탁드립니다.

      삭제
    2. 올바로 대답해 드렸나 다시 보니 웹서버단의 캐싱이라는 부분이 있네요.
      웹서버단 캐싱 로직은 DB부하를 줄이기 위해 일정시간동안 조회를 하지 않도록 XML 이나 JSON 상태로 캐싱하는 방법을 주로 사용합니다. 폴다운메뉴는 Cache Refresh를 하지 않아도 상관없으나 공지사항의 경우 유효 시간이 정해져 있을 것입니다. Cache라는게 Permanent면 하드코딩과 다를게 없으니까요.
      수집된 장애증상 에서는 설명하신 증상이 발견되지 앟았습니다.

      삭제
  11. 4번은 논쟁 제외라 하셨지만, 글에도 적혀있고 모르시는 분들은 4번만 볼거라 썼구요 www - db, info - db, m - db, minfo - db 이렇게 되야 맞는거 아닌가요?

    DDos 방어장비가 그렇게 완벽하고 설정만으로 다 막을 수 있다면 DDos에 당하는 일들이 없어야 할텐데요 지금도 DDos는 널리 쓰이고 있지요?

    단순히 DDos툴을 이용할 것이었으면 좀피 pc를 대당 1천원인가에 저렴하게 판다는 걸 봤는데 궂이 200대의 컴퓨터를 직접 구해서 이용할 필요가 없었을 거구요(비용이 많이 드니까)

    그렇다면 200대에 직접 만든 DDos 프로그램을 넣어서 작동 시켰다고 볼수 있는데 그럼 주민등록번호 생성 로직이 전혀 어려운 로직도 아니고 구글에 치기만 하면 나오는거니 충분히 넣을 수 있습니다.

    캐싱은 웹서버 단에서의 캐싱을 말씀 드린 이유가 DB서버로 쿼리 보내는 것도 외부로의 통신이 필요하니 웹서버에서 캐싱을 했다면 DB가 죽어도 웹서버에서는 그대로 보여줄 수 있을 거구요.

    망 분리는 아무리 DB에서 캐싱이 있다해도 개표를 직접 웹과 연결된 DB에서 하고나서 캐싱을 통해서 요청에 응답하는게 아닐겁니다. 내부망에서 처리 한 후 결과값을 웹서버의 DB에 넣고 보여주겠지요. 위험하기도하고

    잘 이해 못한 부분이 있다면 답 부탁드립니다.

    답글삭제
    답글
    1. 1번의 서버구성도 보시면 물리적 구성이지요?
      4번의 그림은 챕터들 내용을 종합한 논리적 구성이지요?
      연결은 다 되어 있어도 역할이 있다는 건 아실거고 제 글의 논점이 무었인지 다시한번 천천히 보기실 권해 드립니다.

      OSI7 Layer와 Firewall/DDoS Defender/L4/L7 스위치의 기능과 역할에 대해서 생각해 보시길 권합니다. DDoS를 모두 막아냈다 가 아니구요. TCP 공격 이외의 공격 유입은 가능성이 없다 입니다.

      말씀하신대로 캐싱유무와 캐싱시간 자체를 알 수 없습니다. 따라서 그 증상은 증거 중 하나가 될 수 있다고 글에 써 놨습니다.

      경찰이 발표한 DDoS 공격툴은 이미 많이 공개되어 있지요? 자체제작 아닙니다.

      일부분을 문의 하시기 위하여 전체논지를 잃는 경향이 있습니다. 제가 제시하는 이야기는 나무위의 새가 아니라 숲을 보시라는 것 입니다.

      삭제
  12. 아 쓰는 중에 답 주셨네요. 우리가 공지사항의 캐싱 시간을 알 수 없으니 말할 수 없는데 서버가 1대거나 MEMCACHED 같은 것을 사용한다면 저는 글 올라갈 때마다 캐시를 업데이트 하거든요.

    06:00 ~ 07:40 동안 공지사항 같은 게시판 DB에 접속해보신 분이 있는지 궁금하네요

    답글삭제
  13. 제가 기본적인 것도 자세히 알아보지 않고 적었네요 다시 읽어보겠습니다.

    답글삭제
  14. 이런것이 국민이 바라는 검찰의 수사보고인것을.....
    국민으로서 국민을위해 이론분들이 많아야 합니다.
    정보 감사합니다.
    많이 공유 하겠습니다.

    답글삭제
  15. 읽어주신 모든 분들께 감사를 드립니다.
    가능하면 많은 의견을 듣고 싶습니다.
    주변 분들께도 소개 부탁 드릴께요 ^^

    답글삭제
  16. 딴지에 올라온 글 보고 거기 리플 달았는데요... 이제 보니 -_-;; 블로그가 있어서 다시 여기에 댓글 남깁니다.

    IT, 그 중에서도 웹 쪽으로 밥 먹은지 대충 5년 정도 되어가는 사람 입니다. 일견 이해가 안가는 부분들이 있어서 얕은 지식이나마 잠시 들이대볼까하고 댓글 남깁니다. 다만 저 역시 내부 공모자론에 무게를 두고 사태를 보고 있고요.. 정부 여당이나 선관위를 옹호하자는 건 아니라는 점 먼저 밝히고 싶습니다. 철저히 엔지니어의 입장에서, 선관위 서버 다운 사태의 트러블 슈팅이라는 관점에서 제 논리를 풀어 보겠습니다.

    일단 도메인 별로, 혹은 어플리케이션 목적별로 서버 군을 분리해서 해당 도메인 내부에서 로드 밸런싱 시키는건 적어도 제가 본 세상에서는 일반적인 일이었습니다. 해킹 시도나 malware, 기타 서비스 다운 현상들의 isolation을 위해 도메인 별로 서버를 분리합니다. 본문 내의 지적대로 일반적이지 않은 구성, 비효율적인 구성은 아니라는 얘기를 먼저 하고 싶습니다. DB 서버 역시 분리된 도메인 별로 다를 가능성이 높습니다. 제가 요새 운영하고 있는 시스템은 웹 서버 10기가 3개 도메인으로 분리 되어 있고, DB 서버 6기가 Active-Passive 구성으로 클러스터링 되어 총 3쌍 있습니다. 물론 그 안에 실행되고 있는 인스턴스는 더더욱 많지요.

    각설하고, 현재 중점은 내부 공모자에 의한 DB Connection 오류냐, DDoS 피해에 의한 정상적인(?) 오류냐인 것 같습니다. 내부 공모자가 connection string을 조작하거나 DB연결 계정을 바꿔치기 했다면 모든게 설명된다! 는 의견입니다만.. ^^; 트러블 슈팅 관점에서 제가 중요하게 생각하는 부분을 언급해보겠습니다. info.nec.go.kr과 minfo.nec.go.kr은 서버군이 다를지언정, 사용하는 DB는 동일할 가능성이 높습니다. 공격이 info.nec.go.kr을 향해 이루어졌다면, 또 그로 인해 DB 서버가 다운되었다면, minfo.nec.go.kr 역시 투표소 찾기 서비스는 정상적으로 이루어지지 않았을거라는 겁니다. 여기까지는 동의하시죠?

    본문에서는 헤비 쿼리의 가능성을 부정하셨는데, 저는 그렇게 생각치는 않습니다. 저 역시 텅텅 빈 머리를 자랑하듯이-_- 개떡 같은 테이블 디자인과 sp를 남발했던 경험이 있는 사람으로서... 정말 단순한 select 문도 헤비 쿼리일 수 있다는 쪽에 무게를 두고 생각하는게 옳다고 하겠습니다. 주민번호 생성, 유효성 검사 방법을 안다면 껌이죠 뭐.. 적어도 DB까지 쿼리가 날아가도록 script를 작성할 수는 있다는 겁니다. 어쨌든 헤비 쿼리는 투표소 찾기를 위한 쿼리 뿐 아니라, info.nec.go.kr에서 서비스 하고 있는 모든 페이서 사용되고 있는 모든 쿼리가 의심의 대상 입니다.

    얘기를 잠시 돌려서 네트웍 구성쪽을 보면, 일반적으로 NIC를 teaming 시켜서 1Gx2 정도로 서비스하게 되죠..이건 웹 서버나 DB 서버 모두 마찬가지일거고요, Web-DB 간에 10G 구성 시키는 일은 흔치 않을 거라고 봅니다. 즉 2G 정도의 트래픽이 발생하면 이후 리퀘스트들이 큐잉되면서 서비스 불가 상태에 빠질 수 있는 가능성이 있다는 얘깁니다. 다만 본문의 MRTG 자료로는 확실치 않고요.. 또 이건 지적하신 대로 웹 서버가 뻗었다는 증거만 되지 DB 서버가 뻗었다는 증거가 되지는 못합니다. 저는 info/minfo 웹 서버와 DB 서버간의 네트웍 트래픽을 볼 필요가 있다고 생각합니다. 이건 IDC (KT인가요?) 를 쪼면 가져올 수 있는 자료일텐데요.. 여기에 2G 이상의 트래픽이 발생한 기록이 보인다면 다수의 쿼리, 혹은 헤비 쿼리를 날려서 DB가 바빠지고, DB에서 더 이상의 connection을 거부하면서 DB-Web 서버간 통신이 어려워져서 시스템 다운이 일어났다고 생각할 수도 있습니다. 이 현상은 웹 서버에도 영향을 미칠 수 있습니다. DB 쿼리 리턴값을 기다리다가 HTTP Timeout이 나기도 합니다.

    여기에 한발 더 나아가서(옆으로 가는 건가요? ㅋ 아 봉도사님..) 투표소 찾기에 사용되는 DB 인스턴스가 다른 서비스에 이용되는 DB 인스턴스와 같은 클러스터 내에 존재했다면, 다른 서비스에 이용되는 인스턴스 역시 서비스 불가 상태에 빠졌을 것이다, 라고 생각합니다.

    다시 한번 말씀드리지만 내부자 공모다 라고 하면 손 쉬워지는 상황을 -_-;; 굳이 어렵게 풀고 싶지는 않습니다. 다만 현재 서버 구성도나 세팅이 알려지지 않는 상황에서, 가정과 가설로 사다리를 쌓다보면 이런 현상도 불가능한 것만은 아니라는 걸 말하고 싶었고요.. 트러블 슈팅의 관점에서 보면 아래와 같은 것들을 조사해봐야 공격으로 인한 다운인지 아닌지 확실한 결론이 나올 것으로 봅니다. 그 전까지 이뤄지는 추측들은... 이렇게 말하자면 아쉽지만 자료 부족으로 인해 모두 의미 없는 것들이겠죠.

    1. Web-DB 서버간 해당 시간대 traffic 양
    2. DB 서버 구성도
    3. Web 서버 구성도
    4. DB / Web 서버 네트웍 구성
    5. Web 서버 HTTP Session 수
    6. DB 서버 profiling을 통한 heavy query 색출 -_-;;
    7. DB Connection Pool 설정
    8. DB 서버 max connection 수

    긴 글 읽어주셔서 감사합니다. 부디 우리의 심증을 굳혀주는 결정적인 증거가 나오길 바라마지 않으면서, 이만 줄입니다. 새해 복 많이 받고 행복하시길..

    답글삭제
    답글
    1. 장문의 질문을 주셨네요. 순서별로 답변을 드리겠습니다.

      일반적으로 해당 서브도메인별 독립구성(하단 로드벨런싱)은 흔한 구성이 맞습니다. 하지만 각 서브도메인의 기능적 부분을 보시면 나누어야 할 목적 자체가 없습니다. 특정 공격으로 부터 방어를 위한 구성이였다면 아마 다르게 구성하였을 것입니다.

      DDoS로 DB Connection Pool을 오버시켜 Blind 상태로 만들수는 있습니다. 하지만 Chapter2의 내용을 다시 보시면 DDoS 자체에 의미가 없습니다. 위에서 말씀하신 상황이 연출되려면 DDoS공격의 효율성 부터 보장되어야 합니다. (2G를 충족할 수도 없을뿐더러 모든 Request가 DB로 들어가지도 않습니다) 심지어 대충만든 쿼리의 경우라도 299대(검찰발표)로 DB를 다운시킬 가능성은 없습니다. (아마 그랬다면 이후 시간대에도 문제가 발생했어야 합니다)
      게다가 유효한 주민번호를 생성하며 진행하는 공격까지 한다면 공격량 이라는 단어 자체의 의미가 없어집니다.

      서버구성도는 제시할 수 있는 최소한의 구성을 그려놓은 것 입니다. Route Tracing을 한번 해보시길 권해 드립니다.(물론 몇개의 Firewall을 만나실 수 있습니다) 그리고 Chapter3의 시간대별 증상을 다시 보시길 바랍니다.

      1. Pubnet 유입량 만으로도 설명이 가능합니다.
      2. Oracle 제품입니다.
      3. 하단 로드벨런싱이 아예 없다고 봐도 증상설명 되지 않습니다.
      4. 그냥 IP to IP (1 NIC) 로 봐도 증상설명 안됩니다.
      5. 시간대별 증상을 보시면 의미 없습니다.
      6.7.8. 헤비쿼리나 DB세팅으로 인한 증상이면 위에 말씀드린대로 이후 시간대도 서비스 불가입니다.
      (그린존으로 간다고 헤비쿼리가 가벼워 지거나 세팅이 변하지는 않습니다)


      이글을 포스팅 한 이후로 더 많은 정보와 제보를 모을 수 있었습니다. 자료의 출처상 공개하지 못하는 부분도 있습니다. 앞서 말씀드린대로 서버 구성의 경우 최소한을 보여드린 것 입니다. 저 구성에서도 벌어지기 힘든 일이라면 더 큰 구성에서는 일어나지도 않습니다.


      P.S. 다른 펌글에 기술적 질문을 하시면 제가 전부 답해드릴 수도 없을 뿐더러 비종사자 분들의 오해를 불러일으킬 수도 있습니다.

      삭제
    2. 아 딴지에는 처음에 순수 딴지 기사인줄 알고 달았었습니다 ㅋ 삭제하는 방법을 모르겠더군요.. @.@

      비종사자분들의 오해를 불러일으킬 수 있다는 얘기에는 공감합니다만 그렇다고 논의를 안할수는 없는 노릇 아니겠습니까^^; 어쨌거나 이미 답글을 달아주신지 5일이나 지나버렸네요.. 늦은 관심을 민망하게 생각하면서;; 이만 줄입니다. 행복하시길 ^^

      삭제