[기고] 10.26 선관위 접속장애에 대한 기술적 설명 / 김기창

추적 ‘선관위 디도스 공격’

<한겨레>와 함께 선관위 홈페이지 접속장애 사건 수사기록을 검토한 오픈웹 대표 김기창 고려대 교수가 이번 사건에 대한 자신의 분석을 담은 글을 보내왔다. 지난해부터 이 사건과 관련된 기술적 분야에 깊은 관심을 기울여온 김 교수는 다음달 7일 저녁 7시 서울 마포구 동교동 문지문화원에서 ‘10·26 선관위 사건의 이해’라는 제목의 공개강연을 열 계획이다. 김 교수의 더 많은 글들은 오픈웹(openweb.or.kr)에서 확인할 수 있다.

10.26 선관위 접속장애 사건 설명

1. 망사업자 KT의 대응

KT퍼브넷 망의 대략적 얼개는 다음과 같다.

보궐선거일 아침 5:50경에 KT는 공격징후를 즉각 파악하였다. 과천 KT망 관제 센터와 KT혜화지사 IP플랫폼 운용센터에는 침입경보가 그때 표시되었고, 5:55경부터 KT의 네트워크 보안 관제 요원은 트래픽 추이를 모니터하기 시작했으며, 6:00경에는 선관위 회선의 포화상태를 확인하였다.

KT퍼브넷에서 선관위로 송출되는 트래픽 규모는 6:00경에는 1기가(Gbps)에 가까운 수준이었으나, 선관위는 6:25에 KT에게 공격IP를 알려주고 그런 IP에서 오는 트래픽을 차단해 줄 것을 요청하였고, 6:30경에 KT는 14개의 공격 IP로부터 오는 악성트래픽을 차단하였고, 6:50경부터는 KT가 선관위로 송출하는 트래픽이 선관위 KT회선 실질 용량(260Mbps) 이하로 감소하였다(150Mbps - 110Mbps).

(나중에 설명하겠지만) 선관위가 7시에 KT회선을 닫았다는 사실을 KT는 모르고 있었으며 6:30 - 7:00 사이에 선관위가 KT에게 트래픽 추이에 대하여 문의하거나, 회선 장애 여부에 대하여 선관위와 KT측이 의견 교환을 한 적이 있었음을 보여주는 자료는 없다.

2. 망사업자 LG U+의 대응

선거일 새벽에 공격트래픽이 두차례 자동 탐지되고 차단된 바 있으나(0:00:12부터 20분간 1.4Gbps, 00:59:19부터 12분간 4.8Mbps 수준의 공격), 7시 전까지 LG망을 통하여 선관위로 가는 트래픽은 미미했으므로 LG U+가 특별한 관심을 가질 이유가 없었다.

선관위가 KT회선을 닫은 후, LG U+ 망에는 7:04:11에 두 종류의 공격(UDP공격 1.12Gbps, ICMP공격 36.48Mbps)이 14분1초간 지속된 바 있고, LG U+측은 이것이 디도스 공격트래픽이라는 것을 즉시 파악하여 차단하였다. 7:31:10에도 두 종류의 공격(UDP공격 556.61Mbps, ICMP공격 20.88Mbps)이 53분2초 간 지속된 바 있지만, 이것 역시 자동으로 탐지되어 차단되었다. 참조.

7:00-8:30 기간 동안 LG U+가 선관위로 송출한 트래픽은 대체로 평균 7메가(Mbps) 수준에 지나지 않았고, 두차례의 디도스 공격은 모두 탐지되고, 차단되었으므로 LG U+입장에서는 특이 사항이 없는 아침시간이었다. 사실은 LG회선과 연결된 선관위 라우터가 매우 빈번하게 BGP up/down을 거듭하는 상황이었지만, 그런 사정을 "그 당시에" LG U+의 보안 관제 요원이 예상하거나 짐작할 여지는 없었다. 아래 추가설명.

LG U+망이 선관위로 송출한 트래픽 규모

