그냥저냥: 선관위의 설명 자료.

10. 26. DDoS관련 새로운 의혹제기에 대한 설명자료

2012. 2.

(정보화담당관실)

❍ 홈페이지 웹서버 재기동 의혹에 대하여

- 중앙선관위가 참여연대의 정보공개청구에 의해 제공한 LG엔시스의『중앙선거관리위원회 2011년 10월 26일 재보궐선거 서비스 장애 분석 및 보고서(2011.11.26)』중 첨부3. 의 ‘3.6 홈페이지 웹서버 #1 상세 분석 내역’ 및 ‘3.7 홈페이지 웹서버 #2 상세 분석 내역’에 따르면 홈페이지(www.nec.go.kr) 웹서버 #1과 #2 각각 점검결과 항목에 ‘이상없음. 메모리 증가 현상으로 인한 장애방지 차원에서 06:54분에 사용자에 의해 재기동됨’ 이라는 내용이 기재되어 있습니다.

- 이 내용을 근거로 ‘나꼼수 봉주6회(’12.2.22 방송분)’에서는 당일 12시부터 웹 서버 메모리가 100%에 이르러 리부팅을 해야 하는데 오전 6시 52분 내지 54분까지 조치를 하지 않고 버티다가 리부팅을 하자마자 KT 회선 2개를 끊어버려 서비스를 의도적으로 차단한 것이라고 주장하고 있습니다.

- 김기창 교수는 오픈웹 사이트에서도 다음과 같이 ‘나꼼수’와 유사한 의혹을 제기하고 있습니다.

․ 당일 0:00(또는 그 이전) 부터 6:54까지는 홈페이지 웹서버 RAM 메모리가 (어떤 이유에선가) 포화 상태로 내내 있었기 때문에 접속 요청을 제대로 처리하지 못했다.

․ 홈페이지 웹서버가 reboot되어 메모리 포화 상태가 해소되자, 5분 뒤인 7시 부터는 그동안 널널하게 트래픽을 처리하던 상황에서 KT망 두개를 자르고 LG망 하나로만 모든 트래픽이 몰리도록 한 다음, 누군가가 선관위 스위치 라우터를 계속 장난질쳐서 선관위로 트래픽이 오고가기 어렵게 만들었다가 8시 반에 KT망 두개를 다시 연결하여 정상화 된 것으로 보인다.

- 또한 시스템개발자 barry_lee씨는 다음과 같은 의혹을 제기하고 있습니다.

․ 디도스 공격이 시작되었는데, 디도스에 대한 대응을 먼저 하지 않고 한가하게 홈페이지 서버 재시작이나 하고 있었다.

․ 서버의 재시작은 뭔가 설정을 변경했을 때 하기도 하므로 의혹의 여지가 있다.

․ 디도스로 트래픽이 꽉 차있는데 IDC에 있는 선관위 웹서버에 접근을 해서 재기동 한다는 것은 말이 안된다.

➜ 이러한 주장은 10.26. 디도스 공격으로 06시부터 08시30분경까지 중앙선관위 홈페이지 접속장애가 있을 당시 홈페이지 웹서버가 메모리가 포화되어 서비스 처리가 제대로 되지 않았고, 이 장애는 KT 회선 절체와 서로 연관을 가지고 누군가에 의해 의도적으로 이루어졌다는 가정에 근거하고 있지만, 이는 기술적 부분 및 기초적인 사실에 대한 오해에서 비롯된 것으로 사실과 다름

1) 당일 06시 52분과 06시 54분에 메인 홈페이지 서버를 재기동한 것은 시스템 재기동(reboot)이 아니라 웹서버 데몬을 재기동한 것입니다. 웹서버 재기동 하는 동안 웹서비스가 중단되지 않으며, 또한 rebooting이 아니므로 설정 변경도 없었음

 아래 표와 같이 재기동시간은 서버의 종류마다 다르며, OS를 reboot 하려면 최소 15분 정도 걸림. 따라서 두 대의 서버를 reboot 하려면 총 약30분 정도 소요되었을 것이며, 2분 간격으로 두 대의 웹서버를 재기동 했다는 것만으로도 보고서의 재기동은 데몬 restart임을 알 수 있음

