안녕하세요. 윤석찬입니다.
이번에 발생한 소위 인터넷 대란을 겪으면서 불합리성의 대명사인 KT의 시스템을 다시 한번 확인하게 되었습니다. 저희 회사의 모든 서버들은 목동 KTIDC내에 위치하고 있습니다. 25일 오후 2시 경 부터 발생한 KT 기간 백본망의 네트웍 이상으로 인해 저희 회사의 서버들의 서비스들이 운영되지 못했습니다. 서버가 다운된 것이 아니라 네트웍에 비정상적인 과도한 패킷때문에 네트웍이 다운 된 것입니다. 이는 마치 고속도로에 차가 너무 많아서 트래픽 잼이 있어나는 것과 같은 현상입니다.
KT는 이 사고가 일어나자 마자 혜화전화국의 DNS서버가 중단 되었으며, 이는 1시간 만에 복구했다고 했습니다. 그러나, 인터넷 불통 사고는 전국 네트웍으로 번졌고 11시간이 넘어서야 간신히 원인과 복구가 어느정도 이루어졌습니다. 아시다 시피 원인은 MSSQL서버의 취약성을 이용한 웜바이러스 였습니다.
이번 웜바이러스는 MSSQL서버의 1434포트의 취약성을 틈타 무작위로 서버의 인터넷주소(IP)를 선정해 초당 1MB이상 큰 용량의 패킷을 취약점이 있는 또 다른 SQL서버에 보내 서버에 부하를 일으켜 시스템을 다운시킨다고 알려져 있습니다. 이러한 데이터가 마구 생성되면 네트웍의 트래픽이 급격히 늘어나고, 어떤 MSSQL서버의 경우 100Mbps가 넘는 트래픽도 유발했다고 합니다.
KT는 사건 최초 발생 당시 DNS서버가 다운되었다고 했다가, 나중에는 서버가 다운된 것이 아니라 네트웍의 트래픽이 과다해서 운영이 되지 않았던 것 처럼 말을 바꾸었습니다.
원래 DNS(Domain Name Server)는 53번의 UDP포트를 이용하고 대체로 53번 포트 이외에는 열지 않기 때문에, 외부의 감염된 MSSQL서버가 특정 DNS를 집중 공격했다는 것은 맞지 않는 말입니다. 만약 MSSQL서버들이 DNS를 공격하기 위해 53번 포트로 dns request를 생성했다 하더라도 이 query는 DNS가 분산 DB인 관계로 서버 구조상 해외의 상위 root server에도 영향을 주기 때문에, 우리 나라만 그것도 특정 ISP의 DNS만 당한다는 것은 있을 수가 없습니다. 뿐만 아니라 기간망의 DNS서버들이 모두 침입탐지시스템(IDS)이나 방화벽 내에 있기 때문에, 외부에서 막혀진 포트로 그런 공격이 오더라도 대부분 막아내게 됩니다.
그러나, 공격을 당했다는 것은 KT의 DNS서버 방화벽에 분명히 DB접속을 위해 1434번 포트가 열려 있었다는 것이고, 공격을 당한 MSSQL서버가 또한 보안패치가 되어 있지 않았다는 것을 반증합니다. 만약 그렇지 않다면 KT 내부에서 누군가가 외부를 공격했던지, KT 내부에 방화벽이 없었다는 결론이 나옵니다. 어떤 결론이든 KT가 책임질 수밖에 없는 상황이라고 보여집니다.
이 문제 때문에 지난 27일 기자들과 계속 통화해 본 결과, KT는 DNS의 DB를 MSSQL을 썼다는 것을 부인하고, 유닉스와 오라클을 쓴다고 발표 했으면서도, 혜화전화국 DNS 담당자와 IDS를 담당한 윈스테크는 서버의 1434포트를 열어 놓았다고 합니다.1434는 통상 MSSQL의 모니터 포트이므로, MSSQL을 쓰지도 않고 OS도 윈도우2000이 아니면서 1434를 열어 두었다는 것은 이상한 일입니다. 또한, KT는 혜화 전화국 DNS서버에 방화벽도 두지 않았다고 합니다. 따라서, KT는 방화벽도 없었고, MSSQL 모니터 포트인 1434까지 열어놨으니 화를 자초한 셈입니다.
따라서, KT의 발표대로 처음 DNS 서버가 다운되었다는 것은 사실은 DNS 서버 운용 네트웍 내에 MSSQL을 사용했다는 점과 이 서버들이 웜에 대한 패치가 되지 않았으며, 실제로 이 서버들이 다른 MSSQL서버들을 공격했을 것이라는 당연한 귀결이 나옵니다.
KT 기간망 내의 발생된 엄청난 패킷은 백본을 다운 시키게 되고, 인터넷 속도를 느려지게 만듭니다. 그러면 다른 ISP 로 부터의 접속 역시 정체되어 속도가 같이 느려지게 되겠지요. 실제로 저희 회사의 서버가 KT-IDC에 있었는데, 몇시간 동안 네트웍 다운 현상이 있었습니다. 그에 비해 KIDC 등 타 IDC서버들은 정상적으로 작동했던 것으로 보입니다. KT가 원인규명을 못하고 DNS서버를 복구시키려고 노력하고 있을때 이미 DNS서버의 DB서버들이 KT내와 타 ISP의 MSSQL서버들을 공격하고 있었을 것이고, 결국 전국적인 네트웍 다운을 만들 수밖에 없었을 것으로 추측됩니다.
물론 우리나라 개발자들의 MS제품 의존도가 매우 높고, 전자상거래와 인터넷 서비스에서 MSSQL이 보편적인 DB시스템인데다가 대부분 DB서버를 로컬 네트웍에 두지 않고, 개발 편의를 위해 인터넷에 개방한다는 점 그리고 보안 의식이 취약하다는 점 모두가 이 사고를 발생시킨 원인이며, 이는 결국 우리나라 보안 의식의 취약점을 반증한다고 볼수 있습니다.
보라넷을 쓰고 회사내에 MSSQL서버가 없는데다 유닉스 기반의 DNS서버를 자체로 운영하는 저희 회사는 며칠 동안 단절현상은 커녕 비이상적인 패킷이 유입되지도 않았습니다. 저희 회사에서 여러 네트웍으로 ping(데이터 정상여부 검증도구)을 이용하여 본 결과, KT이외 망은 토요일 3시 이전까지 별 이상이 없었습니다.
이 내용은 그동안의 개인적인 경험과 그 당시 상황을 비추어 만든 제 개인적인 판단입니다.
/윤석찬 / IT클럽리포터
——————————————-
제가 글을 쓰고 며칠 후, 그리고 최근에 왜 KT DNS서버가 왜 죽었나 하는 기술적인 레포트들이 많이 올라왔습니다. 그 레포트들을 있게한 KT와 보안업체들의 보고에 따르면 실제로 1434번이 공격 받은 것이 아니고, 53번 포트에 트래픽 폭증이 있었으며 트래픽을 일으킨 것은 과다한 리버스 질의(Reverse Query)라는 사실입니다.
이에 대한 이유에 대한 세가지설이 최근까지 제기되었습니다.
1. 감염된 MSSQL서버가 과부하 상태로 갈때, SQL서버 상의 리버스 질의는 하는 과정이 존재하여 DNS에 무리를 주었다.
(전상훈, http://www.securitymap.net/ 1.29)
2. 감염된 MSSQL서버가 다른 윈도우즈 기반 OS를 공격할때 공격받은 시스템이 패킷의 위치를 알기 위해 리버스 질의를 DNS에 보내 무리를 주었다.
(KT, 하우리, 잉카인터넷 1.30)
3. 어떤 원인에서왔든 DNS의 리버스 질의를 서버 설정 문제로 인해 제대로 수용하지 못하여, 계속적인 질의 시도로 서버에 부하를 주었다.
(아이넷트 호스팅 2.9)
1번 2번은 이번 슬래머 웜이 DNS서버 다운의 근본적인 원인이라는 주장이고, 3번은 KT DNS서버의 관리가 제대로 안된 것을 지적하고 있습니다.
1번 주장은 기술자들에서 설득력 있게 받아들여 지고 있지만 실제 윈도우즈 시스템이 블랙박스이기 때문에 현상만으로 판단하기 어려운 점이 있습니다. 2번은 공식적인 KT와 보안업체의 레포트 인데 공격받은 PC가 패킷이 오면 거부만 해버리기 때문에 DNS에 쿼리를 할 필요가 없는데, 억지로 끼워 맞추기를 할려는 의도가 강합니다.
그리고 3번은 실제 리버스질의 양의 증가의 원인은 설명하지 못한채 단지 왜 서버가 죽었나 하는 점만 부각시키고 있습니다.
따라서 아직도 만족할 만한 결론이 나오지 않고 있습니다.
문제는 실제로 KT의 DNS서버만 당했다는 것입니다. 로이터 뉴스에서 실제 웜공격이 있었을때, 최상위 루트 DNS서버 몇 대가 다운됐었다는 뉴스는 사실이 아닌 것으로 밝혀졌고, 당시 루트 DNS서버의 트래픽을 조사해 본 결과 눈에 띄는 문제점은 발견되지 않았습니다. 또한, 필자가 아는 몇 개 연구 기관에서 이번 슬래머 웜 환경을 만들어 테스트해 본 결과 DNS서버의 트래픽 증가는 없었다는 레포트를 받았습니다.
한 가지 분명한 사실은 리버스 질의가 평소보다 아주 많았다는 것이고 특별히 이번 슬래머 웜이 리버스 질의를 만들었다는 어떠한 결론도 없는 것으로 보아, 사용자의 질의과다로 인한 통상적인 리버스 질의로 볼 수 있습니다. 그러나 이 정도의 리버스 질의 증가로 인해 서버가 쉽게 다운 되지 않는다는 사실과 KT DNS 서버의 1434 포트를 오픈했었다는 사실은 뭔가 석연치 않은 감을 가지게 합니다.
인터넷 접속 문제가 어느 정도 해결된 이후, 유독 KT DNS만 질의량이 많았던 것에 대해 마치 KT는 이번 웜 공격에 DNS가 같이 공격당한다는 것 처럼 아직 감염된 서버가 있어서라고 발표하였습니다. 그러나 통상
DNS가 한번 다운 됐다 켜지면 Cache가 없어지기 때문에 Caching을 위해서라도 2~3배 정도 쿼리가 집중되게 됩니다. 전 세계 어디에서든 이번 사고로 DNS서버가 죽었다는 레포트가 없는데도 유독 KT의 DNS 만 다운된 것은 다른 이유가 있었음을 반증하는 것일 수 밖에 없습니다.
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)