사건 발생 후에 작성된 아래 그래프를 보면 7:43경부터 마치 200Mbps 수준의 트래픽이 LG망으로부터 선관위로 송출된 것처럼 보인다.

실제로 그런 규모의 트래픽이 "지속적"으로 선관위로 송출되었다면 선관위의 LG회선(명목 용량 155Mbps, 실질 용량 130Mbps)이 받아들인 트래픽 규모도 130Mbps 가까운 수준이 되었어야 한다. (물론, 트래픽 과부하로 인한 연결 끊김이 빈번했을 것이므로 유입트래픽이 불안정한 모습을 보이긴 했겠지만.) 하지만, 당시 LG회선과 연결된 선관위 라우터가 받아들인 트래픽의 규모는 10Mbps를 넘지 못할 뿐 아니라, 7:30-8:05 사이에는 응답 트래픽도 전혀 존재하지 않는다.

사실은, 7:43이후 LG회선과 연결된 선관위 라우터는 44초 또는 45초 마다 BGP Down이 반복되고 있었으며(12초간 up상태로 있다가, 32초 또는 33초간 down 상태로 되는 상황이 반복), 트래픽이 선관위 바깥으로 전혀 나가지 못하는 오동작 상태를 지속하고 있었다. 이것은 트래픽 과부화와는 무관한 이유로 발생한 것이다(7:00-7:10 사이에도 트래픽 과부화와는 무관한 이유로 라우터가 오동작하고 있었고, 이 상태가 7:30-7:37 및 7:43-8:08에도 반복된 것이다).

요컨대, 선관위 라우터가 BGP up/down을 비정상적으로 반복하고 있었으므로 LG측이 트래픽을 제대로 보내지 못하는 상황이었고(너무 많은 트래픽이 송출되어 선관위 라우터에 BGP up/down 이 발생한 것이 아니라), 연결이 이렇게 자주 끊어질 경우 LG측 라우터가 트래픽 양을 제대로 측정하지 못하게 되어 실제보다 훨씬 많은 트래픽이 전송된 것 같은 착시현상이 나타날 수 있다.

LG U+측 관계자도 위 첫째 그래프는 5분 간격으로 나뉘어진 각 구간별 "최대" 송출량 기준으로 사후에 작성된 것이고, 5분 간격으로 나뉘어진 각 구간별 "평균"트래픽 규모를 기준으로 판단할 경우 7시 이후 LG회선을 통하여 선관위로 송출되고 유입된 트래픽은 둘째 그림과 같이 미미한 수준에 불과했다는 점을 확인하고 있다.

8:07에 선관위는 LG U+측에 장애 신고를 했지만 트래픽 추이나, 선관위 라우터의 비정상적인 BGP up/down이 거론되었다는 점을 보여주는 자료는 없다.

3. 선관위의 대응

(가) 7:00 이전

선거날 새벽 5시 좀 지나서부터 선관위 직원들이 출근하기 시작하였다.

[DB서버 접근(로그인) 기록] 디도스 공격이 시작되기 10여분 전인 5:37에 누군가가 선관위 어느 직원 id (y****e)로 DB서버에 로그인하였으나, 무슨 작업을 하였는지에 대한 이력은 남아있지 않다.*

5:50에 디도스 공격이 시작되자 선관위는 즉시 인지하였고, 6:20경에서는 국정원, 6:22경에는 KISA측에서도 선관위의 접속장애를 알리는 연락이 왔다. 6:20경에는 협력업체(디도스 방어) 직원들에게도 연락이 되어 이들도 선관위 현장으로 왔다. 그러나, 선관위 K사무관 등이 '대응' 조치를 직접 수행하고 의사결정을 하고 있었으며, 협력업체 직원들은 주로 디도스 방어장비에 대한 모니터링만을 수행하였다.

