[보안사고 분석] 1.25 대란은 1월 25일에 일어나지 않았다

옛날 이야기 하나 해볼까 한다.

2003 1월 24토요일 오후 2시경이었다. 

요즘은 스마트폰이지만당시 집에서는 노트북으로 인터넷 서핑을 달고 살았는데 갑자기 접속이 느려졌다다음(daum)도 느리고 야후(yahoo)도 잘 안 되는 걸로 봐서 서버 측 문제는 아니고케이블 인터넷 서비스(두루넷)을 사용 중이었다흔한 통신 회사의 문제이려니 했다잠시 후 TV 에서 해외도 큰 피해가 발생했고국내도 KT에서 문제가 생겨서 전체 인터넷 서비스가 먹통이 되었다고 한다얼마 후 정보통신부에서는 "인터넷 이용자가 보안 의식이 낮아 악성코드에 감염이 된 것이 원인” 이라고 공식 입장을 발표하고백신을 설치하고 운영체제를 업그레이드(보안 패치)해야 한다고 했다.

 거의 20년 된 일이니 이제는 기억도 못하는 사람이 많겠지만정확한 장애 원인은 아직 밝혀지지 않은 것 같다인터넷 접속이 느려진 이유는사용자가 웹사이트에 접속할 때 입력하는 도메인 주소(dns name)  IP 주소로 변환시켜주는 기능을 제공해 주는 DNS(Domain Name System) 서버에 과부하가 발생했기 때문이라고 발표되었다사용자가 웹브라우저에서 웹사이트 주소(ex: www.daum.net)를 입력해도 PC나 인터넷 라우터(router) 같은 통신 장비가 이해할 수 있는 주소(ex: 114.108.157.155)로 변환을 할 수 없어결국 실제 웹 서버로 패킷을 송신조차 못해보게 되는 것이다그런데 DNS 서버에 과부하가 걸린 원인이 불명확하다.

 당시 악성코드는 슬래머웜’ 으로 마이크로소프트(MS)의 기업용 DBMS 제품인 MSSQLServer2000의 보안 취약점을 이용해 전파됐다서버(또는 PC)가 감염되면 추가 확산을 위해 동일한 감염 시도 패킷을거의 무작위로 생성한 IP 주소로 보낸다인터넷상의 많은 다른 주소로 패킷을 보내려고 하기 때문에 대량의 트랙픽이 DNS 서버에 몰렸다고 했다하지만 목적지가 웹 도메인이 아니라 “IP 주소가 지정된 패킷은 해당 서버로 직접 가지, DNS 서버에 Query를 보내지 않는다그래서 KT DNS 서버와 동일 내부망에 슬래머웜에 감염된 MSSQL 서버가 있어서 내부망 전체가 마비되었을 것이라는 주장도 있었다.

 참여연대 등 시민 단체들은 1.25 대란에 대해 책임 규명이 없었다는 이유로 정보통신부와 KT 등 통신서비스 업체와 마이크로소프트사를 대상으로 피해보상을 요구하고 손해배상소송을 진행했다냉정하게 보면많은 기업과 시민들이 피해를 입은 것은 사실이지만 정부나 KT, 마이크로소프트도 피해자 중의 하나이지 않는가슬래머웜을 제작하고 퍼뜨린 해커만 찾아서 처벌하면 되지 않는가그렇다고 해도 동일한 사고가 재발되지 않을 것이라고 말할 수 없으므로하나씩 차분하게 재검토해보자.

 당시전세계에서 해당 취약점에 대한 보안 패치를 설치하지 않은 MSSQLServer 의 약 90% 7 5000대가 10여분 만에 슬래머웜에 감염되었으며그 중 약 12%인 8,800여대가 국내에 있었다고 한다즉 겨우 8,800 여대의 서버 또는 PC에 악성코드가 감염되어 국내 인터넷 전체가 거의 마비된 것이다요즘 같으면 상상이 잘 안 갈지도 모르겠다.

