code toolbox

보안 제품의 기능 확장·웹 보안과 결합 지속

컴퓨터를 사용하는 사람들은 누구나 한 번쯤은 바이러스에 걸려서 고생을 하거나 애드웨어 때문에 원하지 않는 광고 창을 닫느라 땀을 흘린 경험을 가지고 있다. 또 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌린다. 이러한 악성코드는 나름대로 각각 ‘성격’을 가지고 있다. 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있는 것이다.

단, 스파이웨어는 사용자가 알아차리지 못하게 정보를 빼돌리고 있었으니 눈에 띄는 직접적인 피해나 번거로움은 없었을지도 모르지만, 쇼핑 사이트나 이동통신 사이트의 사용자 정보 유출 뉴스를 듣고 나면 며칠 후부터 메일과 SMS를 통하여 증가하는 스팸과 광고에 짜증내 본 기억도 떠오를 것이다. 

사용자를 불편하게 하고 정보를 빼내려는 이러한 악성코드가 사라진다면 얼마나 좋을까? 하지만 마치 사회에서 도둑이나 강도가 없길 바라지만 사라지지 않듯이, 운영체제를 만드는 마이크로소프트가 ‘신뢰할 수 있는 컴퓨팅’을 내세우며 보안을 강화해 나가더라도 악성코드는 줄어들지 않고 더욱 교묘하고 은밀하게 정보를 빼내가려고 하고 있다. 도둑이나 강도가 없는 세상은 사람들이 모두가 천사가 되는 영화나 소설 속에서나 가능할 것 같다. 

영화나 소설과 같은 이야기가 나왔으니 이어서 비유를 해보자면 베트맨에 나오는 악역인 조커의 캐릭터처럼 악성코드도 ‘성격’을 가지고 있다. 그리고 이 ‘성격’은 탄생 초기에는 어설펐지만 수많은 운영체제와 사용자 환경을 겪으면서 ‘진화’해 가고 있다. 사실, 운영체제가 점점 더 거대해지고 많은 기능을 제공하면서 악성코드가 가질 수 있는 ‘성격’은 점점 더 다양해지고 있는 현실이다. 

그렇다면 최근에 등장하는(또는 등장한 걸 모를 수도 있는) 악성코드들은 어떤 ‘성격’을 가지고 있을까? 악성코드의 미래를 이야기하기 전에 이들의 성장과정인 필모그라피(filmography)를 먼저 아는 것이 도움이 될 것이다.

악성코드, 점점 자신을 숨기다

초기의 악성코드들은 순진한 ‘성격’을 가지고 있었다. 바이러스에 감염되면 벽에 낙서를 하듯이 “아무개 여기 다녀가다”라는 식으로 표시를 하거나 프로그램 내부에 특정한 문자열을 심어서 자신의 사인으로 남기기도 했다. 그냥 어디엔가 자신의 이름이 나온다는 것이 재미있는 그런 호기심 많은 사춘기와 같은 시기였을 테니까. 

그렇게 얌전했던 성격은 1990년대 후반에 들어서면서부터 심각하게 삐뚤어지기 시작했는데, 컴퓨터 운영 체제가 도스(DOS)를 사용하던 것에서 윈도우(Windows) 형태로 바뀌면서부터 더 악동 같은 짓을 하게 되었다. 왜냐하면 윈도우 환경은 집에서 혼자 장난감을 가지고 놀다가 동네 놀이터에 나가서 놀게 되는 것처럼 더 넓고, 더 다양하고, 더 많은(사실 이것이 중요하다! 공격할 수 있는 대상이 무지막지하게 늘어났으니!) 환경을 제공해 주었다. 그뿐만 아니라 인터넷의 대중화는 이러한 놀이터를 연결해서 놀이 동산에 입장한 것처럼 사람들을 쉽게 연결할 수 있게 되었고 악성코드를 만들어서 시험해볼 수 있는 좋은 놀이터를 제공하게 되었기 때문이다. 

그럼 악성코드는 왜 놀이터를 헤집고 다니게 되었을까? 아이러니컬하게도 악성코드를 만들기 쉬워진 것은 GUI(Graphic User Interface)를 제공하는 운영 체제와 Visual C 등으로 편리해진 프로그래밍 덕분이다. 왜냐하면 악성코드도 사용자가 의도하지 않은, 하지만 그 프로그램을 만든 누군가가 원하는 무엇인가를 수행하는 하나의 소프트웨어이기 때문이다. 

악성코드들이 순진함에서 점점 삐뚤어진 성격을 가지게 되면서 좀 더 강렬하고 자극적이고 치명적인 모습으로 진화해가기 시작했다. 왜냐하면 보안 회사들의 방어 능력도 점점 좋아지고 빨라졌고 운영 체제를 만들던 마이크로소프트도 자사 운영 체제의 취약점을 보완하기 위해서 많은 노력과 투자를 하기 시작했기 때문이다.

쉽게 이야기하면 초기에 지은 집들은 방범이 허술해서 도둑이 쉽게 들어올 수 있었지만, 경비원을 두고 주인이 직접 문을 점검하고 다니니 악성코드들은 문을 열고 들어오기 위해서 더 힘들게 고생을 해야 했다. 마치 영화 ‘미션 임파서블’에서 컴퓨터에 접근하기 위해서 줄을 타고 내려와서 대롱대롱 힘들게 매달려 있어야 했던 것처럼 말이다.

악성코드, 당신의 안방을 노리다

위에서 간단하게 살펴본 것처럼 악성코드들은 점점 지능적으로 변해갔다. 들키지 않고 오래 남아 있어야 하고 사용자 몰래 무엇인가를 해야 하기 때문이다. 더 강화된 방범 시스템을 피하기 위해서 더욱 높은 수준의 변장과 다양한 침투 도구들이 필요하게 되었다. 사용자들도 한 두 번쯤은 악성코드에 당하게 되면서 인식이 높아졌기 때문에 악성코드를 쉽게 만들어서 마구 뿌릴 수 있던 그런 시절은 지나가버렸다. 

무척 힘들게 집에 침입한 도둑이 그냥 벽에 낙서만 하고 돌아설까? 그냥 가기엔 도둑 입장에서 무언가 허전하고 아쉽고 바보 같은 느낌이 든다. 그렇다. 힘들게 집에 들어갔으니 돈이 될만한 무엇인가를 좀 들고 나가야겠다. 사실 악성코드를 만들 수 있는 정도의 수준이면 사용자의 컴퓨터에서 무엇인가를 집어 나가는 것은 어려운 일도 아니다.(만들어진 것을 이용하는 사용자와 그것을 만들어주는 개발자의 차이란 참으로 크지 않던가?) 