구분

종료소요시간

(명령어)

기동소요시간

(명령어)

총 소요시간

웹서버

(WebToB)

약 3초 이내

(wsdown)

약 3초 이내

(wsboot)

약 6초 이내

WAS서버

(JEUS)

약3~5분

(jdown)

약3~5분

(jboot)

약 10분 이내

H/W

(유닉스서버)

약 5분

약 5~10분

약 15분 이내

* 중앙선관위 웹서버 구성 : 웹서버 WebtoB, WAS는 Jeus, H/W는 유닉스 서버 사용.

 데몬 재기동 시 이중화된 두 대의 웹서버 데몬을 차례로 재기동했기 때문에 재기동하는 동안 서비스 중단이 발생하지 않았으며, 심지어 서버 reboot를 했다고 할 지라도 두 대의 웹서버를 차례로 재기동할 경우 서비스 중단이 발생하지 않았을 것임

2) 웹서버의 memory saturation 현상은 WebtoB 소프트웨어의 버그 때문임

 10.26. 당시 선관위 웹서버 버전은 WebtoB 4.1.0.2 버전으로, PipeLine Request 시 memory leak 버그, 즉 PipeLine Request의 응답이 304 또는 hth cache 일 경우 memory를 해제하지 않는 버그가 존재함 (티맥스 WebtoB 릴리즈 노트)

 선관위의 웹서버 담당자는 이 버그를 10.26. 전에 인지하였으나, 선거기간 중 시스템 패치작업은 서비스 중지 등 예기치 못한 위험이 발생할 수 있기 때문에 티맥스소프트 엔지니어에게 문의한 결과 해당 버그는 서비스에 미치는 영향이 심각하지 않다는 회신을 받고 선거 후에 패치하기로 협의하였으며, 10.26. 당일 memory saturation 현상은 웹서버 데몬 재기동으로 조치한 것임

 메인 홈페이지 뿐 아니라 선거정보 웹서버(info.nec.go.kr) 5대의 메모리 사용율 그래프도 유사한 패턴을 보이는 것 역시 WebtoB의 버그 때문이며, 이 또한 메모리 증가 현상으로 인한 장애 방지 차원에서 20시 28분에 재기동(데몬 restart)한 것임

3) 메인 홈페이지 웹서버의 memory saturation 현상으로 인한 서비스 장애는 없었음

 선거 당일 홈페이지는 평소 운영하는 홈페이지가 아니고 선거정보(info.nec.go.kr) 사이트로 안내하기 위한 약 7KByte 크기의 intro page로 교체됩니다. 이 페이지는 DB와 연결되는 동적 페이지는 없고 html 코드만 정적(static)으로 보여주는 화면입니다. 따라서 동일한 요청(request)에 대해 caching이 되므로 메모리가 추가로 소요되지 않음

 00시부터 웹서버 데몬을 재기동한 07시까지 메인홈페이지 웹서버 중 1대는 16GByte 메모리 중 98.4%를 사용하고 약 260MByte의 가용 메모리를 가지고 있었으며, 다른 한 대의 웹서버는 약 2.32GByte의 가용 메모리를 가지고 있어 총 2.58GByte의 가용 메모리를 가지고 있었으며, 당시 담당 엔지니어는 비록 메모리의 사용율이 높기는 하지만 서비스에 문제가 없다고 판단되어 계속 모니터링만 하고 있었음. 그런데 디도스 공격으로 인해 홈페이지 접속 장애가 생기자, 만약의 경우에 대비하여 7시경 웹서버 데몬을 재기동하여 웹서버 한 대는 260MByte에서 4.85GByte로, 다른 한 대는 2.32GByte에서 4.56GByte로 총 5.97GByte의 여유 메모리를 확보한 것임

 선거정보(info.nec.go.kr) 웹서버 5대는 총 메모리 30.19GByte를 확보하여 정상적으로 작동하였음

