10.26선관위 웹사이트 서비스 장애의 원인

2012.02.15 글쓴이 youknowit

선관위 웹사이트의 디도스 방어장비를 공급, 관리하는 업체는 LG엔시스입니다. 이 업체가 지난해 11월26일 작성하여 중앙선관위에 제출한 “2011년 10월26일 재보궐선거 서비스 장애 분석 보고서”를 읽어보았습니다. 중앙선관위는 참여연대의 정보공개청구를 일부 수용하여 이 보고서(총36면)를 2012.2.11에 마지못해 공개하였습니다.

결론부터 말씀드리면, 당일 6:00-7:00 사이에 낮은 수준의 디도스 공격(초당 221메가 비트, 초당 4만4천 패킷 수준)이 있긴 하였으나, 디도스 방어장비가 공격을 탐지하여 좀비PC들의 ip에서 오는 접속 요청을 차단시켰고, 그 외 정상적 유저로부터 오는 접속 요청에 대한 차단은 없었다. 따라서 디도스 공격은 선관위 웹사이트 서비스 장애와는 무관하다는 것입니다.

2011.11.26자 기술보고서의 핵심 포인트를 간략히 설명드리겠습니다.

1. 디도스 공격 규모: 초당 221 메가 비트, 4만4천 패킷 정도의 공격은 디도스 공격의 평균 수준에 훨씬 못미치는 소규모 공격입니다. 2011년 후반기 전세계 디도스 공격 추이를 분석한 기사에 따르면, 공격에 동원된 트래픽 규모의 평균치는 초당 5.2기가 비트 수준이었습니다. 선관위 공격은 이것의 1/20 수준.

2. 당일 아침 장애 기간 동안의 정상 트래픽 규모: 웹사이트 가장 앞 단(端)에서 디도스 방어장비가 공격 트래픽을 걸러내고, 정상 트래픽을 통과시키면 방화벽 장비가 그 다음 단계에서 이 트래픽을 처리합니다. 여기에 기록되는 트래픽은 정상적인 접속 요청 트래픽으로 볼 수 있습니다. 문제의 기간 동안 정상 트래픽량은 초당 10메가 비트 수준이었고, 처리세션도 3000세션 미만의 낮은 수준이었으며(3분 단위로 측정), 보고서 3.4는 그 이유를 “앞 단 DDoS 보안장비에서 유해 트래픽이 차단되어 세션 수가 적었음”이라고 설명하고 있습니다.

참고로 그날 하루의 트래픽 추이를 보면 저녁 8시-9시 사이에 접속량이 절정에 달하는데, 이때의 세션 수는 24만 세션(3분 단위 측정) 가량의 수준이었습니다. 따라서 3000 세션이라면 선관위 서버가 아무 부담없이 여유롭고 널널하게 처리할 수 있는 수준의 부하입니다.

3. 장애 기간 동안의 웹서버 상황: 방화벽을 통과한 트래픽은 웹서버가 처리합니다. 선관위는 TMax사가 제작 납품한 WebtoB + JEUS 서버 소프트웨어를 사용하고 있습니다. 웹서버는 유저의 접속 요청을 처리하는 과정에서 DB서버와 교신하여 DB서버로부터 데이터를 가져와서 웹페이지를 실시간으로 생성하는 작업을 합니다. 선관위 웹서버들 중에는 홈페이지 웹서버(www.nec.go.kr)도 있고, 선거정보 웹서버도 있습니다(info.nec.go.kr). 거의 대부분 유저들은 일단은 선관위 홈페이지로 접속을 시도할 것입니다. 인터넷 검색창에 “선관위”, “선거관리위원회” 등을 치면, 제일 먼저 나오는 것이 이것이니까요. 투표소 안내 페이지의 정확한 url 주소를 자신이 직접 주소창에 입력하여 투표소 검색하는 분은 아마 없을겁니다.

선관위 ‘홈페이지’는 2대의 웹서버로 구축되어 있는데, “홈페이지 웹서버#1 상세 분석 내역”(첨부 3.6)을 보면, “메모리 증가 현상으로 인한 장애방지 차원에서 06:52에 사용자에 의해 재 기동됨”이라고 되어 있고, “홈페이지 웹서버#2 상세 분석 내역”(첨부3.7)에도 그로부터 2분 뒤에 “메모리 증가 현상으로 인한 장애방지 차원에서 06:54에 사용자에 의해 재 기동됨”이라고 보고되어 있습니다.