그래서 처음에는 그 집에 있는 돈이 될만한 정보들을 들고 나가기 시작했다. 대표적으로 사용자의 개인 정보를 노리기 시작했고 사용자에게 광고를 보여주고 돈을 벌어보기도 했다. 그 다음에는 사용자의 금융 정보, 그리고 나중에는 사용자의 데이터 파일까지 내보내기 시작했다.(이쯤 되면 악성코드의 성격이 참 많이 빗나가고 있다.)

악성코드, 크게 한 방을 노리다

보안 소프트웨어의 방어 노력과 사용자의 높아진 경각심으로 인하여 악성코드들은 새로운 방법을 모색하기 시작했는데 그것은 바로 눈에 띄지 않게 더 숨어버리는 것이었다. 처음부터 들어가서 노골적으로 무엇인가를 가져가려고 하니 잘 들키게 되어서, 이젠 몰래 들어간 후에, 훗날을 기약하는 원격 조정 폭탄(?)을 조심스럽게 심어놓는 것이다. 

악성코드가 사용자의 PC를 조금씩 조금씩 장악해 나가면서 자신만의 꿈을 키워 나갔는데 그것은 바로 사용자 PC에 심어놓은 원격 조정 폭탄들을 동원하여서 한 탕 크게 하는 것이다. 말하자면 은행강도 정도로 크게 한탕하고 도망가는 것이라고 할까? 힘들게 한 탕을 하려니 개인 사용자 수준의 정보로는 부족하고 기업이나 기관의 큰 데이터베이스를 노리거나, 공격에 대한 예고를 통해 돈을 요구하는 형태로 발전하게 되었다. 지금도 특정 사이트를 공격하는 D-day가 되면, 많은 개인 사용자 PC들이 사용자도 모르게 좀비가 되어서 공격에 동원되는지 알 수 없을 정도이다. 

여기까지 오게 되면 순진하게 시작되었던 악성코드의 성격은 수많은 좀비를 앞세운 무장강도 수준으로 삐뚤어진 성격이 되어버린 것이라고 할 수 있겠다. 지금은 악성코드들이 사용자의 PC를 원격으로 조정하기 위하여 영화 ‘마이너리티 리포트’에 나오는 작은 스파이 로봇들을 뿌리는 것처럼 작지만 알아차리기 힘든 에이전트들을 몰래 몰래 뿌리고 있는 중이다. 언제, 어느 사이트를 공격할지는 알지 못하는 채로.

악성코드의 유비쿼터스 시대; 언제 어디서나, 보이지 않게

그렇다면 앞으로 시간이 좀 더 흐르고 나면 이러한 악성코드들을 싹 없애버릴 수 있을까? 안타깝게도 대답은 ‘아니다’이다. 오히려 악성코드들이 활약할 수 있는 분야는 더 다양해지고 있다. 사람들이 PC뿐만이 아니라 노트북을 사용하고(사실 노트북은 PC랑 운영 체제 기반과 환경이 거의 같다), 핸드폰, MP3P, PDA, PMP, PDP, 내비게이션 등 무수히 많은 디지털 기기를 사용하고 있다. 

사용자들은 앞으로 더 많은 개인화한 디지털 기기들을 이용하게 될 텐데, 이들은 모두 운영 체제를 가지고 있고 또 그 취약점을 가지고 있다. 하드웨어 제품을 만드는 회사와 종류는 다를지 몰라도 운영 체제는 마이크로소프트가 거의 독과점을 하고 있는 상황에서 악성코드들에게는 더 다양한 놀이터를 제공하는 것일지도 모른다. 

사실, 개인화한 기기뿐만 아니라 홈 네트워크가 더 많이 보급되고 가정의 가전 제품들도 급속히 네트워크화한다면 냉장고가 악성코드에 감염되어서 문을 열어 주지 않거나, 반찬을 녹여 버리거나, 냉각기를 세워서 냉장고 앞을 흥건하게 적셔놓을지도 모르는 일이다. 디지털 도어 락이 입력을 거부하거나 디지털 텔레비전이 마음대로 온라인 주문을 하지 않을 거라고 제조업체가 보장할 수 있을까?

악성코드와 보안 제품의 가상화

GUI 환경을 통해 사용자들에게 편리한 환경을 제공했듯이(물론 악성코드에게도 편리한 환경), 최근에는 가상화 환경을 통해 시스템을 절약하고 한정된 자원으로 더 많은 일들을 할 수 있도록 해주는 노력들이 이어지고 있다. 가상화를 통해 구현되는 환경은 사용자 입장에서는 큰 차이를 느끼지 못할 수도 있지만, 시스템의 활용성을 더 높이고 돈을 더 많이 들이지 않아도 된다는 점에서 매우 매력적인 환경이 될 것이다. 

그런데 사용자에게 편리한 환경은 악성코드에게도 편리한 환경이 될 수 있다는 점에서 편리함과 보안성은 동전의 양면과 같은 성격을 가지고 있다. 악성코드가 가상화 환경에서 존재한다면 쉽게 폐기할 수 있을 것이라고 생각할 수도 있지만 가상화 환경에 숨어들어가서 더 찾기 힘들고 치료하기 어려워질 수도 있다. 가상화가 점점 실용적으로 이용될수록 우리가 이제까지 경험하지 못한 새로운 악성코드의 패턴이 등장할 것이라 예상할 수 있다. 

그렇다면 사이버 세상의 미래는 헐리우드식 영화들이 보여주는 것처럼 암울하고 비관적이기만 한 것일까? 아니면 아시아권의 영화들이 보여주는 것처럼 인간적이고 자연적인 모습을 기대할 수 있는 것일까? 

이에 대한 한 가지 답으로 안티바이러스 및 통합보안 제품의 가상화 기술을 제시할 수 있다. 가상화는 이미 1960년대에 시작된, 생각보다 오래 묵은 기술이다. 오래된 만큼 기술적으로 성숙되어 있고 가상화 개념이 적용된 분야 또한 광범위하다. 보안 업계에서도 이미 오래 전부터 화두였다. 가상화 기술을 도입한 서버, 네트워크 등 여러 가지 솔루션의 등장으로 그 취약점 또한 점점 늘고 있다. 가상화 기술을 확보하지 않고서는 이를 위한 보안 제품도 만들 수 없으며 악성코드는 이 점을 노릴 것이다. 이에 대비하기 위해 안철수연구소를 비롯한 보안 업체는 어느 때보다 기술 확보에 노력하고 있다. 

안티바이러스 분야에서 현재 가장 많이 적용된 가상화 기술은 에뮬레이티드 머신(Emulated Machine) 또는 샌드박스 머신(Sandbox Machine)을 이용한 악성코드 분석 기법이다. 이것들은 각각 나름의 가상화 방법을 가지고 구현되어 있다. 또한 이를 통한 자동 분석 시스템 또한 각광을 받고 있다. 엄청나게 폭주하고 있는 악성코드 샘플을 효과적으로 처리하고 늘어만 가는 악성코드를 효과적으로 처리하기 위해 가상화 기술에서 방법을 찾고 있다. 

