'SMS'에 해당되는 글 7건

  1. 2010.12.07 SKT, 서비스 플랫폼 사업 본격화…지도·문자 API 공개
  2. 2009.06.11 ESM(enterprise security management)
  3. 2009.05.31 시스템 및 네트워크 모니터링을 통한 보안 강화
2010.12.07 18:47

SKT, 서비스 플랫폼 사업 본격화…지도·문자 API 공개

SK텔레콤(이하 SKT)이 각종 오픈 API를 모아 외부 개발자에게 공개하는 ‘T API 센터’를 3일 오픈했다고 밝혔다. 1차로 위치기반서비스(LBS – T맵, 위치측위) API와 SMS/MMS의 API(Application Programming Interface)가 ‘T API 센터’에 공개됐다.

이번에 SKT가 ‘T API 센터’를 오픈한 것은 지난 10월 발표한 ‘서비스 플랫폼 육성’ 전략에 따른 것이다. 당시 정만원 SKT 사장은 모든 핵심 서비스를 단계적으로 공개해 글로벌 서비스 플랫폼으로 발전시키겠다는 계획을 발표한 바 있다.


T API 센터 화면 캡쳐

‘T API 센터’는 SKT가 보유한 다양한 서비스를 API 형태로 웹 상에 공개해, 외부 개발자들이 이를 활용한 다양한 애플리케이션을 개발할 수 있도록 하는 개발자 지원 시스템이다. SKT의 LBS(T맵, 위치측위) API와 SMS/MMS의 API와 함께, 정부 및 공공기관에서 제공하는 API를 모아서 소개하고 있다.

SKT는 해당 API를 소개하고 이용방법에 대한 정보를 제공하는 것은 물론, 앱 개발에 필요한 SDK(소프트웨어 개발자 키트)와 API 개발에 적용될 인증키 발급 및 관리 등을 제공하고 개발에 유용한 다양한 포럼도 개최할 예정이다.

SKT는 T맵 API를 공개하면서 정확한 위치 측정 기술과 전국 교통정보를 반영한 빠른 길 안내를 장점으로 다양한 분야의 서비스로 확대해나가겠다는 뜻을 밝혔다. 빠르고 정확한 길 안내로 유명한 T맵 서비스의 경쟁력을 강화하면서, 보행자 영역으로 범위를 호가대해 T맵을 대표적인 LBS 플랫폼을 만들어나가겠다는 것이다.

현재 제공되는 API는 ▲GPS, 와이파이, Cell, P-Cell 등을 활용한 정확한 측위 기술과 ▲전국 맵 플랫폼 ▲T 맵 내비게이션과 연동되는 목적지 길 안내 등이다. 모든 T맵 기능에 대한 API 단순화 작업이 완료되는 내년 상반기에는 ▲각종 위치/장소에 대해 100만 개 이상의 정보가 축적된 POI(Point Of Interest) ▲실시간 교통정보가 반영된 가장 빠른 길 안내 ▲전국 6대 광역시 및 지방 국도 실시간 교통 정보 등까지 제공된다.

SKT는 향후 새로운 기능이 추가될 때마다, 해당 기술을 API로 만들어 개발자들에게 공개한다는 방침이다. LBS기술(T맵/위치확인)이 ▲기업솔루션(택배, 퀵서비스, 대리운전, 운송업체) ▲생활레저형(관광 정보, 방송, 골프, 등산) ▲엔터테인먼트(LBS활용 게임, 뮤직) 등 영역에서 새로운 가치를 제공할 것으로 기대하고 있다.

이와 함께 태블릿 PC와 7인치 내비게이션 단말기, 스마트 TV 등 더욱 다양한 기기로 T맵을 확장시키면서, 각 기기의 특성에 맞는 T맵을 차별화해 제공한다는 전략이다. 현재 T맵은 갤럭시탭에 기본 탑재돼 있으며, 내비게이션 2위 업체인 파인디지털 및 SK M&C의 7인치 내비게이션 기기에도 공급되는 등 단말기 확장성을 넓혀가고 있다.

메시지 발송과 연계한 다양한 서비스를 개발할 수 있도록 SMS/MMS의 API도 공개됐다. 기존에는 이동통신망을 통해서만 문자메시지를 전송할 수 있었던 것과 달리, 비통신형 기기에서도 와이파이나 유선인터넷을 통해 메시지를 발송할 수 있게 해 다양한 산업에서 새로운 시장을 창출하겠다는 전략이다.

예를 들어 냉장고에 보관한 식품의 유효기간이 임박할 경우, 사용자의 스마트폰에 보관 상태와 처리 방법을 문자로 전송해주는 서비스가 나올 수 있다는 것이다.

SKT는 스마트 TV와 냉장고, 세탁기, 카메라 등 비통신 기기에서 SK텔레콤의 메시징 인프라를 활용해 홈네트워크 상용화를 앞당길 수 있도록 다양한 사업자와 B2B 분야의 협력을 추진하고 있다고 밝혔다. 국내 PMP 업계 1위인 코원과 협력해 SMS/MMS 송수신이 가능한 PMP를 이달 중에 출시할 예정이다.

SKT는 지난 3일 서울대에 위치한 SKT 상생혁신센터에서 ‘오픈 API 설명회)를 개최하기도 했다. 앞으로 T스토어, 멜론, 모바일 페이먼트 등에 대해서도 API화 작업을 완료하는 대로 ‘T API 센터’를 통해 제공할 계획이며, 향후 3년간 1조원을 투입해 위치기반서비스(LBS), 상거래(Commerce), 메시징(Messaging), 콘텐츠 유통, 소셜네트워크서비스(SNS), 기업간 거래(B2B), 범용 플랫폼 등 7대 플랫폼 군을 육성한다는 방침이다.

홍성철 SKT 서비스부문장은 “이번 API 개방을 통해 SKT의 핵심 부가서비스가 다양한 서비스 플랫폼으로 진화할 수 있는 계기가 마련됐다”라며 “LBS와 SMS/MMS를 시작으로 콘텐트 유통과 SNS, 상거래 등 다양한 API를 추가로 공개해 구글맵, 아이튠즈와 같은 글로벌 플랫폼으로 발전시켜 나가겠다고”전했다.

‘T API 센터’가 이와 같은 역할을 하기 위해서는 외부 개발자들이 필요로 하는 API를 다양하게 구비하고 안정적으로 제공할 수 있느냐가 관건이 될 것이다. 또한, SDK와 레퍼런스, 개발 가이드 등을 얼마나 잘 만들어 제공하느냐도 중요하다.

지난 10월 SKT가 오픈 API 정책을 발표한 이후 많은 개발자들이 ‘기대감 반 회의감 반’이라는 반응을 보인 바 있다. 이번에 오픈한 ‘T API 센터’의 사이트를 들러본 개발자들의 소감이 궁금하다.

출처 : www.bloter.net


Trackback 0 Comment 0
2009.06.11 16:56

ESM(enterprise security management)

방화벽, 침입 탐지 시스템, 가상 사설망 등의 보안 솔루션을 하나로 모은 통합 보안 관리 시스템. 최근 기업 보안 관리(ESM) 통합 관리 수준에서 벗어나 시스템 자원 관리(SMS), 관리 시스템(NMS) 기업 자원 관리 시스템까지 확대, 개발되고 있다. ESM 기업들이 서로 다른 기종의 보안 솔루션 설치에 따른 중복 투자, 자원 낭비를 줄일 있으며, 솔루션 상호 연동을 통해 전체 정보 통신 시스템에 대한 보안 정책을 수립할 있다는 장점이 있다.

 

ESM 등장배경

보안의 개념은 처음에는 침입차단시스템(Firewall) 수준을 넘지 못했지만 최근의 보안은 침입차단 (방화벽), 가상사설망 (VPN), 침입탐지(IDS), 시스템 보안, 인증, 안티 바이러스, 데이터 백업에 이르기까지 전문화하는 양상을 보이고 있다. 보안의 핵심이 보안 제품 적용 적절한 보안정책에 따른 유지 관리라는 것은 주지의 사실임을 감안할 같은 전문적이고 세분화된 제품의 통합 보안관리에 대한 요구.

 

ESM 정의

l  기업과 기관의 보안정책을 반영, 다양한 보안시스템을 관제ㆍ운영ㆍ관리함으로써 조직의 보안목적을 효율적으로 실현시키는 시스템

l  통합보안관리 솔루션으로 보안 시스템 등의 개별적인 보안 장비들의 모니터링과 다양한 종류의 보안 솔루션을 하나로 통합 관리하며, 이에 소요되는 자원 인력의 손실을 방지하기 위해, 중앙에서 통합하여 보안 현황을 모니터링 함으로써, 집중화된 보안 관리가 가능.

l  방화벽, 침입 탐지 시스템, 가상 사설망 등의 여러 보안 시스템으로부터 발생한 각종 이벤트를 관리, 분석, 통보 대응 보안 정책을 관리하는 시스템

l  기업이 보유한 IT 보안 인프라에 대해 가용성, 무결성, 보안성을 보장하기 위한 전사적인 보안관리 시스템

 

ESM 필요성

l  인터넷 사용의 급격한 증가로 인한 보안관리 필요성 증가

l  해킹, , 바이러스, 정보전 정보화 추진에 대한 역기능 대두

l  다양한 보안시스템 도입에 따른 전체 보안관리 정책관리의 어려움 증가

l  다수의 보안시스템 관리에 대한 관리비용의 지속적 증가

 

ESM 구조

l  1 계층 : Agent

-      보안장비, 시스템장비, 네트워크 장비 등에 탑재되어 사용

-      사전에 정의된 규칙에 의한 이벤트 수집 보안정책 반영

-      수집된 이벤트 데이터를 Manager 전달 통제 받음

l  2 계층 : Manager

-      사전에 정의된 규칙에 의한 이벤트 데이터 분석 저장

-      다양한 정책에 대한 분석, 저장 관리자 Console 리포팅 기능

l  3 계층 : Console

-      Manager 의해 전달된 자료의 시각적 정보 전달 판단

-      Manager 대해 규칙을 설정하도록 통제

 

ESM 기반기술

l  위험등급 구분 방법론 : Risk Classification Methodology

-      보안 제품별 보안 패턴에 대한 분석을 통한 위험 분류 방법론

-      관리 시스템의 위험도에 따른 대응기준을 수립한 Rule

l  정규화/규칙 기반 이벤트 수집 : Normalization/Rule base Event Collection

-      관리 대상 시스템 평가기준의 표준화 규칙 기반 이벤트 수집 기술

l  비정상 감지 대응 : Abnormal Detection/Reaction

-      정상적인 시스템 사용의 탐지 이에 대한 실시간 대응 기술

-      탐지 방법 : 통계적 방법, 규칙기반, 패턴 분석

l  통합정책 관리 : Integrated Policy Management

-      이벤트 데이터의 수집/분석에 의한 보안 취약점 그에 대한 대응조치를 통합관리

-      ESM 시스템이 단위 보안 시스템에 대한 보안정책 반영

 

ESM 도입효과

l  각종 보안 솔루션의 알람 로그 정보를 중앙 집중화된 시스템에서 통합관제 관리하여, 보안 시스템 관리의 효율성 증대

l  소수의 특정 관리 인원을 할당하여 관리를 담당하게 있어 비용 효율적인 보안 관리 가능

l  보안 관리자의 교육 시간과 숙달 시간을 최소화

l  각종 로그 정보에 대한 통합 관리를 통해 사전 예방책 마련 가능

l  통계 처리 기능을 이용하여 주기적인 시스템 상태 분석 가능

l  표준화된 보안관리 정책/절차의 수립

l  문제 발생 사후조치에서 예방적인 보안관리 체계로의 수립

 

ESM 발전방향

l  ESM 진정한 의미의 통합보안관리를 수행하기 위해 넓은 영역으로 확장

l  기존에 보안시스템에 국한되었던 관제대상을 일반 서버에까지 확장하여 보안관리에 의한 보안 사각지대의 최소화

l  ESM 실제적인 `위협` 수준이 아니라 잠재적인 `위험` 수준에서 관리가 이루어지는 위험관리시스템(RMS; Risk Management System) 수준으로 개발

l  모든 보안 프로세스를 단일한 시스템에 포함시켜 수집-모니터링-분석-경보-대응-처리-보고-정책 피드백 일련의 프로세스를 지원

 

ESM 전망

l  국제적으로 OPSEC(Open Platform for Security) 통한 인터페이스 표준화 진행

l  국내에서 인터넷 보안기술 포럼에 의해 ESM API 표준화 진행

l  보안에 대한 요구사항 시스템 도입이 증가함에 따라 이들의 효율적인 운영관리 보안정책의 관리 필요성 인지로 ESM 도입 증가 예상

 

통합된 보안 관리 솔루션으로 등장해 각광을 받은 ESM은 TMS, SIEM, RMS 등으로 진화해 나가고 있다. 특히 차세대 ESM 솔루션은 NAC이나 네트워크 관리 등과의 통합에 힘입어 이제는 기존의 사후 대책 마련 수준에 머무르던 ESM을 넘어 능동적인 문제 해결 방법을 제시하고 있다.

안종석 | 엔터라시스네트웍스코리아 컨설팅지원팀&서비스팀 이사
<출처- 온더넷>

네트워크 관리자에게 보안은 더 이상 생소한 영역이 아니며, 더 나아가서 이제는 보안 담당자만의 영역이던 보안 관리까지 관심을 가져야만 하는 상황이 되고 있다.
보안 관리에 네트워크 관리가 통합되는 경향이 네트워크의 안정화에 크게 기여하기 시작했기 때문이다.