쉽게 설명하면, 선관위 웹서버 관리자가 ‘홈페이지’ 서버 상태를 살펴보니, 메모리(RAM 메모리를 말하지요)가 거의 소진되어 그냥 두면 뻗을 것 같아서 아침 6시52분과 54분에 홈페이지 서버2대를 다시 시작(reboot)했다는 뜻입니다. 메모리 사용수준은 그래프로 판명될 수 있으므로, 그래프를 보았습니다(첨부2.3). 그래프도 재미있고, 그 옆에 “점검결과”란에 적힌 내용은 더욱 재미있습니다.

기술보고서의 해당 페이지는 이렇게 생겼습니다. 아래 그림을 클릭하면 full size로 보실 수 있습니다.

세개의 그래프 중, 중간 것을 보시기 바랍니다. 이렇게 생겼습니다.

그래프 왼쪽 끝이 2011.10.26.새벽 0시이고, 오른쪽 끝이 그날 23:59 입니다. 왼쪽 상단을 보시면, 그날 0시부터 6:50 경까지 메모리 사용이 거의 100%에 이르고 있습니다. 새벽 4:20경부터 5:20경까지 한시간 동안 잠시 떨어졌다가 다시 100%에 달하는데, 결국 6시52분, 54분에 서버관리자가 reboot을 하고 나니까, 정상 수준(70%-80%)으로 돌아왔다는 것입니다. 무언가 비정상 프로세스가 메모리를 밤새도록 잡아먹고 있었고(새벽 4시-5시 사이에 잠시 내려갔다가), 이 사태는 아침 6시50분쯤에 서버관리자가 reboot을 하니까 비로소 회복되었다는 이야기 입니다. 따라서

  • 접속자가 거의 없는 한밤중이나 새벽에 어째서 선관위 홈페이지 웹서버 RAM 메모리 포화상태가 계속되었는지?
  • 새벽 4:20경에는 누가 어떻게 했길래 메모리가 회복되었는지, 5:20 분경에는 무슨 일이 있었길래 다시 RAM메모리가 소진된 상태로 맛이 갔는지?
  • 선거 당일날 0시부터 이런 일이 벌어지고 있었는데 어째서 6시50분까지는 아무도 홈페이지 웹서버 상황을 모니터하지 않고 있었는지? 아니면, 모니터하면서도 가만히 보고 있었는지 규명되어야 합니다.

그런데 흥미로운 점은, 위 그래프 오른쪽 란을 보시면 “장애발생 당시 메모리 사용률은 과부하가 존재하지 않은 상태임”이라고 적혀 있다는 것입니다. 그럼, 같은 보고서 첨부3.6과 첨부3.7에서 “메모리 증가 현상으로 인한 장애방지 차원에서 06:52(6:54)에 사용자에 의해 재 기동됨”이라 적은건 뭥미? 그냥 실수? “장애 발생 당시에” 무슨 일이 있었지에 대한 분석보고서의 핵심 부분에서?

4. DB서버: 이상 상황 없습니다. 그도 그럴것이 6시54분까지는 홈페이지 웹서버 자체가 메모리 포화로 버벅대고 있었으므로, DB서버에 제대로 요청도 못하고 있는 상황이었기 때문입니다. DB서버는 그냥 한가하게 놀고 있는 것이지요. 그점은 DB로그에도 나타날 것입니다. DB서버와 웹서버 간의 연결을 강제로 끊고 말고 할 필요도 없었습니다. 접속량은 3분에 3000세션 밖에 안되는 널널한 수준인데도, 어떤 이유에선지, 웹서버의 메모리가 포화상태로 있었기 때문입니다.

5. 7:00-8:32 사이: 선관위 홈페이지 웹서버의 메모리 포화 상태가 6:54경에 해소되자, 약 5분 후인 7시부터 8:32까지 선관위는 KT망서비스를 끊습니다. LG엔시스 보고서는 이렇게 적고 있습니다. “선거당일 06시부터 07시 사이 대량의 트래픽이 유입됨. 07시부터 08시32분까지 KT망 서비스를 단절함”