현재 안철수연구소는 악성코드 샘플 처리 자동화 시스템에 Light-weight Virtualized Environment 기술을 적용하고 있다. 이 기술은 엔진의 진단율을 높이는 데도 적용하고 있다. 또한 제너릭 디텍션(Generic Detection), 휴리스틱 디텍션(Heuristic Detection), 프로액티브 프리벤션(Proactive Prevention) 등의 기법을 테스트하고 있다. 이런 기술로 악성코드에 더 효과적으로 대응할 수 있으며 더 많은 악성코드를 차단할 수 있다.

통합보안 제품, 더 가볍고 더 빨라지다

한편, 백신 및 통합보안 제품의 변화 추세를 보자면 급변하는 인터넷 환경과 고객의 요구에 대응하며 포인트 솔루션에서 토털 솔루션으로, 다시 웹 2.0 기술을 접목한 서비스 형태로 지속적인 진화를 하고 있다. 단순 안티바이러스 툴을 넘어 사용자의 PC 사용을 더욱 안전하고 편하게 하는 방향으로 변화를 거듭하고 있는 것이다. 특히 최근 통합보안 제품의 변화를 주도하는 방향은 크게 ‘경량화와 가속화’, ‘케어 영역의 확대’로 나누어볼 수 있다. 

인터넷의 급속한 성장과, PC와 PC가 네트워킹된 상황에서 악성코드의 유포 채널이 미디어를 통한 수동적인 방법에서 사이트를 통한 능동적인 방향으로 바뀌어 가고 있다. 그에 따라 악성코드가 기하급수적으로 늘어나고 있다. 이에 대한 대응으로 통합보안 제품이 진단하는 악성코드 DB도 1년에 2배 정도씩 늘어나고 있다.  

최근 PC를 사용하는 주된 목적은 인터넷 쇼핑이나 뱅킹, 동영상, 게임 등 금융과 엔터테인먼트로 집중되고 있다. 이에 따라 운영체제나 타 프로그램 때문에 PC 작동이 끊기거나 지연되는 일이 없기를 바라는 요구가 증가하고 있다.
 

이와 같이 PC 사용의 목적 및 패턴이 변화함에 따라 통합보안 제품에 대한 요구가 기능 중심에서 PC 사용에 미치는 영향을 최소화하는 경량화로 이동하고 있다. 악성코드가 증가함에 따라 통합보안 제품 엔진의 크기가 커지므로 경량화에 대한 요구가 지속적으로 확대될 것으로 보인다. 보안 업체는 엔진 파일 크기의 증가를 최소화하고 행위 기반, 가상화 등의 기술을 접목하는 한편, 파일/프로세스 검사 시 파일 I/O(Input/Output), CPU 사용량을 최소화하기 위한 다양한 방법을 찾고 있다. 

지난해 안철수연구소가 출시한 ‘V3 365 클리닉 2.0’의 경우가 최근 통합보안 제품 업계의 경량화 트렌드를 가장 먼저 반영, 시장에 선보인 예로 들 수 있다. 공통 요소의 모듈화, 최적화를 통해 CPU, 메모리 등 주요 리소스의 사용을 최소화했다. 이로써 용량은 1/10로 줄어들고, 실행과 검사 속도가 이전 버전과 비교해 2-3배 빨라졌다. 특히 메모리 점유율을 개선하여 실시간 감시 중에도 속도 저하를 전혀 느낄 수 없는 수준으로 개선하였다. 

시만텍의 노턴 2009의 경우도 시스템 리소스에 대한 부하를 줄이는 데 초점을 맞춰 통합보안 제품 가동에 따른 PC 속도 저하 문제를 줄이는 데 중점을 두었다고 강조하고 있다. 실질적으로 300MB가 넘는 용량이 100MB로 크게 줄어들었으며 검사 속도 또한 확연히 줄어들었다고 시만텍 측은 설명하고 있다. 

이러한 통합보안 제품의 ‘Lighter and Faster’의 추구는 실시간 감시만 켜두면 버벅거리는 PC 때문에, 그리고 두세 시간의 시스템 검사 시간 때문에 답답해하던 사용자들에게 ‘보안이냐 편리함이냐’란 딜레마를 훌훌 털어버리게 할 수 있는 반가운 성과라고 할 수 있다.

단순 백신을 넘어 토털 PC 케어로

사람들은 컴퓨터를 사용하면서 늘 궁금하고 답답하다. ‘늘 내 PC는 느린 것 같아’, ‘왜 나만 하면 인터넷이 이렇게 느려지지?’ PC에서 발생하는 문제의 원인은 매우 다양하다. 그 해결 방법 또한 원인만큼 복잡하고 다양하다. 하지만 그 원인을 알고 해결할 수 있는 파워유저보다 일반 초보 유저가 절대적으로 많아지고 있다. 단순히 백신 고유의 기능인 악성코드 치료만으로는 ‘편리하고 안전한 PC의 사용’에 어려움을 겪는 사용자가 대부분이라는 것이다. 

이에 보안 업체의 고민이 있고 여기서 통합보안, 토털 케어로의 미래를 엿볼 수 있다. 물론 현재도 레지스트리, 디스크 등 리소스에 대한 최적화, 드라이버 업데이트 등으로 기능 확장을 해 나가고 있으나 아직은 운영체제에서 제공해 주는 기능의 확장에 머물러 있다. 

향후 보안 업계는 이와 같은 기능 확장과 웹 보안과의 결합이 지속적으로 이루어질 것으로 보인다. 백신이 초기 의료 체계를 모델링해서 나왔듯이 지속적인 모니터링과 관리를 받을 수 있는 서비스 형태로 진화할 것으로 전망된다. 또한 PC에 문제가 있을 때 사용자가 조치하는 수동적인 방법에서 자체적으로 판단하고 능동적으로 대응하는 형태의 ‘능동형 서비스’로 발전해 나갈 것으로 보인다.

도전과 응전은 계속된다

자동차를 타는 사람들이 처음에는 사고에 대응하지 못했지만 점차 안전벨트를 메고, 에어백을 달고, 후진 센서를 달고 하는 식으로 안전에 대한 노력을 해 온 것처럼, 우리가 생각할 수 있는 미래는 지금보다 더 편리한 환경을 제공할 것이다. 

마찬가지로 악성코드가 사라지지 않을 것이 자명하지만, 또 분명한 것은 악성코드들을 막기 위한 인간의 노력은 더 많은 발전을 이룰 것이고, 보안을 전문적으로 연구하는 좋은 기업들의 노력이 빛을 발할 것이라는 점이다. 