통합은 범위를 확장해 가면서 IT 업계의 핵심 키워드로 주목받고 있으며, 네트워크와 보안 분야에서도 오래 전부터 통합이 진행되고 있다.
보안 관리를 위해 초기에는 파이어월이나 IDS/IPS 등의 보안 장비가 생성하는 이벤트를 통합 수집해 모니터링하는 ESM(Enterprise Security Manager) 또는 전사적 보안관리 솔루션이 있었다(이는 해외 시장의 로그 관리 솔루션 시장과 비교될 수 있다). 

그러나 초기 ESM이 수동적으로 사후 관리에 치중한 솔루션이기 때문에 네트워크 보안 환경에 능동적으로 대처하기에는 부족했다.
시장에서는 초기 ESM에서 부족한 것을 보충할 수 있는 요구를 수용해 기능 추가에 주력해 왔으며, 이제 차세대 ESM이라 불러도 될 만한 수준의 솔루션들이 선보이기 시작했다.
이같은 차세대 ESM은 데이터 수집 대상 장비의 종류를 확장했고, 분석 수준도 높아지면서 해외 시장의 SIEM(Security Information and Event Management)과 비교될만한 수준으로 진화하고 있는 중이다.

진화의 한 방향은 ESM을 기반으로 TMS(Treat Management System) 기능을 통합하는 것이다.
그리고 최근에는 ESM와 TSM를 본격적으로 통합해 RMS(Risk Management System)라는 종합위험관리 기능을 제공하기도 한다(TMS는 해외 시장의 NBAD(Network Behavioral Anomaly Detection)와 비교할 수 있다).


네트워크와 보안 관리의 통합으로 기능 확장
보안 전문 담당자는 ESM의 발전 추세를 보안 처리의 프로세스 관점으로 이해함에 따라, 프로세스를 위한 포렌직과 프로세스의 자동화를 개선하는 관점으로 보고 있다.
그러나 차세대 ESM에는 네트워크 관련 장비에서 수집한 데이터를 기반으로 정보가 생성돼, 이를 이용하면 네트워크 담당자가 능동적으로 빠르게 문제점을 해결할 수 있다.
또한 최근 화두가 되고 있는 NAC(Network Access Control)는 기술 자체가 네트워크와 보안을 통합한 기술이기 때문에 ESM에 NAC의 관리 기능을 추가해 사용자 인증을 강화하면 네트워크 관리자에게 유용한 고급 정보를 생성할 수 있다.

초기의 ESM은 이벤트 모니터 결과를 정리하는 수준이었기 때문에 문제 해결을 위해서는 네트워크 관리자가 직접 작업을 수행해야 했다.
이것만 보자면 ESM 도입 전과 별로 달라진 것이 없으며, 단지 보안 측면에서 로그 관리가 통합된 포렌직 측면의 개선이 있었을 뿐이다.
이 때문에 초기의 ESM 사용자는 무엇인가 대단한 일을 할 수 있을 것 같았던 환상으로부터 일찍 깨어나야 했고, 기대했던 기능을 업체에 요구하기 시작했다.
이에 따라 ESM에 능동적으로 문제를 해결하기 위한 기능이 추가되면서 ESM의 진화가 시작됐다.

ESM은 이제 애플리케이션 계층까지 영역을 확대하면서 더 많은 종류의 이벤트와 데이터를 수집하고 더 높은 지능을 사용해 제로데이 공격 차단은 물론 스파이웨어 차단과 온라인 도용방지 그리고 사기성 사이트에 대한 검색 차단 등의 기능까지도 연동해 관리해 나가고 있다.

(그림 1)에서는 공격자의 트래픽이 지나는 경로의 장비에서 발생하는 이벤트를 관리 시스템에서 수집해 처리하는 과정을 보여준다.
파이어월에서 수집하는 차단/허용 이벤트 데이터에는 OSI 3/4계층 정보를 포함하고 있으며, IDS나 IPS에서 수집하는 이벤트는 카테고리별 분류와 함께 3~7계층 정보를 포함한다.
NAC(Network Access Control) 솔루션으로부터는 2/3계층은 물론 사용자 ID나 PC 이름 등의 신원 데이터를 수집한다.
또한 네트워크 장비로부터 플로우 데이터를 수집할 수 있어, 플로우 발생의 물리적인 위치를 포함하는 1~4계층 데이터를 얻을 수 있다.

이렇게 수집한 데이터는 관리 시스템의 분석에 의해 위협 또는 위반이라고 판단될 경우 사용자 인증을 포함하는 공격자 위치 기반의 정보를 경보와 함께 알리고, 이때 공격자의 사용자 인증을 포함한 자세한 정보는 네트워크 관리자가 문제 해결에 소요하는 시간을 대폭 경감할 수 있도록 도움을 준다.

ESM이 네트워크 장비들로부터 수집한 이벤트나 플로우 데이터를 데이터베이스에 저장하려면 일정한 규격으로 다듬는 규격화(Normalization) 과정이 필요하다.
업체에 따라 자동으로 장비를 인식하고 규격화하거나 수동으로 규격화하는 방법을 사용한다.
규격화하는 과정에서 자연스럽게 처리에 불필요한 데이터를 필터링하기도 한다.

규격화와 필터링 후에는 생성한 데이터베이스를 기반으로 상호연관 관계(Correlation)를 분석한다.
이때 상호연관 관계 분석의 지능 정도에 따라서 큰 차이의 결과를 보여줄 수 있다.
또한 결과를 실시간으로 분석하는 것과 아닌 것은 효과 측면에서 큰 차이를 보인다.
데이터베이스를 구축한 다음 분석을 시작하는 시스템은 실제로 사건이 발생하고 시간이 경과한 후에 경보하므로 경보의 효과가 대폭 감소한다.

4계층 기반으로 분석하는 지능을 가진 시스템보다는 7계층 기반으로 분석하는 시스템에서 제공하는 정보가 더 우수하다.
한편으로는 NAC 정보를 같이 처리하는 시스템은 그렇지 못한 시스템보다 사용자 인증 정보 제공 능력이 더욱 우수할 수 있다.

이벤트 수집과 동시에 플로우 데이터를 수집하는 관리 시스템은 TMS 기능까지 제공하는 경우가 증가하고 있다.
최근에는 ESM과 TMS의 통합을 기반으로 고도의 분석 기능을 추가해 RMS 기능까지 제공하는 솔루션이 출현하고 있다.

협의의 ESM은 초기의 EMS 시스템에 초점을 두고 있지만, 광의의 ESM은 ESM을 기반으로 시장에서 요구하는 다양한 기능을 추가하고 있다.
차세대 ESM이란 광의의 ESM이라는 이름 속에 포함한다.
그러나 이같은 차세대 ESM은 기능이 너무 광범위해 TMS이나 RMS라는 용어로 기능이나 제품을 세분화해 표현할 수도 있다.


차세대 ESM의 처리 과정
SEIM으로 진화하고 있는 ESM은 상호 연관 관계 분석 후에 최종적으로 처리의 우선순위를 정하기 위해, 등급(Magnitude)을 정하는 과정이 필요하다.
등급을 정하는 과정은 크게 관련성(Relevance), 신빙성(Credibility) 그리고 가혹성(Secerity)등 3가지 요소가 있으며, 정도에 따라 처리의 우선순위를 정한다.

(그림 2)는 처리 등급을 정하는 과정을 보여주고 있다.
관련성은 위반 시 우선순위를 정하는 가중치이며, 예를 들어서 서버나 중요한 단말기는 우선순위를 높여서 처리한다.

신빙성은 같은 사건이라도 더 많은 장비에서 이벤트 데이터가 수집됐을 경우가 우선순위가 높으며, 오탐이 아닌 확실한 사건으로서 관리자에게 경보할 수 있도록 한다.

가혹성은 공격자의 위협 정도이며, 공격 대상의 중요도나 목표 대상의 보호 장치 등에 따라서 처리의 우선순위를 정한다.
가혹성의 예를 들면 동일하게 윈도우 XP를 사용하는 두 명의 사용자가 각각 SP1과 SP2를 사용할 경우 취약한 SP1 사용자에 대한 위험 순위를 높여서 처리한다.

네트워크 관리자가 바라는 것은 빠르게 네트워크의 문제점을 해결하는 것이다.
그리고 이를 위해 보안 관리 시스템이 도움이 될 수 있기를 바라는 것이다.
진화하고 있는 ESM은 네트워크 관리자가 필요로하는 정보를 점점 더 유효하게 제공하고 있다.
발생하고 있는 수많은 이벤트를 분류해 압축하고, 위협 정도에 따라서 우선순위를 부여해 관리자에게 경보한다.
이 정도만으로도 관리자의 작업량을 대폭 줄일 수 있다.
그리고 좀더 진화한 ESM에서는 공격자의 위치 정보나 공격자에 대해 발생한 모든 이벤트를 분류하고 분석해 관리자에게 알려준다.

(그림 3)에서는 ESM이 진화해 가는 방향인 SEIM(Security Information and Event Management)의 처리 순서를 보여주고 있다.
네트워크 환경의 모든 장비에서 발생하는 이벤트와 정보를 수집해 가공하고 분석해 관리자에게는 꼭 필요한 것부터 차례대로 보여 주는 것이다.
이를 통해 관리자는 빠르게 네트워크 보안 문제를 처리할 수 있기를 기대하고 있으며, 더 나아가 하루에 수백만 개의 이벤트가 발생하더라도 몇 개의 사건이나 공격으로 정리하고 처리 방법을 제시하기를 바라고 있다.


실시간 상호 연관 분석 정보와 응답
진화한 ESM일수록 실시간으로 보여주는 정보의 품질이 우수하다.
실시간으로 유해성 정도에 따른 공격자의 우선순위나 심각성에 따른 공격의 우선순위 등을 대시보드 등을 통해 보여준다.
그리고 해당 공격이나 해당 공격자를 중심으로 모든 이벤트에 대해서 정리하고 분석한 것을 실시간으로 갱신하며 제공한다.

초기의 ESM이 디스크 I/O나 초당 이벤트 수집 건수로 처리량을 산정했다면, 차세대 ESM은 그 위에 CPU 사용 위주의 처리량이라는 척도를 더해야 한다.
그리고 공격이나 공격자에 대해서 자동으로 응답하는 시스템은 보안과 네트워크가 연동해 보여줄 수 있는 최고의 정점이라고 볼 수 있다.
ESM이 네트워크를 연동하는 것이 보안 프로세스 자동화의 마지막을 완성하는 모습으로 생각해도 좋을 것이다.

차세대 ESM 기반의 응답 자동화는 IP 어드레스 기반과 이보다 진보한 위치 기반이 있다.
이는 위치 기반 데이터 수집이 가능한 NAC을 연동하느냐 여부에 따라 차이가 있다.

IP 어드레스 기반은 공격자나 해커 등이 자신의 IP 어드레스를 숨기기 때문에 바로 응답하기보다는 관리자에게 응답의 여부를 묻는 경우가 대부분이다.

그러나 사용자 인증를 포함하는 위치 기반의 정보를 제공하는 응답에 대해서는 오탐에 대한 우려가 적어 사건 발생과 동시에 치료를 포함하는 응답 과정까지 자동화할 수 있다.
NAC가 단말기 접속 전에 검사를 통해 사용정책과 권한을 부여하는 것을 자동화했다면,
차세대 ESM은 NAC을 통해 접속한 단말이 접속 후에 사용 정책을 위반할 경우 권한을 조정하고 치료를 유도하는 것을 자동화하는 것이다.

(그림 4)는 위치 기반 데이터를 처리하는 차세대 ESM이 공격자를 색출해 네트워크에 접속한 공격자를 조치하는 최종 과정까지 모두 자동화하는 순서다.
이를 위해 ESM은 오류를 최소화해 이벤트를 NMS로 전송하고, NMS는 ESM의 이벤트로부터 공격자의 위치와 축소된 권한을 확인한다.
NMS는 축소된 권한을 스위치에 적용하면서 동시에 치료를 유도하는 강제 유도(Redirect) 정책을 적용한다.
결과적으로 공격자가 PC를 치료하거나 ④와 같은 안내 화면이 표시된다.


리포팅 기능의 강화
ESM은 등장 초기부터 리포트를 중요한 요소로 생각해, 이와 관련된 많은 서비스를 제공했다.
그리고 능동적인 문제 해결 기능을 다수 추가한 차세대 ESM에서도 리포트는 중요한 요소다.
능동적인 보안 관리를 위한 정보는 주로 모니터에 실시간으로 제공하는 반면, 리포트는 사후 관리에 필요한 정보를 제공해 장기적인 계획이나 튜닝을 위한 기초 데이터로 사용하기도 한다.

차세대 ESM에서는 정기적으로 중요한 리포트를 자동으로 생성, 저장하거나 관련자들에게 이메일 등을 통해 자동으로 배포하는 서비스를 제공한다.
그리고 공공이나 금융, 의료 분야 등에서는 필요한 준수 사항에 대한 분석 리포트도 별도로 작성해 저장, 배포한다.
이같은 리포트들은 사용자에 따라 매우 중요한 부분이 될 수 있다.

하부 기관의 ESM이 일정한 규격의 리포트를 온라인을 통해 자동으로 상위 기관의 ESM으로 전송하면, 상위 기관에서는 광범위한 영역의 이벤트나 정보를 수집해 엔터프라이즈 단위에서 얻을 수 없는 유효한 정보를 얻을 수 있다.
이런 기대는 공공 기관들이 ESM 통합을 서두르는 이유가 되고 있다.