6:25경 선관위는 KT에게 공격IP를 알려주었고, KT는 6:30부터 이를 적용하여 공격트래픽을 차단하였다. 6:40경 유입 트래픽이 220Mbps수준으로 잠시 감소되었다. 그 직후(6:42), 선관위는 KT회선과 연결된 선관위 라우터의 네트워크 연결점(인터페이스) 중 하나(172.xx.xx.2)를 30초 가량 닫았다가 다시 열었고, 6:46에도 선관위는 KT회선과 연결된 선관위 라우터의 또 다른 연결점 하나(172.xx.xx.6)를 30초 가량 닫았다가 다시 열었다.

6:46후에도 선관위는 KT회선 "두개"를 모두 사용하여 트래픽을 받고 있었다. 예를 들어, 6:50-6:55 사이에 KT회선을 통하여 선관위로 유입된 트래픽은 148Mbps 이며, 이 규모의 트래픽은 KT 회선 "하나"(실질 용량 130Mbps)로 들어올 수는 없는 규모이다. 참고.

5:50부터 선관위 KT 두 회선으로 유입된 트래픽의 대부분은 공격트래픽이었고, 선관위의 디도스 방어장비는 이들을 제대로 걸러내고 평균 10Mbps규모의 정상트래픽 만을 통과시키고 있었다. 6:50경부터는 KT회선 두개로 유입되는 트래픽이 빠른 속도로 감소하여(6:50에는 148Mbps, 6:55에는 120Mbps), 7:00경에는 약 110Mbps 수준까지 내려갔으므로 KT회선의 포화상태는 대체로 해소되었다. 이때 선관위는 KT회선을 모두 닫았다. 당시 K사무관이 직접 선관위 라우터 콘솔(console; 화면)에서 관리자 암호를 이용하여 로그인한 상태로 해당 명령어를 실행하였고, 이때 KT측 네트워크 보안 관제 요원과 이 결정에 대하여 협의하거나 KT가 선관위로 송출하는 트래픽의 당시 규모 또는 변동 추이에 대하여 선관위가 KT측에 문의한 적은 없다. KT측은 선관위가 7:00에 KT회선을 닫은 사실을 알지 못했다.

(나) 7:00-7:10

선관위가 KT회선을 닫기 전까지 전세계의 라우터들은 선관위로 가는 트래픽을 모두 KT망(AS path 4766 9768 38683)으로 보내고 있었다. 그러나 선관위가 KT회선을 닫자, 전세계 라우터들은 선관위로 가는 트래픽을 모두 LG망(AS path 3786 9950 38683)으로 보내기 시작했다. 이 사실은 7:01:00에 미국 콜로라도의 어느 통신사(Level3 Comm) 망의 라우터(208.51.134.246)가 최초로 알리기 시작했으며, 이 정보는 순식간에 퍼져나갔다. 참조.

그러나, 선관위가 KT회선을 닫음과 거의 동시에 LG망과 연결된 선관위 라우터는 7:00:56부터 약30초에 한번꼴로 연결(peering)이 끊기는 이상 징후(BGP up/down 비정상 빈발)가 나타났다. LG망으로는 평균 7Mbps 규모의 정상트래픽이 들어왔지만, 트래픽이 선관위 바깥으로 나가지 못하는 상황이 생겨났다. 이런 상태는 7:10까지 유지되었다.

이 기간(7:00-7:10) 동안 선관위가 KT회선을 다시 열거나 LG U+에 연락을 취하여 트래픽 송출 현황을 문의하지는 않았다. LG U+ 기업품질관리팀의 장애접수 담당자가 선관위로부터 통상적인 접속장애 신고를 접수한 시점은 한시간 뒤인 8:07이었다.

(다) 7:10-7:30