먼저, DNS 서버에 과부하가 걸린 원인은 모르겠지만아무튼 증상으로 KT DNS 서버 용량이 부족했으니용량을 대폭 늘리면 해결되지 않았을까 생각을 할 것 같다당시도 100MBps 급 인터넷 서비스가 많이 보급되긴 했었지만전반적으로 인터넷 서비스의 처리 속도가 더 빨랐으면 괜찮았지 않았을까 생각도 할 것 같다만일 그랬다면조금 더 짧은(빠른시간에훨씬 더 많은 양의 슬래머웜 전파 패킷이 발생하면서 결국 동일한 결과를 가져왔을 것이다. DNS 서버가 용량이 남아돌아 멀쩡했더라도 인터넷망은 슬래머웜 감염을 위한 패킷(UDP 1434)으로 가득 찼을 것이다웜은 서버나 네트웍이 허용하는 한도까지 최대 용량으로 전파 패킷을 계속 보내고감염 대수는 모든 서버가 감염될 때까지 기하급수적으로 늘어나기 때문이다생물학적 바이러스가 시골보다유동인구가 많고 교통이 발달한 도시에서 더 감염속도가 빠르고 피해가 큰 것과 같은 원리이다.

 그럼에도 불구하고사고 대책으로 KT DNS 서버와 회선 용량을 대폭 증설했다결과적으로 이것만으로 제한해서 보면향후 동일한 문제가 생겼을 때악성코드의 전파 속도만 더 빨라지고피해는 줄어들지 않는다기술적으로 보면 KT도 피해자였지만당시 공기업으로서억울하더라도 정부 입장에 반하는 행동을 하기 힘들었을 것 같다그 심정 이해는 한다하지만 내부자 고발까지는 아니더라도 뭔가 아쉬움이 남는다시스코, HP 같은 통신 장비나 서버 사업자는 매출이 올라서 속으로 많이 좋아했을 것 같다.

 정부에서는 일반 인터넷 이용자의 낮은 보안의식이 근본 원인이었다고 말했다포커스를 너무 확대해서 흐려놨다악용된 MSSQLServer나 관련 개발 모듈은 모두 일반 개인이 구하거나 가정용 PC에 설치가 쉽지 않은 기업용 프로그램이며일부 예외를 제외한다면 모두 기업용 서버나 기업 내 전산 업무용 PC에만 설치되어 있다.

굳이 책임을 묻자면 기업의 서버 관리자가 우선이 될 것 같다마이크로소프트에서는 해당 취약점과 함께 패치를 약 6개월 전인 2002년 7월에 이미 발표했다자기가 관리하는 서버의 보안 취약점을 장기간 방치한 채로 전국민이 함께 사용하는 인터넷에 방화벽도 없이(또는 방화벽에 불필요한 포트까지 다 열어둔 채로연결해둠으로 인해 자사의 서버뿐만 아니라 공공재인 인터넷 서비스를 과다하게 점유한 것이다.

웜은 특성상감염된 서버나 PC 도 피해를 입히지만그 주인의 의사에 관계 없이 주변에 더 많은 피해를 입힌다그렇다고 해서 일반 이용자에게 보안 패치를 안 한 직접적인 책임을 묻기는 어렵겠지만 기업의 서버 관리자라면 월급 받고 하는 일인데 일정 수준 책임이 따른다고 봐도 될 것 같다.

 1.25 대란은 당시 초대형 사건이었다요즘은 그런 일 없겠지 라고 생각할지도 모르겠다인터넷의 속도도 더 빨라졌고인터넷에 연결된 PC나 서버의 대수도 더 많고인터넷을 통한 업무나 기업용 서비스 의존도도 더 높아졌다그만큼 리스크가 더 커졌을 뿐이다하지만여전히 기업용 서버 운영체제나 DBMS는 성능만 좋아졌을 뿐관리자가 계정관리를 소홀히 하거나보안패치를 제대로 하지 않는 경우가 여전히 많으며일반 업무용이나 가정용 PC도 악성코드가 전혀 감염되지 않은 것을 찾기가 더 어려울 정도다.

 2009 7.7 DDoS 대란, 2011년 농협의 전산망 장애, 2013 3.20 사태 등 대부분의 해킹사고도 악성코드의 감염에서부터 시작되었다거의 모든 해킹의 시작은 공격 대상의 PC나 서버에 악성코드를 침투시키는 것으로 시작한다악성코드 감염의 주요 원인은 취약한 계정(ID/PWD) 방치보안패치 미적용확인되지 않은 프로그램 실행이다.

 보안 담당자라면 다들 알고 있고서버나 PC를 관리하는 실무자도 알고 있다다만 심각성을 인식 못 하거나 다른 우선 순위의 일이 많아서 하지 못할 뿐이라고 속단할 수도 있다제대로 해보기 전에는 알 수 없는 일이다간단해 보여도 쉽지 않다보안 담당자가 단독으로 할 수 없기 때문에 더 어렵다우리 회사만 해도 사내 전체 PC나 서버 대수가 몇 대인지 현황 파악도 어렵다그 외 다양한 목적의 무인기기와 노트북갤럭시탭 같은 스마트 기기까지 있다한 대도 빠짐 없이 100% 정보 자산 파악도 어렵고사내 모든 장비의 운영체제와 모든 운영되고 있는 응용 소프트웨어에 대해서 적기에 보안 패치를 적용하는 건 현실적으로 불가능하다특히 서버 OS DBMS는 업무 영향도를 고려하면 더욱 그렇다.

더군다나 말이 쉽지출처 불확실 등 의심 가는 프로그램은 함부로 실행하지 않는 게 일반 PC 사용자에게 가능한 것인지 반문도 된다인터넷이 일상화되고 쇼핑몰에서 물건 하나 결제할 때도 여러 개의 프로그램(ActiveX)를 설치해야 하는데도대체 출처가 확실한 것의 기준은 뭐고, IT와 보안 전문가인 나도 못하는 걸 일반 사용자에게 교육하고 규정에 반영하는 것은 한편으론 책임 전가가 아닌가 반문도 든다.

 그렇지만해야 한다너무나 기본적이고 중요하기 때문이다보안은 완벽할 수 없다고 포기 하는 게 아니라 가능한 부분까진 해야 한다쉽진 않지만 리스크를 평가해서 인적금전적 자원을 효율적으로 배분해야 한다. CISO CEO CIO 및 현업 부서를 설득해야 한다. CIO의 능동적인 지원과 정보시스템의 자산 관리 체계 구축충분한 IT 관리 인력 충원 등의 지원이 필요하다.

modified at
Aug. 27, 2022, 1:36 p.m.
admin
Aug. 22, 2022, 12:37 a.m.
0개의 댓글이 있습니다.