4) 선관위의 시스템은 통신서비스 사업자의 IDC에 입주해 있지 않고, 자체 전산실을 보유하고 있음

 디도스로 모든 회선이 막힌 상태에서 선관위 서버 담당자가 어떻게 원격에 있는 웹서버에 접근하는 것은 불가능하며 누군가에게 지시를 내렸다는 의혹을 제기하는 것은 선관위 시스템 구성에 대한 오해에서 비롯된 것임. 웹서버 재기동은 서버 담당자가 전산실에서 직접 작업하였으며, 또한 서버 담당자와 통신, 보안 담당자가 서로 다르기 때문에 각자 자신이 맡은 역할을 수행한 것이지, 디도스에 대한 대응을 뒤로하고 한가하게 웹서버 재기동을 한 것이 아님

❏ 결 론

 중앙선관위 메인 홈페이지(www.nec.go.kr) 웹서버의 재기동은 시스템 rebooting이 아닌 웹서버 데몬 restart로 KT회선 절체와 직접적인 관련이 있는 것이 아니며, 웹서버 재기동으로 인한 서비스 중지가 발생하지 않았음

 메인 홈페이지 웹서버 메모리 포화시에도 약 2.58G의 가용 메모리가 확보되어 있었으며, 실제로도 웹서버로 인한 서비스 장애는 발생하지 않았음

❍ 세개의 회선으로 넉넉하게 처리하던 상황(회선 총용량의 절반에도 못미치는 트래픽을 처리하던 상황)에서 회선 두개를 끊은 이유는?

➜ KT 2회선을 차단하고, LG　U+ 1회선을 유지하는 결정을 하는 당시의 상황은 우리위원회 홈페이지 접속장애 현상에 대한 원인 파악과 조치단계에서 KT 2회선으로 대량의 패킷이 유입되는 DDoS로 공격으로 인지 한 후, 우리위원회가 2011. 3. 제정하여 운영 중인 『분산서비스거부(DDoS)공격 대응지침』중 DDoS공격 대응절차의 3단계 초동조치에 의거 공격으로 사용되는 좀비 PC를 차단하는 조치를 취하며, KT와 공조를 통해 KT측에서도 접속차단 하도록 조치를 취하고 있었음.

➜ 당시 LG　U+ 1회선의 사용량은 경미한 상태였고, KT측으로 들어오는 DDoS 공격을 ACL등록 방법으로 완화시키는 조치에 한계가 있는 것으로 판단하여 KT 2회선을 차단하는 결정을 하게 되었음

➜ 이러한 결정은 『분산서비스거부(DDoS)공격 대응지침』중 DDoS공격 대응절차의 5단계 차단조치에 의거 조치한 사항임

다. 3단계 : 초동조치

❍ DDoS공격으로 판명되면, 정보보호담당실무자는 기술대응절차서에 따라 장비별 담당실무자로 하여금 피해규모를 최소화하기 위하여 공격IP주소 차단, 장비 임계치 조정 등 기본조치를 수행하도록 한다.

(중략)

마. 5단계 : 차단조치

(중략)

❍ 정보보호담당실무자는 DDoS공격에 대한 지속적 차단조치에도 불구하고 피해범위가 계속 확산되고 방어조치가 원활히 이루어지지 않는다고 판단되면, 정보보호책임관 및 정보보호책임자에게 보고하고 네트워크 케이블의 일시단절 및 서버 재부팅 등 강력한 대응조치를 수행할 수 있다.

❍ 10. 26. 당시 총 465Mbps(KT : 310Mbps(155Mbps 2회선), LG U+ :155Mbps 1회선)의 회선 용량에 263Mbps 또는 221Mbps의 사용량을 계산하여 56% 정도 사용하였다는 견해에 대하여

➜ 최소 경로를 배정받는 라우팅 경로상 KT회선으로 들어오는 경로가 최소경로임에 따라 (LG회선에 연결된 라우터의 BGP정책에 따라서 사용자는 KT회선으로 최소경로를 배정받아 들어옴) KT회선으로 유입된 패킷이 많았음