데이터 수집의 장비 연동 자동화와 함께 다양한 리포트 템플릿을 제공하면 리포트 튜닝 서비스의 부담을 줄일 수 있다.
또한 이런 리포팅 기능을 각각의 수직 시장(Vertical Market)의 네트워크 담당자들이 이용할 수 있도록 적절하게 미리 튜닝해 어플라이언스 형태로 제공한다면 네트워크 담당자들도 ESM 도입을 통해 또 하나의 이점을 얻을 수 있게 될 것이다.
실제로 이같은 시도가 많은 업체들을 중심으로 진행되고 있다.



ESM과 TMS의 통합은 거스를 수 없는 현대의 추세다. 기존의 플로우 기반 솔루션인 TMS는 위협에 대한 사전적인 보안 관리가 가능했으나 이벤트 로그 분석에 약점이 있었다. 그러나 최근 들어 TMS는 이벤트를 동시에 처리하면서 향상된 위협 정보를 제공하기 시작했고 이벤트 기반의 ESM도 SIM·SIEM으로 진화하며 플로우 데이터 처리 능력을 보유하게 됐다.

안종석 | 엔터라시스네트웍스 코리아 컨설팅지원팀&서비스팀 이사

이벤트 기반 솔루션인 ESM은 이벤트 로그 관리가 빠르고 가격에 비해 처리 규모가 크다는 장점이 있지만, 수동적인 보안 관리를 해야 하고 보안 패치나 시그니처가 준비되지 않은 상태의 제로데이 공격 등에는 취약하다. 이를 개선하기 위해 ESM은 해외 시장에서 볼 수 있는 SIM또는 SIEM을 모델로 계속 진화하고 있다. 

ESM에서 이미 SIM으로 발전한 시스템들은 플로우 기반의 데이터를 처리할 수 있도록 기능을 추가해 제로데이 공격 감지 능력을 강화하는 중이다. 이렇게 능동적인 보안정책 기능을 추가한 제품은 초기 ESM과 차별화를 위해 RMS 등으로 제품을 구분하기도 한다.

한편 플로우 기반으로 출발한 TMS는 제로데이 공격 등에 강하지만 이벤트 로그 분석에 약점이 있었다. 그러나 최근에는 TMS도 이벤트를 동시에 처리하기 시작하면서 위협 관리 정보의 수준을 높이기 시작했고, 나아가 RMS로 거듭나려 하고 있다. 능동적인 보안 관리에 대한 시장의 요구가 ESM과 TMS의 통합을 RMS로 가는 연장선상에 놓고 있다.

ESM이나 TMS를 판매하는 각각의 업체들은 기반 기술이 다르지만 서로의 기술을 통합하는 작업을 진행 중이거나 완료한 상태며, 특히 시장에서 요구하는 능동적 보안 관리 기능을 추가하고 있다.
전사적인 보안관리 도구와 NMS의 연동은 네트워크 관리자의 관리·제어의 시간이나 비용 등을 획기적으로 절약할 수 있다. 또한 보안 담당자에게는 기존의 보안 프로세스 단계를 좀 더 자동화·체계화하는 도구가 된다. ESM과 TMS의 통합은 기업 내 네트워크와 보안 조직의 협력 등을 위한 거스를 수 없는 추세로 자리 잡고 있다.


플로우 기반 TMS의 기술적 특성
플로우란 MAC주소/IP주소/TCP주소 등의 송수신 조합이며, 웹서핑의 경우 대개 10개 이내의 플로우를 통해 처리할 수 있다고 이해하면 된다.

TMS는 플로우를 투시하면서 정상적인 행동과 다른 변칙(Anomaly)을 찾아내는데, 이는 ESM의 진화 모델인 SIM이나 SIEM의 이벤트 비율 분석과 유사하다. 찾아낸 변칙은 애플리케이션, 프로토콜, 위협 등의 위반 형태와 함께 관리자에게 경보한다. 변칙에 대한 분석을 통해 찾아낼 수 있는 것으로는 ‘홈을 부르는 트로이 목마’나 ‘이메일 기반의 웜 바이러스’ 그리고 ‘비인가 서버의 운영 감지’ 등이 있다.
또한 이벤트 기반 솔루션과는 달리 무중단(Non-stop) 서비스의 정지나 비정상적인 동작과 사고를 감지할 수 있는데, 호스트들에게 응답하는 웹서버 중단이나 게이트웨이 기기의 트래픽 손실과 중단을 감지하는 것 등이 예다. 그리고 TMS 기반의 기술을 확장해 RMS에 도입하고자 하는 기능인 정책 관리나 능동적으로 미래를 관리하는 개념을 적용할 수 있는데, 애플리케이션 행동 수준의 변화를 감지해 SSH 서버, 라우터와 스위치의 기능 변화나 웹 서버에서 프록시로의 변화 등을 감지하는 것이 예가 될 수 있다. 또는 TMS를 통해 믿을 수 있는 협력업체라도 사내 정책으로 허용된 기준보다 많은 데이터를 가져 갈 경우 관리자에게 경보를 줄 수도 있다.

이러한 경보들의 종류는 미리 준비한 것을 사용할 수도 있고, 상황에 따라서 새롭게 만들 수도 있다. 이는 솔루션 공급업체의 정책에 따라서 큰 차이가 있다. 중소 규모의 기업을 위해서는 시장의 성격에 따라 필요한 경보의 정형화를 미리 준비하는 것이 추세이고, 대기업이나 서비스업체를 위해서는 요구에 따라서 도입 시에 준비하는 것이 일반적이다.

TMS는 플로우를 모니터링하며 실시간으로 변칙 등의 행동을 분석한다. 그리고 분석한 결과를 보여주면서 동시에 공격 전부터의 상세정보를 제공하는 것은 물론 사건 진행과 사건 이후의 네트워크 플로우를 투시해 보기 좋게 정리한 다음 실시간으로 제공한다.

플로우 분석의 방법은 수학적인 방법에 의존할 수 있으며, 그 중 하나는 부울린(Boolean) 방정식에 의한 테스트다. (그림 1)은 세 가지 사용 예를 보여주고 있다. 첫 번째는 플로우를 수집하면서 실시간으로 공격에 응답하는 피해자를 분석하는 방정식이며, 두 번째는 IRC를 사용해 웜 공격의 발생지가 되는 봇들의 네트워크를 분석하는 식이다. 그리고 마지막 세 번째는 공격에 대한 피해로 서비스 불능인 것을 찾는 식이다. 


홀트-윈터스 알고리즘을 이용한 변칙 감지 방식
변칙을 찾는데 사용하는 수학적인 방법 중에는 이외에도 홀트-윈터스(Holt-Winters) 알고리즘과 같은 것도 사용한다. 홀트-윈터스 알고리즘은 플로우의 비율과 양을 시간에 따라 학습하는데 사용하며, 학습결과를 토대로 정상적인 행동에서 벗어난 변칙을 찾아낸다. 이런 알고리즘으로 변칙을 찾기 위해서는 항상 데이터가 있어야 하는 환경(no zero values)이 필요하다. 때문에 백본이나 트렁크 구간에서 플로우를 모니터링할 때 효과적이다.

홀트-윈터스 알고리즘을 사용하는 분석으로 새로운 온라인 서비스 시작 등의 큰 스케일의 대역폭 변화를 감지하며, 웜 바이러스나, 공격 전 스캐닝, DoS 공격은 물론 새로운 형태의 프로토콜이나 애플리케이션 사용을 감지할 수 있다. 특히 장기간에 걸쳐 조금씩 침투하는 행동을 감지하는데 효과적이며, 관리자가 없는 자정쯤 회사의 SMTP 메일을 이용해 메일 바이러스를 퍼뜨리는 행위나 Syn 트래픽으로 통계 엔진이 무력화되는 것을 감지할 수 있다.

또한 플로우 기반 분석에서 사용하는 알고리즘은 이벤트 기반의 관리 솔루션에서 제공할 수 없는 기능을 제공하는데, 예를 들면 변칙적으로 감소하는 트래픽의 경보 등이 있다. 이런 알고리즘 기반의 분석을 통해 공격을 당한 웹 서버 응답 정지뿐만 아니라, 백업 서버까지 응답이 없다면 백업 시스템에 대한 경보도 줄 수 있다.

홀트-윈터스 알고리즘에서 사용하는 학습 범위(Definable Season)는 대개 일, 월, 년 (day, month, year) 등으로 구분한다. 이를 조정 값을 통해 전체적인 추세나 과거 분석을 위한 것 등의 다양한 계정들을 만든다. 홀트-윈터스 알고리즘은 오래 학습한 것일수록 정확한 결과를 제공하며, 지속적인 학습과 보정으로 업무 성장에 따라 적절하게 정상적인 윤곽을 보이도록 유지할 수 있다.

(그림 2)와 (그림 3)은 학습을 하는 장시간 윈도우와 함께 변칙을 감지하면서 시간에 따라 이동을 하는 단시간 윈도우 두 개를 사용하는 방법을 보여준다. 뿐만 아니라 (그림 4)와 같이 수학적으로 미래를 예측할 수 있는 기능을 제공한다. 미래를 예측하면 위협에 대해 능동적 사전 조치가 가능하며 이들 기능을 통해 시장에서 RMS라는 다른 이름으로 구분해 정의하기도 한다.

 

 

(화면 1)은 홀트-윈터스 알고리즘을 실제로 응용한 장비에서 기능을 정의할 수 있도록 구현한 예를 보여준다. 학습범위뿐만 아니라 분석 트래픽의 특성까지 수준을 정할 수 있도록 하는 기능이 보인다.

(화면 1) ‘홀트-윈터스 알고리즘을 응용한 제품의 화면(예)’



플로우 기반 TMS과 이벤트 기반 ESM의 통합
국내 시장에서는 ESM과 TMS에 이어서 RMS가 많은 관심을 끌며 차세대 통합보안관리 기술로 평가받고 있다. 그리고 여러 업체들이 제품을 시장에 활발히 소개하고 있다. 이런 추세 속에서 기존 보안관리업체들도 자사의 ESM이나 TMS 제품에 RMS 기능을 추가하기 위한 작업을 진행하고 있다. 이들이 ESM과 TMS 통합의 원동력이 되는 것이다.

플로우 기반으로 찾은 위협에 대한 정보는 이벤트 기반의 정보를 통합해 더 수준이 높고 더 효과적인 정보를 제공한다. 물론 이와 반대로 ESM 기술 진화 모델인 SIM 또는 SIEM 기술이 플로우 기반 분석 처리를 통합할 때도 같은 효과를 얻을 수 있다.

플로우 기반의 TMS는 위반(offence)에 관련된 플로우 정보를 전후 관계에 따라 제공한다. 그리고 이벤트 처리 기반의 SIM이나 SIEM은 백도어(Backdoor)에 대해서는 많은 센서들로 수집한 이벤트를 로그로 저장하고, 이를 “공격자는 <SRC>이다 공격 목표는 <DST>이다 사용 포트는 새로운 것으로 플로우는 양방향이다 <bi-directional>”과 같은 식으로 표현한다.

이벤트 기반 처리를 위한 센서는 네트워크 상의 파이어월이나 IDS/IPS 등이다. 최근에는 인증서버나 NAC 정보뿐만 아니라 네트워크 장비들로부터 이벤트를 받는 등 기기를 가리지 않고 네트워크 상의 모든 정보를 수집하는 추세다. 그리고 이들의 DB에는 이미 오래 전부터 정형화된 주석이나 조치사항 등이 있어 공격자나 공격 등에 대해 바로 조치 가능한 정보를 제공할 수 있다.

(화면 2)는 플로우 기반으로 처리한 화면에서, 공격자 IP 주소를 표시하는 필드 위에 마우스 커서를 올려놓으면 이벤트 기반으로 처리한 데이터를 연동해 공격자에 대해 좀 더 자세한 정보를 제공하는 모습이다. 수집한 이벤트 제공 장비의 특징에 따라서 공격자의 위치정보까지 얻을 수 있다. 인증서버는 사용자 ID나 MAC주소, 이메일 주소 등 일반 보안장비가 제공할 수 없는 정보를 제공한다. NAC 기기 또한 신원 정보와 함께 취약성 분석 정보를 더할 수 있다.

(화면 2) ‘플로우 기반 처리 화면에서 이벤트 기반 처리 정보를 연동하는 모습(예)’

SIM을 진화 모델로 하는 ESM은 취약성 분석 도구와 미래의 위험을 능동적으로 관리하고, TMS는 정책이나 추세의 수학적 분석을 통해 장래의 위협에 대응한다. ESM과 TMS를 통합한 기반의 관리 도구는 두 가지 기반에서 주는 장점들을 사용해 위험에 대한 좀 더 높은 수준의 정보를 제공한다.


대규모 네트워크에서 더 강력한 TMS와 ESM의 통합
기반 기술에 상관없이, 시장이 원하는 핵심은 IT자산 전체를 대상으로 취약점과 위협의 사전 파악과 대응을 통해 보안 사고를 예방하고 보안수준을 상시적으로 관리하는 것이다. 이를 통해 내부에서 새롭게 발생하는 취약점과 위협이 발생하고 있는 지점을 즉각적으로 찾아 우선순위별로 대응 조치를 취하고, 보안 문제를 해결하는 시간과 비용 면에서 효율성을 크게 향상시키길 기대하고 있다.

네트워크 관리자 입장에서 TMS와 ESM의 통합이 줄 수 있는 장점은 네트워크 규모가 크면 클수록 그 효과가 크다. 예를 들어 규모가 큰 기업의 경우 보안 장비의 숫자나 네트워크 장비의 숫자가 수백 대에 달하는데, 네트워크의 가용성에 영향을 주는 보안 문제가 발생할 경우, 네트워크와 보안 관리 화면의 이벤트가 너무 많아 수동으로 해결하기에는 너무 긴 시간이 걸린다.