악성코드가 들어오는 방법, 악성코드가 숨어 있는 것을 찾는 방법, 악성코드가 최종적으로 노리는 목표를 찾아내고 위험을 제거하기 위한 기술 등 실질적인 방어를 위한 연구를 쉬지 않고 고민하고 찾아내고 있는 전문가들이 있기 때문이다. 그리고 인류의 역사는 끊임없는 공격과 방어에 대한 연구에서 발전하여 왔고 그러한 노력을 통하여 더 살기 좋은 세상을 만들어 왔기 때문이다. 

2. 파일기반의 탐지 기법(File Base Detection Tech)

현재까지 알려진 안티 바이러스(Anti-Virus) 소프트웨어 대부분이 파일 기반(File Base)의 진단법을 사용하고 있다. 이는 대부분의 악성 코드가 특정 운영체제에서 실행되기 위해서는 해당 운영체제에서 실행이 가능한 특정한 파일 형태로 되어 있다는 점에서 기인한 것이다. 그러므로 악성 코드가 윈도우 시스템(Windows System)에서 실행되기 위해서는 윈도우 시스템에서 실행 가능한 파일 포맷인 PE(Portable Executable) 형식을 가지고 있어야 된다는 것이다.


[그림 3] PE(Portable Executable) 형식의 악성 코드 파일

이러한 PE(Portable Executable) 형식의 악성 코드를 진단하기 위해서는 안티 바이러스(Anti-Virus) 소프트웨어 역시 이러한 파일 형식을 인식하고 악성 코드로 판단을 내릴 수 있는 특정 형식의 시그니처(Signature)를 가지고 있어야 된다. 이러한 진단법이 대부분의 안티 바이러스(Anti-Virus) 소프트웨어가 사용하는 시그니처 기반(Signature Base) 또는 스트링(String – 여기서 말하는 스트링이란 일반적인 문자열이 아닌 파일의 헥사코드(Hex Code)를 의미하는 것이다.) 검사 방식이라고 이야기하는 진단법이다. 이러한 시그니처 기반(Signature Base)의 진단법은 악성 코드로 분류된 파일의 특정 부분 또는 고유한 부분을 검사의 대상으로 삼으므로 오탐(False Positive)과 미탐(False Negative)을 최소화하는 정확한 진단이 가능하다는 것과 파일 검사 시에 파일들의 특징적인 부분들만 비교 함으로 빠른 스캐닝(Scanning)을 장점으로 들 수 있다.

그러나 이러한 시그니처 기반(Signature Base) 진단법은 악성 코드의 파일 자체가 몇 백 바이트(Byte)만 바뀌어도 진단이 되지 않는 미탐(False Negative)이 발생함으로 파일이 조금만 변경된 새로운 변형에 대해서는 대응을 할 수가 없게 된다. 그리고 기존에 알려진 악성 코드에 대해서만 대응을 할 수 있으므로 새로운 형태의 알려지지 않은 악성 코드에 대해서는 대응을 할 수 없다는 단점을 가지고 있다.

1) 휴리스틱 탐지 기법 (Heuristic Detection Tech)

이러한 시그니처 기반(Signature Base)의 진단법이 가지고 있는 한계를 극복하고자 개발한 탐지 기법 중 하나가 휴리스틱 탐지(Heuristic Detection) 기법이다. 휴리스틱 탐지(Heuristic Detection) 기법은 일반적인 악성 코드가 가지고 있는 특정 폴더에 파일 쓰기와 특정 레지스트리 부분에 키 생성과 같은 명령어(Instruction)들을 스캐닝 엔진(Scanning Engine)에서 시그니처(Signature)화하여 파일을 검사할 때 이를 사용한다. 그래서 검사 대상 파일이 휴리스틱 시그니처(Heuristic Signature - 이 것을 부스터(Booster)라고도 한다.)와 비교를 통하여 일반적으로 알려진 악성 코드와 얼마나 높은 유사도를 가지고 있는지를 판단하여 알려지지 않은 새로운 악성 코드를 탐지하는 기법이다.
이러한 휴리스틱 탐지(Heuristic Detection) 기법은 검사 대상이 되는 파일에 대해서 휴리스틱(Heuristic) 검사 시에 스캐닝 엔진(Scanning Engine)이 어떠한 형태를 취하는가 에 따라서 아래와 같이 크게 2가지 형태로 나누어서 볼 수 있다.

- 동적 휴리스틱 탐지 기법 (Dynamic Heuristic Detection Tech)
동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 검사 대상이 되는 파일을 가상화된 영역 또는 운영체제와 분리된 특정 공간에서 파일 실행(File Execution)을 통해 수집한 다양한 정보들을 휴리스틱 시그니처(Heuristic Signature)와 비교를 통하여 검사를 수행하는 기법이다. 즉 검사 대상이 되는 파일이 어떠한 형식으로든 실행이 되어야 하며 이러한 점으로 인해 런 타임 휴리스틱 탐지 (Run-Time Heuristic Detection) 기법이라고도 불리고 있다. 이러한 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법은 이 후에 다룰 에뮬레이터(Emulator)과 샌드박스(Sandbox)에서 조금 더 자세하게 알아 보도록 하자.

- 정적 휴리스틱 탐지 기법 (Static Heuristic Detection Tech)
정적 휴리스틱 탐지(Static Heuristic Detection) 기법은 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과는 반대로 파일에 대해서 어떠한 형식의 파일 실행(File Execution) 없이 파일 자체를 그대로 스캐닝 엔진(Scanning Engine)에서 읽어 들여 휴리스틱 시그니처(Heuristic Signature)와 비교를 수행하는 탐지 기법이다.


[그림 4] 정적 휴리스틱(Static Heuristic)과 동적 휴리스틱(Dynamic Heuristic)

이 외에도 네거티브 휴리스틱(Negative Heuristic – 이 것을 스토퍼(Stopper)라고도 한다.)탐지 기법도 있다. 이는 이제까지 기술한 휴리스틱 탐지(Heuristic Detection) 기법과는 반대로 악성 코드에서 전형 사용하지 않은 윈도우 팝업 창 생성과 같은 명령어(Instruction)들이 존재 할 경우에는 악성 코드로 판단하지 않는 기법이다. 즉, 휴리스틱 시그니처(Heuristic Signature)와 동일한 명령어들이 존재하지 않는 부정의 경우에만 악성 코드로 판단한다.
이러한 형태들의 휴리스틱 탐지(Heuristic Detection) 기법은 기존에 알려진 악성 코드도 탐지가 가능하며 알려지지 않은 새로운 악성 코드 역시 탐지가 가능하다는 점에서 매력적인 탐지기법이라고 할 수 있다. 그러나 이 탐지 기법은 정상 파일을 악성 코드라고 판단하게 되는 오탐(False Positive)의 발생이 가장 큰 단점으로 작용한다. 특히나 파일을 삭제하고 치료하는 안티 바이러스(Anti-Virus) 소프트웨어의 특성상 오탐(False Positive)율이 높게 된다면 컴퓨터 시스템 자체에 큰 문제를 유발할 수 있게 됨으로 이는 치명적인 문제점이라고 볼 수 있다.