이것은 기술적으로 “해괴망칙한 짓” 이라고 밖에는 달리 표현하기 어렵습니다. 왜 그런지 설명드리겠습니다.

선관위는 평소 3개의 망을 이용하여 인터넷과 연결되어 있습니다. KT망이 두개(KT ATM#0, KT ATM#1) 그리고 LG망이 하나입니다. 각 회선은 초당 155메가 비트(bps)의 트래픽을 감당할 수 있는 용량입니다. 따라서 선관위는 합계 465메가 규모의 트래픽을 감당할 수 있습니다. 선거당일 6시부터 07시 사이 “대량의 트래픽”이 유입되었다고 하지만, 실은 221메가 수준의 트래픽에 불과했기 때문에 세개 회선 중 KT망 두개(용량 310M)만으로도 충분히 처리하고, LG망은 그냥 놀고 있었습니다. 그런 상황에서 KT망 두개를 끊으면 그 트래픽이 어디로 가겠습니까? 회선을 끊는다고 트래픽이 공중으로 사라집니까? 땅으로 꺼집니까? 인터넷은 원래 군사목적의 교신 수단으로 개발된 것이기 때문에 회선의 일부가 절단되면, 트래픽이 사라지거나 drop 되는 것이 아니라, 마지막까지 남아있는 다른 회선을 어떻게라도 찾아서 가도록 설계되어있습니다. 따라서 그때 까지 KT망 두개를 통하여 널널하게 오고가던 221메가 수준의 트래픽이, 아직 끊기지 않고 남아 있는 LG망(용량 155메가)으로 몰리게 됩니다. 즉 155메가 용량의 회선에 221메가 규모의 트래픽이 몰리는 과부하 상황이 “연출”되는 것입니다. (선관위가 올해 1.27일 게시한 “중앙선거관리위원회 DDoS관련 기술분석 보고서” 슬라이드 12면 참조).

파이프 세개로 널널하게(워낙 널널해서 파이프 하나는 아예 사용도 안하면서) 트래픽을 처리하다가, “트래픽이 많다는 이유로” 파이프 두개를 자르고 하나의 파이프로 트래픽을 몰아넣는 해괴한 짓을 7시부터 한 것입니다.

망을 자른다고 트래픽이 없어지는 것이 아닙니다. 어느 하나의 망을 자르면, 트래픽은 남아 있는 망을 통하여 찾아오는 것입니다. 회선 자체는 정상 트래픽이건 공격 트래픽이건 가리지 않습니다. 공격 트래픽은 망 변경때문에 선관위 사이트를 찾아오지도 못하는데 정상 트래픽만 용케 찾아온다거나, 그 반대의 경우는 애초에 있을 수 없습니다. 디도스 장비에까지 도달한 트래픽의 추이는 다음과 같습니다.

6시-7시 사이에는 초당 221메가 수준이던 유입 트래픽이 7시 이후에는 26메가 비트 수준으로 대폭 줄어듭니다. 어째서 이렇게 유입 트래픽 자체가(공격 트래픽인지 정상 트래픽인지 가릴것 없이) 거의 10분의1 수준으로 줄어들게 되는지에 대하여, LG엔시스 보고서 2-2을 보면, “07시 이후 08시30분까지 LG망을 통해 서비스하였으나 LG망과의 BGP Down/UP 연속발생으로 인해 서비스가 중단된 것으로 판단됨”이라고 적고 있습니다.

무슨 뜻인고 하니, 세개의 망을 모두 사용하여 트래픽을 널널하게 받다가, 7시에 KT망 두개를 끊고 LG망 하나로만 트래픽이 몰리도록 했을 뿐 아니라, 누군가에 의해 또는 어떤 이유에선가 LG망과 연결된 선관위 라우터가 꺼졌다/켜졌다(link up/link down)를 반복해서, 트래픽이 어느 망으로 선관위를 찾아가야 할지 갈팡질팡하게 되어 접속 트래픽(공격트래픽이건 정상트래픽이건)이 네트워크 주소를 제대로 찾아 오고가지를 못하게되어 전반적으로 접속량이 줄어들었다는 것입니다.

따라서, 다음 사항들이 규명되어야 할 것입니다:

  • 홈페이지 웹서버를 6:54경에 reboot하여 메모리 포화 상태가 해소되자, 약 5분 후 선관위와 연결되는 세개의 회선 중 두개를 단절하였는데, 누가 이 결정을 했는지? 이 결정을 한 기술적 근거는 무엇인지?
  • 465메가 규모의 처리 용량을 가진 선관위 회선망이 그 용량의 47%에 불과한 221메가 정도의 트래픽을 처리하고 있는 상황에서 어째서 회선 두개를 단절하여 용량 초과(221/155 = 142%) 상황을 연출했는지?
  • 하나만 남겨둔 LG망 자체의 접속 문제(BGP Negotiation 등의 문제)까지 있어서 장애가 일어난다면, 왜 그런 문제가 없었던 두개의 KT망을 다시 연결하지 않고 1시간 30분이나 그냥 두었는지?

실은, “BGP up/down 연속 발생”이라는 것도 저절로 생겨나기는 어려운 것입니다. 독립된 망들 간의 연결을 처리하는 Border Gateway Protocol(BGP)는 소프트웨어적으로는 그리 쉽게 down되지는 않습니다. 여러 게이트웨이 호스트들과의 연락 가능성을 확보해두고 하나가 실패하면 다른 호스트와 연락해서 결국 네트워크 주소를 찾아가도록 설계되어 있는 것입니다. 물론, 종착지의 라우터가 어떤 이유에서건 link up/link down 상태를 반복하면(트래픽을 보내라 했다가, 보내지 말라하는 요청을 변덕스럽게 반복한다면) BGP 라우터가 그 요청을 전달받아 처리하는데 걸리는 시간 때문에 트래픽이 이리저리 방황하는 상태가 초래될 수 있겠지요…

디도스와는 무관한 이런 기술적 이슈들이 규명되어야 10.26 선관위 웹사이트 장애 사태가 밝혀질 수 있습니다. 보궐선거 당일 아침의 서비스 장애는 디도스와는 무관하다는 기술보고서가 11월26일에 선관위에 이미 제출되었음에도 이를 무시하고(기술보고서를 무시하려면, 기술적으로 합당한 근거라도 제시해야 할 것입니다), “20대 전과자 몇명이 나경원을 좋아해서 술김에 디도스 공격을 하니까 선관위 사이트가 두시간 넘게 뻣더라”는 황당한 스토리를 경찰은 2011.12.9일에, 검찰은 2012.1.6에 온국민을 상대로 “수사발표”라는 미명하에 유포한 이유가 무엇인지는 앞으로 차근 차근 규명되어야 할 것입니다.

ps. 결국, 10.26 선관위 웹사이트 장애는

(1) 당일 0:00(또는 그 이전) 부터 6:54까지는 홈페이지 웹서버 RAM 메모리가 (어떤 이유에선가) 포화 상태로 내내 있었기 때문에 접속 요청을 제대로 처리하지 못했고,
(2) 홈페이지 웹서버가 reboot되어 메모리 포화 상태가 해소되자, 5분 뒤인 7시 부터는 (어떤 이유에선가) 그동안 널널하게 트래픽을 처리하던(하도 널널해서 세개의 망 중 하나는 아예 놀려두고 있던) 상황에서 KT망 두개를 자르고 LG망 하나로만 모든 트래픽이 몰리도록 한 다음, 누군가가 선관위 스위치 라우터를 계속 장난질쳐서 선관위로 트래픽이 오고가기 어렵게 만들었다가 8시 반에 KT망 두개를 다시 연결하여 정상화 된 것으로 보입니다.

LG엔시스 보고서 3.1 하단의 “종합의견”에도 “정상적인 서비스가 이루어지지 못한 이유는 Router와 LG망과의 BGP Down으로 인한 것”이라고 되어 있습니다.

디도스는 이런 내막을 덮으려는 쇼. 왜 그런 “쇼”를 했을까요?

Categories: 보안, 선관위 접속장애 사건 | 13 comments  오픈웹 구독 메일로 받기

2 Pingbacks/Trackbacks

  • http://www.facebook.com/profile.php?id=100002520652382 최동선

    정말 선관위가 왜 그런 ‘쑈’를 했을까요? 혹시 꼼꼼한 그분이(?) ㅎㅎ 이정도 근거면 음모론이 라고 치부해 버릴 수 도 없겠는데요 ㅎ 충분히 합리적인 판단으로 의문점을 가질 수 있겠어요. 

  • http://twitter.com/ziofront 쥐 쥐 해주시겠습니까?

    이 글은 어떻게 볼 수 있는건가요?

  • Pingback: 10.26사태관련 선관위 10문10답에 대한 세가지 질문 | Open Web

  • Pingback: 10.26부정선거의 선관위 발표 보고서에 대한 분석 | Barry's Post

  • http://twitter.com/kool82 Dai-Hyug Kwon

    정말 이건 아니네요…인위적으로 일부러 그런게 아닌이상은…

  • http://www.facebook.com/crimsonluna Kyooha Hwang

    10.26보궐선거 당일 아침 6:58까지의 유입트래픽 추이

    데이터 단위 표시해주시면 더 좋을것같내요

    당연히 max 250MB(250,000KB)…..인건 아는사람이야 알겠지만.

  • Hosang Yoon

    웹서버 메모리 100% 사용 부분은 이렇게 보실 수도 있을것 같은데요.

    - Unix 는 기본적으로 (값비싼) 메모리가 남으면 이를 파일 캐시로 적극적으로 활용하여 디스크 I/O 성능을 향상시키는 용도로 사용하므로 모니터링 툴로 보기에 단순히 사용률 100% 라고 보이는것 자체가 실제로는 메모리 부족 징후가 아닐 수 있습니다.
    - 특히, 새벽 시간에는 보통 백업이 돌기 때문에 파일 캐시 사용량이 크게 늘어날 수도 있습니다. (백업을 위해 디스크에 있는 파일을 죽~ 읽어서 메모리에 올려놓은 다음 그것을 테잎에 쓰기 때문에 메모리 사용량은 쉽게 100% 가 될 수 있습니다.)
    - Unix 서버에서 정말로 메모리가 부족한 상황인지 아닌지는 스왑 디스크로의 페이지 아웃이 발생하는지 여부를 보고 판단해야 합니다.
    - 이런 전제조건에서 메모리 사용률은 100% 였지만 정말로 메모리가 부족한 상태였는지를 확인할 수 있는 페이지 아웃까지 함께 확인한 관리자가 “메모리 사용은 과부하가 아니다” 라고 코멘트를 해 놨을 가능성도 있어 보입니다.

    • http://www.facebook.com/people/Taewan-Kim/100001395271244 Taewan Kim

      대상 서버가 웹 서버라는 것을 상기할 필요가 있습니다.
      웹 서버의 특성상 이런 작업은 어렵지 않을까요?

  • http://twitter.com/gsgod BOKYUNG KIM

    정리 잘 되었네요 수고하셨습니다 
    트위터에서 많은 사람들이 보왔으면 하네요…

  • http://www.facebook.com/chanhyuk.jeong ChanHyuk Jeong

    10.26 선관위 의혹 사건을 IT 전문가들이 촘촘하게 분석한 내용들. DDos 방어담당이었던 LG엔시스 엔지니어들이 맘대로 말하지는 못하고 군데군데 숨겨둔 답답한 심정들이 엿보인다는….ㅎㅎ

  • http://twitter.com/JongWonKim2000 Jong-Won Kim

    마침내 10.26 부정선거 관련 기술적인 분석 세편을 다 읽었습니다. 많은 사람들이 함께 할 수 있도록 나누겠습니다.

  • http://twitter.com/kkanari Tongseob KIM

    파일캐쉬로 메모리 할당이 100% 된다면. 모니터링 요원이 적절하게 조치를 취했어야 하는 부분이고 새벽 6시부터 투표가 시작되는 새벽에는 백업을 돌지 않게 해야하는게 정상 아니였을까요?

    투표날은 백업보다 서비스에 만전을 기해야 하니까요

  • http://www.facebook.com/profile.php?id=100003092481317 Yunseng Baek

    선거관리 위원회 훌륭하네..

«

»