그러나 통합 솔루션의 분류 기능은 (화면 3)과 같이 네트워크 상의 모든 기기들에서 발생하는 모든 이벤트를 분석해 실시간으로 특정 위반 사항에 관련한 1만 여개의 이벤트를 정리해준다. 이는 관리자가 분석하는데 필요한 시간을 대폭 감소시킬 뿐만 아니라 네트워크의 가용성을 높이는데 큰 도움이 된다.

(화면 3) ‘이벤트 기반 처리 화면에서 제공하는 정보(예)’

특히 최근에는 ESM과 TMS의 통합을 통해 제공하는 위험정보의 수준이 높아지고, 오탐 등의 오류 감소뿐 아니라 조치에 필요한 정보를 NMS와 연동해 위치정보를 제공하고 있다. 그리고 이들을 NMS와 연동시키는 네트워크 관리의 일상적인 업무 프로세스도 보안관리 프로세스 자동화처럼 컴플라이언스 등의 이슈를 해결하기 위한 통합 솔루션으로 거듭나고 있다.


ESM과 TMS 통합의 의미
현재 시장에서는 기존의 ESM과 TMS를 통합한 기반에서 새로운 기능을 제공하는 환경이 조성되고 있다. 그리고 각 ESM/TMS 업체들은 고유의 기술 기반 위에 필요한 기능을 추가하면서 각자의 약점들을 보완해 시장에서 원하는 능동적인 보안 관리 도구로 진화하고 있다. 또 기존 제품과 차별화하기 위해 RMS라는 이름을 사용하기도 한다. 기존의 ESM나 TMS까지 새로운 버전을 통해 RMS라는 이름을 사용하기 때문에 사용자들을 혼란스럽게 만든다. 영업 전략상 이름은 TMS와 유사하면서 내용은 RMS로 설명하는 경우까지 있다. 그러나 어떤 기술을 기반으로 하든 ‘사후대응’ 방안으로 사용하는 ESM 솔루션과 TMS를 보완해 기업에 ‘사전예방’ 체계를 준비하는 것이 최근의 추세다.

수동적인 관리보다 능동적인 사전 보안 예방을 통해 보안 투자와 운영 관리 효율성을 높일 수 있다. ESM과 TMS의 통합은 기술의 정의로 구분하기 보다는 시장에서 원하는 능동적인 보안관리 기능을 추가해 가는 과정의 한 단면이라고 이해하는 것이 더 옳을 것이다.

월간 온더넷 11월호


Trackback 0 Comment 0
2009.05.31 16:01

시스템 및 네트워크 모니터링을 통한 보안 강화

시스템 네트워크 모니터링을 통한 보안 강화

 

 

                                            오늘과내일 넷센터 홍석범 (antihong@tt.co.kr)

 

 

1.        포트(Port) 개념과 포트 제어의 모든

2.        내부 시스템(호스트) 모니터링 소프트웨어 활용

3.        외부 시스템(네트워크) 모니터링 소프트웨어 활용

 


1.
포트의 개념과 포트 제어의 모든


시스템의
접속은 포트와 포트간의 통신이라고 정도로 포트의 의미는 매우 중요하다. 당연히 시스템의 모니터링을 위해서는 포트의 개념에 대한 이해가 매우 중요한데, 단순히 다음 파트에서 설명할 시스템 네트워크 모니터링 프로그램에 대한 사용 방법을 익히는 것도 좋지만 사전에 포트에 대한 기본적인 개념을 이해하고 있어야 각종 현상에 대한 이해 상황에 대한 즉각적인 대처가 가능하고, 또한 문제 발생시 원활히 처리를 있다.


이번
호에서는 서버를 운영하면서 자주 다루어지는 포트(Port) 개념과 포트 제어 방법에 대해 알아보도록 하겠다.

 

포트의 개념과 포트 분류의 원칙.

 

시스템간에 통신을 물리적인 전송선은 하나이지만 그것을 여러 개의 응용 프로그램들이 서로 나누어 사용하기 위해서 포트(Port) 라는 개념이 도입되었다. 시스템 내의 소켓(Socket) 사용하는 모든 프로세스는 별도의 포트 번호가 할당된 소켓을 갖게 되는데, 이것은 TCP/IP 지원하는 상위 계층의 응용 프로그램을 구분하기 위한 번호이다.


 
서버와 클라이언트간의 모든 네트워크는 일정화 규칙에 따라 포트를 이용해 통신을 하게 된다. 일반적으로 포트 번호로 16비트를 사용하며 사용 가능한 포트는 0번부터 65535 번까지인데 특히 0번부터 1023번까지를 특별히 Privileged Port 하고 1024번부터 65535 포트까지를 Unprivileged Port 라고 한다.  포트 바인딩등과 같은 소켓 프로그램을 이용하거나 80번을 사용하는 아파치 웹서버와 같이 데몬을 셋팅하여 특정한 포트를 점유하는 프로그램을 실행할 있는데, Privileged Port 영역내에 있는 포트를 이용하는 프로그램을 작동하려면 반드시 root 권한으로 작동하여야 한다. , 다른 말로 표현하면root 이외의 유저라면 1024번부터 65535번까지의 포트만을 생성(바인딩) 있는 것이다. 물론 root 권한으로는 0부터 1023 사이의 포트뿐만이 아니라 1024 포트 이후의 포트도 사용 가능하다. 그러나 root 권한으로 작동하는 대부분의 데몬들은 0번부터 1023 사이에 존재하고 1024 이후의 포트는 주로 일반 유저 권한으로 데몬을 실행하거나 클라이언트가 서버와 통신시 사용된다. 따라서 1024이후의 포트를 흔히 클라이언트 포트라고 부르기도 한다.


참고로
현재의 시스템에서 클라이언트가 사용  가능한 포트는

sysctl -a | grep local_port 확인 가능하며

sysctl -w net.ipv4.ip_local_port_range="32768 61000"  같은 명령어로 설정 변경이 가능하다.  클라이언트의 포트는 OSI 7 Layer 에서 7계층인 Application Layer 에서 결정되게 되는데, 예를 들어 브라우저를 이용해 http://www.tt.co.kr/ 이라는 서버를 접속하였다면 서버측에서는 www 포트인 80 포트가 반응하게 되고, 클라이언트에서는 브라우저에서  1024 이후의 임의의 포트를 할당하여 서로 통신이 되는 것이다.


PC
에서 telnet 이나 ftp 접속을 netstat –na 실행하여 클라이언트 PC에서 반응한 포트를 보면 1024이후의 포트에서 임의로 할당되는 것을 확인할 있을 것이다.


 
외에 Well Known Port 라는 것이 있는데, 이는 IANA 에서 TCP UDP 대해 정책적으로 할당한 포트로서 www  80,  SMTP 25,  telnet 23 등과 같이 통상적으로 약속한 프로토콜이 사용하는 포트에 대한 정의인데, 이는  /etc/services 파일에 규정되어 있다.


원리를 이용하여 아래의 문제를 풀어보도록 하자.


갑자기
서버에 과부하가 걸리고 있는 하여 ps aux 시스템의 프로세스 상황을 살펴 보니 아래와 같이 sendmail 프로세스가 많이 있는 것을 확인하였다.


그런데
, 아시다시피 sendmail 외부에서 서버로 보내어진 메일을 받는 역할(Local25 포트 작동, Foreign Unprivileged Port 작동) 내부에서 큐로 보내어진 메일을 외부로 발송하는 기능(Local Unpriviliged port 작동, Foreign 25 포트 작동) 있는데, 아래의 sendmail 프로세스는 가지 기능 전자와 같이 외부에서 내부로 보내어지고 있는 메일을 받는 프로세스일까? 아니면 후자와 같이 현재 서버에서 외부로 발송되는 메일을 처리하는 프로세스일까?
 

[root@www /root]# ps aux|grep sendmail

root      3425  0.0  0.2  2472 1256 ?        S    Aug10   0:10 sendmail: accepti

root     20818  0.0  0.2  2596 1520 ?        S    01:07   0:00 sendmail: server

root     24572  0.0  0.3  2728 1684 ?        S    01:32   0:00 sendmail: sevrer

root     24970  0.0  0.2  2596 1524 ?        S    01:34   0:00 sendmail: server

root     25811  0.0  0.2  2596 1524 ?        S    01:38   0:00 sendmail: server

root     13455  0.0  0.2  2472 1256 ?        S   Aug11   0:10 sendmail: accepti

root     23766  0.0  0.2  2344 1520 ?        S    01:07   0:00 sendmail: server

root     47932  0.0  0.2  2432 1524 ?        S    01:34   0:00 sendmail: server

root     98793  0.0  0.2  2342 1524 ?        S    01:38   0:00 sendmail: server

 

때의  해결책은

결과만으로는 없으며 아래와 같이 netstat 이용하면 된다.


Sendmail
작동한다면 Local 이든 Foreign이든 하나는 반드시 25 포트가 사용된다는 특징을 이용하면 된다. 

 

[root@www /root]# netstat -na|grep :25

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 211.47.65.56:25         211.47.66.71:3420       TIME_WAIT

tcp        0      0 211.47.65.56:25         198.6.49.12:36877       ESTABLISHED

tcp        0      0 211.47.65.56:25         211.119.130.90:3626     ESTABLISHED

tcp        0      0 211.47.65.56:25         210.121.167.112:3565    ESTABLISHED

tcp        0      0 211.47.65.56:25         210.111.91.130:4858     ESTABLISHED

tcp        0      0 211.47.65.56:25         128.134.24.193:4931     ESTABLISHED

tcp        0      0 211.47.65.56:25         211.54.29.139:1631      ESTABLISHED

tcp        0      0 211.47.65.56:25         203.25.16.2:2666        ESTABLISHED

tcp        0      0 211.47.65.56:25         211.54.29.139:1630      ESTABLISHED

tcp        0      0 211.47.65.56:25         192.198.165.17:51757    ESTABLISHED

tcp        0      0 211.47.65.56:25         210.219.250.207:2300    TIME_WAIT

tcp        0      0 211.47.65.56:25         210.106.207.100:1036    ESTABLISHED

tcp        0      0 211.47.65.56:25         134.239.84.2:4499       ESTABLISHED

tcp        0      0 211.47.65.56:25         202.119.208.10:42934    ESTABLISHED

 

결과를 보면 왼쪽에 보이는 것이 (Local)서버쪽의 IP:PORT 상태이며 오른쪽에 보이는 것이 (Foreign)원격지의 IP:PORT 상태이다. 상태를 보면 좌측의 서버(Local)측에서는 25 포트가 반응하고 있고, 우측의 원격지(Foreign)에서는 1024 이후의 포트중 임의의 포트 클라이언트 포트가 반응하고 있는 것을 확인할 있다.
 

이를 통해 현재의 상태는 외부(원격지) 에서 로컬 서버로 메일을 전송하고 있는 상태( 서버가 외부에서 발송된 메일을 받고 있는 상태)라는 것을 있다.
 

그리고 만약 아래와 같이 반대의 상황이라면 앞의 상황과는 반대로 외부의 원격지에서 25 포트가 반응하고 있으므로 내부 로컬에서 외부로 메일을 발송하고 있는 상태라는 것을 있다.

 

[root@www /root]# netstat -na|grep :25

tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN

tcp        0      0 211.47.65.56:38799         211.47.66.71:25       TIME_WAIT

tcp        0      0 211.47.65.56:43634         198.6.49.12:25       ESTABLISHED

tcp        0      0 211.47.65.56:43891         211.119.130.90:25     ESTABLISHED

tcp        0      0 211.47.65.56:7478         210.121.167.112:25    ESTABLISHED

tcp        0      0 211.47.65.56:1234         210.111.91.130:25     ESTABLISHED

tcp        0      0 211.47.65.56:2152         128.134.24.193:25     ESTABLISHED

tcp        0      0 211.47.65.56:3645        211.54.29.139:25      ESTABLISHED

tcp        0      0 211.47.65.56:3601         203.25.16.2:25        ESTABLISHED

 

포트 번호외에  프로토콜에 따라 TCP UDP 포트로도 분류할 있는데 telnet, sendmail, httpd 대부분의 프로토콜은 신뢰성이 보장되는 TCP 사용하나 DNS 특정 프로토콜의 경우 UDP 사용하거나 TCP UDP 함께 사용하는 경우도 있다.  UDP패킷은 TCP 패킷에 비해 헤더에 패킷의 순서에 대한 정보가 없기 때문에 패킷의 신뢰성 보다는 오버 헤드가 없고 빠른 속도를 필요로 쓰이며 시스템 이상에게 메시지를 전달하는 멀티 캐스트로 사용되기도 한다.

 

 

포트 점검 제어

 

그렇다면 내가 운영하는 서버에는 어떤 포트가 떠서 서비스 요청을 기다리고 있는지 있는 방법이 있을까?  간단히 검색하고자 하는 서버에 대해 포트 스캔을 보면 된다. 특정 포트가 반응하는지 여부는 여러 방법으로 확인 가능한데, 단순히 특정 포트로 telnet 접속하여(: telnet www.server.com 522) 접속이 되는지 여부를 확인하는 방법도 있고, 별도의 포트 스캔 전용 프로그램을 사용해도 된다. 포트 스캔을 위해 가장 권장할 만한 프로그램으로는 nmap 있는데, http://www.insecure.org/nmap/ 에서 tarball 형태의 소스를 다운로드 받아 설치하거나 http://rpmfind.net/ 에서 rpm 형태의 파일을 검색한 다운로드하여 사용하여도 된다.