2) 제너릭 탐지 기법 (Generic Detection Tech)

앞서 설명한 휴리스틱 탐지(Heuristic Detection) 기법 외에도 알려지지 않은 악성 코드를 탐지하기 위한 기법 중에는 제너릭 탐지(Generic Detection) 기법이라는 것이 있다. 이 탐지 기법은 유사한 형태의 악성 코드 집합을 탐지하기 위해 해당 집합을 이루는 악성 코드 파일들의 공통된 코드 영역(Code Section)을 진단하도록 한다. 그러므로 소스 코드(Source Code)상에서 사용자 코드(User Code)의 변화가 없거나 약간의 수정만 가하여 컴파일(Compile)만 새롭게 하여 생성한 새로운 악성 코드 변형들에 대해 탐지가 가능함으로 유사한 형태의 악성 코드 변형들이 지속적으로 제작되더라도 시그니처(Signature) 업데이트 없이 탐지가 가능하다는 장점이 있다.

이러한 제너릭 탐지(Generic Detection) 기법에서는 일반적으로 파일에 대한 OPcode(Operation Code) 명령어 비교 방식이 많이 사용되고 있다. 이 OPcode(Operation Code) 명령어 비교 방식에는 크게 와일드카드 비교(Wildcard Matching – Don’t Care 비교라고도 한다)와 미스매칭(Mismatching) 방식으로 나누어진다. 먼저 와일드카드 비교(Wildcard Matching)는 유사한 형태의 악성 코드 변형들의 특정 코드 영역(Code Section)에서 사용되는 OPcode(Operation Code) 명령들이 조금씩만 다르고 동일할 경우 해당 다른 OPcode(Operation Code) 명령어 부분에 와일드카드를 적용하여 다른 OPcode(Operation Code) 명령어가 사용되어도 이를 무시하겠다는 것이다.


[그림 5] 메모장(Notepad.exe) 프로그램의 OPcode(Operation Code) 명령어들

[그림 5]를 예로 들어 메모장 프로그램을 원본 악성 코드라고 가정을 한다면 이 원본 악성 코드의 일부 OPcode(Operation Code) 명령어들은 [그림 5]의 붉은색 박스 영역의 순서대로 진행된다. 이렇게 PUSH, PUSH, PUSH, PUSH 순서로 진행되는 OPcode(Operation Code) 명령어들이 다른 악성 코드 변형들에서는 PUSH, PUSH, PUSH, MOV가 사용된다면 마지막 MOV 부분을 와일드카드(Wildcard)로 적용하여 마지막 4번째 OPcode(Operation Code) 명령은 어떠한 것이 사용되더라도 이에 구애 받지 않겠다는 것이다. 이렇게 적용하게 되면 원본 악성 코드와 변형 악성 코드의 전체 OPcode(Operation Code) 명령어 진행 순서는 유사한데 일부가 조금 틀리더라도 모두 진단하게 되는 효과를 구현할 수가 있다. 그러나 미스매칭(Mismatching) 방식은 와일드카드 비교(Wildcard Matching)와는 반대로 MMX(Multi Media eXtension) 명령어 또는 FPU(Floating Point Unit) 명령어와 같이 악성 코드에서 잘 사용되지 않는 명령어들이 [그림 5]의 해당 붉은색 박스영역과 같이 특정 부분에 사용 될 경우, 해당 파일을 악성 코드 변형으로 판단하지 않겠다는 것이다. 이런 미스매칭(Mismatching) 방식은 앞서 설명한 네거티브 휴리스틱(Negative Heuristic) 탐지 기법과 기본적인 개념은 동일하다고 볼 수 있다.

그러나 이러한 제너릭 탐지(Generic Detection) 기법은 악성 코드의 공통된 코드 영역을 진단함으로 새로운 악성 코드 변형들이 제작되더라도 탐지가 가능하다는 장점이 있지만 새로운 악성 코드 변형들이 완전히 새로운 OPcode(Operation Code) 명령어 순서로 진행된다던가 아니면 안티 디버깅(Anti-Debugging)과 암호화(Encryption) 등과 같이 실행 파일 보호 기법을 통해 OPcode(Operation Code) 명령어의 진행 순서를 뒤섞어 놓게 된다면 스캐닝 엔진(Scanning Engine)에서는 이를 탐지하지 못하게 되는 문제가 발생할 수가 있다.

이상으로 파일을 기반으로 알려지지 않은 악성 코드 탐지 기법들에 대해서 알아 보았다. 다음으로는 파일 실행을 통해서 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법 설명 시에 잠시 언급한 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아보도록 하자.[Ahn]

[저자] 안철수연구소 ASEC 장영준 주임연구원 

3. 에뮬레이터(Emulator)과 샌드박스(Sandbox)

앞 장에서 설명한 새로운 악성 코드 탐지기법들은 모두 실행 파일(Executable File) 자체를 대상으로 한 탐지 기법들이다. 그러나 이번 장에서 설명하는 에뮬레이터(Emulator)와 샌드박스(Sandbox)는 모두 실행 파일(Executable File) 자체에 관한 탐지 기법이 아니라 해당 실행 파일(Executable File)의 실행을 통해 수집한 정보들을 이용하여 새로운 악성 코드를 탐지하는 기법들이다. 그러므로 앞서 이야기한 바와 같이 실행 파일(Executable File)의 실행을 통하여 새로운 악성 코드를 탐지하는 동적 휴리스틱 탐지(Dynamic Heuristic Detection) 기법과도 상당히 밀접한 연관 관계를 가지고 있는 것이다.

1) 에뮬레이터(Emulator)

사전적인 의미에서 에뮬레이터(Emulator)는 대리 실행기 라는 의미를 가지고 있다. 대리 실행기 라는 의미에서와 같이 에뮬레이터(Emulator)는 실제 컴퓨터 시스템 상에서 실행 파일(Executable File)을 직접적으로 실행하는 것이 아니라 실제 컴퓨터 시스템에 가상(Virtual)의 환경이나 가상의 하드웨어(Hardware) 이미지를 생성하여 해당 가상 하드웨어(Hardware)를 통하여 간접적으로 실행하는 것을 의미한다. 이러한 의미로 인해 일부에서는 에뮬레이터(Emulator)를 이용한 탐지 기법을 코드 에뮬레이션(Code Emulation) 또는 CPU 에뮬레이션(CPU Emulation) 이라고도 이야기 한다.