➜ DDoS공격 발생 상황이 아니더라도 평시에도 KT회선을 주로 많이 사용하고 있으며, LG U+에 가입된 가입자의 경우 LG U+ 회선이 연결된 구간을 이용하게 됨

➜ 따라서 모든 사용자에 대해 KT 2회선과 LG U+ 1회선 총 3회선 즉 465Mbps를 적정하게 이용할 수 있도록 하는 것이 아니며, 사용자가 가입된 통신사업자의 중앙선관위 접속경로 중 최소경로를 배정받아 접근하는 방법이 적용됨에 따라, KT 회선의 이용률이 LG U+보다 상대적으로 많게 됨

➜ KT회선의 310Mbps이고 이것을 기준으로 하여, 선관위에 연결된 라우터 인터페이스가 ATM모듈임에 따라 이더넷으로 변환 시 Data패킷이 차이가 발생함 (ATM header를 Ethernet header로 변환하는 과정을 거치므로 약 85%의 속도를 지원하는 것으로 되어 있음. OC-3 155Mbps의 경우 약 130Mbps의 속도를 낼 수 있음)

(KT와 LG U+의 공식적인 입장임)

※ LG U+를 제외한 KT, SK Broadband, 기타 통신사업자의 경우 KT회선을 주로 이용하게 됨 (통신사업자의 공식적 의견 임)

※ LG U+ 회선에 연결된 라우터 Config 내역

router bgp 3XXXX

no synchronization

bgp router-id 210.XXX.XX.XX

bgp log-neighbor-changes

network 58.XXX.XX.XX mask 255.255.255.0

network 210.XXX.XX.XX

network 210.XXX.XX.XX mask 255.255.255.192

neighbor 58.XXX.XX.XX remote-as 9950

neighbor 58.XXX.XX.XX soft-reconfiguration inbound

neighbor 58.XXX.XX.XX route-map permit_subnet_prepend out

neighbor 58.XXX.XX.XX filter-list 1 out

neighbor 172.XXX.XX.XX remote-as 3XXXX

neighbor 172.XXX.XX.XX next-hop-self

neighbor 172.XXX.XX.XX soft-reconfiguration inbound

no auto-summary

route-map permit_subnet_prepend permit 10

match ip address prefix-list permit_subnet

set as-path prepend 3XXXX 3XXXX 3XXXX

❍ KT망을 끊기 전 06:58 상황은 긴박하지도 않았고, 유입트래픽은 회선 용량 절반에도 훨씬 못 미치고, 디도스 방어장비는 공격트래픽을 말끔히 걷어내고 약 10M bps 규모의 정상 트래픽을 통과시키고 있는 상황이었다는 견해에 대하여

➜ 06:46경 KT회선 #1을 차단(Sub interface down)함으로써 KT회선 #2를 통해 유입된 패킷에 대한 용량이며, DDoS 장비에 유입된 패킷은 2개의 회선을 유지시킬 당시보다 감소한 현상을 보이고 있는 것임

Oct 26 06:39:55: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.5 Down BGP Notification sent

Oct 26 06:39:55: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.5 4/0 (hold time expired) 0 bytes

Oct 26 06:42:40: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.5 passive 2/8 (no supported AFI/SAFI) 3 bytes 000101

Oct 26 06:46:04: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Down Interface flap

Oct 26 06:46:33: %SYS-5-CONFIG_I: Configured from console by console

Oct 26 06:47:22: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Up

Oct 26 06:47:24: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.5 passive 4/0 (hold time expired) 0 bytes

Oct 26 06:47:39: %SYS-5-CONFIG_I: Configured from console by console

Oct 26 06:49:00: %SYS-5-CONFIG_I: Configured from console by console

Oct 26 06:49:28: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Down BGP Notification sent

Oct 26 06:49:28: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.1 4/0 (hold time expired) 0 bytes

Oct 26 06:49:40: %SYS-5-CONFIG_I: Configured from console by console

Oct 26 06:49:48: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Up