nmap – p 1–65535 localhost 하면 현재 자신의 시스템에 어떤 포트가 있는지 모든 포트에 대해 확인 가능하다. 만약 아무런 옵션을 주지 않고 nmap localhost 실행하면 /etc/services 파일에 정의된 Well  Known Port 대해서만 스캔을 하게 되는 것을 주의하기 바란다.

또한 nmap -p 21,23,53,80 192.168.1.0/24 같이 스캔할 경우에는 192.168.1.0 대역( 192.168.1.1부터 192.168.1.254까지 모든 호스트) 대해  21,23,53,80 등의 특정 포트가 열려있는지에 대해서만 스캔을 하게 된다.

그런데, 스캔을 결과를 보니 자신이 못하는 이상한 포트가 있는 경우가 있다. 일반적으로 해킹을 후에는 이후에 원격에서도 쉽게 접속할 있도록 특정한 포트에 백도어를 설치하여 숨겨놓는 경우가 있으므로 백도어가 아닐까 의심하는 경우가 있는데, 포트를 사용하는 프로세스가 어떤 것인지 확인하는 방법과 포트를 죽이는 방법은 무엇일까?

.

 Port       State       Service

21/tcp     open        ftp

23/tcp     open        telnet

25/tcp     open        smtp

80/tcp     open        http

110/tcp    open        pop-3

1234/tcp   open        hotline

3306/tcp   open        mysql

4321/tcp   open        rwhois

7755/tcp   open        unknown

10101/tcp  open        unknown

 

만약 포트 스캔 결과 위와 같이 나왔을 경우 우측에 telnet, ftp 포트번호에 해당하는 서비스의 이름이 나오는데, 이는 단순히 스캔된 포트에 대하여 /etc/services 파일에 정의된 서비스명과 매치를 시켜 놓은 뿐이며  80 포트라고 해서 반드시 웹데몬이 아닐 수도 있음을 주의하기 바란다. 아울러 unknown 이라고 나온 것은 /etc/services파일에 정의되지 않은 포트이기 때문이다. 스캔 결과에서  10101 포트가 수상하여 10101 포트를 쓰고 있는 프로세스가 무엇인지 알고 싶은 경우 있는 방법은 아래와 같이 가지가 있다.

첫번째는 lsof 이용하는 방법이고, 두번째는 fuser 라는 명령어를 이용하는 방법이다.

명령어는 대부분의 시스템에서 기본적으로 이용 가능한데, 명령어가 실행되지 않으면 해당 패키지를 찾아 설치하면 된다. Lsof lsof 라는 패키지에, fuser psmisc 패키지에 포함되어 있다. 패키지는 http://rpmfind.net/ 에서 rpm 으로 다운로드 가능하다.

 

1)       lsof 이용시

lsof LiSt Open Files 약자로서 현재의 시스템에서 프로세스가 오픈하고 있는 모든 파일과 상세 정보를 보여주는데  lsof –i | grep 10101 하면 10101 포트를 사용하고 있는 프로세스를 확인할 있다. 만약 단순히 lsof 실행 파일만 다른 시스템에서 복사하여 사용하는 경우에는 –i 옵션이 제대로 작동하지 않는 수가 있는데, 이러한 경우에는  lsof > result.txt 실행하여 result.txt 파일의 결과를 참고해도 된다. 외에도 lsof 많은 다른 목적으로 사용되는 유용한 프로그램이므로 사용 방법을 익혀 두는 것이 좋다.

 

2)       fuser 이용시

fuser 특정한 파일이나 파일 시스템을 사용하고 있는 프로세스의 PID 보여주는 명령어로 fuser –n tcp 10101 같이 입력하면 10101 포트를 사용중인 프로세스ID 보여준다. 물론 UDP 포트일 경우에는 fuser –n  udp 53 같이 사용하면 된다.

이때 프로세스 ID 570번이라는 것을 확인했다면 PID 570번을 사용하는 프로세스를 확인하여야 하는데, 이는 ps 에서 보이는 결과로 확인을 하거나  ls –la /proc/570/ 결과중 exeà 가리키는 결과를 확인 하면 된다. exeà 가리키는 경로는 현재 실행 파일을 의미하며 cmdà 실행 파일이 참조하는 파일이나 디렉토리의 경로를 알려준다.

만약 exe à /home/user1/hacking/hacking* 이라고 되어 있으면 경로에 있는 파일이 10101 포트를 바인딩하고 있는 프로세스라는 것을 확인할 있다.

그리고 만약 프로세스가 정상적인 것이 아니라면 kill –9 570 (570 PID)  또는

 killall –9 –ev  hacking (hacking 프로세스 이름) 으로 해당 프로세스를 강제로(-9) 죽이면 포트도 닫히게 된다. 또는 커널 레벨에서 작동하는 패킷 필터링 툴인 ipchains(커널 2.2.X 기반) iptables(커널 2.4.X 기반) 이용하여 소스나 목적지 포트를 제어할 수도 있다.

들어오는 패킷에 대해서는 INPUT, 나가는 패킷에 대한 제어는 OUTPUT 그리고 소스 포트에 대한 제어는 –sport, 목적지 포트에 대해서는 –dport 이용하면 된다. 이를테면

# iptables –A INPUT –p tcp ! –sport 0:1023 –dport 25 –j ACCEPT

같은 경우 들어오는(INPUT) 패킷중 소스 포트가 0부터 1023 아닌(! –sport 0-1023) 1024부터 65535까지의 포트 그리고 목적지 포트는 25번인 패킷(--dport 25) 허용하겠다는 (-j ACCEPT) 의미 이다.

iptables 이용한 패킷 필터링에 대해서는 iptables 관련 문서나 글을 참고하기 바란다.

 

포트가 닫혔는지 여부는 “telnet localhost  port번호 확인하면 된다.

이외 netstat –lnp 같이 확인시에는 현재의 시스템에서 리슨(Listen)하고 있는 포트와 해당하는 프로그램의 목록을 쉽게 있다.

또한 아래의 사이트를 참조하면 특정한 포트 번호가 어떤 역할을 하는지에 대해서 상세한

정보를 얻을 있으니 특정 포트의 역할에 대해 궁금하신 분은 참고하기 바란다.

 

http://tantalo.net/ports/index.php3

http://advice.networkice.com/advice/Exploits/Ports/default.htm

http://www.chebucto.ns.ca/~rakerman/port-table.html

http://www.networksorcery.com/enp/nav0204.htm

http://www.practicallynetworked.com/sharing/app_port_list.htm

http://www.technotronic.com/tcpudp.html

 

 

 

 

 

 

 

2.     내부 시스템 모니터링 소프트웨어 활용

시스템에 문제가 발생했을 또는 발생 가능한 사고를 사전에 예방하기 위해서는 여러 가지 방법으로 시스템을 모니터링하고 또한 문제의 원인을 파악하여 문제를 해결하여야 하는 것이 시스템 관리자의 역할이다.  이번 파트에서는 간단한 명령어를 이용하여 호스트 시스템을 모니터링 있는 방법부터 각종 응응 프로그램을 이용하여 효율적으로 시스템을 모니터링하는 방법에 대해 알아보도록 하겠다.

 

간단한 명령어로 시스템 모니터링하기.

 

시스템 모니터링을 위해 가장 막강하면서도 간단한 프로그램으로는 앞에서 잠깐 설명한 netstat 있다. netstat 네트워크 연결정보, 라우팅 테이블, 인터페이스 정보등을 제공하며 그림과 같이 netstat –l 입력시 현재 시스템에서 리슨(Listen) 하고 있는 프로그램 포트 정보를 알려준다.

 


         < 그림1  netstat –l 실행 결과>

 

 

또한 SYN 패킷 요청만 보내는 서비스 거부 공격의 일종인 TCP SYN Flooding 공격(본지

7월호 SysAdmin “TCP SYN Flooding 공격의 원인과 해결책참고) 이나 아래와 같이

특정 데몬의 접속 요청을 독점해 버리는 Connect Flooding 공격도 감지 (netstat –na|grep EST) 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


     < 그림2.  Connect Flood 공격 감지 화면>

 

netstat –s 각종 프로토콜에 대한 통계를 있으며 netstat –r 라우팅 상황(route 명령어와 동일) netstat –i 인터페이스 상태를 점검(ifconfig 동일) 있다.  기타  netstat 이용 방법에 대해서는 man 페이지를 참고하기 바란다.

또는 tcpdump 사용할 수도 있다. Tcpdump 사용하여 특정 포트나 IP 에서의 패킷을 모니터링하여 패킷이 오가는지 여부를 점검하여 네트워크 장애시 문제 해결을 위해 활용할 있다.  이를테면 소스IP 192.168.1.30 고객이 서버에 접속이 된다고 한다면   tcpdump src 192.168.1.30 으로 띄워 놓은 패킷이 오가는지 접속 여부를  모니터링해  있을 것이다.

기타 tcpdump 아래와 같이 활용이 가능하다.

tcpdump port 80              # 80 포트로 오가는 패킷을 모니터링

  tcpdump src 192.168.1.1        # 192.168.1.1 소스로 하는 패킷을 모니터링

  tcpdump dst 211.3.4.5          # 211.3.4.5 목적지로 하는 패킷을 모니터링

  tcpdump host 211.3.4.5         # 소스나 목적지가 211.3.4.5 패킷을 모니터링

tcpdump net 211.3.4.0/24       # 소스나 목적지가  211.3.4.0 대역

( 211.3.4.1부터 211.3.4.254까지) 패킷을 모니터링

 

또한   tcpdump -a port 23 같이 사용할 경우에는 아래와 같이 telnet 접속을 스니핑 하는 용도로 사용될 수도 있다.

 

22:23:33.957216 eth0 > target.com.telnet > source.com.47034: P 83:90(7) ack 74 win 5792 <nop,nop,timestamp 34471591 12102054> (DF) [tos 0x10]

                          E^P ^@ ; .. w  @^@  @^F  r : .. /  A j

                         .. /  B 2 ^@^W .... ....  a ) .... ....

                         ..^X ^V..  J ~ ^@^@ ^A^A ^H^J ^B^M ....

                         ^@.. ....  l o  g i  n :

22:24:15.101414 eth0 > target.com.telnet > source.com.47034: P 102:112(10) ack 84 win 5792 <nop,nop,timestamp 34475706 12106168> (DF) [tos 0x10]

 

                          E^P ^@ > ....  @^@  @^F  r - .. /  A j

                         .. /  B 2 ^@^W .... ....  a < .... ....

                         ..^X ^V.. .... ^@^@ ^A^A ^H^J ^B^N ^N..

                         ^@.. ....  P a  s s  w o  r d  :

tcpdump  이용에 대한 추가적인 정보에 대해서는man 페이지나 http://www.tcpdump.org/ 참고하기 바란다.  추가적으로, 많이 사용하는 프로그램으로 ps 라는 명령어가 있다. Ps Process Status 약자로 시스템의 프로세스 상태를 모니터링할 있는데 주로 ps auxw 옵션을 주어 사용하면 각종 정보를 모니터링 있다. 특히 어떤 프로세스가 cpu 메모리를 많이 사용하는지 등의 정보를 확인할 있다.

netstat tcpdump 그리고 ps 명령어 사용법만 알고 있어도 대부분의 모니터링과 문제 발생시 해결을 있으며 이들 프로그램은 다른 툴의 기본이 되는 프로그램이므로 명령어의 사용법에 대해 확실히 숙지하는 것이 좋다. 

 

 포트 스캔 감지 프로그램 활용

 

원격지 시스템의 정보를 얻기 위해 공격자들이 제일 먼저 사용하는 방법이 바로 포트 스캔이다. 포트 스캔을 통해서 시스템의 열린 포트를 알아내어 어떤 서비스를 하고 있는지 있을 뿐만 아니라 운영체제, uptime 등의 정보도 얻을 있으며 정보를 토대로 시스템의 대략적인 보안 수준도 추측할 있다.  떄문에  서버 관리자 입장에서 포트 스캔을 당했다 함은 차후에 침해를 받을 있는 가능성이 있다는 것을 뜻하므로 포트 스캔을 감지하고 이에 대해 대처할 있는 프로그램을 필요로 한다.

포트 스캔을 감지하거나 차단하는 프로그램은 많이 있는데, RTSD 라는 프로그램을 추천한다. RTSD Real Time Scan Detector 약자로 한국정보보호진흥원(certcc.or.kr)에서 공개한 프로그램인데, 실시간으로 클라이언트와 서버의 포트가 상호 반응하는 관계를 보여주거나 포트 스캔으로 감지시 해당하는 내용을 관리자에게 통보해 주기도 한다.

프로그램은 http://www.certcc.or.kr/cvirc/y2kvirus/down/RTSD/register.html 에서 다운로드 가능하며 압축 해제후 Makefile rule.h 파일을 수정해 주면 된다.

Makefile 에서는 SunOS 관련 설정인 LIBS   = -lsocket -lnsl –lpcap 주석 처리하고 대신

주석되어 있는 리눅스의 #LIBS = -lpcap 주석을 삭제한다. 그리고 rule.h 파일에서는

#define IGNET "and not src net 192.168.1" 같이 스캔을 무시할 네트워크 대역을 정의하고 #define IGPORT "and not (port 80 or 110 or 20 or 21 or 25)" 같이 일반적으로 접속이 많아서 포트 스캔으로 감지하지 않을 포트를 or 나열해 주면 된다.

변경이 끝난후 make 실행하면 아래와 같이 가지를 묻게 된다.

[기관명]:-> 에는 자신의 기관이나 상호명을 입력하고(:오늘과내일)

    [스캔공격 탐지를 보고받을 E-mail 주소(Default root)]:->   포트 스캔 감지시 공격 탐지 정보를 받을 E-mail 주소를 기입하면 된다.(:antihong@tt.co.kr)