7:10부터 선관위 라우터의 이상 징후(빈번한 BGP up/down)는 멈추었다. 7:01경부터 LG회선으로 평균 7Mbps가량의 트래픽이 선관위로 들어오긴 했으나 선관위 바깥으로 트래픽이 나가지 못하고 있다가, 7:10부터는 약 40Mbps 규모의 응답 트래픽이 KT회선쪽과 연결된 디도스 방어장비를 거쳐서, KT회선과 연결된 선관위 라우터까지 도달한 다음, (선관위 KT회선이 여전히 닫혀있으므로) 그 트래픽이 LG회선과 연결된 선관위 라우터로 "포워드"되어 LG망을 통하여 원활하게 바깥 세상으로 송출되어 나가기 시작한다. 이 상황이 7:30까지 지속된다. 아래 트래픽 흐름 개요도 참조.

이 기간(7:10-7:30) 동안 선관위로 유입된 트래픽은 공격트래픽이 없는 정상트래픽이었다. 그러나, 그 당시에 공격 자체가 멎었던 것은 아니다. 7:04:11-7:18:12 사이에 1.12Gbps규모의 UDP공격, 36.48Mbps규모의 ICMP공격이 LG U+망으로 들어왔으나, 망사업자 LG U+가 자체적으로 모두 탐지하여 차단하고 정상트래픽만을 선관위에 송출하였다.

선관위가 LG U+에게 좀비PC들의 IP(공격 IP)를 알려준 바는 없다.

[DB서버 접근(로그인) 기록] 선관위로 들어오고 나가는 합계 50Mbps가량의 정상 트래픽이 이처럼 원활하게 처리되어 유저입장에서건, 서버입장에서건 아무런 접속장애가 없었을 7:10-7:30분 사이, 두 차례에서 걸쳐 누군가가 선관위 직원 id를 사용하여 선관위의 DB서버에 로그인한 기록이 존재한다. 한번은 7:13에 c***j 라는 id로 로그인한 기록이 남아있고, 또 한번은 7:22분에 y****e 라는 id로 로그인한 기록이 남아있다.

이들 유저가 그 시점에 DB서버에 로그인하여 구체적으로 어떤 작업을 수행하였는지에 관한 기록은 남아있지 않다. 끝으로, 9:37에는 누군가가 Admin 권한으로 DB서버에 로그인한 기록이 존재한다. 그자가 어떤 작업을 했는지에 관한 기록은 남아있지 않다. 9:37에 있은 Admin 로그인 이후에는 그날 중 DB서버 접근 기록이 나타나지 않는다.

(라) 7:30-7:37

LG회선을 통하여 트래픽이 제대로 들어오고 나가던 상태는 7:10부터 20분 동안 유지되다가 7:30부터는 또다시 트래픽이 선관위 라우터들 간에 포워드되지 못하는 현상이 생겨났다. LG회선으로 7Mbps 규모의 트래픽이 들어오기는 하지만, 트래픽이 선관위 바깥으로 나가지 못하는 현상(7:00-7:10 사이의 증상)이 또다시 나타났고, LG회선과 연결된 선관위 라우터의 BGP up/down 빈발 현상도 7:29:38부터 되풀이 되었다. 이 상태는 7:37까지 지속된다.

LG회선과 연결된 선관위 라우터가 BGP up/down 증세를 보이기 시작한지 1분32초뒤인 7:31:10에 LG U+망으로 556.61Mbps규모의 UDP공격, 20.88Mbps규모의 ICMP공격이 들어오기 시작해서 53분2초 간 지속되었다. 그러나 LG회선과 연결된 선관위 라우터의 BGP up/down 빈발현상은 이 공격이 개시되기 전에 이미 시작했고, LG U+가 이 공격을 즉각 탐지하여 차단하고 나서도 선관위 라우터의 비정상적 BGP up/down 빈발현상은 이와는 무관하게 계속되었다.

이 기간 동안 LG U+가 탐지해 내지 못하고 선관위로 그대로 송출한 공격트래픽이 많았다고 판단할 근거는 없다. 그날 아침에 선관위가 LG U+측 네트워크 보안 관제 요원과 직접 접촉을 시도하거나, LG U+가 선관위로 송출하는 트래픽 추이를 문의해 본 적은 없다.

(마) 7:37-7:43