이 탐지 기법은 실제 컴퓨터 상에서 스캐닝 엔진(Scanning Engine)이 검사를 수행하지만 컴퓨터 시스템 내부에 가상의 CPU와 메모리 등의 가상의 환경을 제공하여 실행 파일(Executable File)을 실행하고 정보를 수집함으로 실제 컴퓨터 시스템에서는 악성 코드로 인한 어떠한 감염 피해도 발생하지 않는다. 이러한 점으로 인해 알려지지 않은 악성 코드를 탐지하기 위한 부분에서는 상당히 강력한 방법이라고 할 수 있다.
이러한 가상의 환경을 이용하는 에뮬레이터(Emulator)가 컴퓨터 시스템에서 구현되기 위해서는 크게 다음과 같은 4가지가 포함 되어야 한다.

- 가상 CPU 환경
실행 파일을 실제 CPU를 이용한 연산과 동일하게 처리하기 위해 일반적인 모든 명령어들뿐만이 아니라 MMX(Multi Media eXtension) 명령어와 FPU(Floating Point Unit) 명령어까지도 모두 처리 할 수가 있어야 한다.

- 가상 메모리 환경
32비트(Bit) 주소 체계에서는 최고 4 기가바이트(GB)까지 확장이 가능하지만 가상의 메모리 환경에서는 이렇게 많은 메모리는 필요하지 않다. 다만, 실행 파일(Executable File)이 실행되었을 때 변경하는 메모리 주소들에 대해 모두 기록하고 이를 추적할 수 있어야 하며 논리적인 메모리 주소와 물리적인 메모리 주소들을 모두 제공할 수 있어야 한다.

- 가상 저장 장치 환경
물리적인 저장 장치와 동일하게 실행 파일(Executable File) 실행 시 발생하는 저장 장치에 대한 파일 읽기 및 쓰기처럼 저장 장치에 대한 I/O(Input/Output)가 발생할 때 에뮬레이터(Emulator)에서는 실제 하드웨어와 동일한 환경을 제공 할 수 있어야 한다.

- 에뮬레이션 제어기(Emulation Controller)
에뮬레이션 제어기(Emulation Controller)는 에뮬레이터(Emulator)에서 가장 핵심이 되는 부분이다. 실행 파일(Executable File)이 가상 환경에서 실행 시 악성 코드로 판단 할 수 있을 정도의 충분한 정보를 수집하고 이를 제어하는 것이 바로 에뮬레이션 제어기(Emulation Controller)이기 대문이다. 그래서 에뮬레이션 제어기(Emulation Controller)에서는 실행 중인 악성 코드를 어느 시점에서 실행을 중단할 것인가와 얼마 정도의 시간을 실행에 소비할 것인가를 판단하고 제어할 수 있어야 한다. 일반적으로는 인텔 X86 CPU에서 에뮬레이션(Emulation)을 수행 하기 위해서는 최소 1,000개에서 최대 30,000개의 CPU 명령어 수행과 함께 45초 정도의 시간 소요를 기본으로 설정 한다.

이렇게 가상의 환경에서 실행 파일(Executable File)을 실행하고 수집된 실행 결과들을 통해서 악성 코드로 판단하는 에뮬레이터(Emulator)는 실제 시스템에 전혀 감염의 피해를 입히지 않고 알려지지 않은 악성 코드를 탐지할 수 있다는 점에서는 상당히 강력한 방법이라고 이야기 하였다. 하지만 에뮬레이터(Emulator)는 스캐닝 엔진(Scanning Engine)이 실행 파일(Executable File)을 검사 할 때마다 모두 가상의 환경에서 실행을 하고 분석을 해야 된다는 점에서는 컴퓨터 시스템에 대한 자원 소모가 커지게 되는 부담을 안고 있다. 이 문제로 인해 전반적인 스캐닝 엔진(Scanning Engine)의 검사 속도 저하로 이어지는 점이 가장 큰 단점이라고 할 수 있다.

2) 샌드박스(Sandbox)
에뮬레이터(Emulator)와 샌드박스(Sandbox)는 실행 파일(Executable File)의 실행을 통하여 수집된 정보를 통하여 악성이라고 판단하는 점에서는 유사한 형태라고 할 수 있다. 그러나 에뮬레이터(Emulator)와 샌드박스(Sandbox)의 가장 큰 차이점은 어떠한 형태로 실행 파일(Executable File)을 실행하고 어떠한 방식으로 악성 코드로 판단할 수 있는 정보들을 수집하는가에 가장 큰 차이점을 가지고 있다.
일반적으로 샌드박스(Sandbox)는 어플리케이션 에뮬레이터(Application Emulator)라고도 알려져 있는데 이러한 명칭에서 알 수 있듯이 샌드박스(Sandbox)는 에뮬레이터(Emulator)와는 달리 가상의 공간을 생성하는 것이 아니라 실제 컴퓨터 시스템상에서 바로 실행 파일(Executable File)을 실행하고는 정보를 수집한다는 점에서 가장 큰 차이점을 가지고 있다.


[그림 6] CWSandbox의 기본 구조

일반적인 어플리케이션 에뮬레이터(Application Emulator)로 널리 알려져 있는 CWSandbox는 [그림 6]과 같은 기본적인 구조로 되어 있다. CWSandbox의 경우 실행 파일(Executable File)이 실행되면 해당 파일의 스레드(Thread)로 모니터링 모듈인 CWMonitor.dll 파일을 인젝션(Injection) 시킨다. 인젝션(Injection) 이 후 해당 실행 파일(Executable File)이 실행되는 되는 모든 절차를 추적하여 해당 정보를 모두 CWSnadbox로 전달하게 된다.


[그림 7] CWSnadbox에서 윈도우 API 호출의 후킹(Hooking)

그리고 실행 파일(Executable File)이 실행되는 과정에서 발생하는 윈도우 API(Windows API) 호출 모두를 API 후킹(API Hooking) 기법을 이용하여 가로챈 후 CWSandbox로 전달 된 다. 전달 된 윈도우 API(Windows API) 호출은 CWSandbox를 통해 윈도우 커널 레벨(Windows Kernel Level)로 전달하는 정상적인 절차를 수행하게 되고 호출되는 윈도우 API(Windows API) 역시 호출한 해당 실행 파일(Executable File)로 바로 전달하는 것이 아니라 CWSandbox를 거쳐서 전달하게 되는 것이다. 이러한 과정을 표현한 것이 바로 [그림 7]과 같다.