[스캔공격 탐지를 CERTCC-KR 보고하시겠습니까(Y/N, Default Y)]:->    Y 설정시에는 스캔 공격 정보를 CERTCC-KR에도 함께 발송하여 포트스캔 공격 사실을 신고하게 된다.

이후 make 생성된 RTSD 실행 파일에 –d 옵션을 주어 ./RTSD –d 실행하면 백그라운드로 작동하게 된다.

 

아래는 실제 포트 스캔을 감지시 관리자에게 발송되는 메일 예이다.

 

[01/09/26 01:02:09]
[Scan Attack] From 192.168.1.2:34814  To 210.40.65.5:2503
[Scan Attack] From 192.168.1.2:34815  To 210.40.65.5:12294
[Scan Attack] From 192.168.1.2:34816  To 210.40.65.5:6813
[Scan Attack] From 192.168.1.2:34817  To 210.40.65.5:10197
[Scan Attack] From 192.168.1.2:34818  To 210.40.65.5:8144

 

RTSD 간단하면서도 훌륭한 기능을 제공하지만, 다른 포트 스캔 감지 프로그램처럼 Passive 모드에서의 FTP 데이터 전송을 포트 스캔으로 인식하는 문제가 있으며 엄격하게 설정을 적용하였을 경우 정상적인 접속도 포트 스캔으로 간주하는 경우가 있기도 하므로 각자의 상황에 따라 모니터링후 룰을 적당히 적용하여 사용하면 된다.

이외 Inetd 모드에서 작동하는 Klaxon (http://www.eng.auburn.edu/users/doug/second.html) 이나 RTSD 비슷한 기능을 가진Scanlogd(http://www.openwall.com/scanlogd/) 그리고, 실시간으로 포트 스캔을  감지하여 Tcp Wrapper ipchains 등을 이용하여 포트 스캔을 하는 소스IP 차단하는 강력한 기능을 가진 PortSentry (http://www.psionic.com/abacus/portsentry/)  있다. 특히 PortSentry 경우 스캔을 하는 소스 IP 실시간으로 차단하는 기능이 있는데, 소스 IP 위조하여 스캔할 경우 문제가 있으니 정책 설정시 주의하여야 한다.

 

 

 

로그 모니터링 프로그램 활용

 

리눅스등 *NIX 계열이 Windows 계열에 비해 다른점은 로그에 대한 정책을 설정할 있고 많은 로그를 남길 있다는 점이다. 따라서 로그 정보를 효율적으로 모니터링하고 관리하는 것이 서버 관리자의  중요한 임무중 하나이다. 그러나 끝도 없이 쌓여가는 로그를 일일이 분석한다는 것은 거의 불가능에 가까우므로 이를 효과적으로 관리하여야 필요성이 제기된다.  이를 위해 로그를 관리해 주는 몇몇 프로그램에 대해 간단히 소개를 하겠다.

로그 모니터링 프로그램을 활용하기에 앞서 시스템에서 로그를 남기는 방식에 대해 먼저 이해를 하여야 하는데, 이에 대해서는 본지 8월호의 Focus Part2 ” 로그파일관리 자세히 소개되었으므로 로그 관련 글을 먼저 참고하기 바란다.

 

# Logcheck

Logcheck 실시간으로 로그 파일을 분석하여 사전에 해킹 시도등 비정상적인 상황이라고  정의된 내용이 로그에 남을 경우 해당 로그의 내용을 관리자에게 메일로 발송해 준다. 실시간 로그 체크는 logtail 이라는 프로그램을 이용하는데, 프로그램은 프로세스에 상주하여 실행되면서 체크한 로그 파일의 끝부분을 기억하고 있다가 새로운 로그의 내용이 추가될 때마다 계속적으로 로그 체크를 하게 된다.

Logcheck http://www.psionic.com/abacus/logcheck 에서 다운로드 하여

압축 해제 압축이 풀린 디렉토리에서 make linux 실행하면 설정 파일과 실행 파일이 자동으로 /usr/local/etc/ /usr/local/bin/ 디렉토리에 설치가 완료된다.

이후 /etc/crontab 파일에

00 * * * * root /bin/sh /usr/local/etc/logcheck.sh

같이 추가 설정하여 시간마다 logcheck 자동으로 실행하도록 한다.

이때 logcheck.sh 파일에서 SYSADMIN=antihong@tt.co.kr 부분을 이상 발생시 수신할

자신의 e-mail 주소로 변경해 주면 된다.

그리고

 /etc/logcheck/logcheck.hacking       // 해킹공격 관련 메시지

 /etc/logcheck/logcheck.ignore         // 해킹관련 로그에서 무시할 패턴

 /etc/logcheck/logcheck.violations      // 부적절한 보안관련 메시지

 /etc/logcheck/logcheck.violations.ignore // 부적절한 보안관련 로그에서 무시할 패턴

파일을 자신의 상황에 맞게 적절히 수정하여 사용하면 된다.

 

 # Swatch

Swatch 역시 Logcheck 비슷하게 로그 파일을 모니터링하다가 사용자가 지정한 패턴이 확인되었을 해당 내용을 메일로 발송하거나 벨소리를 내거나, 특정 스크립트를 실행하도록 있는 기능이 있으며 사용 방법에 대한 자세한 내용은  http://oit.ucsb.edu/~eta/swatch/ 참고하기 바란다.

 

 # Colorlog

이름에서도 있듯이 복잡한 로그 파일을 메시지의 내용에 따라 색을 다르게 하여 보여주는 프로그램으로서 사용 방법이 매우 쉽다.

 http://www.resentment.org/projects/colorlogs/ 에서 관련 파일을 다운로드하여 압축해제 colorlogs.conf 에서 모니터링할 이벤트(메시지) 색을 적절히 설정 (기본설정을 그대로 사용해도 무방하다.)  /etc/ 디렉토리로 옮긴

cat /var/log/messages | /usr/local/Colorlogs/colorlogs.pl  같이 실행하면 로그 파일에서 보안적으로 특별히 문제가 되는 부분만 다른 색으로 보여주어 로그 파일을 한눈에 쉽게 관리가 가능하다.

그리고 로그를 모니터링하여야 서버가 많을 경우 로그 서버를 별도로 운영하여 모든 로그를 서버에 몰아서 한꺼번에 관리할 수도 있다.

로그 서버를 운영하려면 먼저 로그를 보낼 서버의 /etc/syslog.conf 파일을 열어

authpriv.*      @logserver.tt.co.kr 같이 설정후 syslogd 재실행하고

로그를 받을 로그 서버에서는 별도의 설정 변경 없이  기존의 syslogd kill한 후 /usr/sbin/syslogd -m 0 -r –h 를 실행해 주면 된다. 이후 로그 서버의 /var/log/secure 를 보면 아래와 같이 여러 서버의 로그가 한꺼번에 저장되는 것을 확인할 수 있다.

 

Sep  8 18:34:50 192.168.1.30 ipop3d[544]: connect from 211.47.64.90

Sep  8 18:34:50 192.168.1.72 ipop3d[29281]: connect from 211.107.196.139

Sep  8 18:34:50 192.168.3.2 ipop3d[30311]: connect from 211.118.155.221

Sep  8 18:34:50 192.168.3.55 ipop3d[25460]: connect from 211.47.64.90

Sep  8 18:34:51 192.168.2.100 ipop3d[27111]: connect from 128.134.0.8

 

위와 같이 원격지 서버의 IP 대신 호스트 이름이 남도록 하려면 로그 서버의 /etc/hosts 파일에

 

192.168.3.55          www50

192.168.3.2           www16

와 같이 호스트 이름을 정의해 주면 IP 대신 쉽게 구분이 가능한 호스트 이름으로 남게 된다.

 

Sep  8 18:34:50 www34 ipop3d[544]: connect from 211.47.64.90

Sep  8 18:34:50 www28 ipop3d[29281]: connect from 211.107.196.139

Sep  8 18:34:50 www16 ipop3d[30311]: connect from 211.118.155.221

Sep  8 18:34:50 www50 ipop3d[25460]: connect from 211.47.64.90

Sep  8 18:34:51 www26 ipop3d[27111]: connect from 128.134.0.8

 백도어 점검하기

 

공격자들이 시스템을 공격하여 일정 권한을 획득한 후에는 차후에 다시 쉽게 들어올 있도록 자신만이 알고 있는 백도어(BackDoor) 만들어 두는 습성이 있다. 백도어는 여러 방식으로 구현 가능한데,  간단히 쉘을 복사해 두는 전통적인 방법부터 최근에는 커널 기반의 루트킷(RootKit) 까지 방식이 갈수록 교묘하고 고도화해지고 있어 백도어가 설치되어 있는지 여부를 점검하는 것이 매우 어렵다. 특히 보안에 그리 익숙하지 않은 초보 서버 관리자에게는 더더욱 그러한데, 이를 위해  아주 쉬우면서도 유용한 백도어 점검 프로그램인 chkrootkit 이라는 프로그램을 소개하고자 한다.  프로그램은 호스트내에서 t0rn 이나 라면 바이러스, 라이온 바이러스등 20여가지의 최근의 각종 루트킷 설치 여부를 점검해 주며 ifconfig, ps , netstat 변조되기 쉬운 40여가지의 바이너리 프로그램의 변조 여부를 체크해 준다.

프로그램을 이용하려면 먼저 http://www.chkrootkit.org/ 에서 최신 버전의 tarball 파일을 다운로드하여 압축 해제후 압축 해제한 디렉토리에서 make sense 실행하여 컴파일해 주기만 하면 모든 설치는 완료된다.

체크 방법은 가지로 있다. 첫번째는 chkrootkit 설치된 디렉토리에서

# ./chkrootkit 실행해 주면 자동으로 시스템을 검색하여 루트킷이나 파일 변조 여부를 알려준다.  세밀한 분석을 하고자 경우에는 # ./chkrootkit -x | more 같이 strings 이용하여 바이너리 파일을 직접 분석할 수도 있다.

또한 ./chkproc -v Hidden Process 여부도 확인 가능하다. Hidden Process 실제 프로세스에 떠서 작동하고는 있지만 ps auxw 등으로는 보이지 않는 것으로 이는 ps 에서 보이는 프로세스 정보와 /proc/pid/ 정보와 비교하여 ps 에서 보이지 않는 숨겨진 프로세스가 있는지 여부를 조사하는 방법으로 매우 유용하다. 하지만 짧은 시간에 많은 접속이 있는 웹서버등의 시스템의 경우 짧은 시간에 많은 프로세스가 죽었다 살았다를 반복하므로 잘못된 정보가 출력될 수도 있으므로 여러 실행해 보아야 한다.

 

파일 시스템 무결성 감시 프로그램

 

 # Fcheck

현재의 파일 시스템이 무결한 상태라고 판단하였을 경우 파일이나 파일 시스템의 무결성을 체크하기 위해 매번 프로그램을 실행할 수는 없다. 또한 chkrootkit 경우 일부 프로그램에 대해서만 체크를 하므로 상시적으로 모든 파일 시스템의 무결성을 체크하는 모니터링 프로그램을 필요로 하게 된다. 이러한 목적으로 파일이나 파일 시스템의 무결성을 모니터링 있는 프로그램으로는 Tripwire 가장 많이 알려져 있다.  Tripwire 설정예는 본지 9월호에서 다루어졌으므로  여기에서는 Tripwire 비해 간단한 설정으로도 막강한 기능을 제공하는 Fcheck 라는 프로그램을 소개하고자 한다.

Fcheck 지정한 디렉토리나 파일에 대한 각종 정보를 데이터베이스로 보관하고 있다가 정해진 시간마다 시스템을 체크하여 현재의 데이터 베이스 정보와 비교하여 파일 변조 여부를 모니터링하는 프로그램으로 빠른 속도와 간단한 사용 방법으로 사용을 권장하는 프로그램이다.  Fcheck http://www.geocities.com/fcheck2000/fcheck.html

 에서 다운로드하여 압축 해제후 fcheck 라는 실행 파일과 fcheck..cfg 라는 설정파일 이렇게 두개 파일만 수정해 주면 된다. 먼저 fcheck 파일에서 $config 부분을 $config="/usr/local/fcheck/fcheck.cfg"; 같이 fcheck 설치된 디렉토리로 변경하고

 

fcheck.cfg 파일을 열어

Directory = /bin/       #  무결성을 모니터링할 디렉토리

Directory = /usr/bin/   #  무결성을 모니터링할 디렉토리

Exclusion              #  모니터링을 제외할 디렉토리나 파일

Database =  /usr/local/fcheck/data/data.dbf    # 파일 시스템에 대한

데이터 베이스가 저장될 파일의 경로 

TimeZone= GMT-9     # Timezone 설정

 

과 같이 설정후 fcheck –ac 를 한번 실행해 주면 현재의 파일 시스템 정보를 데이터 베이스화 하여 지정한 파일에 저장한다. 현재의 파일 시스템 데이터베이스 정보를 근거로 이후에 변경되는 파일 시스템의 정보를 비교하므로 현재의 파일 시스템은 무결해야 한다.

아울러 /var 등과 같이 로그 파일이 있어 파일 시스템 정보가 자주 변경되는 파티션이나 파일은 모니터링할 디렉토리에 지정하지 않는 것이 좋다.  이후 fcheck –a 를 실행하면 현재의 파일 시스템 정보와 비교하여 추가나 삭제 또는 변경된 내용이 있을 경우 변경된 내용을 알려주고, 패키지 업데이트등 변경된 정보가 정상적인 경우에는 fcheck –ac 로 데이터 베이스를 업데이트 하여야 한다.

아래는 /usr/bin .hack 이라는 파일을 생성 후 fcheck –a 를 실행해 본 결과이다.

ADDITION: [www.tt.co.kr] /usr/bin/.hack

        Inode   Permissons      Size    Created On

        275505  -rw-r--r--      0       Sep 06 01:28 2001

 위와 같이 파일이 추가되었음을 알 수 있다. 파일의 정보가 변경시에는 ADDITION 대신 WARNING 이라는 메시지가 뜨고 파일이 삭제되었을 경우에는 DELETION 이라고 나타난다.

fcheck 에는 자동 메일통보등의 기능이 없으므로 이 작업을 매일 자동으로 하고 싶으면 /etc/cron.daily/ 디렉토리에 아래와 같은 실행 스크립트를 뱔도로 설정하여 실행하면 된다.

 

 

 

 

#!/usr/bin/perl

 

$TASK = `/usr/local/fcheck/fcheck -a|grep Inode`;  # 설치한 자신의 경로에 맞게 설정.

$HOSTNAME = `/bin/hostname`;

$TO_MAIL      = 'antihong@tt.co.kr';   # 이상 발견시 통보를 받을 e-mail 주소를 입력.

$SUBJECT      = "$HOSTNAME File 변조 확인";  # 통보받을 메일의 제목을 지정.

$MAIL_PROGRAM  = "/usr/sbin/sendmail";

if ($TASK){

  $TASK_CONFIRM = `/usr/local/fcheck/fcheck -a`;  #  자신의 경로에 맞게 설정.

&task_confirm;

}

sub task_confirm{

open(MAIL, "|$MAIL_PROGRAM -t");

    print MAIL "To: $TO_MAIL \n";

    print MAIL "Subject: $SUBJECT \n\n";

    print MAIL "Host: $HOSTNAME \n";

    print MAIL "$TASK_CONFIRM \n";

close(MAIL);

 }

 

위와 같이 설정 후에는 매일 자동으로 파일 시스템의 무결성을 체크하여 변경된 정보가 있을 경우에는  변경된 내용을 관리자에게 메일로 통보해 주게 된다.

만약 통보된 변화가 정상적인 것이라면 “fcheck –ac” 명령을 이용하여 데이터 베이스를 새로운 정보로 업데이트 하면 된다.

 

  # sXid

suid sgid s비트가 설정된 디렉토리나 파일은 보안상 매우 중요하다는 것을 잘 알고 있을 것이다. 따라서 suid sgid가 설정된 파일이나 디렉토리의 무결성에 대해서만 별도로 모니터링하는 프로그램을 필요로 한다면  sXid 라는 프로그램을 추천한다.

이 프로그램은 위에서 설명한 fcheck 와 작동하는 방식이 유사하다. cron을 이용하여 정기적으로 suid/sgid 를 모니터링하여 기본적으로 시스템에서 suid sgid 가 설정되어 있는  디렉토리나 파일에 어떤 변화가 있는지 체크를 한다.  파일이나 디렉토리가 새롭게 생기거나 또는 비트나 다른 모드를 변경했을 경우 sXid 는 그 변화에 대해  e-mail등으로 보고를 하게 된다.  일단 설치가 되면 자동으로 모든 일을 처리하므로 일일이 신경 쓰지 않아도 된다.

먼저 ftp://marcus.seva.net/pub/sxid/sxid_4.0.1.tar.gz 에서 파일을 다운로드 받아

압축 해제후 압축해제된 디렉토리에서 ./configure ; make ; make install 를 실행하면  설치가 완료된다.

실행 파일은 /usr/local/bin/sxid 이고 설정 파일은 /usr/local/etc/sxid.conf 인데, 특별히 변경할 부분은 없고 단지 EMAIL = “antihong@tt.co.kr부분만 정보 변경시 통지를 받을 자신의 e-mail 로 변경하면 된다.

그리고 /etc/cron.daily/ 디렉토리에

#/bin/sh

/usr/local/bin/sxid

와 같이 파일을 만들어 두면 매일 자동으로 sxid 를 실행하여 모니터링 결과를 메일로 발송해 준다.

 

패킷 모니터링 프로그램

 

앞에서 tcpdump netstat 등을 이용하여 간단히 패킷이나 세션을 모니터링하는 방법에 대해 알아보았다. 그러나 위 프로그램의 경우 직관적으로 패킷 모니터링을 하기에는 한계가 많으므로 iptraf 라는 별도의 패킷 모니터링 프로그램을 추천하고자 한다.

 Iptraf 는 작고 가벼우면서도 강력한 기능을 제공하는 프로그램으로서 네트워크에서 나가고 들어오는 모든 요청을 실시간으로 모니터링하는데, 각 호스트, 포트, 프로토콜등에 대한 세부적인 정보를 제공한다. Iptraf http://iptraf.seul.org/ 에서 파일을 다운로드후 압축을 해제하여 ./Setup 만 실행해 주면 설치가 완료된다.

설치된 디렉토리에서 iptraf 를 바로 실행하면 IP 트래픽, 인터페이스 통계, LAN station 모니터등 메뉴식으로 각종 정보를 쉽게 볼 수 있으며 프로토콜별로 필터링 기능도 제공한다. iptraf -d eth0 -B  와 같이 Background 로 작동시에는 기본적으로 /var/log/iptraf 디렉토리에 매 5분마다 각 프로토콜의 사용량, 트래픽등의 정보가 출력된다.

    < 그림3. iptraf IP Traffic 모니터 > 

 

 

 

 

 

 

 

 

 

 

 


               < 그림4. iptraf 를 이용한 프로토콜별 통계>

 

 

 

 

 

 

 

 

 

 

 

 

           < 그림5. iptraf 를 이용한 Port 별 통계>

 

            

가상 호스팅 도메인 모니터링

 

 

서버에 여러 개의 도메인을 설치하여 웹호스팅을 하는 경우 각각의 도메인에 대해

트래픽이나 하루 접속자 수등을 모니터링 해야 필요성이 제기된다.  특히 웹호스팅을 전문적으로 하는 업체에서는 필수 기능이라 있는데도 불구하고 실제로 방법이 알려져 있지 않아 일일이 수작업으로 모니터링을 하거나 아예 모니터링을 포기해야 하는 경우가 많다.  서버 전체에 대해 트래픽을 관리하려면 서버에 snmpd 데몬을 띄우고 mrtg 설치하여 모니터링하면 된다. 방법은 본지에서도 여러 소개되었으므로 관련 기사(본지 8월호 focus) 참고하시기 바란다. 아울러 서버에 여러 도메인을 설치하여 가상 웹호스팅을 서비스 하고 있는  경우 각각의 도메인에 대해 트래픽을 관리할 있는 방법은 가지가 있지만 일일이 직접 프로그램을 코딩해야 하므로 가장 쉽고 효과적인  방법으로 mod_throttle  이라는 아파치 모듈을 이용하는 방법을 추천한다.   아파치 모듈은 가상 호스트별로, 디렉토리별로, 위치(Locations)별로 또는 유저에 따라 서버의 로드를 낮추거나 대역폭을 낮추기 위해 개발되었다.  이를 통해 각각의 가상 호스팅 도메인에 대해  접속 속도를 조절하거나 일정 제한을 초과할 경우에는 접속 요청을 거부할 수도 있다.   설치를 하려면 아파치 웹서버에 모듈로 포함시키거나 정적으로 포함시켜야 하는데, 결국 아파치 컴파일을 다시 하여야 한다.

먼저 http://www.snert.com/Software/mod_throttle/mod_throttle312.tgz 에서 관련 소스 파일을 다운로드하여 압축을 해제한다.

DSO 모듈을 빌드하기 위해서는 아파치 소스 디렉토리에서 아래와 같이 한다.

cd (path to)/mod_throttle-3.1

make install

 

권장하는 방법으로, 스태틱하게 모듈을 빌드하려면 아파치 소스 디렉토리에서 컴파일시 아래와 같이 mod_throttle 모듈에 추가하도록 한다.

./configure --prefix=/usr/local/apache --activate-module=src/modules/php4/libphp4.a

--add-module=../mod_throttle-3.1.2/mod_throttle.c

  설정은 php4 mod_throttle 아파치에 모듈로 설정하는 화면이다.

아파치 컴파일을 완료한 생성된 /usr/local/apache/bin 디렉토리에서 httpd -l 실행하여 mod_throttle.c 모듈에 포함되었는지 여부를 확인한다. 모듈로 포함되었음이 확인되면

일단 설치는 완료되었으니  이제 본격적으로 httpd.conf 설정을 보도록 하겠다.

 

# 공통설정부분

<Location /throttle-status>

Order deny,allow

Deny from all

Allow from 192.168.1.0/255.255.255.0 

</Location>

위는 throttle-status 설정하였을 경우 http://domain.com/throttle-status/ 접속시 모든 도메인에 대한 트래픽이나 접속자수등의 중요한 정보가 그대로 노출되므로 throttlee-status 대해 특정 IP 대역에서만 (위의 경우 192.168.1.0 대역에서만)  접근이 가능하도록 제한하는 설정이다.

 

# 일반 설정 부분.

<IfModule mod_throttle.c>

ThrottlePolicy None          // 기본적으로는 None 으로 설정한다.

<Location /throttle-status>

SetHandler throttle-status      // throttle-me 등도 있는데, throttle-status 필요하다.

</Location>

</IfModule>

 

참고로 throttle-me http://domain.com/throttle-me/ 접속시 domain.com 이라는 하나의 도메인에 대해서만 정보를 확인할 있도록 하는 방법이다. http://domain.com/throttle-status/ 접속시에는 모든 가상 도메인에 대해 정보를 있게 된다.

 

# 가상 호스트 설정 부분. 

<VirtualHost data1.tt.co.kr)