7:37:08부터 전세계의 라우터들은 선관위로 가는 트래픽을 KT망으로 보내기 시작한다. 참조. 선관위가 KT회선을 이때 다시 열었기 때문이다. 그러자 KT회선으로 다량의 트래픽(대부분 공격트래픽으로 보이는)이 유입되었고, 이로 인해서 KT회선과 연결된 선관위 라우터의 BGP 연결은 7:39:07에 한차례 끊긴 것으로 추정된다. 그러나 KT회선을 다시 연 이 기간동안 극심한 BGP up/down 증상은 관찰되지 않았다.

7:43:41부터 전세계 라우터들은 선관위로 가는 트래픽을 다시 LG망으로 보내기 시작한다. 선관위가 KT회선을 다시 닫았기 때문이다. LG회선과 연결된 선관위 라우터는 또다시 극심한 BGP up/down 증상을 나타내 보이고, 7Mbps 규모의 트래픽이 LG회선으로 들어오기는 하지만, 트래픽이 선관위 바깥으로 나가지는 못하는 상황이 다시 생겨났다.

선관위는 "KT망 공격여부 확인을 위하여" KT회선 하나를 잠시 활성화했다고 설명한다(선관위 기술보고서 슬라이드11면). 그러나 선관위가 7:37에 KT회선을 열거나 7:43에 KT회선을 다시 닫을 때 KT측에게 선관위로 송출되는 트래픽 규모를 문의하거나 KT망으로 공격트래픽이 유입되는지 여부를 문의한 적은 없다.

(바) 7:43-8:09

7:43에 선관위가 KT회선을 다시 닫음과 동시에 LG회선과 연결된 선관위 라우터에는 빈번한 BGP up/down현상이 또다시 발생하고, 트래픽이 포워드되지 못하여 바깥으로 나가지 못하는 현상도 다시 생겨났다.

8:07에 선관위는 LG U+의 기업 품질 관리팀의 장애접수 담당자에게 전화를 걸어 장애 신고를 접수하였다. 8:09부터는 KT회선과 연결된 선관위 라우터에는 트래픽이 완전히 사라졌는데, 그 기술적 원인은 알 수 없다. 그 전까지는 비록 KT회선이 닫혀있어도 극히 미미한(평균 약10-20Kbps) 트래픽은 KT측 라우터로 들어오거나 나가고 있었다. 8:09부터는 이것조차 멈추었다(혹시 전원스위치가 내려졌는지?).

(사) 8:09-8:39

이 기간 동안에는 선관위가 사이버 대피소 이동에 필요한 여러 설정 작업을 진행하던 관계로 서비스는 역시 이루어지지 못했다.

선관위의 DNS정보는 8:26에 변경되고, 선관위가 사이버 대피소의 프록시 서버를 이용하여 서비스하는데 필요한 설정작업도 그 무렵 진행되긴 하였다. 그러나, 실제로 사이버 대피소를 이용한 서비스가 원활하게 개시된 시점은 선관위가 KT회선을 다시 연 8:39:32 부터 였다.

8:39 전까지는 선관위 라우터들 간의 트래픽 포워딩이 여전히 안되고 있었으므로 사이버 대피소로 이동하긴 했지만 여전히 트래픽이 선관위 바깥으로 나가지 못하고 있었고, 유저 입장에는 접속 장애가 계속되고 있었다.

4. BGP up/down(라우터 간의 연결 끊김 또는 연결 재개)

(가) 7:00 이전

라우터는 보통 30초(이 주기는 조절할 수 있음)마다 상대방 라우터에게 KeepAlive 메세지를 계속 교환한다. 상대방이 보내오는 이 메세지에 대답을 못하는 라우터는 “죽은 것”으로 간주하여(BGP Down이 바로 이 뜻) 다른 라우터들이 경로 계산에서 이 라우터를 삭제(WITHDRAW)하게 된다. 그러나, 회선 자체가 다운(link down)된 것이 아니므로 KeepAlive 메세지는 여전히 주기적으로 보내지고, 여기에 다시 응답하게 되면 이 라우터가 경로 계산에 다시 포함(ANNOUNCE)되어 트래픽을 주고 받을 수 있게 된다(BGP Up이 그런 뜻).