그런데 여기에서 바로 어플리케이션 에뮬레이터(Application Emulator)인 샌드박스(Sandbox)의 가장 큰 특징이 나타난다. 호출 되는 윈도우 API(Windows API)가 CWSandbox를 통해 실행 파일(Executable File)로 전달 된 후 다시 그 리턴 값이 윈도우 운영체제로 바로 전달 되는 것이 아니라 CWSandbox를 통해 전혀 다른 리턴 값을 윈도우 운영체제로 전달하게 된다는 것이다. 이러한 다른 리턴 값을 전달하게 됨으로 실행 파일(Executable File)이 악성 코드여서 감염으로 인해 발생하는 악의적인 기능들이 모두 CWSandbox에 의해 걸러지게 됨으로 실질적인 컴퓨터 시스템에는 감염으로 인한 피해가 발생하지 않게 된다. 그리고 수집된 윈도우 API(Windows API) 호출과 리턴된 값과 같은 정보들을 통하여 CWSandbox는 해당 실행 파일(Executable File)이 알려지지 않은 악성 코드인지 판단을 하게 된다.
그러나 에뮬레이터(Emulator)와 같이 가상의 공간이 아닌 실제 컴퓨터 시스템의 환경에서 실행 파일(Executable File)을 실행하는 샌드박스(Sandbox) 역시 윈도우 응용 프로그램이다. 그러므로 샌드박스(Sandbox)가 특정 악성 코드를 정상적으로 제어하지 못하게 될 경우에는 그 감염으로 인한 피해가 고스란히 실제 시스템으로 전달되게 됨으로 예측하지 못하는 문제가 발생할 가능성이 크다.

이제까지는 실행 파일(Executable File)의 실행을 통해서 알려지지 않은 악성 코드를 탐지 할 수 있는 에뮬레이터(Emulator)와 샌드박스(Sandbox)에 대해서 알아 보았다. 하지만 다음 장에서는 일반적인 윈도우 실행 파일 포맷이 아닌 전자 메일로 형태는 급속한 확산을 시도하는 알려지지 않은 매스 메일러 웜(Mass Mailer Worm)을 탐지 할 수 있는 기법에 대해서 알아 보도록 하자.[Ahn] 

1. packetstorm.linuxsecurity.com
2. synnergy.net
3. unsecure.altervista.org
4. www.blacksheepnetworks.com
5. www.circlemud.org
6. www.dsinet.org
7. www.metasploit.com
8. www.nostarch.com
9. www.packetstormsecurity.org
10. www.rosiello.org
11. www.safemode.org
12. www.security-corporation.com
13. www.thc.org

D-DOS란 "Distribute Denial of Service attack"의 약자로 우리말로는'서비스 분산 거부 공격' 이라고한다.
단적으로 특정 기법을 통해 대량의 네트워크 접속을 유발해 해당 네트워크, 서버등의 시스템을 마비시키는 악의적인 네트워크에 대한 공격이다.
결과적으로 네트워크 마비 등으로 인해 정상 이용 고객들의 접속 자체도 이루어지지 않는 상태가 되는것으로
다음의 기법들이 대표적으로 많이 사용되고 있다.

1. SYN Flood
특정 TCP 포트로  허용치 보다 초과된 수의 연결 요청(SYN) 전송
대부분 Source IP가 Spoofing 되어 있음

2. UDP Flood
허용치 보다 초과된 수의 UDP 패킷

3. ICMP Flood
허용치 보다 초과된 수의 ICMP 패킷

4. Fragment Flood
허용치 보다 초과된 수의 fragmented IP  패킷

5. Connection Flood
Connection 수가 정상의 경우보다 매우 높은 경우

6. Source Flood
단일 Source 가 허용치보다 많은 수의 IP 패킷을 전송하는 경우

7. Zombie 공격 
너무 많은 합법 IP Source로부터 합법적인 TCP 패킷을 전송하는 경우

8. Slammer 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 1434로 전송

9. DNS 공격 
허용치 보다 초과된 수의 패킷이 UDP 포트 53으로 전송

10. My Doom 공격 
Zombie로부터 허용치보다 높은 수의 HTTP 패킷 전송

11. Smurf 공격
대상 서버의 소스 주소를 위조하여 다수의 Echo(Ping) 메시지를 IP Broadcast트 주소로 전송. 
해당 Broadcast주소로 트래픽을 전달하는 라우팅 장치가 Layer 2 Broadcast 기능에 대해 IP Broadcast를 
수행하기 때문에 대부분의 네트워크 호스트는 각각 ICMP Echo 요청을 받아들여 Echo 응답을 수행하게 되므로 응답 중인 호스트 수에 비례하여 트래픽이 증가

12. Fraggle 공격  
Fraggle은 UDP (7)Echo  메시지를 사용한다는 점을 제외하곤 smurf와 유사함. 
멀티액세스 Broadcast 네트워크에서는 수백 대의 시스템이 각 패킷에 응답할 수 있음.
Echo(7) 및 Chargen(UDP 19)를 이용하여 Loop 형성 가능 

특히 최근에는 악성코드 혹은 바이러스를 통한 Bot 감염에 의한 좀비PC들(BotNet)이 D-dos 공격에 많이 이용되는 7번 이후의 공격이 증가하고 있으며 IDC내로 최근에 유입되는 트래픽이 수G를 넘는 경우도 흔하다.

현재 국내외의 많은 네트워크 장비업체, 솔루션 업체에서 D-Dos 방어 장비, 솔루션이 출시되고 있으나 워낙 다양한 공격에 대처하기에는 기반 기술자체의 한계로 인해 효용성이 떨어지고 있다.

기존의 대부분 IDS, IPS,  백신등의 기본 아키텍처가 Signature 를 기반으로 패킷 비교를 통한 차단방식을 사용하고 있으나 근본적으로  D-Dos 공격 자체가 TCP, UDP 프로토콜 자체의 취약성 혹은 매커니즘을 이용한 대량 패킷을 전송해서 시스템 혹은 네트워크에 과부하를 일으키는 방식을 사용함에 따라 Signature가 없거나 수집이 되었다 해도 해당 패턴이 장비에 업데이트가 되는데 수시간 혹은 수십일이 소요되는 현실을 감안할때 일명 "Zero Day 공격"에는 근본적으로 대처할 수가 없는것이 현실이다.

단, 현재 해외에서 각광받는 RBIPS(Rate-Based Intrusion Prevention System) 장비가 큰 효과를 얻고 있다고 하는데 해당 장비에 대해서 조만간 소개해 보겠다.

ICMP(Internet Contol Message Protocol)는 IETF RFC792에 정의된 프로토콜로써 호스트간 혹은 호스트와 라우터간의 에러 상태 혹은 상태 변화를 알려주고 요청에 응답을 하는 기능을 담당하는 네트워크 제어프로토콜이다. 활성화된 서비스나 포트가 필요하지 않는 유일한 프로토콜이다. 이러한 ICMP의 특징을 악용한 ICMP Flooding은 대량의 ICMP패킷을 공격자가 직접 victim에게 전송하는 방법으로 그 변종의 예러 Smurf, Welchia worm 등이 있다. Smuf는 공격자가 source IP address를 victim의 IP address로 설정한 후, broadcast address로 ICMP ehco request패킷을 전송하면 그 하위 모든 시스템들이 ICMP echo reply 패킷을 victim으로 전송하게 되어 대량의 패킷들이 집중하여 네트워크 부하를 높이게 된다. 최근 발견된 Welchia worm은 감연 시스템에 대하여 IP address의 B클래스를 고정시키고 C클래스부터 증가시키며 ICMP 패킷을 전송하여 다른 감염 대상을 찾고 감염 시스템의 성능을 저하시키는 형태이다.