ServerAdmin antihong@tt.co.kr

DocumentRoot /home/data/public_html

ServerName data1.tt.co.kr

ThrottlePolicy Volume 300M 1d      //하루에 전송량 300M

ThrottlePolicy Request 1000 1d       //하루에 히트수 1000 제한

ThrottleClientIP 100 volume 200 300   // 로그를 100K 남기며 300초간 200K 전송량 제한

</VirtualHost>

 

위와 같이 설정 전송량이나 히트수등을 초과하면 data1.tt.co.kr 접속시 원래의 페이지가 아닌 503 에러 화면이 뜨게 되며, ErrorDocument 503  /~user/ redirect 설정을 추가해 주면 트래픽 초과시  503에러화면 대신 /~user/index.html 파일을 보여 주도록 한다. 따라서 파일에 트래픽이나 히트수등의 초과에 대한 경고문등 적당한 메시지 화면을 만들면 된다.

 

그리고 아래와 같이 설정시에는,

 

# 일반 설정 부분.

<IfModule mod_throttle.c>

ThrottlePolicy Volume 300M 1d

<Location /throttle-status>

SetHandler throttle-status

</Location>

</IfModule>

 

# 가상 호스트 설정 부분. 

<VirtualHost data2.tt.co.kr)

ServerAdmin antihong@tt.co.kr

DocumentRoot /home/data2/public_html

ServerName data2.tt.co.kr

ThrottlePolicy Volume 500M 1d    // 하루에 전송량 500M

</VirtualHost>

 

위와 같이 설정시 별도로 제한을 설정하지 않은 모든 도메인은 하루 전송량이 1

300메가로 제한되지만 data2.tt.co.kr 500메가로 제한된다.

모든 설정에 대한 관리는 http://www.mydomain.com/throttle-status 에서 가능하며

보다 자세한 이용 방법은 http://www.snert.com/Software/mod_throttle/ 참고하기 바란다.

또한 http://www.snert.com/Software/mod_watch/ 모듈을 이용하면 기능외에 가상 도메인별로 인바운드, 아웃 바운드되는 트래픽을 mrtg 그래프로도 있다.


 

 

   < 그림5. 실제 throttle-status 작동 화면 >

 

 

 

 

 

3.외부 시스템(네트워크) 모니터링 소프트웨어 활용

호스트 기반의 보안이 운영체제에 의존하여 하나의 호스트에 대한 각종 보안 정책 모니터링 설정을 의미하는 것이라면 네트워크 보안은 운영 체제에 관계없이 네트워크 패킷에 대한 정책 설정을 의미한다. 파트에서는 개념 뿐만이 아니라 넓은 의미의 외부 시스템 보안을 포함하여 각종 네트워크 모니터링 방법에 대해 알아보도록 하자.

 

 

스니핑(Sniffing) 모니터링

 

동일 네트워크에 대형의 시스템들이 몰려있는 웹호스팅 업체나 IDC등에서는 스니핑 공격에 매우 유의하여야 한다. 취약한 하나의 시스템에서만 관리자 권한을 획득하여 스니핑을 돌린다면 전체 네트워크를 장악하는 것은 시간 문제이기 때문이다.

일반적으로 스니핑이 작동하고 있다면 인터페이스 카드가 PROMISC 모드(우리말로 무차별 모드라고 한다.) 변하게 된다.  Promisc 모드로 설정되어야 상의 모든 트래픽을 받아들일 있기 때문이다.  시스템 내부에서 스니핑이 작동하고 있는지의 여부는 단순히 ifconfig -a|grep PROMISC 이더넷 카드에 PROMISC 설정되어 있는지를 쉽게 확인할 있으나 시스템 외부에서 여부를 확인하기는 쉽지 않다.

대부분의 문서에서는 인터페이스 카드가 Promisc 설정되어 있다면 스니핑이 돌고 있다고 밝히고 있지만, 실제로 시스템에 따라 기본적으로 Promisc 설정되는 경우도 있으므로 PROSMIC 설정되어 있다고 해서 반드시 스니핑이 작동하고 있는 것은 아니다.