라우터가 KeepAlive 메세지에 응답을 못하는 이유는 여러가지가 있을 수 있는데, 트래픽이 많아서 회선이 혼잡한 경우에도 KeepAlive 메세지 전달 및 응답에 시간이 많이 소요되어 주어진 시간 내에 응답을 못하는 결과가 생긴다. 이렇게 BGP Down 이 발생하면, 트래픽이 더 이상 그리로 보내지지 않으므로 회선에 다시 여유가 생기고 KeepAlive 메세지를 신속히 주고받을 수 있게 되어 BGP연결이 회복되고 트래픽 전송이 재개된다.

선관위가 KT회선과 LG회선을 모두 열어두고 있었던 기간(7시 이전)에는 선관위 망(210.204.204.0/24)으로 오는 트래픽은 모두 KT망으로 들어오고 있었다. 그 기간 중, KT회선에 연결된 선관위 라우터는 다음 그림에서 보는 바와 같이 이따금씩 BGP down이 발생하였는데, 이러한 현상은 트래픽 과부하로 인하여 생겨나는 현상으로 판단된다.

이 기간 동안 KT회선을 통하여 선관위로 유입된 트래픽 양은 다음과 같다.

KT회선과 연결된 선관위 라우터의 BGP연결이 끊긴 순간에는 유입트래픽이 급격히 줄어들다가 몇분 내로 BGP연결이 다시 재개되고 트래픽 전송이 다시 계속되고 있음을 알 수 있다.

(나) 7:00이후

선관위가 KT회선을 닫은 7:00경 이후에는 LG회선과 연결된 선관위 라우터에 "비정상적"인 빈도로 BGP up/down 이 발생한다. 워낙 자주 BGP Down 이 발생하여 아래 그래프의 점들이 마치 이어진 선과 같이 보일 정도이다. 참고.

이런 현상은 선관위 내부 라우터들 간의 트래픽 포워드 규칙 설정이 잘못되어 있을 경우 생겨날 수 있다. CEF (Cisco Express Forwarding)기술을 채용하는 라우터들로 BGP 멀티홈(둘 이상의 ISP를 이용하여 인터넷에 연결되는 것을 말함; 선관위가 이런 경우임) 구성을 할 때, 웹서버가 자신의 라우터들 간의 트래픽 포워드 규칙 설정을 제대로 해두지 않을 경우(또는 그 설정이 선거날 이전 어느 시점에 잘못 변경된 경우), 한쪽 회선(예를 들어, KT회선)과 연결된 인터페이스가 다운(Interface flap) 되면, 나머지 회선(예를 들어, LG회선)과 연결된 라우터는 BGP up/down을 무한 반복하고, 트래픽이 바깥세상으로 전혀 송출되지 못하는 오류가 생긴다는 것은 Cisco 기술문서에 자세히 설명되어 있는 내용이다. 선관위는 KT회선 쪽 라우터에는 Cisco 7606을 쓰고, LG쪽에는 Cisco 7507 을 사용하는데, 이들은 모두 CEF 기술을 기본으로 채택하고 있다.

7:00 이후 두 차례에 걸쳐 BGP up/down 이 멎고 정상적으로 트래픽이 들어오고 나가던 기간이 있었는데, 첫번째는 7:10-7:30 사이이고, 두번째는 7:37-7:43 사이이다. 두번째 경우에는 선관위가 KT회선을 열었기 때문에 위에서 설명한 오류가 사라진 것으로 판단된다.