트래픽 모니터로 '패킷 개수' 체크
네트워크 장비라고 함은 스위치, 파이어월, 라우터 등을 말하며, 대다수의 네트워크 장비에는 자체적으로 포트별 트래픽 또는 세션별 트래픽을 관찰할 수 있는 기능이 있다. 물론 포트별 트래픽이나 전체 트래픽을 관찰할 수 있는 NMS(Network Management System)를 활용할 수도 있다. 네트워크 장비를 이용하는 것은 웜 트래픽의 패턴을 찾는다기보다는 트래픽의 양을 관찰하는 것이다. 트래픽이 많고 적음으로 웜인지 아닌지를 판단하는 것은 조금 위험스러운 생각이라고 할 수도 있겠지만, 웜 트래픽의 특징을 생각해보면 간단하게 웜에 감염된 PC 또는 IP 어드레스를 찾을 수 있다. 
여기에서 전체 송수신되는 데이터 양(Bytes)을 기준으로 판단하기 보다 패킷 개수로 판단해야 한다. 데이터 양을 기준으로 판단하면 많은 데이터를 업, 다운로드하는 경우와 혼동될 수 있기 때문이다. 예를 들어 SYN 공격이라고 하면 대략 100Mbps 네트워크에서 초당 1000개 이상의 SYN 패킷이 한 IP 어드레스를 통해 전송된다. 하지만 SYN 패킷은 크기가 65bytes이기 때문에 1초에 전송하는 데이터 양은 65Kbytes이다. 또한 대역폭 사용양도 700Kbps 미만으로 1%도 되지 않는다. 
물론 많은 NMS 도구를 사용해 전체 트래픽 발생량을 수시로 관찰해야 한다. 많은 고객 사이트를 방문하면서 의아해했던 점이 대부분 패킷 개수보다는 대역폭에 영향을 주는 데이터 양에 더 신경을 쓴다는 것이었다. 장비에 과부하를 발생시키는 것은 물론 총 송수신되는 데이터 양일 수도 있지만, 더더욱 영향을 주는 것이 패킷의 개수이다. 이제 다음과 같은 경우를 생각하면서 트래픽을 관찰해 보자.

·특정 IP 어드레스 또는 포트를 살펴보니 송신되는 패킷은 상당히 많은데 수신되는 패킷은 없다
·데이터 양(bytes)에 비해 송수신되는 패킷의 개수가 너무 많다
·한 IP 어드레스가 지나치게 많은 세션을 형성한다

사용자가 아무리 손이 빠르고 애플리케이션이 특수하게 설계돼 있다고 하더라도 1초에 100여 개 이상의 세션을 한 IP 어드레스가 형성하기란 쉽지 않다. 모두가 비정상적인 트래픽으로 생각할 수 있다. 
실제 패킷을 저장할 수 없는 NMS 도구나 장비의 콘솔 화면을 사용하는 것은 간단하고 추가 비용이 들지 않는다는 장점이 있지만, 몇 가지 어려움이 있다. 첫째, 사용자가 수시로 장비에 접속해 트래픽 상태를 관찰해야 하기 때문에 오히려 해당 장비에 부하를 가중할 수 있다. 둘째 과도한 트래픽에 의해 시스템이 과부하 상태인 경우에는 트래픽을 관찰하기 위해 접속하기 조차 힘들 수 있다. 
셋째 IP 어드레스별 트래픽과 세션 정보를 관찰할 수 있지만, 의심되는 트래픽이 실제 웜으로 인해 발생하는 트래픽인지 분석하기 어렵다. 즉, 증거가 될만한 실제 패킷을 저장할 수 없다. 이것은 패킷 저장 기능이 있는 NMS나 IDS(Intrusion Detection System)를 사용해 해결할 수도 있다. 넷째 의심되는 IP 어드레스에 대한 차단은 사용자 몫이다. 주의할 점은 트래픽뿐만 아니라 해당 장비의 CPU, 메모리 상태도 항상 점검해야 한다는 것이다.

UDP(User Datagram Protocol)를 이용한 패킷전달은 비연결형 서비스로서 포트대 포트로 전송한다. 대표적인 응용 서비스로 TFTP, SNMP, 실시간 인터넷 방송들이 이에 해당한다. UDP Flooding은 UDP의 비연결성 및 비신뢰성 때문에 공격이 용이한 방법이다. UDP는 source address와 source port를 spoofing 하기 쉽다. 이러한 약점들을 이용해 과다한 트래픽을 victim에 전송함으로써 spoof가 되는 victim간 네트워크를 마비시킨다. <그림>에 나타낸 바와 같이 공격자가 victim A에게 source IP address를 victim B의 IP address로 spoofing하여 대량의 UDP 패킷을 전송하면 victim A와 victim B는 계쏙해서 서로 패킷을 주고받게 되어 두 시스템 사이의 네트워크에 과부하가 초래된다. 이 공격은 주로 echo와 chargen 서비스를 이용한다.

ICMP Protocol

신뢰성을 제공해주지 못하는 IP Protocol 통신 환경에서 발생할 수 있는 문제에 대한 Feedback을 제공하기 위해 설계되었다. 따라서, 프로토콜 컨트롤을 위해 다양한 형태의 메시지를 포함하고 있다. 그 중 잘못된 서비스 Port로 UDP 패킷이 전달 되었을 때 발생되는 ICMP Destination Port Uncreachable 메시지는 UDP Flooding 공격과 밀접한 관련이 있다.

보통 UDP storm attack 이라 불리는데, UDP 서비스 중에 echo/chargen을 이용하여, 시스템을 다운시키는 공격이다. 이것들을 이용하여 공격을 받는 경우가 많고, 또한 실제로 echo/chargen service는 별로 이용되는 일이 없기 때문에 시스템에서 제거하는 편이 좋다. 제거하는 방법은 /etc/services 와 /etc/inetd.conf 파일에서 echo, chargen을 제거한 후에 inetd 수퍼서버를 다시 띄우는 것이다.

• 3.1 ICMP flood
• 3.2 Teardrop attacks
• 3.3 Peer-to-peer attacks
• 3.4 Permanent denial-of-service attacks
• 3.5 Application level floods
• 3.6 Nuke
• 3.7 Distributed attack
  
• 3.8 Reflected attack
• 3.9 Degradation-of-service attacks
  
• 3.10 Unintentional denial of service
• 3.11 Denial-of-Service Level II
• 3.12 Blind Denial of Service