네트워크에서 스니핑이 작동하는지 여부를 모니터링 있는 가지 프로그램이 있는데, 추천하고 싶은 프로그램으로 Sentinel 이나 Antisniff 그리고 관련 프로그램으로 ARPWATCH 있다.

Sentinel 설치하려면 미리  패킷 캡처 라이브러리인 Libnet 1.0 libpcap 설치되어야 하는데, 각각 (http://www.packetfactory.net/Projects/libnet) (ftp://ftp.ee.lbl.gov/libpcap-0.4.tar.Z) 에서 다운로드 받아 압축 해제 압축이 풀린 디렉토리에서 ./configure; make ; make install 설치하면 된다.  그리고 Sentinel http://www.packetfactory.net/Projects/sentinel/  에서 다운로드 가능하며 다운로드하여 압축 해제   압축이 풀린 디렉토리에서 make all 컴파일하여 설치하면 된다.  현재 Sentinel 원격지 시스템에서 스니핑이 작동하는지 여부를 감지하는 방법은 3가지가 있는데,  방법은 각각 DNS test,  Etherping test,  ARP test이다.

 

먼저 각각의 방법이 가능한 원리에 대해 간단히 살펴보면, 우선 DNS test 경우 목적지 서버에 위조된 연결 요청을 보내어, 일반적인 스니핑 프로그램이 요청받은 시스템의 IP 주소를 역리졸브(Inverse DNS lookup) 한다는 특징을 이용하여 DNS 트래픽을 감시하여 스니핑을 감지하는 방법이다.

Etherping test 목적지에 ping 보낼 목적지의 IP 맞지만 목적지의MAC 주소는 존재하지 않는 정보로 하여 Icmp Echo Packet 보내어 응답이 오는지를 감시하는 방법으로 대부분의 정상적인 시스템에서는 MAC 정보가 올바르지 않기 때문에 패킷을 DROP 하지만 promiscuous mode 설정된 시스템에서는 응답을 한다는 특징을 이용하여 감시하는 방법이다.  마찬가지로 ARP test 역시 IP 맞지만 목적지의 MAC 주소를 다르게 하여 ARP 요구를 보내는 방법으로 Promisc 모드가 아닌 경우에는 패킷이 목적지까지 없으므로 목적지에서는 응답하지 않지만 Promisc 모드인 경우에는 모든 패킷을 받아들이므로 결국 응답한다는 특징을 이용하여 감시하는 방법이다.

각각의 방식에 대한 실행 방법예는 아래와 같다.

 

./sentinel -a -t 192.168.1.2                 # ARP 테스트

./sentinel -d -f 1.1.1.1 -t 192.168.1.2         # DNS 테스트

./sentinel -e -t 192.168.1.2                 # Etherping 테스트

./sentinel -t 192.168.1.2 -f 1.1.1.1 -d -a –e     # 3개의 테스트를 동시에  수행

 

위와 같이 실행시

Results: 192.168.1.2 tested positive to etherping test.

같이 탐지 결과가 positive 나오면  Promisc 모드로 설정되었다는 의미이므로 해당 인터페이스의 PROMISC 여부를 조사하여야 한다.

 

아울러 Antisniff 경우 http://www.securitysoftwaretech.com/antisniff/ 에서 다운로드 가능하며 리눅스 버전과 아울러 윈도우 버전의 프로그램도 이용 가능하다. 테스트 방법은 위의 Sentinel 비슷하며 추가적으로 Latency test 라는 방법이 있는데, 방법은 스니핑이 작동시 무차별 모드로 설정되어 있어 로컬 네트워크상의 모든 트래픽을 받아들이느라 로드가 높아진다는 점을 이용해 불필요한 트래픽을 전송하여 시스템의 응답 시간이 길어지는지 여부를 조회하는 재미있는(?) 방법으로 아직까지는 100% 신뢰할 수는 없는 방법이며 계속적으로 개선중인 기능이다.

 

윈도우 버전의 경우 테스트하는 IP 대역을 지정하여 한꺼번에 검사가 가능하고  검사 결과에 대해 각종 통계도 있으며, 얼마의 주기로 테스트를 것인지를 시간대별, 날짜별, 주별로 정할 있는 예약 기능 검사 결과가 변경시 메일로 발송하거나 음악이 나오게 하는 등의 알람 기능도 있어 편리하게 사용이 가능하다.

 


                  < 그림6. Antisniff 이용한 체크결과 화면>

 

 

 

끝으로 이와 관련하여 권장할 만한 프로그램으로 ARPWATCH 있다.

프로그램은 ARP 트래픽을 모니터링하여 MAC 주소와 IP 매칭을 감시하는 프로그램으로 정보가 변경되거나 새로운 MAC 주소가 확인시에는 해당하는 내용을 관리자에게 메일로 통보하게 된다. ARPWATCH 이용시 MAC 주소나 ARP 이용하는 공격에 대한 대응에 매우 유용하다.  ARPWATCH 패킷 캡처 라이브러리인 libpcap 사용하므로 먼저 ftp://ftp.ee.lbl.gov/libpcap.tar.Z  파일을 다운로드하여 압축 해제후 ./configure; make ; make install libcap 프로그램을 설치한다. 설치되지 않으면 http://rpmfind.net/ 에서 rpm 으로 다운로드하여 설치도 가능하다. 라이브러리가 설치되면  ftp://ftp.ee.lbl.gov/ 에서 arpwatch 프로그램을 다운로드 하여 압축 해제 설치 전에 addresses.h 파일을 열어 

#define WATCHER "antihong@tt.co.kr"

#define WATCHEE "arpwatch (Arpwatch)"

같이 변경된 ARP 정보 발견시 메일을 수신할 e-mail 주소와 발송시 발신자 정보를 정의한다.  변경 압축 해제한 디렉토리에서 ../configure; make ; make install 설치를 하면 된다.

 설치 이후 같은 디렉토리에서 touch arp.dat 파일을 생성 ./arpwatch –d 실행하면 현재 네트워크의 MAC 정보와 IP 정보를 매칭하여 arp.dat 파일에 데이터 베이스쌍을 생성한다.

데이터 베이스 생성이 완료된 ./arpwatch 실행하여 두면 실시간으로 ARP 트래픽을 체크하여 새로운MAC 정보가 추가되거나 MAC 정보가 변경되는 현재의 데이터 베이스 정보와 다른 정보가 발견 시에는 앞에서 지정한 관리자에게 해당하는 내용에 대해 통보를 하고 데이터 베이스를 갱신하게 된다.

아래는 MAC 정보가 변경시 관리자에게 메일로 통보된 내용의 예이다.

 

     hostname: arp.tt.co.kr

     ip address: 192.168.1.1

     ethernet address: 0:0:1c:2:38:18

     ethernet vendor: JDR Microdevices generic, NE2000 drivers

     old ethernet address: 0:50:bf:30:fe:50

     old ethernet vendor: <unknown>

     timestamp: Monday, April 23, 2001 21:49:08 +0900

     previous timestamp: Monday, April 23, 2001 20:11:47 +0900

     delta: 1 hour

 

 

 네트워크에서 특정 문자열 탐지하기

 

얼마전까지 많은 서버에 피해를 주었던 코드레드 바이러스는 Windows NT Windows 2000  IIS 서버만 공격하는 것으로 알려져 있지만 실제로 웹서버의 버전과는 관계 없이 80 포트로 무차별적인 접속시도를 하여 기반의 스위칭이나 라우터등 일부 네트워크 장비가  다운 되는 등의 문제가 있었다. 또한 아파치 서버의 경우 로그를 남겨 놓았을 경우 서버에 많은 로그를 남기어 디스크가 Full 되는 경우도 있었다. 코드 레드의 경우 서버의 로그 파일을 보면 공격지 IP 확인할 있지만 일일이 서버의 로그파일을 남기거나 분석하지 않고도 네트워크상에서 특정 문자열로 탐지가 가능하다.

이는 ngrep 이라는 툴을 이용하면 된다.   ngrep 네트워크에 전송되는 트래픽에서 특정

문자열이나 텍스트만을 검색하는 막강한 기능을 가진 프로그램으로 코드 레드의 경우  기본

적으로 default.ida 파일을 요구하므로 문자열을 요구하는 패킷을 검색하면 된다.

 

# ngrep -qt ".ida\?" tcp port 80

 2001/09/05 18:50:34.514746 211.192.184.151:3441 -> 211.40.15.176:80 [A]

  GET /default.ida?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

 

위의 경우 211.192.184.151 에서 211.40.15.176 서버로 코드레드 시도를 하고 있는 것을 있다.   이처럼 ngrep 네트워크상의 패킷에서 특정 문자열만을 뽑아냄으로써 이를 응용한다면 모든 네트워크 모니터링 프로그램이 그러하듯이 막강한 스니핑 툴로도 악용이 가능하다.  만약 네트워크상에서

# ngrep  -wi  'user|pass'  tcp port 110 같이 입력하였다면 잠시 아래와 같이

interface: eth0 (211.40.165.43/255.255.255.0)

filter: ip and ( tcp port 110 )

match: ((^user|pass\W)|(\Wuser|pass$)|(\Wuser|pass\W))

 

T 61.73.202.236:26129 -> 211.40.165.43:110 [AP]

  USER admin..

 

T 61.73.202.236:26129 -> 211.40.165.43:110 [AP]

  PASS qwert!23a..

 

pop3 접속하는 Id /pw 그대로 노출되는 것을 확인할 있을 것이다. 물론 위와 같이 110 외에 다른 Port 스니핑도 가능하다. Ngrep 패킷 라이브러리를 사용하므로 프로그램 설치에 앞서 앞에서 설명한 libpcap 먼저 설치한

http://www.packetfactory.net/projects/ngrep/ 에서 ngrep 다운로드하여 압축 해제후 압축 해제한 디렉토리에서 ./configure; make  설치하면 된다. 또는 http://rpmfind.net/ 에서 rpm 형태의 파일을 직접 다운로드하여 설치하여도 된다.

# ngrep -q 'sex|porno' 같이 실행 시에는 네트워크내 패킷에서 sex porno 라는 문자열이 포함된 트래픽을 찾아주는 여러 가지로 활용이 가능하니 구체적인 이용에 대한 안내는 홈페이지를 참고하기 바란다.

 

 mrtg 메일서버 모니터링 하기

 

mrtg 이용하여 서버나 라우터의 트래픽이나 데이터 전송량을 모니터링 하는 방법은 많이 소개되었으니 이번에는 메일 서버에서 각종 정보를 mrtg 통계내어 확인하는 방법을 살펴보도록 하자. 일단 메일 서버의 각종 통계 데이터는 sendmail 에서 제공하는 mailstats 라는 프로그램을 이용하면 되는데, mailstats /var/log/sendmail.st 파일을 참고하므로 sendmail.cf 에서 설정이 주석 처리되지는 않았는지 확인하여 주석이 되어있으면 주석을 제거하고,  /var/log 디렉토리에 sendmail.st 파일을 생성한 sendmail 재시작해 주면 파일에 관련 정보가 생성된다.

그리고 메일서버의 정보를 mrtg 보려면 mrtg-mailstatus 라는 별도의 프로그램을 필요로 하는데, 프로그램은 http://www.infocom.com/~littell/software/mrtg-mailstats.html 에서 관련 파일을 다운로드하여 설치 아래와 같이 mrtg 위한 cfg 파일을 만든 mrtg 실행해 주면 된다.

 

# 설정은 하루에 전송되는 smtp.tt.co.kr 서버의 메일개수를 mrtg 보여준다.

 

Target[mail.tt.co.kr]:`/usr/local/mrtg/mrtg-mailstats -s smtp.tt.co.kr`

Title[mail.tt.co.kr]: E-mail 개수

YLegend[mail.tt.co.kr]: Sent mail number

 

# 이 설정은 smtp.tt.co.kr 서버의 하루전송 메일 트래픽을 mrtg 로 보여준다.

Target[mail.tt.co.kr]: `/usr/local/mrtg/mrtg-mailstats -b -s smtp.tt.co.kr -p 2525`
MaxBytes[mail.tt.co.kr]: 1250000
Title[mail.tt.co.kr]: Remote Mail Traffic
PageTop[mail.tt.co.kr]: <H1>Remote Mail Traffic</H1>

 

그리고 메일 서버에서는 /etc/services 파일에

smtp-stats      2525/tcp        snmp-stats 추가하고

/etc/inetd.conf

smtp-stats      stream  tcp     nowait  nobody  /usr/sbin/tcpd       /usr/sbin/mailstats

같이 추가하면 된다.

설정이 끝난 5 간격으로 정기적으로 실행하여 주기 위해 /etc/crontab 파일을 열어

0-59/5 * * * * root run-parts /usr/local/mrtg/run/mrtg  mail.cfg  같이 추가해 주면 5분마다 자동으로 실행하여 아래와 같이 그래프를 생성하게 된다. 아래의 경우 하루 평균 5000여통이 메일이 전송되고 있는 것을 있다.

기타 Mrtg 사용방법에 대해 궁금하신 분은 본지 8월호 part3 “시스템 모니터링과 자동화하기 참고하거나  http://www.mrtg.org/ 또는  http://www.mrtg.co.kr/ 참고하기 바란다..

 


 

    < 그림7. 전송되는 메일 개수를 mrtg 화면>

 

 

 mrtg 로 네트워크 속도 모니터링하기

 

추가적으로, mrtg 를 활용하여 특정 네트워크와의 접속 속도등을 모니터링하는 방법을 알아보도록 하자. 이를 위해서는  mrtg-ping-probe 라는 별도의 프로그램을 사용하면 되는데, 이 프로그램을 이용하면 특정 호스트 사이의 ping 소요 시간, 패킷 로스등을 그래프로 볼 수 있다.