[10.26부정선거 폭로] 선관위의 자살골을 공개합니다.
댓글
0조회
819추천
0
[10.26부정선거 폭로] 선관위의 자살골을 공개합니다.
출처 : http://ideaphotographer.blogspot.com/
김기창 교수(오픈웹 운동가, 고려대 교수) :
베리(미국에서 근무 중인 시스템 개발자) :
이마진(웹솔루션 개발자) :
선관위의 자살골을 공개합니다.
우선 글을 쓰기에 앞서 다시한번 이런 내용을 포스팅하게 된 점을 슬프게 생각합니다. 이전 포스팅 내용이 너무 난해했기 때문에 이번에는 최대한 짧고, 쉽게 쓰려고 노력을 하겠습니다.다만 제 글실력이 부족한 부분은 양해를 부탁 드립니다.
이번 포스팅은 아래 자료들를 토대로 11인의 전문가 분들과 함께 분석한 내용을 가지고 선관위의 자살골을 소개해 드릴까 합니다.
1. 선관위가 12.01.27일 발표한 공식변명(?) " 10.26. 재·보궐선거 관련 의혹제기에 대한 10문10답 " - [Link]
2. 참여연대의 요청에 의해 선관위가 공개한 LG 엔시스의 분석자료 - [Link]
3. 이전에 포스팅 했던 선관위의 서버구성 중 info, minfo 서버 구성
이 그림은 선관위가 10문10답과 함께 발표한 기술자료 중 선관위의 대응을 시간대별로 이쁘게 설명해 주시는 자료입니다. 여기서 초동 조치로 06:58분에 KT회선을 차단했다는 부분을 눈여겨 봐두시기 바랍니다.
<모든 이미지는 클릭 하시면 확대됩니다>
선관위가 발표한 자료들에 의하면 05:50~08:30분 동안의 UDP/ICMP공격을 받고 대역폭이 소진되어 정상적인 서비스가 불가능했다는 이야기를 합니다. 피해상황 으로는 전체 서비스 장애, 간헐적 서비스 지속 이라고 명시해 놨네요.
자 이상황을 "선관위의 10문 10답"에서는 이렇게 설명을 합니다. 상당히 자상한 설명이 아닐 수 없습니다.
대역폭(Bandwidth)은 여기에서 이야기 하는 도로와 같은 것 입니다. 말그대로 "폭"입니다. 고갈되고 소진되는 것이 아니죠. 만약에 도로가 완전 포화되면 어떻게 되냐구요? 그냥 느려집니다 그러다 장비가 소화할 수 없는 대역폭이 계속 밀려오면 장비는 그냥 죽어버립니다. 이런것을 보통 다운된다 라고 이야기합니다.
KT의 두 회선(155MBps x 2)만 놓고 봤을때 310MB의 도로에 263MB의 트래픽이 발생합니다. 솔직히 이야기 하자면 84.8%의 대역폭 사용에 의해 회선에 속도저하가 발생했다는 말도 믿기는 어렵습니다. 회선 대역폭 이라는 것은 딱 그만큼의 장비(Hardware)를 사용하는 것이 아니라 장비의 처리능력 내에서 ISP(인터넷 서비스 제공자)가 허가해 준 만큼의 대역폭을 사용하는 것이기 때문입니다.
하지만 고의적으로 무식하게 UDP/ICMP를 쏟아부어서 84.8%의 트래픽으로 장애를 발생시켰다고 하니 쿨하게 그냥 그랬다 쳐줍니다. 쌩쌩 달리지 못할 뿐이지 끈기있는 누군가는 목적지에 잘 도착 했다는 결론까지 양보하고 다음 이야기를 진행해 보겠습니다.
간헐적 서비스 지속 부분에 대해 이야기해 봅시다. 자! 누군가는 문제의 시간대에 정상적으로 서버에 접속해 결과물을 가져 왔습니다. 과연 몇명의 사용자가 결과물을 가져왔는지 알아봐야 합니다.
오! 생각보다 많은 사용자가 문제의 시간대에 선거정보 웹서버(info,minfo)에 도착합니다. 합산하면 22,000명이 넘는군요. 한명이 모바일 등으로 여러가지 접속을 했다 치고 반띵해도 1만명 입니다. 그렇다면 정상적인 페이지를 본 사람은 몇명이 있을까요?
합산하면 10만 페이지가 정상 처리 되었다고 합니다. 투표소 조회 결과만 보지못한 사람, 접속 장애를 격어 여러번 페이지를 접속한 사람 다 무시하고 보면 평균적으로 1연결당 5개의 정상 페이지를 보게되고 아주 지극히 정상 서비스를 한 것으로 나타납니다.
위 자료는 선관위에서 사이트가 정상 작동 했다는 증거로 제시한 극소량의 웹서버 로그 입니다. 선관위 사이트 코딩 스타일을 분석해본 결과 구/군 셀렉터 부분은 AJAX방식으로 JSON데이터를 읽어들여 옵니다. 그리고는 입력받은 데이터를 몽땅 다시 자신의 페이지에 POST 방식으로 던져 버립니다. 뭔소리야? 하시는 분들은 무시하셔도 좋습니다. 다만 "GET /bizcommon... xhtml?&searchkey=..." 으로 보이는 부분은 투표소 조회창이 정상적으로 나타난 것이고 "POST /bizcommon...xhtml" 로 보이는 부분은 투표소 조회가 정상적으로 사용자에게 전달된 것입니다. 선관위는 문제의 시간대 06:00~08:00에 약 20,000명의 접속에 100,000개의 페이지를 정상으로 전달했다고 보여집니다.(100,000개 중 POST로 투표소 결과를 전달해준 수치는 알 수 없습니다 로그에서 보아도 미미할 뿐)
물론 위의 자료만 가지고는 제가 수집한 장애 증상들 "404 File Not Found(요청하는 파일이 없음)", "324 Empty_Response - No Data Received(결과값 비어있음)" 에러 및 독립된 minfo(모바일 서비스 서버)의 동일증상들을 선관위가 해명할 수는 없습니다. 하지만 적어도 06:00~07:00 사이에 3367명의 접속자에게 6894개의 페이지를 정상적으로 보여줬다고 선관위가 주장하고 있음을 알 수 있습니다.
그런데!! 선관위는 05:50 ~ 06:58 까지의 UDP공격(ICMP는 소량이었음)때문에 서비스 장애가 발생하였고 이를 방어하기 위해 KT회선을 차단(응?뭑?)했다고 이야기 합니다. 일단 선관위가 발표한 서버구성도를 본후 회선차단이 왜 자살골인지 이야기 해 보도록 하겠습니다.
선관위는 155MBps의 3개의 회선(KT 2개, LG U+ 1개)으로 465MBps의 서비스를 하고 있었습니다. 05:50분 공격을 자체적으로 인지 하였고 공격의 종류를 몰랐을 확률은 0%에 수렴합니다. 이유는 DDoS 장비는 기본적으로 공격 레포트를 서버 관리자에게 알리도록 설정되어 있기 때문이죠.(안 알려줘도 서버 관리자라면 장애분석부터 하는게 당연합니다. 여기에 1시간이 걸렸다면 그나마 이해를 좀 해보겠습니다)
자! 서버 관리자가 문제를 풀어야 한다는 생각이 있다면 KT와 LG U+에 전화한통 때리는 것으로 상황은 종료됩니다. 어떻게 하냐구요? 하단에 명제로 정리해 보도록 하죠.
- DDoS 공격에 의해 회선 대역폭 문제로 서비스에 장애가 발생했다.
- 디도스의 종류는 UDP/ICMP다.
- 현재 서버는 1시간동안 3367명에게 6894개의 페이지를 정상적으로 전달했다.
- 나는 서버관리자다.
The 서버관리자 to ISP : "여보세요? 아 예 저희 선관위 회선으로 다량의 UDP와 ICMP 공격이 들어와 문제가 생겼습니다. 일단 공격을 차단해 주시구요. 저희 회선 대역폭좀 늘려주세요. 네 감사합니다."
상 황 종 료 !!
참 쉽죠? 그래요 별거 아니에요. 이런 상황에 판단 착오나 실수가 일어날 확률은 파리가 새가 될 확률보다 적습니다. 그럼에도 불구하고 선관위가 선택한 방법은? "KT회선차단" 입니다. KT회선을 차단해 버리면 전체 465MBps의 대역폭 중 155MBps의 서비스 만이 가능해 집니다. 심지어 당시의 LG U+의 망은 원인을 알수없는(?) BGP 장애로 30MBps도 제대로 사용하기 힘든 상태였습니다. 결국 465MBps -> 30MBps로 갈아타는 결과를 만들어냅니다. DDoS 공격으로 대역폭이 부족해 장애가 일어났다면서 거꾸로 대역폭을 대폭 줄여 버립니다. 이런 것을 "죽어가는 놈에게 청산가리를 먹이는 짓" 이라고 합니다. 메뉴얼에 따라 대처했을 뿐이라구요? 메뉴얼을 쓴 사람부터 검증해 보시길 바랍니다.
자 그리고 또 하나의 FACT !!
KT 회선을 차단하면 DDoS가 길을 잃고 선관위 서버로 오지 못할 것 같습니꽈? 백본 라우터님은 그러한 길 잃은 어린 양들을 다시 선관위 서버로 정확하게 인도해 주시는 역할을 합니다.
결국 선관위의 "KT회선차단"은 DDoS도 막지 못하고 상황을 더욱 악화시키는 "자살골"이 되는 것 입니다. 게다가 선관위는 스스로 문제를 만들고도 이 모든 책임을 DDoS공격에 떠넘기고 그것도 모자라 이러한 행위를 자랑스럽게 기술문서로 만들어 공개했습니다.
이제와서 담당 직원의 실수라고 한다면 과연 누가 믿어줄까요? 담당 직원의 실수를 덮기 위해 각종 발표자료를 만들고, 내부 방어팀을 구성하여 한결같은 어조로 DDoS공격임을 주장했던 선관위의 모습에서 그들은 이미 돌아올 수 없는 강을 건너갔다고 봅니다. 또한 더 많은 자료들을 가지고도 이러한 FACT들을 찾아내지 못한 검/경찰 수사력과 신뢰도 또한 다시한번 생각해 봐야 할 것 같습니다.
마지막으로 "무조건 DDoS님의 강림이니 믿어라!" 라는 하단의 두 성서를 [비방흑색선전조사TF팀]님의 입을 빌어 공지에 올리심에 경의를 표하며 글을 마치는 바입니다.
[현안브리핑] 정보시스템 구축관련 의혹제기에 대한 입장 - 2012.02.11
[현안브리핑] 디도스 공격이 아니라는 주장에 대한 입장 - 2012.02.16
[2012.02.19 23:00 추가] - 선관위가 [비방흑색선전조사TF팀]이던 게시자를 [정보화담당관]으로 변경하였습니다. 공개도 안한 제 블로그를 보고 있는건지 참... 걱정안하셔도 됩니다. 캡쳐해 놨으니까요.
부록 : 이길환 정보보호소장의 페이지디도스
이길환 정보보호소장에 대해서는 장문으로 길게 쓰고 싶지만 귀차니즘의 발동으로 인해 확실한 팩트만 짚고 넘어가겠습니다.
자 먼저 DDoS공격에 DB는 불사의 존재인가?
결론부터 말씀드리면 아닙니다. DB사용 페이지를 통해 무리한 부하가 걸리거나 DB Connection Pool 능력을 초과하는 DB 접속이 있다면 당연히 데이터를 불러오는데 장애를 겪거나 DB가 먼저 뻗어버리는 현상이 발생할 수 있습니다.
그런데도 왜 페이지 디도스는 안되는 걸까요?
어떠한 공격자도 DDoS공격시 웹서버와 DB중 무엇이 먼저 뻗을지는 알 수가 없습니다. DB의 종류가 무엇인지, DB의 성능이 어느 정도인지, 캐싱은 어느정도 되는지, DB Connection Pool 세팅은 어떻게 되어있는지, 어떠한 페이지를 호출해서 얼만큼의 쿼리를 날려야 DB에 무리를 주는지 등등의 변수가 많기 때문입니다. 이러한 것들을 알아내려면 직접 서버에 들어가서 봐야하고, 그정도 실력자라면 DDoS공격을 하지는 않습니다. 왜냐구요? 이미 들어갔으니까요.
간략하게 결론을 내리자면 특정 페이지를 다운시킬 목적으로 DDoS공격을 하려해도 웹서버와 DB중 무엇이 먼저 죽을지는 며느리도 모른다는 이야기 입니다. 이러한 목적을 상실한 공격을 페이지 다운이라는 특수한 목적으로 실행한다는 것은 말인지 당나귀인지 구분이 안되는 이야기입니다.
이런게 가능하다고 떠들어 대는 사람들에게 "어디서 약을 팔어?!" 라고 말하고 싶지만 그냥 참겠습니다.
새로운 알고리즘에 의해 DDoS로 DB를 공격할 수 있다면 그러한 보안이슈는 빨리 공개되고 공유 되어야 방어책도 만들어지고 새로운 피해자도 막을 수 있습니다. 정보보호연구소 소장님 이라는 분이 꽁꽁 싸매고 자신만이 알고 있다고 떠들며 언론플레이를 해야할 성질의 것이 아닙니다.
결국 그동안 기술자들이 제시했던 이야기는 "보안이슈"와 "알고리즘"의 공개이지 선관위를 공격하라는 것이 아닙니다. 그리고 이번 이슈에 재연을 요구한 기술자들을 싸잡아서 꼼수빠 나 음모론자로 몰고간 이분법자 들에게는 "ㅗ(ㅡ..ㅡ)ㅗ"라고 말씀드립니다. 기술자들은 디지털 코드를 다루지만 당신들처럼 디지털 적인 [0]아니면 [1]이라는 이분법적 사고를 하는 사람들이 아닙니다. 지금이라도 깨닫고 개과천선 하시어 후세에는 좀 더 발랄하고 다양한 사고로 삶을 영유하실 수 있기를 바랍니다. 한가지 더하자면 저는 나꼼수에 대해서 비판적수용을 주장하는 사람이지 당신들이 생각하는 맹목적 신도가 아닙니다.
첨부 1. 포스팅 하는동안 선관위 유훈옥 사무관님이 김기창 교수님과의 통화에서 KT회선을 차단하는 결정에 자신도 관여하였으나, 실제로 차단한 당사자의 성함은 밝히기 곤란하다라는 발언을 하셨답니다.
첨부 2. 언제나 글이 길어지는 문제는 해결이 안되는군요. 쉽게 쓴다는게 가장 어려운 것 같습니다.
첨부 3. 읽어주셔서 감사합니다.
이번 사안에 관련된 다른 전문가 분들의 의견은 이곳에서 보실 수 있습니다.
IT 전문가 Barry 님의 글 - [Link]
오픈웹 김기창 교수님의 글 - [Link] .................................................................... 전자개표기를 악용한 개표조작 증거,정황보기 http://www.ooooxxxx.com 석종대
석종대의 최근 게시물