그러나 첫번째 기간(7:10-7:30) 동안에 BGP up/down 이 멎은 이유는 KT회선을 열었기 때문이 아니다(그 기간 동안 KT회선은 닫혀 있었다). 가능한 하나의 기술적 설명은 선관위가 자신의 내부 라우터들 간의 트래픽 포워드 규칙 설정을 7:10경에 변경하였기 때문이라고 할 수 있다. LG회선과 연결된 선관위 라우터의 설정 파일 중, ip route 와 관련된 행을 한 줄 (올바르게) 변경할 경우, 라우터들 간의 트래픽 포워딩 오류(loop)는 사라지고 LG회선으로 트래픽이 들어온 다음, 선관위 서버에서 정상적으로 처리되고, 응답 트래픽이 KT회선과 연결된 라우터로 가서, 거기서 LG회선쪽 라우터로 포워드된 다음, 바깥 세상으로 나가는 과정이 원활하게 이루어지게 된다(7:10-7:30 사이 트래픽 흐름이 이러했다).

이런 원활한 트래픽 흐름이 7:30부터 다시 중단되고 BGP up/down이 또다시 발생하는데, 앞서 이야기한 설정 파일 중 해당 부분이 그 시점에 다시 (틀리게) 변경될 경우 그런 현상이 나타날 수 있다.

7:00-8:39 사이 기간에 관찰되는 특이한 빈도의 BGP up/down이 이상 제시한 것과는 다른 기술적 이유로 인한 것이라는 것이 선관위의 입장이라면, 선관위는 그 정확한 기술적 원인을 설명해야 할 것이다. 아울러 06:46:33, 06:47:39, 06:49:00, 06:49:40, 06:56:24에 KT회선과 연결된 선관위 라우터(172.xx.xx.6) 콘솔에서 선관위가 어떤 설정 변경 작업을 했는지도 해명되어야 할 것이다.

5. Failover 기능(회선 중 하나가 작동하지 않게 될 경우, 다른 회선으로 서비스하는 기능)

선관위는 KT회선과 LG회선을 동시에 사용하여 트래픽을 주고받도록 구성되어 있다(BGP 멀티홈 구성). 210.204.204.0/24를 도착지로 하는 '유입'트래픽은 모두 KT회선을 사용하도록 되어있지만, 선관위가 바깥으로 내보내는 응답트래픽은 회선 상황에 따라 KT회선 또는 LG회선을 이용하여 바깥으로 나가도록 되어 있다.

KT회선이나 LG회선 중 어느 한 회선이 어떤 이유에서건 작동하지 않을 경우(스스로 닫은 경우도 포함), 나머지 회선을 통하여 트래픽이 들어오고 나갈 수 있도록 되어 있어야 하고(failover 기능), 이 기능은 애초에 선관위 네트워킹 작업을 했던 업체의 입장에서는 가장 기본적으로 테스트하고 정상 작동 여부를 확인하였을 것이 분명한 사항이다. 이 기능(하나의 회선이 다운될 경우, 다른 회선으로 트래픽을 주고받는 기능)이 제대로 작동하지 않는다면 애당초 멀티홈 구성을 할 이유가 없기 때문이다.

10월26일 아침에 나타난 현상은 이러한 failover기능이 7:00-7:10 사이에는 작동하지 않다가, 7:10-7:30 사이에는 제대로 작동하다가, 7:30-8:39 사이에는 다시 작동하지 않은 것이다(KT회선을 선관위가 다시 열었던 7:37-7:43 사이 기간은 failover 상황이 아님).

[관련기사]

① 선관위 디도스 공격 기술쟁점
② 선관위 디도스 공격 정치쟁점
③ 디도스 트래픽 용량의 실체
④ 김기창 오픈웹 대표 기고

※ 이번 사건과 관련해 네트워크·보안 전문가들의 의견 및 관련자의 제보를 기다립니다. 이번 보도에 대한 의견, 반론, 제보 등을 전자메일([e-mail])로 보내주시면 추가 취재를 거쳐 다시 한번 기사로 쓰겠습니다. 수사당국이 “신의 영역”이라 밝힌 이번 사건의 실체를 밝히는 일에 많은 분들의 관심과 참여를 청합니다.