Oct 26 06:51:24: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Down BGP Notification sent

Oct 26 06:51:24: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.1 4/0 (hold time expired) 0 bytes

Oct 26 06:51:42: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX..1 Up

Oct 26 06:53:47: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Down BGP Notification sent

Oct 26 06:53:47: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.1 4/0 (hold time expired) 0 bytes

Oct 26 06:54:05: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Up

Oct 26 06:56:16: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.1 Down BGP Notification sent

Oct 26 06:56:16: %BGP-3-NOTIFICATION: sent to neighbor 172.XXX.XX.1 4/0 (hold time expired) 0 bytes

Oct 26 06:56:24: %SYS-5-CONFIG_I: Configured from console by console

Oct 26 06:56:34: %BGP-5-ADJCHANGE: neighbor 172.XXX.XX.5 Up

❍ 6시부터 오후 1시까지 LG 망이 이상 증상을 보였다. (경로를 못 찾고 헤매는 현상)견해에 대하여

➜ 07:00경 KT회선 단절 후 LG U+망을 이용하였으며, KT 사이버대피소로 이동한 후 08:53 ~ 13:11 까지는 LG U+망을 이용하지 않음

❍ 이 보고서만으로 판단할 때, 선관위 라우터에 디도스 공격이 도달한 시점은 5:50부터 7:00 뿐이다. 7:00에서 8:32 까지는 KT 망이 끊어졌기 때문에 선관위 라우터에 도달한 디도스 공격이 없었다는 견해에 대하여

➜ KT회선이 연결된 라우터의 Sub interface를 down하여 LG U+회선으로 패킷이 유입되었으며, 디도스 대량 패킷이 유입되어 라우터의 BGP가 up/down되는 현상이 발생하여 정상적인 서비스가 어려운 상황이었으나, 이 상황에서도 DDoS패킷이 유입되었음

Oct 26 07:00:56: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:00:56: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:01:28: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:01:41: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:01:41: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:02:13: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:02:25: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:02:25: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:02:57: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:03:10: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:03:10: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:03:42: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:03:55: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:03:55: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:04:27: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:04:38: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:04:38: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:05:11: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:05:23: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:05:23: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:05:55: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:06:11: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:06:11: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:06:43: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:06:56: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:06:56: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:07:28: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:07:40: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:07:40: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:08:12: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:08:24: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:08:24: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:08:56: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:09:08: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:09:08: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:09:40: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:29:38: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:29:38: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:30:10: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:30:22: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:30:22: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:30:54: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:31:06: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:31:06: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:31:38: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:31:59: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:31:59: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:32:31: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:32:44: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:32:44: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

Oct 26 07:33:16: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Up

Oct 26 07:33:28: %BGP-5-ADJCHANGE: neighbor 58.XXX.XX.161 Down BGP Notification sent

Oct 26 07:33:28: %BGP-3-NOTIFICATION: sent to neighbor 58.XXX.XX.161 4/0 (hold time expired) 0 bytes

❍ LG U+망이 제대로 작동하지 않은 이유는 BGP Down으로 인해 트래픽이 제대로 전달되지 않았다고 되어 있다. 이는 원래 155MBps의 회선 대역폭이 있는데 여기에 200MBps가 유입되었고, 이 과정에서 30MBps 만 전달되고 나머지는 아예 상호 전송이 안되는 이상 현상이 발생됐다는 의미다. 하지만 아래 그래프 만으로는 LG U+망에 200MB가 유입된 흔적을 찾기 어렵다는 견해에 대하여

➜ LG U+로부터 제공된 MRTG 그래프에 의하면 약 200M의 트래픽이 선관위로 유입되었음.

중앙선거관리위원회 DDoS관련 기술분석 보고서 中 12페이지 (3-2. DDoS장비 등 분석결과(5)

❍ LG U+망은 왜 비정상 동작했는가?

➜ 대량의 DDoS 공격패킷에 기인하여 BGP up/down현상이 지속적으로 발생하여 정상적인 작동이 어려운 상황이었음