0. 개요
최근 대한민국을 떠들썩하게 만든 이슈가 하나 있습니다. 바로 KT 연결망 장애 사건입니다. 약 1시간 반정도 통신망이 마비가 되었던 사건인데, 저도 개인적으로 핸드폰과 인터넷을 KT껄 사용하고 있어서 애먼 공유기만 때린 기억이 나네요
KT로 인해 47억년 업데이트행....
처음에는 DDoS라고 했다가, 나중에는 라우터 설정이라고 했다가.... 저도 왜 이렇게 된 것인지 궁금해서 이번 사건을 분석을 해보았습니다. 분석은 2021년 10월 29일 공개된 공식 보고서를 기반으로 작성했습니다.
1. 요약
이번 KT 네트워크 장애사고는 10.25.(월) 11시 16분경부터 시작되어, DNS 트래픽 증가에 이어, 네트워크 장애가 발생하였고, 12시 45분경 KT의 복구조치가 완료되어 약 89분의 서비스 장애가 발생하였다.
결론적으로, DNS 서버에 대한 트래픽 증가는 있었지만, 시스템 자원 DDoS 공격 및 네트워크 대역폭 공격은 확인되지 않았다.
결국 한 개 라우터의 잘못된 라우팅 경로 업데이트가 전국의 라우터에 연쇄적으로 일어나서 장애가 전국적으로 확대되었다.
본 사건의 3줄 요약은 위와 같습니다. 네트워크 장애로 인한 89분의 서비스 거부가 발생하였고, 처음에는 DDoS라고 발표하였으나 알고 보니 라우터 설정 미스였습니다.
또한 애초에 이렇게 전국적으로 마비될 일은 아니었으나 라우팅과 관련해서 모두 통합하여 연결되어있었고, 엎친데 덮친 격으로 밤에 진행했어야 하는 일을 덜컥 낮에 진행해버려 훨씬 더 큰 일이 발생하였습니다.
참... 이것만 봐도 참 안타까운 사건인데, 보안인의 입장으로 더 전문적인 시각, 그리고 '왜 일어났을까?'라는 시각으로 바라보겠습니다.
2. 배경지식
이 사건을 이해하기 위해 알고 있어야 하는 개념들을 소개합니다.
# DDoS (Destributed Denial of Service)
분산 서비스 거부 공격이라고도 불리우는 DDoS 공격은 사실 접하기 매우 쉬운 단어라고 생각합니다. 개인적으로 정보보안 관련 이슈에서 언론이 좋아하는 단어 중 하나라고 생각하고, 그만큼 대중들에게도 어느 정도 알려져 있는 단어라고 생각합니다.
DDoS에 대해서 간략한 개념만 설명해보자면, 뜻 그대로 서비스를 거부하게끔 유도하는 공격입니다. 기본적으로 웹 서비스는 서비스를 제공하는 측인 서버와 그 서비스를 이용하는 클라이언트로 이루어져 있습니다. 당연히 서버는 주로 네이버나 구글 같은 기업이 될 것이고, 클라이언트는 그 서비스를 이용하는 우리가 되겠죠.
그러나 아무래도 서버도 하나의 컴퓨터라고 봐야 하기 때문에, 컴퓨터의 성능에 따라 감당할 수 있는 클라이언트들의 접속 요청, 즉 request가 한정되어있습니다. 그러나 서버가 감당할 수 있는 request가 너무 많이 들어오는 경우, 서버는 "안함ㅅㄱ"를 선언하고 접속조차 안되는 참사가 일어납니다.
그래서 보통 DDoS는 서비스 거부를 일으키기 위해 request를 많이많이많이 보내는 것에 초점을 맞춥니다. 네트워크에 레이어에 따라서 공격 방법이 달라지지만, 결론적으로 서버에 감당할 수 없는 양의 request 및 패킷을 보내는 것이 목표입니다. 이제 이 공격을 하는 것이 컴퓨터 1~2대냐, 몇 100~1000대의 컴퓨터냐에 따라서 DoS와 DDoS로 나뉩니다.
이제 하루에 100명 정도 접속하는 개인의 서버에 DDoS 공격이 일어난다면 그건 일어났는지도 모를 수 있겠지만, 직접 겪으신 분은 알겠지만 KT같은 초대형 기업은 1시간 마비만으로도 전국적 패닉을 일으킬 수 있습니다.
Client-Server Model, Wikipedia
이렇게 하니 대충 DDoS라는 것에 대한 감이 오실 것 같습니다. 너무 자세히 얘기하진 않겠지만, 이런 공격들을 막기 위해 하나의 IP에서 너무 많은 패킷이 날라올경우 그 IP를 차단한다거나, 그에 대한 자동 트래픽 탐지 시스템을 구축하기도 합니다. 서버실이라고 검색했을 때 수십 대의 컴퓨터가 주루륵 나열되어있는 사진이 보이는 이유 중 하나도 DDoS 대비라고 볼 수 있구요.
이제 단순히 서버에게 보내어 서버에 request를 보내는 시스템 자원 공격과 DNS 서버를 타겟으로 하는 네트워크 대역폭 공격으로 나뉘는데, 이건 다른 글에서 심층적으로 다루도록 하겠습니다. 아무튼 DDoS의 포인트는 n개의 컴퓨터(IP)가, 엄청난 양의 request를 요청한다는 것을 기억하고 넘어가도록 합시다.
# 라우팅 / 라우터
다음은 라우팅과 라우터에 대해서 알아보도록 합시다. 앞서 DDoS에서 클라이언트에서 서버로 request를 보낸다는 이야기가 기억나시나요? 그 request 및 패킷을 보내는 과정에 밀접하게 연관되어 있는 것이 라우팅입니다.
서버와 클라이언트는 물리적으로 떨어져있습니다. 당연히 이렇게 편하게 모든걸 사용하고 있는 우리의 입장에서는 무슨 마법을 통해서 바로 이용할 수 있는 것처럼 보이지만, 결론적으로 KT와 같은 통신사를 통해 정보를 전달받게 됩니다. 그래서 KT와 같은 통신사들은 고객들에게 빠른 속도로 송/수신할 수 있도록 돕는 것이 주 업무이구요. 그리고 그 최적의 송/수신 방법을 찾는 것이 라우팅이고, 그 라우팅을 수행하는 것을 라우터라고 합니다.
211029 KT 네트워크 장애 원인 분석 결과, 과학기술정보통신부
라우팅을 할 때 사용하는 통신 규약을 라우팅 프로토콜이라고 합니다. 보통 통신을 위해 라우팅 프로토콜은 라우터 간 메시지 교환을 통하여 IP 주소에 따른 경로정보를 관리하며, 경로정보의 범위가 AS 내부인지 외부인지에 따라서 IGP와 EGP로 구분합니다. 이번 사건에서 exit을 빼먹어 문제가 되었던 프로토콜이 IGP에 종류 중 하나인 IS-IS이고, 외부용으로 사용되는 프로토콜이 EGP, 특히 KT가 사용하는 BGP입니다.
이해가 잘 안된다면 KT가 라우팅을 하는데, 내수용으로는 IS-IS를 채택하고, 외부용으로는 BGP를 채택하는구나. 정도로 보면 되지 않을까 싶네요.
3. 다시 한번 사건을 봅시다.
# DDoS가 아니다?
과기정통부는 결론적으로 이 사건이 DDoS로 인한 공격이 아니라고 발표했습니다. 이렇게 발표하게 된 몇 가지 근거를 확인해봅시다.
첫째로, 시스템 자원 DDoS 공격과 관련하여, 조사반의 패킷분석 결과, 당시 개별 IP의 DNS 질의는 최대 15개 이내 수준(중앙 1차 DNS 기준)으로, 다량의 도메인 질의는 없었으며,
*통상 DDoS 공격 시, 개별 IP에서 수백, 수천 개의 질의가 발생
네이버, 다음 등 정상적인 도메인 질의 이력만 존재하였고, 존재하지 않는 비정상적인 도메인(예 : abec.naver.com, q12jk.naver.com 등)의 반복적인 질의도 없었던 것으로 파악되어, 시스템 자원 DDoS 공격은 없었던 것으로 분석되었다.
먼저 분석 결과 각 IP마다 최대 15개 이내 정도의 request가 발생했다고 합니다. 감이 안오시는 분들을 위해 비유를 하자면, 구글에서 검색을 한다고 가정할 때 request 15번이면 5분도 채 안되는 시간동안 request 15번은 요청하고도 남는 정도입니다.
DDoS는 아닐 확률이 높지 않을까...?라는 생각을 하면서 계속 읽어봅시다.
둘째로, 네트워크 대역폭 공격과 관련하여, 트래픽 분석을 실시한 결과 중앙 1차 DNS서버 대역폭의 최대 8%, 부산 DNS 서버 대역폭의 28% 규모의 트래픽 유입*만 있어서 대역폭 대비 충분히 수용가능한 수준으로 네트워크 대역폭 공격은 아닌 것으로 판단되었다.
* (중앙1차) 10G 중 약 800Mbps, (부산) 1G 중 약 280Mbps
그리고 앞서 잠깐 언급했지만, DDoS에는 총 2가지 방법이 있습니다. 직접적으로 서버에 request를 보내는 방법, 그리고 DNS 서버 대역을 마비시키는 방법이 있다고 가볍게 언급하였습니다. 위의 내용을 보면, 각 대역폭의 8%와 28%수준으로 전혀 감당이 가능한 정도의 트래픽인 것을 확인할 수 있습니다. 따라서 이와 같이 DDoS 공격은 아닌 것으로 판단이 되었으며, 실제로 문제가 되었던 라우터 오류로 넘어가도록 합시다.
# 라우터 설정 오류
관련 기사를 찾아보면 "exit, 한 단어로 인한 사고"같은 맥락의 말을 쉽게 볼 수 있습니다. 왜 한 단어가 이렇게 큰 일을 불러일으켰는지 한번 확인해봅시다.
작업자가 잘못된 설정 명령을 입력하였고, 이후 라우팅 오류로 인해 전국적인 인터넷 네트워크 장애가 발생한 것으로 분석되었다.
라우터는 이렇게 BGP, IS-IS 등 프로토콜을 통해 교환한 경로정보를 종합해서 최종 라우팅 경로를 설정하게 된다.
작업자의 작업내역을 확인한 결과, 사고발생 라우터에 라우팅 설정명령어 입력과정에서 IS-IS 프로토콜 명령어를 마무리하는 부분에서 ‘exit’ 명령어를 누락했으며, 이로 인해, BGP 프로토콜에서 교환해야 할 경로정보가 IS-IS 프로토콜로 전송되었다.
통상 1만개 내외의 정보를 교환하는 IS-IS 프로토콜에 수십만개의 BGP 프로토콜의 정보가 잘못 전송되면서, 라우팅 경로에 오류가 발생하게 되었다.
아하... 이런 일이 있었네요. 기본적으로 IS-IS 프로토콜은 BGP 프로토콜보다 더 작은 양의 데이터를 처리하는데, IS-IS 프로토콜에서 멈추지 않고 BGP 프로토콜까지 다루게 해서 문제가 발생했던 것이였습니다.
그리고 이걸 읽고 떠오른 하나의 짤...
콩쥐야.... IS-IS만 주겠다며....
아무튼 참고로 사고발생 라우터는 부산 시설지사에 위치한 라우터라고 합니다. 기본적으로 이런 망들은 보통 지역별로 묶여있기 때문에 이런 오류가 발생했더라도 부산에서만 발생했을텐데, 문제는 전국적으로 일어났던 점을 마지막으로 기억하면서 다음 섹션을 읽어봅시다.
# 그 외의 것들
여기까지 읽어보았을 때, "아니 부산에서 잘못 설정한거면 부산만 문제가 생겼을 텐데, 왜 전국적으로 문제가 생겼을까?"에 대한 질문이 아직 남아있을 것입니다. 이건 아래를 읽어보도록 합시다.
IS-IS 프로토콜 내의 라우터들은 상호간의 정보 최신화를 위해 자동으로 데이터를 주고받는데, 부산 지역라우터에 잘못된 라우팅 경로가 설정된 이후, 다른 지역의 IS-IS 라우터 등에도 잘못된 업데이트 정보가 전달되었다.
아 저런... 아무래도 라우팅이라는 것 자체가 통신 데이터를 최적화된 경로로 보내는 작업이다 보니, 각 라우터끼리도 동기화가 되도록 설정이 되어있던 것 같습니다. 당연히 납득이 가능한 체계이지만, 충분한 검증 과정 없이 진행이 되었다는 점이 가장 큰 문제라고 생각합니다. 이런 동기화때문에 30초만에 부산에서의 실수가 전국의 문제로 변해버리고 말았네요.
4. 대응 방안?
이번 사건은 Kimsuky나 Lazarus같은 전문 해커 집단의 공격이 아닌, 허무한 구멍들이 이어져 선을 만든 사례 중 하나라고 생각합니다. 이 사건을 앞으로는 방지하고, 더 나은 대응을 하기 위해서는 다음과 같은 대응 방안이 있다고 생각합니다.
1.
가상 테스트베드 구축
라우팅의 개념을 고려하였을 때 자동동기화 자체로는 문제가 있다고 논할 수는 없다고 생각합니다. 다만 자동 동기화의 편리성과 함께 동반되는 위험성 또한 파악하고, 그 전에 정상적으로 가동이 되는지 확인하는 가상 테스트베드가 꼭 필요하다고 생각합니다. 검수 매커니즘을 추가하는 방법도 있겠지만 이게 제일 확실하지 않을까 싶네요.
이 외로도 비슷한 일이 발생하였을 때 송수신 우회로를 설정한다거나, 백업 장비를 준비하는 방법 등도 있겠네요.
실제로 과기부도 이번 사건을 기점으로 시뮬레이션 시스템을 통신3사에 도입한다고 하네요.
2.
검수의 자동화
1, 2차에 걸친 사전검증 단계가 존재했으나, 사람이 직접 검토하는 체계이기 때문에, 오류를 발견하지 못했다.
보고서를 살펴보면 1, 2차 검수 과정이 존재는 하였으나, 발견을 못했다고 합니다. 근데 뭐 일을 해보신 분들은 알겠지만, 내가 작업한 내용을 꼼꼼히 검수하는 게 쉬운 일은 아니라고 생각합니다. 그렇기 때문에 이건 자동적으로 검수를 해주는, 최소한의 에러는 잡아줄 수 있는 체계가 만들어져야 한다고 생각합니다.
3.
그 외의 제도적인 것들
사실 기사들을 읽으면서 깜짝 놀랐던 부분인데, 통신이 3시간 이상 끊겨야 피해보상이 들어가도록 KT 약관에 제정이 되어있다고 합니다. 그리고 이 지침은 유선통화 시절에 만들어진 것이구요... 오늘은 기술적인 부분들을 논할 거라 너무 구체적으로 들어가진 않겠습니다.
그리고 그 외로는 규율을 지키지 않은 사람들을 처벌한다거나, 제대로 피해보상을 해주는것들 등이 있겠네요.
5. 결론
개인적으로 매우 허무한 사건이라고 생각합니다. 다시금 우리나라 보안의 수준에 대해서 생각하게 되는 사건이었고, 많은 언론들이 이번 사건을 인재라고 비판할 만큼 관리적인 부분에서 아쉬운 점이 많았던 것 같습니다.
생각보다 작은 실수들이 대형사고를 만들어냈다는 것이 놀라웠고, 이번 기회에 KT의 네트워크 구조도 알게 돼서 흥미로웠습니다ㅋㅋㅋㅋ... 그리고 통신사가 가지고 있는 어떤 파급력이 정말 크다는 것 또한 깨닫게 되었습니다. 앞으로 이런 실수는 일어나지 않았으면 좋겠습니다! 그리고 마지막으로 담당자는 얼마나 마음을 졸였을지.... 이만 줄이겠습니다. 끝!
틀린 부분이 있다면 언제나 kor.dubini0@gmail.com으로 연락부탁드립니다. 감사합니다
참고자료