제 목:[9908]네트워크정복의 첫걸음(1) [241] 1999-08-31 14:22 네트워크 정복의 첫 걸음!(1) NMS의 개념 네트워크와 분산 시스템은 정보화 사회의 중추적인 역할을 담당하고 있으며 그 중요성이 날로 커지고 있다. 이에따라 얼마 전부터 안전하고 효율적인 네트워 크 환경을 위한 관리의 개념이 중요하게 대두되고 있다. 이에 연재를 통해 인 터넷 환경에서의 네트워크 관리 시스템에 대한 전반적인 내용을 살펴보도록 하 겠다. 이번 호에서는 네트워크 관리 시스템의 개념과 이를 기술하기 위한 언어 인 ASN.1(Abstract Syntax Notation.1)에 대해 알아보도록 하겠다. 노정민 한국항공대학교 항공통신정보공학과 대학원 hmask@esc.cl.hangkong.ac.kr 디지털 시대를 맞아 대부분의 대기업과 관공서에서 네트워크를 기반으로 주요 업무를 처리하고 있다. 따라서 네트워크가 다운된다거나 갑자기 속도가 떨어진 다면 단순한 문제가 아니라 국가적인 문제가 될 수 있다. 이같은 이유로 21세 기 기업 컴퓨팅 환경의 인프라라고 할 수 있는 네트워크의 중요성은 나날이 커 지고 있다. 네트워크 관리의 개요 네트워크는 인터넷의 보편화와 함께 급속도로 번지고 있다. 또한 데이터망 (Data Network)과 기존 통신망(Telecom m unication Network)의 통합과 서로 다른 시스템, 네트워크 장비, 운영체계(Operating System), 통신규약(Protocol) 등이 복잡하게 묶여 있으며 이를 사용하는 서비스와 사용자가 급격하게 증가하 여 점점 규모가 커지고 있다(그림 1). 따라서 안정적이고 효율적인 네트워크 환 경을 제공하기 위해서 네트워크 상에 존재하는 다양한 자원들을 모니터링하고 제어하는 네트워크 관리의 개념이 필요하게 되었다. 네트워크 관리의 개념을 세분화 시켜보면 다음과 같다. ① 전산 자윈의 중요성이 커짐 네트워크와 분산된 전산 자원들은 그 단체에서 가장 중요한 역할을 수행할 뿐 만 아니라 자산으로서도 중요성이 커지게 되어 전산자원 자체도 효율적인 관리 를 필요로 하게 되었다. ② 복잡해진 네트워크 관리 구조 다양한 네트워크 구성요소와 인터페이스, 프로토콜의 사용과 서비스로 인해 네 트워크가 한층 복잡해져 관리가 어려워졌다(그림 2). ③ 서비스 개선 네트워크를 이용하는 규모가 커지고 이에따라 자원과 정보가 증가함에 따라 안 정적인 고속 서비스를 원하게 되었다. ④ 사용자의 다양한 요구 충족 성능, 가동율(Availablity), 보안(Security) 등에서 사용자의 다양한 요구를 만족 시켜야 한다. ⑤ 자원의 활용성(Utilization) 증대 네트워크에 소요되는 경비를 조절하기 위해 분산된 네트워크 자원의 활용성을 모니터링하고 제어하는 것이 필요해졌다. 네트워크 관리 시스템 네트워크 관리 시스템(이하 NMS)은 네트워크 상의 자원들을 모니터링하고 제 어하기 위한 도구로 네트워크 관리 정보를 입력받아 적당한 관리 동작을 한다 (그림 3). NMS는 하드웨어 또는 소프트웨어로 구성되며 기존의 네트워크 자원 에 덧붙여 사용된다. 네트워크 관리 시스템의 구조 NMS는 관리자가 쉽게 사용할 수 있는 간단명료한 인터페이스로 구성되어야 하지만 전체 네트워크를 일관된 구조로 살펴보기 위해서는 모든 네트워크 관리 업무를 수행할 수 있을 만큼 기능이 강력해야 한다. 이를 위해 NMS는 전체 시스템에서 관리하는 네트워크 요소의 각 지점과 특정 한 속성에 주소와 이름을 지정하고, 반대로 작동하는 네트워크 요소들은 주기 적으로 자신이 가진 정보를 중앙 제어 센터에 제공하는 구조를 취한다. 이런 구조를 관리자-대리자(Manager-Agent Paradigm) 구조라고 한다(그림 4). 네트워크 관리 시스템의 구성 NMS는 에이전트(Agent)와 매니저(Manager)로 나뉘어지며 NME와 NMA로 이루어져 있다(그림 5). NME(Net work Management Entity)는 실제 에이전트 의 역할을 수행하는 객체로 네트워크 자원들에 대한 직접적인 관리를 한다. 워 크스테이션(Workstation), 브릿지(Bridge), 라우터, PC를 비롯해서 기타 관리되 는 시스템에 존재하며, 네트워크와 관련된 정보를 수집하여 저장하고 매니저로 부터 요청이 들어오면 자신이 관리하는 정보를 보내준다. NMA(Network Management Application)는 매니저의 역할을 수행하는 응용프 로그램으로 에이전트가 관리하는 객체의 내용들을 수집해서 전체 네트워크를 관리한다. 에이전트와 통신을 할 때는 다양한 종류의 네트워크로 인해 표준화 된 프로토콜(SNMP, CMIP)을 사용하여 정보를 교환한다. Proxy 매니저와 에이전트가 서로 다른 프로토콜을 사용하거나 표준에 맞지 않는 자체 적인 관리 인터페이스를 가지는 경우 중간에 프록시(Proxy)를 둔다(그림 6). 프록시는 매니저의 표준 프로토콜을 받아 상대 시스템에 맞는 형태로 변환시켜 서 전달하고, 상대 시스템에서 되돌아온 결과를 표준 프로토콜로 바꾸어 매니 저에게 전달한다. 네트워크 모니터링 네트워크 모니터링이란 NMS를 이용하여 네트워크 자원들의 상태를 관찰하여 분석하는 것이다. 모니터링 정보의 분류 네트워크 모니터링에서 얻는 정보는 크게 정적 정보(Stat ic Information), 동적 정보(Dynamic Information), 통계 정보(Statistical Information)로 구분된다. 정 적 정보는 네트워크의 구성과 구성 요소와 같이 쉽게 변하지 않는 정보를 말한 다(예：포트 번호). 동적 정보는 네트워크의 상태와 이벤트에 의해서 변하는 정 보를 말한다(예：패킷의 전송량, 에러 개수). 마지막으로 통계 정보는 동적 정 보의 통계치(평균 전송량)를 뜻한다. 모니터링 방법 에이전트의 내용을 매니저에게 전달하는 방법에는 폴링(Polling)과 이벤트 보고 (Event Reporting)가 있다(그림 7). 폴링은 요청에 의한 응답 (Request-Response) 방식으로서 매니저가 에이전트에게 원하는 정보를 요구 (Request)하면 에이전트는 매니저가 원하는 정보를 찾아서 응답(Response)해 준다. 그리고 SNMP(Simple Network Management Protocol)에서 정보를 교환 하는 주된 방법으로 구현은 쉽지만 네트워크에 부하를 많이 주는 단점이 있다. 다음으로 이벤트 보고는 에이전트가 매니저의 요구가 없어도 매니저에게 정보 를 보내는 방법으로 상태나 속성값이 자주 바뀌지 않는 경우에 폴링 방식보다 효율적이다. 특별한 이벤트가 발생했을 경우에 주로 사용되며 SNMP에서는 트 랩(Trap)이라고 한다. 네트워크 모니터링에 의한 관리 네트워크 모니터링에 의한 관리는 크게 결함 관리, 과금 관리, 성능 관리로 구 분할 수 있다. 이들 관리를 자세히 살펴보도록 하겠다. 결함 관리(Fault Management) 결함 관리 기능은 그림 8과 같이 관리하고 있는 네트워크 장비에 결함이 발생 했을 경우 원격에 위치한 관리 시스템이 이를 빠르고 효과적으로 처리하여 시 스템과 네트워크가 정상적으로 동작하도록 하기 위한 기능이다. 결함 처리 과 정은 다음과 같다. ① 결함이 발생한 위치를 파악한다(Detect). ② 결함이 발생한 부분을 다른 부분으로부터 격리한다(Isolate). ③ 결함의 영향을 최소화하기 위해 네트워크를 변경해서 재구성한다 (Reconfigure). ④ 결함을 일으킨 구성 요소를 수리하거나 교체한다(Repair). 이런 결함 관리를 위해서는 로깅(Logging), 이벤트 보고, 연결 테스트 기능이 필요하다. 로깅 기능은 중요한 사건들과 에러를 기록하는 기능으로서 로그 데 이터의 분석을 통해 결함을 발견할 수 있다. 이벤트 보고 기능은 어떤 사건이 발생하면 바로 관리자에게 보고하는 기능이다. 진단 기능은 연결 테스트(예 : traceroute), 프로토콜의 무결성, 응답시간검사(Response Time Check), 생존 검 사(예 : ping), 루프백(loop-back) 등을 검사하는 기능이다. 과금 관리(Accounting Management) 과금 관리는 네트워크 자원에 대한 활용(Utilization) 정보를 얻기 위해서는 사 용 용도에 따른 쿼터(quota)를 할당하고 사용자를 구분(Identify)해서 사용자별 로 관리 내역을 기록해야 한다(그림 9). 이와 같이 과금 관리는 사용자들의 네 트워크 자원 사용 현황을 지속적으로 검사하여 이를 데이터베이스에 저장해서 자원의 사용 정도에 따라 이용료를 부과하기 위해 필요한 기능이다. 또한 과금 관리에서 얻어진 정보들은 다른 곳에서도 유용한 정보로 사용된다. 성능 관리 기능(Performance Management) 현재 네트워크 장비들과 링크에 대한 활용도를 조사해서 가장 효율이 높은 경 로를 찾거나, 성능 저하가 있는 부분을 찾아내어 문제를 해결하는 기능이다(그 림 10). 네트워크 성능을 측정하기 위한 지표들은 표 1과 같고 성능은 다음 사 항들과 밀접한 관련이 있다. ·용량 활용도(Capacity Utilization)가 얼마나 높은가? ·과도한 흐름(Excessive Traffic)이 있는가? ·처리량(Throughput)이 줄어들었는가? ·어디서 병목(Bottleneck)이 일어나는가? 따라서 성능 관리에는 이들을 모니터링 할 수 있는 다음 기능들이 필요하다. ·성능 측정(Performance Measurement) : 실제 트래픽을 측정하는 기능으로 에이전트에 의해 수행된다. ·성능 분석(Performance Analysis) : 에이전트들이 측정한 통계치를 모아서 분석하는 기능으로 매니저에 의해 수행된다. ·테스트 트래픽 생성(Synthetic Traffic Generation) : 인위적으로 트래픽을 생 성하여 성능을 측정하는데 사용한다. 네트워크 제어에 의한 관리 네트워크 제어는 네트워크 관리와 관련된 여러 가지 설정값들을 변화시키고 각 자원들에 대한 구성에 대한 관계를 정의하는 것이다. 구성 관리 기능(Configuration Management) 구성 관리는 그림 11과 같이 관리하려는 대상을 정의하고 대상들 간의 관계를 설정해서 관리자가 관리 대상의 설정을 바꾼다거나 관리 정보를 가져오는 것을 쉽게 할 수 있도록 도와주는 기능이다. 보안 관리 기능(Security Management) 보안 관리 기능은 중요한 정보를 침입자로부터 보호하기 위해 허락되지 않은 사용자들이 네트워크 자원을 사용하는 것을 막고 관리 정보에 접근하는 것을 막아 안전한 네트워크 환경을 제공하기 위한 것이다. 보안 관리를 위해서는 먼 저 표 2와 같은 사항을 고려해야 한다. 보안 관리를 위한 기능은 다음과 같다. ·데이터를 암호화하는 기능 ·암호화에 필요한 키를 생성하고 분산시켜 관리하는 기능 사용자를 인증할 수 있는 기능 ·네트워크 자원에 대한 접근 권한을 제어하는 기능 ·보안정보와 감사정보(Audit Records or Security Logs)를 모아 저장하고 점 검하는 기능 -- 객체의 자리를 구분짓는 색인 internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } -- 객체가 가질 수 있는 type의 종류 IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value, IMPLICIT OCTET STRING -- “double-wrapped” 네트워크 관리 정보의 정의방법과 표현 방법 앞서 설명한 많은 종류의 네트워크 관리를 효과적으로 수행하고 서로 다른 NMS 간에 정보를 공유하기 위해서는 먼저 관리 정보의 정의와 표현 방법에 대한 표준안이 있어야 한다. 이를 위해서 NMS는 관리 정보를 정의하기 위해 공통의 구조를 가지며, 이 구조를 통해 다양한 객체를 정의한다. 정의된 객체들 은 모든 NMS가 이해할 수 있는 추상적인 언어를 통해 표현된다. 실제 NMS 시스템에서는 다음 그림 13과 같은 구조로 구현된다. SMI(Structure Management Information) 관리 대상이 되는 객체를 정의하기 위한 스키마로 객체가 가질 수 있는 다양한 형태(Type)와 서로 다른 객체들을 구분 짓기 위한 색인(Index)으로 MIB의 뼈 대를 이룬다. SNMP에서 사용하는 SMI의 예(RFC1155)는 다음과 같다. MIB(Management Information Base) NMS가 관리하는 객체를 정의하고 객체의 특성을 기술해서 모아놓은 데이터베 이스로서, 관리하는 객체는 SMI의 기초 아래 정의된다(그림 14). MIB는 개념 적으로 트리(Tree) 구조로 이루어져 있으며 관리되는 알맹이 객체들은 Leaf Node라고 한다. 실제 Leaf Node들이 구현될 때는 객체의 수에 따라 하나 혹은 여러 개의 인스턴스(Instance)로 만들어진다. 참고로 예를 하나 들면 NIC(Network Interface Card)는 한 시스템에 여러 개 존재할 수 있다. 여기서 객체는 NIC이 되며 인스턴스화 되면 NIC[0], NIC[1] 등이 된다. ASN(Abstract Syntax Notation) 시스템에 따라 사용하는 바이트 순서가 다르고 표현하는 방법도 다르기 때문에 하나의 시스템에 의존적인 언어나 기계어로 SMI와 MIB를 표현하면 다른 시스 템에서는 사용할 수 없는 문제가 발생한다. 이런 문제를 해결하기 위한 객체의 표현 방식이 ASN이다. ASN은 인코딩 규칙에 상관없이 데이터를 표현하기 위해, 일반적인 데이터 구 조를 가진 단순한 형태의 문법으로 이루어진 언어다. ASN을 이용하여 응용프 로그램 계층 간에 정보를 교환하여 사용자가 그 내용을 볼 수 있게 해주고, 인 코딩 규칙에 의해 데이터를 변환하여 상대방 시스템에 전송할 수 있도록 도와 준다. 변환 규칙(Encoding Rules) ASN으로 정의된 SMI와 MIB의 내용을 상대방 시스템에 전달하기 위해서는 데이터를 상대방 시스템에 사용할 수 있는 형태로 바꾸어야 한다. 이렇게 ASN 으로 정의한 객체들을 다른 시스템으로 전송하기 위해 변환하는 규칙에 따라 이루어지며, 변환된 데이터는 Octet의 배열이 된다. 또 Octet 형태의 변환된 데 이터는 디코딩을 통해 원래의 ASN 형태로 돌아가기도 한다. 리스트 1 : 구조적 형인 SEQUENCE의 예(RFC1213) IpAddrEntry ::= SEQUENCE {--IP 주소의 엔트리를 표현 ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr INTEGER, ipAdEntReasmMaxSize INTEGER (0..65535) } 리스트 2 : APPLICATION type의 예(RFC1155) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) ASN.1 ASN.1(Abstract Syntax Notation.1)은 서로 다른 CPU나 언어 체계에 종속적 이지 않은 표준 object define 언어로, CCITT와 ISO(ISO.8824)의 표준이다. 이 는 응용 프로그램의 데이터를 추상적으로 정의하거나 응용프로그램의 구조를 정의하기 위해 사용되는 언어로서 BNF(Backus-Naur Form) 형태를 가지는 파 스칼이나 C와 비슷한 문법으로 이루어져 있다. ASN.1의 자세한 사항을 6가지 부분으로 나누어 살펴보도록 하겠다. ① ASN.1의 특징(Lexical Convention) ASN.1 구조에서는 type과 value가 다른 프로그래밍 언어와 비슷한 형태로 표 현되며 이들과 구별되는 고유한 특징은 다음과 같다. ·Layout은 크게 중요하지 않다. multiple space나 blank lines 등은 single space로 간주된다. ·주석은 두 개의 연결된 하이픈‘--’로 시작해서 다른 하이픈이 나오거나 한줄이 끝날 때까지 계속된다. ·값과 필드 이름의 Identifier나 형(type)의 이름, 모듈(module) 등은 대문자나 소문자, 숫자, 하이픈 등으로 표현할 수 있다. ·형(type)의 identifier는 항상 대문자로 시작해야 한다. ·값(value)의 identifier는 항상 소문자로 시작해야 한다. ·type에 의한 값의 할당은 다음과 같은 형태로 이루어진다. ::= ② 문자 ASN.1에서 사용 가능한 문자는 다음과 같다. (1) A to Z (2) a to z (3) 0 to 9 (4) : ; | = , { } . ( ) [ ] - ‘ “ ③ 키워드(keyword) ASN.1에서 사용되는 키워드는 표 3과 같다. ④ 데이터 형과 값의 정의 ASN.1에서 사용되는 데이터 형들은 표 4와 같은 네 개의 카테고리로 구분할 수 있다. 참고로 구조적 형인 SEQUEN CE의 예(RFC1213)와 APPLICATION type의 예(RFC 1155)를 살펴보기 바란다(리스트 1, 2). ⑤ 모듈(module)의 정의 ASN.1 문법으로 정의하는 객체는 모듈(module)이라고 하며, 모듈의 기본 형태 는 다음과 같다. ‘module reference’에 모듈의 이름을 정하고 ‘DEFINITI ON’키워드를 사 용해 모듈을 정의함을 알린다. 모듈은 ‘BEGIN’ 키워드로 시작해서 ‘EN D’ 키워드로 끝나며, 다른 모듈을 가지고 오는 경우에는 ‘IMPORTS’ 키워 드로 이를 선언하고 ‘FROM’ 키워드를 사용해서 다른 모듈의 내용을 가지 고 온다. ‘Assignment list’에서는 할당 연산자인 ‘::=’를 사용하여 형이나 값을 할당한다. 마지막으로 ‘END’ 키워드를 사용해서 모듈 정의를 마친다. ⑥ ASN.1의 매크로(MACRO) 정의 매크로는 새로운 형이나 값을 정의하여 ASN.1의 문법을 확장시킨다. 매크로 안에는 새로운 형과 값이 동시에 들어갈 수 있다. 매크로의 구분은 표 5와 같 다. 그리고 매크로의 정의 형식은 다음과 같다. 마치며 이번 호에는 NMS에 대한 전반적인 내용과 실제 표현 문법인 ASN.1에 대해 살펴보았다. 다음 호에는 인터넷 관리체제 표준인 SNMP에 대해 구체적으로 알아보고 각 운영체계 별로 구현되어 쉽게 접할 수 있는 네트워크 관리 프로그 램들에 대해 알아보겠다. DEFINITIONS ::= BEGIN EXPORTS IMPORTS FROM Assignment list (type assignment, value assignment) ::= END MACRO ::= --은 전부 대문자로 쓴다. BEGIN TYPE NOTATION ::= --새로운 형을 정의한다. VALUE NOTATION ::= --형의 값을 정의한다. --새로운 형을 추가하는 문법 규칙을 제시한다. END 제 목:[9909]네트워크 정복의 첫걸음(2) | 인터넷 표준 관리체제, SNMP [243] 1999-09-07 14:10 네트워크 정복의 첫 걸음!(2) 인터넷 표준 관리체제, SNMP 인터넷의 효시인 ARPANET은 1969년 미국 국방부에서 원격 호스트간의 데이 터 통신을 위해 만들어졌다. 그리고 여기에 각국 대학의 컴퓨터들이 연결되고 TCP/IP가 ARPANET의 표준 프로토콜로 채택되면서 급속히 발전하였다. 현재 인터넷은 약 4천만대의 컴퓨터가 인터넷에 연결되어 있을 정도로 규모가 커졌 으며, 일반인에게도 중요한 생활요소로 자리잡았다. 이처럼 규모가 커짐에 따 라, 인터넷을 효과적으로 관리하기 위한 체제의 필요성이 대두되었다. 이같은 필요성을 만족시키기 위한 대안으로 등장한 것이 SNMP이다. 노정민 한국항공대학교 항공통신정보공학과 대학 hmask@esc.cl.hangkong.ac.kr 인터넷의 관리체제는 IETF(Internet Engineering Task Force)에 의해 이루어 지고 있다. 여기서는 네트워크 관리를 위한 관리 구조, 관리 정보의 구조, 관리 프로토콜 등에 대한 표준화 작업을 한다. 현재 널리 사용되고 있는 SNMP도 IETF에 의해서 제정된 인터넷 관리 프로토콜이다. SNMP에 의한 인터넷 관리체제의 발전 SNMP는 1988년 초안(draft)으로 상정되어 1990년 인터넷 관리 프로토콜의 표 준으로 제정되었다. 그 후 대부분의 워크스테이션과 브리지, 라우터, 스위치, 허브 등의 네트워크 장비에 SNMP 에이전트가 장착되었고, 시스템과 여러 응용 프로그램에도 이들 을 SNMP 상에서 관리할 수 있도록 하는 MIB들이 정의되었다. 현재의 SNMP는 SNMPv2 등을 거쳐 SNMPv3로 기능이 확장되고 있으며, 관 리 영역도 RMON(Remote MONi toring) MIB 등을 통해 확장되고 있는 추세 이다. 인터넷 관리체제의 기원 ● ICMP(Internet Control Message Protocol) 1970년대 말부터 사용된 프로토콜로 네트워크 상에서의 여러 가지 문제점들 에 대한 피드백(feed-back)을 제공하기 위해 사용되었다. 라우터나 호스트들 사이에 제어 메시지(echo/echo-reply)를 전달한다. 현재 ping, traceroute 등을 통해 널리 사용되고 있다. ● SGMP(Simple Gateway Monitoring Protocol) 게이트웨이를 모니터링하기 위해 사용되었던 프로토콜로 1987년 채택되었다. ● HEMS(High-Level Entity Management System) 호스트를 모니터링 하는데 사용했던 HMP(Host Monitoring Protocol)를 네트 워크 관리에 맞게 발 전시킨 프로토콜이다. ● SNMP(Simple Network Management Protocol) SGMP를 발전시킨 모델로 주로 TCP/IP 네트워크를 관리하는데 사용되는 단 순한 형태의 프로토콜이다. 처음엔 가장 광범위한 네트워크 관리체제인 OSI 관 리체제(CMOT)로 가기 위한 중간 단계의 과도기적 운영 방안으로 제안되었지 만, 현재 가장 널리 사용되고 있다. ● CMOT(CMIP over TCP/IP) OSI 관리체제인 CMIP를 TCP/IP 위에서 동작하도록 만든 것. SNMP를 대 체할 목적으로 제안되었지만, 너무 복잡한 구조로 인해 현재는 SNMP에 밀려 사양길에 접어들었다. SNMP 관리체제의 구조 SNMP에 의한 관리 구조는 그림 1과 같이 에이전트와 매니저로 되어 있다. 여기서 MIB(Management Information Base)란 네트워크 요소들이 유지하는 정보를 말하는 것으로 에이전트들은 네트워크 노드에서 그 노드에 대한 정보를 유지하고 있다. 매니저는 전체 네트워크에 대한 MIB 명세서를 가지고 각각의 에이전트가 관리하는 MIB를 수집해서 관리한다. SNMP 관리 프로토콜의 구조 SNMP는 TCP/IP 스택 중에 응용프로그램 계층(Application Layer)에 해당되 는 프로토콜로 전송 계층에서는 UDP를 사용하며 161, 162 두 개의 포트를 통 해 메시지를 주고받는다(그림 2). SNMP 메시지 종류 에이전트와 매니저 사이에 전달되는 정보의 완성된 형태를 메시지라고 한다. 매니저가 에이전트에 질의를 하면 에이전트는 그림 3과 같이 이에 대한 응답을 되돌리는 형식으로 정보를 주고받는데, 이를 위해 총 다섯 개의 메시지 종류를 정의하고 있다(표 2). SNMP MIB SNMP에서 사용되는 MIB들은 계층별로 전송속도, 오류율, 송수신 프레임 수, IP 주소 등의 관리대상 항목들을 유지하고 있다. 리스트 1 : RFC1155-SMI DEFINITIONS --------------------------------------------------------------- RFC1155-SMI DEFINITIONS ::= BEGIN EXPORTS -- EVERYTHING internet, directory, mgmt, experimental, private, enterprises, OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax, ApplicationSyntax, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks, Opaque; -- the path to the root internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } --------------------------------------------------------------- SMI(RFC1155) SMI는 SNMP MIB들을 정의하기 위한 일반적인 구조이다. MIB 객체들은 ASN.1 문법에 따라 정의되는데 각각의 객체들은 각각 이름과 표기 문법, 다른 시스템으로의 전송을 위한 인코딩 규칙 등을 가지고 있다(리스트 1). 이들은 서로 고유한 객체 식별자에 의해 구분된다. SNMP MIB에서 사용되는 객체들은 RFC1155에 ISO의 표준안에 따라 정의되어 있다. 참고로 리스트 1에 서 EXPO RT는 SMI에서 정의한 디렉토리와 여러 가지 데이터형(type)을 다른 SNMP MIB에서 가져다 사용할 수 있도록 개방시켜주는 역할을 한다. 다른 MIB에서는 SMI에서 EXPORTS로 열린 데이터형을 IMPORTS 구문을 통해 가져와 사용할 수 있다. OBJECT IDENTIFIER O-ID(OBJECT IDENTIFIER)는 MIB 내에서 관리 객체를 유일하게 지정하는 식별자로 객체가 구성하는 트리(tree)에 따라 할당되는 일종의 디렉토리다. O-ID는 계층 구조이므로 항상 자신의 이름과 번호를 가지고 있으며 자신의 부 모를 가지고 있다. O-ID는 가장 상위 계층부터 dotted decimal(.)을 사용해 표 현하는데 다음의 예와 같이 숫자나 이름을 모두 사용할 수 있다. mgmt의 경우 mgmt : iso.org.dod.internet.mgmt mgmt : 1.3.6.1.2 RFC1155에서 정의한 O-ID를 살펴보면 최상위인 root에 iso가 있으며, 그 하위 로 org(Organization)와 dod(Depart ment of Defense) 밑에 internet을 정의하 고 있다. intern et 하위의 노드들은 표 3과 같다. 리스트 2 : 데이터형 --------------------------------------------------------------- ApplicationSyntax ::= CHOICE { address NetworkAddress, counter Counter, gauge Gauge, ticks TimeTicks, arbitrary Opaque -- other application-wide types, as they are -- defined, will be added here } -- application-wide types NetworkAddress ::= CHOICE { internet IpAddress } IpAddress ::= [APPLICATION 0] -- in network-byte order IMPLICIT OCTET STRING (SIZE (4)) Counter ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) Gauge ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) Opaque ::= [APPLICATION 4] -- arbitrary ASN.1 value, IMPLICIT OCTET STRING -- "double-wrapped" --------------------------------------------------------------- 데이터형(type) RFC1155에서는 O-ID와 함께 MIB의 객체를 정의하기 위한 여러 가지 데이터 형들을 정의하고 있다(리스트 2). 여러 형태들은 CHOICE를 통해 한가지로 사 용된다. 데이터형의 종류는 표 4와 같다. Concise MIB(RFC1212) SMI마다 구조가 다른 가장 큰 이유는 MACRO형의 구조가 각각 다르기 때문 이다. 보통 데이터형과 값을 묶어서 MACRO형을 만들기 때문에 SNMP에서 관리하는 실제 객체의 구조는 대부분 MACRO형으로 정의한다. RFC-1212에서 는 SNMP에서 사용하는 객체의 구조인 ‘OBJECT-TYPE’에 관해 정의하고 있다(리스트 3). OBJECT-TYPE은 MIB에서 관리하는 객체의 구조로 크게 문 법(SYNTAX), 사용권한(ACCESS), 상태(STATUS), 값(VALUE) 등으로 이루 어진다(표 5). STATUS에 따른 옵션 사항은 표 6과 같다. 리스트 3 : OBJECT-TYPE --------------------------------------------------------------- IMPORTS ObjectName FROM RFC1155-SMI DisplayString FROM RFC1158-MIB; OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= -- must conform to RFC1155’s ObjectSyntax "SYNTAX" type(ObjectSyntax) "ACCESS" Access "STATUS" Status DescrPart ReferPart IndexPart DefValPart VALUE NOTATION ::= value (VALUE ObjectName) Access ::= "read-only" | "read- write" | "write-only" | "not- accessible" Status ::= "mandatory" | "optional" | "obsolete" | "deprecated" DescrPart ::= "DESCRIPTION" value (description DisplayString) | empty ReferPart ::= "REFERENCE" value (reference Display String) | empty IndexPart ::= "INDEX" "{" IndexTypes "}" | empty IndexTypes ::= IndexType | IndexTypes "," IndexType IndexType ::= value (indexobject ObjectName) | type (indextype) -- if indexobject, use the SYNTAX -- value of the correspondent -- OBJECT-TYPE invocation -- otherwise use named SMI type -- must conform to Index Syntax below DefValPart ::= "DEFVAL" "{" value (defvalue ObjectSyntax) "}" | empty END --------------------------------------------------------------- MIB-II(RFC1213) MIB-II는 SNMP 프로토콜이 만들어진 이후 첫 번째로 나온 MIB로 TCP/IP 프로토콜 상에서 관리되어야 하는 객체들에 관해 정의하고 있다. 현재는 여러 가지 MIB들이 나와있지만, 보통 네트워크 장비들이 SNMP를 지원한다고 써있 으면 대부분 이 MIB-II에 정의된 객체를 관리한다고 봐도 무방할 정도로 가장 대중적으로 사용되는 MIB이다. MIB의 기본 구조는 리스트 4와 같다. 리스트 4 에서는 먼저 IMPORTS 구문을 통해 RFC1155에 정의된 mgmt O-ID와 여러 가지 데이터형을 가져오고 RFC-1212에서 OBJECT-TYPE 매크로를 가져온다. 새롭게 OCTET STRING형을 기초로 DisplayString과 PhysAddress형이 추가 되었으며 ‘mib-2’O-ID가 mgmt 밑에 정의되었다(리스트 5). MIB-II에서 정의된 모든 객체는 mib-2 밑에 위치하는데 전부 10개의 그룹이 정의되어 있다. 각 그룹이 하는 역할은 표 7과 같다. 각 그룹들은 다시 그룹 특 성에 맞는 객체로 나뉘어진다. 각각의 객체는 RFC-1212에 정의되어 있는 ‘OBJECT-TYPE’형으로 구성되며, 에이전트에 의해 인스턴스화되면 실제 값을 가지게 된다. 이를 가리켜 ‘leaf no de’로 부르기도 한다. 여러 가지 그룹 중에서 system 그룹에 대해서 살펴보면, 이는 관리하는 시스템 의 일반적인 정보를 제공하는 그룹으로서, system 그룹에서 관리하는 정보는 다음 그림 5와 같이 일곱 개의 객체에 나뉘어져 있다. system 그룹의 객체들이 하는 역할은 표 8과 같다. system 그룹에 속한 객체중 하나인 ‘sysDescr’객체에 관해 MIB-II 에서 정 의한 예를 살펴보면 리스트 6과 같다. ‘sysDescr’이 에이전트에 의해 인스턴 스화되었을 때 가지는 값의 예를 살펴보자. SNMP MIB 브라우저를 사용하여 system 그룹의 ‘sys Descr’을 선택하면 우측 상단의 객체설명 창에 ‘sysDescr’에 대한 정의 내용을 볼 수 있고, SNMP 에이전트의 IP 주소를 질의를 보내면 실제 되돌아오는 값을 우측 하단 창을 통해 확인할 수 있다(그림 6). 리스트 4 : MIB 기본 구조 --------------------------------------------------------------- RFC1213-MIB DEFINITIONS ::= BEGIN IMPORTS mgmt, NetworkAddress, IpAddress, Counter, Gauge,TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- MIB-II (same prefix as MIB-I) -- textual conventions DisplayString ::= OCTET STRING -- This data type is used to model textual information taken from the NVT ASCII -- character set. PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. -- For example, an ethernet address would be represented as a string of 6 octets. --------------------------------------------------------------- 리스트 5 : mib-2 O-ID --------------------------------------------------------------- system OBJECT IDENTIFIER ::= { mib-2 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at OBJECT IDENTIFIER ::= { mib-2 3 } ip OBJECT IDENTIFIER :: = { mib-2 4 } icmp OBJECT IDENTIFIER ::= { mib-2 5 } tcp OBJECT IDENTIFIER ::= { mib-2 6 } udp OBJECT IDENTIFIER ::= { mib-2 7 } egp OBJECT IDENTIFIER ::= { mib-2 8 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp OBJECT IDENTIFIER ::= { mib-2 11 } --------------------------------------------------------------- SNMP 메시지 형식 SNMP 메시지 형식은 인코딩 되어 네트워크를 통해 전송될 때의 패킷 형태이 다. 메시지 전체의 구조(RFC1157) SNMP 메시지의 전체적인 구조는 리스트 7과 같이 RFC1157에 정의되어 있다. 메시지는 version, community, data의 세 가지 요소를 SEQUENCE로 묶은 형 태를 취하고 있다. 여기서 version은 SNMP의 버전을 의미하며, community는 매니저와 에이전트간의 메시지 인증 방법을, data는 실제 알맹이 데이터를 의 미한다. SNMP의 보안 방법 여러 가지 정보를 안전하게 관리하기 위해서는 컴퓨터 시스템과 네트워크에 보안이 보장되어야 한다. SNMP는 인증과 접근 방침을 정하는 낮은 단계의 보 안을 제공한다(이 부분은 SNMPv3에서 크게 향상되었다). ● community 인증, 접근 방침, proxy의 특성을 정의하는 하나의 에이전트와 여러 매니저 사 이의 관계이며 각 에이전트를 기준으로 정의된다. 한 에이전트는 여러 community를 가질 수 있으나 각각의 이름은 그 에이전트 내에서 유일하며 다 른 에이전트가 같은 이름의 community를 가질 수는 있다. 또한 community의 이름은 패스워드의 역할을 하므로 매니저로부터의 모든 메시지는 이 이름을 포 함해야 한다. 그림 7은 에이전트가 GET과 SET 동작에 대해 서로 다른 community를 가지고 있는 예이다. 관례적으로 모두에게 공개하는 MIB 객체 나, 동작에 대해서는‘public’community를 사용하고, SET과 같은 쓰기 동작 이나 private한 MIB에 대해서 비밀의 comunity를 적용하는 것이 일반적이다. ● access policy 각각의 community마다 MIB에 대한 각각 다른 형태의 권한으로 접근을 제어 한다. 이러한 접근 제어의 방법은 SNMP MIB에 의한 관점(관리 객체들의 집 합으로 각 community마다 다른 SNMP MIB 관점을 가질 수 있음)에 의한 방 법과 SNMP 접근 모드(각 community에 대한 접근 모드로 READ-ONLY나 READ-WRITE 중 한 값을 취할 수 있음)에 의한 방법으로 나뉠 수 있으며 이 둘에 대한 비교는 표 9와 같다. ● proxy 서비스 proxy는 SNMP나 TCP/IP를 지원하지 않는 관리 대상을 위한 에이전트를 말 하는 것으로 proxy는 자신이 대신하는 관리 대상에 대한 SNMP 접근 방침이 나 인증 서비스를 제공하기도 한다. PDU(Protocol Data Unit)의 구성 SNMP 메시지의 알맹이라 할 수 있는 PDU는 리스트 8과 같이 CHOICE를 사 용하여 다섯 개의 메시지 종류 중에 하나를 선택하도록 되어 있다. 하나의 PDU는 리스트 9와 같이 객체의 O-ID와 value를 SEQUENCE로 묶은 형태로 되어 있다. 이를 하나로 묶어서 전체의 SNMP 메시지를 살펴보면 그림 8과 같 다. 참고로 PDU의 필드 내용은 표 10과 같다. 프로토콜 분석기를 사용하여 실 제 SNMP 패킷을 잡아보면 그림 9와 같다(IP 주소 203.253.145.59의 매니저에 서 203.253.145.5의 에이전트로 request와 response를 받은 경우). 여기서 variable-binding을 자세히 살펴보면 이 메시지의 O-ID는 1.3.6.1.2.1.1 임을 알 수 있다. 이는 sysDescr의 O-ID이며 request이기 때문에 value 영역엔 NULL 이 삽입되었다. 리스트 6 : sysDescr --------------------------------------------------------------- sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system’s hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." ::= { system 1 } --------------------------------------------------------------- Trap 메시지 트랩은 특별한 이벤트나 사고가 발생했을 경우 에이전트가 자의적으로 판단하 여 매니저에게 알리는 메시지이다. 트랩 PDU는 enterprise, agent-addr 등 여 러 구성 요소들이 SEQUENCE로 합쳐진 형태이다. 각 항목의 내용은 표 11과 같다. 그리고 일반적인 트랩의 종류는 표 12와 같다. 실제 발생한 트랩의 예를 살펴보자. 그림 10은 ‘e-watch’내의 있는 트랩 매니저를 사용하여 IP 주소 203.253.145.68의 SNMP 에이전트에서 Specific형의 트랩 메시지를 발생시킨 경 우다. specific형은 viriable binding 부분에 특정한 O-ID가 따라옴을 알 수 있 다. 리스트 7 : SNMP 메시지 구조 --------------------------------------------------------------- RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, Network Address, IpAddress, TimeTicks FROM RFC1155-SMI; -- top-level message Message ::= SEQUENCE { version INTEGER { version-1(0) }, -- version-1 for this RFC community OCTET STRING, -- community name data -- e.g., PDUs if trivial ANY -- authentication is being used } --------------------------------------------------------------- 참고 그림 6에서 예로든 MIB 브라우저 화면은 프로토콜 분석기인 ‘e-watch’내에 포함되어 있는 SNMP MIB 브라우저를 사용한 것으로 http://ewatch.hangkong.ac.kr에서 ‘e-watch’를 다운받을 수 있다. 다른 그룹 의 내용들도 system 그룹과 같은 형식을 취하므로 직접 MIB 브라우저를 사용 하여 각각의 내용을 확인하기 바란다. 마치며 이번 호에는 SNMP의 관리 방식과, MIB, 메시지 형태, 윈도우 98에서의 응용 등을 살펴보았다. 다음 호에는 리눅스와 윈도우NT 등의 멀티유저 운영체계에 서의 SNMP 활용 방법을 살펴보겠다. 리스트 8 : PDU --------------------------------------------------------------- PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-response GetResponse-PDU, set-request SetRequest-PDU, trap Trap-PDU } --------------------------------------------------------------- 리스트 9 : PDU --------------------------------------------------------------- PDU ::= SEQUENCE { request-id INTEGER, error-status INTEGER { noError(0), tooBig(1), noSuchName(2), badValue(3), readOnly(4), genErr(5) }, error-index INTEGER, variable-bindings VarBindList } VarBind ::= SEQUENCE { name ObjectName, value ObjectSyntax } VarBindList ::= SEQUENCE OF VarBind --------------------------------------------------------------- 리스트 10 : Trap 메시지 --------------------------------------------------------------- Trap-PDU ::= IMPLICIT SEQUENCE { enterprise OBJECT IDENTIFIER, -- type of object generating -- trap, see sysObjectID in [5] agent-addr NetworkAddress, -- address of object generating trap generic-trap INTEGER { coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4), egpNeighborLoss(5), enterpriseSpecific(6) }, -- generic trap type specific-trap INTEGER, -- if generic-trap is not enterpriseSpecific time-stamp TimeTicks, -- time elapsed between the last (re)initialization of the network entity and -- the generation of the trap variable-bindings VarBindList - - "interesting" information } --------------------------------------------------------------- 윈도우 98에서 SNMP 활용 보통 에이전트와 매니저 툴은 관리하려는 장치의 특성에 맞게 제작되기 때문에 고가이며 접하기도 힘들다. 윈도우 98에는 고급화된 기능의 SNMP는 지원하지 않지만 RFC 1213 MIB-II를 지원하는 에이전트를 기본적으로 제공하므로 SNMP MIB 브라우저와 이 에이전트를 이용하면 기본적인 SN MP 모델을 구 현할 수 있다. 또한 프로토콜 분석기를 사용하여 SNMP 메시지 사례별로 패킷 을 검사해보면 더 큰 SNMP 모델의 구현도 쉽게 할 수 있을 것이다. 윈도우 98의 SNMP 에이전트를 사용하는 방법은 다음과 같다. ① 제어판의 네트워크 항목에서 ‘서비스 추가’를 선택하고 윈도우98 CD를 삽입한다(그림 11). ② 서비스화면에 SNMP 서비스가 나오지 않으면 ‘디스크 있음’을 선택한다. ③ 윈도우98 정품 CD의 ‘tools\reskit\netadmin\snmp’ 디렉토리를 살펴보면 SNMP 에이전트 프로그램을 추가할 수 있다(그림 12). 제 목:[9910]네트워크 정복의 첫걸음(3) [252] 1999-10-04 11:45 네트워크 정복의 첫 걸음!(3) Linux의 SNMP 관리 도구 SNMP를 이용한 관리 프로그램은 두 가지로 분류할 수 있다. 하나는 라우터, 허브, UPS 등 네트워크와 통신 장비에 임베디드(embedded) 되어 구현되는 에 이전트(agent) 프로그램이고, 다른 하나는 각종 운영체계 아래서 개발되어 agent의 정보를 수집해 전체적인 네트워크를 관리하는 매니저(manager) 프로 그램이다. 최근 공개 운영체계로 각광받고 있는 리눅스에서 구현된 공개 SNMP 관리 프로그램들을 살펴보고, 이를 이용해 네트워크를 관리하는 방법을 알아본다. 노정민 한국항공대학교 통신정보공학과 대학원 hmask@esc.cl.hangkong.ac.kr 연재 순서 99/08 NMS의 개념 99/09 인터넷 표준 관리체제, SNMP 99/10 Linux의 SNMP 관리 도구 리눅스는 유닉스의 네트워크 기능을 대부분 사용할 수 있다. 소스가 공개된 네 트워크 프로그램을 쉽게 구할 수 있기 때문에 네트워크를 공부하려는 독자들에 겐 꼭 필요한 준비물이다. SNMP 관리 프로그램 또한 소스가 공개된 경우가 많아 리눅스를 비롯한 여러 운영체계에서 쉽게 사용할 수 있다. 대표적인 것은 CMU(Carnegie Mellon University) SNMP 프로그램으로 대부분의 네트워크 장비에 포함되는 SNMP 모듈들이 사용하고 있을 정도로 SNMP 에이전트의 표본이다. CMU-SNMP의 소개 CMU-SNMP는 카네기 멜론 대학에서 개발한 SNMP 관리 프로그램이다. CMU-SNMP는 SNMP 에이전트와 몇 가지 SNMP 응용 프로그램들을 포함하 고 있으며, SNMPv1과 SNMPv2를 지원한다(SNMPv2의 보안 문제해결을 위해 초기 버전인 SNMPv2party 모델은 지원하지 않고 SNMPv2usec 모델을 지원 한다). 현재 가장 최신 버전은 3.6이며 리눅스 안정커널 v2.0.35, 실험커널 v2.1.125와 libc v5.4.38이상에서 동작한다. 하지만 버전 3.4 이상은 큰 차이가 없으므로 낮 은 버전을 사용해도 상관없다. CMU SNMP에서 지원하는 MIB는 다음과 같다. - MIB-2(RFC 1213) - Identification MIB(RFC 1414) - Host Resources MIB(RFC 1514) - TUBS Linux MIB(리눅스 사양에 맞는 실험적인 MIB) 설치 CMU-SNMP는 다음의 site에서 구할 수 있다. Main ftp site ftp://ftp.ibr.cs.tu-bs.de/pub/local/linux-cmu-snmp/ Mirror ftp://sunsite.unc.edu/pub/Linux/system/network/admin(국외) ftp://ftp.kreonet.re.kr/pub/Linux/sunsite/system/network/admin(국내) 배포판은 소스 버전과 바이너리 버전의 두 가지 종류가 있으며, 3.4 버전을 기 준으로 설명하고자 한다. 각각의 파일이름은 다음과 같다. - cmu-snmp-linux-3.4-src.tar.gz(소스 버전) - cmu-snmp-linux-3.4-bin.tar.gz(바이너리 버전) 설치 방법 설치하는 방법은 바이너리 버전을 설치하는 방법과 소스를 컴파일해서 설치하 는 방법 등 두 가지가 있다. (1) 바이너리 설치 바이너리 배포판을 설치하기 위해서는 먼저 리눅스 시스템이 ELF를 지원해야 한다(ELF libc, ELF kernel). 그리고 기존의 snmpd 데몬이나 snmplib를 사용 하고 있으면 삭제한 다음에 설치해야 한다. 설치 과정은 다음과 같다. - root로 login - cd /(root 디렉토리로 이동한다.) - tar xvzf .../cmu-snmp-linux-3.4-bin.tar.gz (배포판을 푼다.) - cd /tmp/cmu-snmp-linux/etc - ./installconf -mini (agent의 패스워드를 설정한다.) - /etc/rc.local 파일에 다음과 같이 ‘snmpd’ 데몬을 추가한다. - /usr/sbin/snmpd -f ; echo ‘snmpd’ (2) 소스 설치 - root로 login - tar xvzf .../cmu-snmp-linux-3.4-src.tar.gz (적당한 디렉토리에 소스를 푼다.) - cd cmu-snmp-linux-3.4 - ./configure - make(컴파일 한다.) - make install - cd ./etc - ./installconf -mini (agent의 패스워드를 설정한다.) - /etc/rc.local 파일에 다음과 같이 ‘snmpd’ 데몬을 추가한다. /usr/sbin/snmpd -f ; echo ‘snmpd’ 설치를 끝났으면 재 부팅한 다음 snmpwalk 프로그램을 사용하여 테스트 해보 자. 그림 1은 snmpwalk를 사용하여 시스템 테이블을 살펴본 것으로 현재 설정 되어 있는 시스템 내용을 확인할 수 있다. 응용 프로그램들 (1) snmpd CMU의 SNMP 에이전트로서 SNMPv1과 SNMP 2usec의 질의에 대한 응답을 해준다. 환경 설정은 snmpd.conf 파일에 의해서 이루어지며 관리자는 system .sysName, system.sysLocation과 system.sys Contact 등의 내용을 설정해 줄 수 있다. SNMPv1 질의에 대한 community 이름은 기본적으로 모두 ‘public’이며, host 테이블의 SNMPv2usec 형태의 질의는 보안 내용에 따라 다른 community를 사용한다. 옵션은 다음과 같다. - d : SNMP 패킷 내용을 덤프해서 보여준다. - f : 실행한 다음 백그라운드에서 동작하게 한다. - c : 실행에 필요한 설정 파일을 불러들인다. - a : 실행에 필요한 agent 설정 파일을 불러들인다. (2) snmpd.conf snmpd를 위한 설정파일이다. 파일의 내용은 view와 user, community 설정에 관한 부분과 포트, 인터페이스 설정에 관한 부분의 두 가지로 나뉜다. 전자의 설정은 보안을 위해서 접근 권한을 다음과 같이 세 가지로 구분된다. switch security posture - mini internet subtree에 대해서만 read-only 권한으로만 접근할 수 있다. - semi system subtree와 agent 통계에 대해서만 read-only 권한으 로 접근할 수 있다. - very agent 통계에 대해서만 read-only 권한으로 접근할 수 있다. 처음 설치(installconf)할 때 이 스위치에 따라서 패스워드를 정해 줄 수 있다. 그 외 다른 설정에 대한 키와 파라미터는 다음과 같다. 이를 바탕으로 설정한 snmpd.conf 파일의 예는 다음과 같다. 이를 바탕으로 설정한 snmpd.conf 파일의 예는 다음과 같다. (3) snmpget SNMP 에이전트에게 Get Request를 해서 Response를 받아오는 프로그램이다. 사용법 : snmpget host community variable COMMUNITY Argument snmpget 프로그램은 SNMPv1/SNMPv2c/SNMPv2u sec을 전부 지원하기 때문 에, 이들을 argument를 통해서 구분한다. - community 문자열의 첫 자가 “+”로 시작되면 SNMPv2c (cmomunity-based SNMPv2)로 인식한다. - community 문자열의 첫 자가 “-”로 시작되면 SNMPv2u(User-based - security model)로 인식한다. - 그 외 다른 community 문자열은 전부 SNMPv1로 인식한다. SNMPv2u의 전체적인 community문자열은 다음과 같다. /userName/[authenticationKey]/[privacyKey]/[contextSelector] 여기서 키 값은 문자열과 hex 코드를 사용할 수 있으며, hex 코드를 사용할 때 는 반드시 맨 앞에 ‘0x’를 추가해야 한다. 사용 예는 다음과 같다. /joy : QoS = noAuth/noPriv, userName = "joe" /boneless/chicken/ranch : QoS = auth/priv, userName ="boneless", authKey ="chicken", privKey ="ranch" /maplesyrup/sugarbush// : QoS = auth/noPriv, context ="other", userName ="maplesyrup" authKey ="sugarbush" /glenn/0x4ca25023b00a6689ef21cb1b6fa9cb0e : QoS = auth/noPriv, context="", userName ="glenn" authKey ="0x4ca25023b00a6689ef21cb1b6fa9cb0e" +public : SNMPv2c public : SNMPv1 (4) snmpgetnext SNMP 에이전트에게 Get Next Request를 사용하여 여러 개의 Response를 되 돌려 받는다. 사용법 : snmpgetnext host community variable-name [variable-name] . . . (5) snmptrap SNMP 트랩 메시지를 지정한 호스트에 전송한다. 사용법 : snmptrap host community trap-type specific-type device-description device description 트랩 메시지에 전달할 장치에 관한 설명으로 system. sysDescr.0에 저장되는 변수 값이다. # snmptrap nic.andrew.cmu.edu public 0 0 ‘SUN 3/60: SUNOS 4.0’ # (nic.andrew.cmu.edu의 시스템에 coldStart 트랩을 전송한다) (6) snmptrapd 외부에서 전달된 SNMP 트랩 메시지를 162번 포트를 통해서 받는다. 옵션은 다음과 같다. - p : 메시지를 화면에 출력한다. - s : syslog를 사용하여 메시지를 저장한다. 이런 syslog 메시지는 LOG_WARNING 레벨로 전달된다. - v 1 : SNMPv1 트랩 메시지를 받는다. - d : 패킷을 덤프하여 출력한다. snmptrapd를 동작시키고 snmptrap을 사용하여 localhost로 트랩 메시지를 전송 한 예. snmpd.conf의 예 # snmpd.conf - created Mon Aug 30 16:26:04 KST 1999 # view configuration # viewName OID included/excluded # internet view all .1.3.6.1 included # internet view mini .1.3.6.1 included # for v1 public exclude exclude mib-2.ident.identInfo # and mib-2.host.hrSWRun in the mini view: view xmini .1.3.6.1 included view xmini .1.3.6.1.2.1.24.1 excluded view xmini .1.3.6.1.2.1.25.4 excluded # system, snmp, usecAgent, usecStats view semi .1.3.6.1.2.1.1 included view semi .1.3.6.1.2.1.11 included view semi .1.3.6.1.6.3.6.1.1 included view semi .1.3.6.1.6.3.6.1.2 included # . . . 중략 # community configuration # commName readV writeV community public xmini - ## uncomment for private entry: # community private mini mini ## port to use (default is 161): # port: 161 ## the entry of system.Contact and system.Location: sysContact: Not Configured sysLocation: Not Configured ## the system name is per default determined from the hostname: # sysName: chappell ## trap sink address and community string. (passed to snmptrap(1)utility). ## authentraps contains the value of snmpEnableAuthenTraps; (default is `disabled’). trap sink: localhost trap community: public snmpEnableAuthenTraps: disabled ## specify type and speed of interfaces: if the last char is an asterisk, any suffix will match. interface: lo0 24 20000000 interface: eth* 6 10000000 interface: sl* 28 28800 interface: ppp* 23 28800 SNMP 라이브러리 활용 CMU SNMP는 소스를 공개하기 때문에 에이전트뿐만 아니라, 공개된 라이브 러리를 사용하여 다양한 SNMP 관련 프로그램을 제작할 수 있다. SNMP 라이 브러리는 snmplib 디렉토리 밑에 있으며, 보통 이 라이브러리만 따로 배포하기 도 한다. 파일들은 다음과 같다. (1) asn1.c ASN.1의 문법에 맞게 정의된 데이터들을 네트워크를 통해 전송하기 위해 BER(Basic Encoding Rules)에 맞게 인코딩하는 부분이다. BER의 정확한 규격 은 ISO8825에 나와 있다. SMI에 대한 태그는 다음과 같고 소스를 살펴보면 각 SMI에 대한 인코딩 함수가 기술되어 있어서 필요한 함수를 불러 사용하면 된 다. (2) parse.c SNMP 관련 프로그램을 개발할 때 가장 까다로운 부분중의 하나가 ASN.1 문 법으로 쓰여진 MIB를 해석하는 컴파일러(엄밀히 말하면 parser)의 제작이다. 물론 C언어나 파스칼 같은 고급언어에 비하면 구문이 단조로운 편이어서 parsing에 대한 개념이 잘 잡혀있다면 비교적 쉽게 제작할 수 있지만 효과적인 parser를 제작하기 위해서는 많은 노하우가 필요하다. CMU SNMP에서는 이런 어려움을 parse.c 파일을 통해 쉽게 해결해 준다. parse.c파일안의 parse() 함수 는 다음 그림과 같은 과정으로 MIB 파일을 컴파일 한다. 먼저 MIB에서 사용되는 예약어와 SMI의 내용을 가지고 심볼 테이블을 만들어 초기화를 한다. 다음 컴파일할 MIB 모듈을 입력받으면 각각의 구문을 토큰으로 만들어 테이블 과 비교한 후, 문법에 따른 트리를 만들면 된다. parse.c 파일에서는 테스트 모 드를 지원하기 때문에 이를 사용하여 여러 가지 MIB 파일을 컴파일 해볼 수 있다. 테스트 모드를 사용하기 위해서는 #define 구문을 사용하여 TEST를 선 언하고 parse.c 파일만 따로 컴파일 하면 된다. 변경한 parse.c 파일은 다음과 같다. 이렇게 파일을 변경하고 parse.c 파일을 다음과 같이 컴파일 하자. # gcc -o parse parse.c 컴파일 후 mib.txt를 복사해와서 parse를 실행하면 다음과 같이 mib.txt가 컴파 일 되는 과정을 확인할 수 있다. MRTG MRTG는 SNMP 에이전트가 탑재된 장치의 트래픽을 모니터링하는 툴이다. MRTG는 장치에 주기적으로 SNMP 폴링을 하여 트래픽 정보를 그래프로 보 여주는 html 페이지를 생성한다. 그래프는 GD 라이브러리를 통해 PNG 또는 GIF 형태로 바뀌고, 이는 일정 시간마다 갱신된다. MRTG는 Perl과 C로 작성 되었으며 리눅스를 비롯한 UNIX와 윈도우NT에서 동작한다. MRTG는 SNMP 에이전트에서 받은 모든 데이터를 로그로 기록해두기 때문에 일간, 주간, 월간, 연간 트래픽과 관련된 정보를 검사해 볼 수 있다. 로그 파일은 자동으로 저장 되어 2년 동안 보존되며, 시간이 경과되어도 로그파일의 크기는 커지지 않는다. MRTG는 인터페이스의 트래픽 정보뿐만 아니라 SNMP 특정변수에 대해서도 각각의 Object Identifier를 지정해 주어 모니터링이 가능하다. 변경한 parse.c 파일 예 #include #include #include #ifdef linux #include #include #endif #include #include “parse.h” #define TEST /*TEST를 첨가한다.*/ /* A quoted string value-too long for a general “token” */ char *quoted_string_buffer; /* 중략 */ #ifdef TEST main(argc, argv) int argc; char *argv[]; { FILE *fp; struct node *nodes; struct tree *tp; fp = fopen(“mib.txt”, “r”);/*mib.txt를 컴파일 하는 경우*/ if (fp == NULL){ fprintf(stderr, “open failed\n”); return 1; } nodes = parse(fp); tp = build_tree(nodes); print_subtree(tp, 0); fclose(fp); } #endif /* TEST */ MRTG 설치 현재 MRTG의 최신 버전은 2.8.8이며 다음의 site에서 다운 받을 수 있다. http://ee-staff.ethz.ch/~oetiker/webtools/mrtg/pub/ 그래프를 실시간으로 바꿔주기 위해서는 먼저 GD 라이브러리가 필요하다. 이 는 다음 site에서 받을 수 있다. http://www.boutell.com Perl은 5.003 이상의 버전이 있어야 한다. 리눅스의 경우 대부분 기본으로 설치 되어 있지만 NT는 그렇지 않으므로 다음의 site에서 다운 받아야 한다. http://www.perl.com/perl/info/software.html 설치과정은 다음과 같다. - root로 로그인 - tar -xvzf .../ mrtg-2.8.8.tar.gz (적당한 디렉토리에 프로그램 소스를 설치한 다.) - cd mrtg-.2.8.8 - ./configure (컴파일하기 위한 설정을 수행한다.) - make (컴파일) 압축을 풀면 다음과 같은 디렉토리가 생긴다. make가 성공적으로 끝났으면 run 디렉토리에서 mrtg.cfg 파일을 만들어야 한 다. doc 디렉토리에 sample-mrtg.cfg가 있으므로 이를 참조하거나 mrtg.cfg로 복사해서 만들 수 있다. mrtg.cfg의 설정 프로그램을 시작하기 전에 설정할 사항은 다음과 같다. - WorkDir : 웹브라우저에게 보여 줄 html 파일과 log 파일이 들어갈 디렉토 리를 설정한다. httpd의 DocumentRoot의 하위 디렉토리에 만든 다음 images 디렉토리의 모든 파일을 복사한다. 가령 아파치 웹서버의 DocumentRoot가 /usr/local/etc/httpd/htdocs라면 - WorkDir: /usr/local/etc/httpd/htdocs/mrtg로 디렉토리를 설정한다. - Target : MRTG가 모니터링할 장치를 설정한다. 사용 형식은 다음과 같다. - Target : port : community@ Target 정보는 cfgmaker를 사용해서 알아낼 수 있다. cfgmaker의 사용법은 다 음과 같다. # cfgmaker @ community는 일반적으로 public을 사용하지만 다를 수도 있으므로 에러가 발 생하는 경우는 관리자에게 문의하기 바란다. cfgmaker를 실행한 예는 다음과 같다. 기타 설정에 사용되는 키와 파라미터는 다음과 같다. 부가적으로 설명하는 index를 만들고 싶다면 indexmaker를 사용하여 만들 수 있다. 기본적인 설정이 끝난 mrtg.cfg의 예를 살펴보면 다음과 같다. # Multi Router Traffic Grapher -- Example Configuration File # # * copy this file to ../run and call it mrtg.cfg # * consider using ../run/cfgmaker to build your initial mrtg.cfg file . . . 중략 # Global Configuration # Where should the logfiles, and webpages be created? WorkDir:/usr/local/etchttpd/htdocs/mrtg ## Target ---------------------------------------- # * The most basic format is “port:community@router” This will generate a traffic graph # for port ‘port’ of the router ‘router’ and it will use the community # ‘community’ for the snmp query. Target[210.119.30.147]: 2:public@210.119.30.147 MaxBytes[esc.cl.hangkong.ac.kr]: 1250000 Title[esc.cl.hangkong.ac.kr]: esc.cl.hangkong.ac.kr : eth0 PageTop[esc.cl.hangkong.ac.kr]:

Traffic Analysis for eth0 mrtg의 실행 mrtg.cfg의 설정이 끝났으면 mrtg를 실행시켜 html 페이지를 만든다. 실행 방 법은 다음과 같다. # ./mrtg mrtg.cfg 실행이 끝나면 WorkDir 밑에 다음과 같은 새로운 html 파일이 만들어진 것을 확인할 수 있다. 그래프는 5분 간격으로 생성한 ‘Daily’ 그래프와, 30분 간격 으로 생성한 ‘Weekly’ 그래프, 두 시간 간격으로 생성한 ‘Monthly’그래 프, 하루 간격으로 생성한 ‘Yearly’ 그래프, 이렇게 네 개가 만들어진다. 다 음 호에는 NMS시스템의 보안과, 인증에 관련된 알고리즘을 소개하고 활용법 을 알아보겠다. 이근형 기자 rilla@pserang.co.kr 제 목:[9911]네트워크 정복의 첫 걸음!(4) [260] 1999-11-01 16:33 인터넷은 개방적인 구조로 되어 있어서 보안에 약한 게 흠이다. 일례로 LAN 환경의 경우 LAN에 연결된 모든 사용자들이 하나의 회선(bus)을 공유하기 때 문에 promiscuous 모드에서 동작하는 analyzer 프로그램을 사용하면 e-메일 패스워드나 PC통신 ID 등 다른 사람의 통신정보를 간단히 알아낼 수 있다. 따 라서 최근의 네트워크 응용프로그램들은 자체적으로 보안구조를 갖추고 있으 며, NMS에도 다양한 보안 구조가 도입되고 있다. security service 먼저 네트워크에서 보안이 필요한 이유를 구분하여 보면 다음과 같다. · 비밀 보장(Confidentiality) : 컴퓨터 시스템의 정보와 이 정보가 전송될 때 허락받은 사용자만 접근하여 사용할 수 있도록 한다. 보통 printing, displaying 등 기존의 정보를 드러내는 모든 활동에 해당된다 · 인증(Authentication) : 메시지 원본과 이를 표현한 전자 문서가 완전히 같 다는 것을 보증하는 것 · 무결성(Integrity) : 허락 받은 사용자만 컴퓨터 시스템의 환경이나 전송되는 정보를 변경시킬 수 있게 하는 것 · 부인방지(Nonrepudiation) : 송신단이나 수신단이 전송된 메시지에 대해서 전송한 사실을 부인하지 못하게 막는 것. · 접근제어(Access Control) : 통신 회선을 통해 컴퓨터 시스템과 응용 프로 그램에의 접근을 제한하는 것 · 유효성 보장(Availability) : 허가된 사용자가 컴퓨터 시스템을 사용하기 위 해 필요한 사항 네트워크 정복의 첫 걸음!(4) NMS의 보안체계 인터넷은 개방형 구조이기 때문에 NMS를 구성할 때는 정보의 안전한 관리를 위한 보안 요소가 먼저 고려되어야 한다. 이번 호는 인터넷 보안의 기본적인 개념을 살펴보고, NMS에서 사용되는 암호화 기법과, 사용자 인증 알고리즘 등 을 살펴본다. 또 네트워크 응용프로그램에서 널리 채용되고 있는 MD5 사용자 인증 알고리즘을 직접 구현해 본다. 노정민 한국항공대학교 통신정보공학과 대학원 hmask@esc.cl.hangkong.ac.kr security attack 크래커(cracker)가 컴퓨터 시스템이나 네트워크를 공격하는 유형을 살펴보면 그림 1과 같다. · Interruption(방해하기, attack of availability) : 시스템을 파괴하거나 내용을 손상시키는 것(하드디스크 파손, 회선 절단, 기타) · Interception(가로채기, attack of confidentiality) : 허락 받지 않은 사용자가 시스템에 접근하여 정보를 얻어내는 것 · Modification(변조, attack of integrity) : 허락 받지 않은 사용자가 시스템의 내용과 전송되는 정보를 임의로 바꾸는 것 · Fabrication(위조, attack of authentication) : 허락 받지 않은 사용자가 거짓 의 정보를 꾸며서 전달하는 것 이런 공격의 유형은 활동하는 정도에 따라 passive attack과 active attack으로 나뉜다(표 1 참조). NMS security model 다양한 네트워크 공격 유형을 막기 위한 NMS의 보안 모델은 그림 3과 같다. NMS 개체들은 정보를 주고받기 위해서 기존의 메시지에 보안 파라미터를 추 가한다. 그 다음 security 변환기가 메시지를 보안 파라미터에 따라 다른 개체 는 알아볼 수 없는 형태로 메시지를 변환시킨 후 네트워크를 통해 전송하게 된 다. NMS 개체간의 보안 파라미터는 사전에 협의를 거쳐 결정되며, 이 내용은 신뢰할 수 있는 제 3자에 의해 관리된다. 메시지 암호화 NMS에서 사용되는 메시지를 네트워크로 전송할 때 다른 사용자가 알아 볼 수 없도록 암호화해서 전송한다. SNMP에서 메시지 암호화는 SNMPv1 다음 버전 인 SNMPparty 버전부터 채용되었다. SNMP에서 사용하는 암호화 방식은 키 생성 방식에 따라 대칭형 암호화 방식과 비대칭형 암호화 방식이 있다. 대칭형 암호화 방식 (symmetric encryption) 암호화 할 때 사용한 키와 암호화된 자료를 해독할 때 사용한 키가 동일한 방 식이다. 대칭형 암호화 방식은 고대 로마시대의 시저황제가 사용했을 정도로 오래 전부 터 사용되어 왔다. 암호화의 핵심인 키는 통신 상대만 알 수 있는 기호로 사전 에 정해진다. 암호화된 문서만 가지고 암호를 해독할 수 없도록 암호화 알고리 즘 자체가 강력해야 하며, 키를 비밀리에 관리하는 것이 가장 중요하다. 암호화 기법 치환 (substitution, permutation) 단순히 문자열의 순서를 뒤죽박죽 섞어주는 방법으로, 섞인 순서가 해독 방법 이 된다(그림 4 참조). 실제 암호문에서는 입력 비트보다 출력 비트가 많은 확장치환(extended permutation)과 입력된 비트 중에서 몇 개가 제외되는 선택치환(permuted choice)이 많이 사용된다(그림 5 참조). 전치 (Transposition) 주어진 문장을 직접 암호화하는 방법으로 우선 문자열을 일정한 단위 블록으로 분할한 뒤 그 순서를 바꿔 암호화한다. 이 암호화는 블록의 크기와 바꾸는 순 서로 암호의 난이도가 결정된다. 난이도를 높이기 위해 행렬을 다시 열(row)로 전치하기도 한다(그림 6 참조). 대칭형 암호화 알고리즘 DES (Data Encryption Standard) IBM에서 1974년에 개발한 대칭형 공개 암호 시스템으로 알고리즘의 공개를 원 칙으로 한다. 이로 인해 NMS의 메시지 암호화에 널리 채용되고 있다. 알고리 즘을 공개한다 해도 안정성은 키에 의존하기 때문에 키를 모르면 암호문에서 평문을 유추할 수 없다(그림 7 참조). DES 알고리즘은 자리바꿈(permutation), 치환, modulo 연산을 사용하여 64비트 로 이루어진 블록을 한꺼번에 암호화하는 방식이다. 64비트 중 최상위 8비트는 에러 방지를 위한 패리티 검사를 위해 사용되며 56비트의 키를 사용하여 암호 화한다. 암호를 풀기 위해서는 키 값을 알아내야 하며 이 키 값을 알아내기 위 해선 이론적으로 최고 256 만큼 조합해야 가능하다. IDEA(International Data Encryption Algorithm) DES 이후에 나온 대칭형 암호화 알고리즘이다. 64비트로 이루어진 블록을 한 꺼번에 암호화하는 방식은 DES와 같지만 128비트의 키를 사용하여 DES보다 안정성이 훨씬 높아졌다. NMS와 전자메일 등에서 사용되고 있다. RC2, RC5(Ron Rivest Crypto) Ron Rivest에 의해 개발된 대칭형 암호화 방식이다. 공개키 암호화 방식(public-key encryption) 키를 비밀리에 관리하기 어려운 대칭형 암호방식의 단점을 해결한 비대칭형 암 호방식의 대표적인 알고리즘이다. 공개키 방식은 메시지를 암호화하는 키와 암호화된 메시지를 해독하는 키가 쌍 으로 사용된다. 메시지를 암호화하는 키는 공개(public)하고, 메시지를 해독하는 키는 수신자가 비밀리에 관리하기 때문에 대칭형 암호방식에 비해 안전하게 키 를 관리할 수 있다. 공개키 암호의 원리 키 시드(key seed)는 공개키 암호의 가장 중요한 요소로 암호화키와 해독키 생 성의 모체가 된다. 키 시드 값을 함수 F에 입력하면 공개키가 생성되고, 함수 G에 입력하면 해독키가 생성된다. 키 시드 값에 따라서 공개하는 암호화키와 해독키는 다양하게 변화된다. 수신자는 암호화키로부터 해독키를 직접 얻어낼 수는 없지만, 암호화키와 해독키 사이의 함수 관계를 이용해서 답을 얻어낼 수 있다(그림 9 참조). DES 동작 순서와 키 생성 방법 DES 동작 순서 ① 64비트 데이터를 입력받아 초기 치환(Initial Permutation) 과정을 거쳐 좌우 32비트의 내용을 바꾼다 ② 바뀐 32비트의 내용은 각각 L. R 레지스터에 분리, 저장된다. ③ R 레지스터의 32비트는 확장전치를 거쳐 48비트로 늘어난다. ④ 확장된 48비트는 키 제너레이터에서 생성된 16가지 키의 순서에 따라 모듈 러(modula) 연산이 이루어진다. ⑤ 48비트는 6비트씩 분리되어 S-Box의 선택치환 연산에 의해 4비트씩 축소 된다. ⑥ S-Box가 8개 있으므로 최종결과는 32(4×8)비트로 출력된다. 출력 값은 다 시 치환을 거친 후에 L 레지스터와 모듈러 연산 과정을 통해 임시 레지스터에 저장된다. ⑦ 초기의 R레지스터 값을 L 레지스터에 대입한 뒤 임시 레지스터의 값을 R 레지스터로 옮긴다. ⑧ ③∼⑦ 단계의 과정을 15회 반복(전체 16회)한다. ⑨ 마지막으로 L, R 레지스터의 값을 교환 하고, 초기 치환의 역 치환을 실행하여 출력한다. 키 생성 방법 ① 초기의 키도 64비트로 구성된다. 64비트 는 8비트의 8개 그룹으로 분할되고 8비 트의 마지막 비트는 패리티비트로 사용 되어 연산에서 제외된다. 여기에서는 ‘선택전치1’이 사용된다. ② 56비트만으로 새롭게 구성된 키를 28비트의 C, D 쉬프트 레지스터에 저장 한다. ③ C, D 레지스터의 값을 각각 비트 단위로 암호화하기 위해 좌측으로 로테이 션을 수행한다. ④ 56비트의 결과를 선택전치를 수행하여 48비트로 줄인다. ⑤ 이 과정을 15회 반복(전체16회)한다. 공개키 암호화 기법 유한 계산(Finite Arithmetic) 음수와 분수를 제외한 0과 양수만을 사용하는 연산으로 나머지(modular) 연산 이 사용된다. 이 연산은 일반적으로 mod 연산으로 불리며 모듈러 m을 사용하 여 0부터 m-1까지의 정수를 얻는다. 유한 계산의 사칙연산을 살펴보면, 먼저 덧셈은 a+b를 연산한 결과가 m보다 작으면 보통 덧셈의 결과와 같지만, 결과 가 m보다 크거나 같으면 결과 값에서 m을 뺀다. 뺄셈, 곱셈 나눗셈 연산도 이 와 동일하다. 지수함수와 페르마의 정리 (Fermat’s Theory) 지수함수는 다음과 같이 표현된다. an= a * a * a * . . . . . . * a (n 회 곱셈) 지수함수와 앞에서 살펴보았던 모듈러 연산을 결합하면 유한 계산의 지수함수 가 된다. 또한 여기에 소수를 모듈러로 사용하면 곱셈에 대한 역수가 항상 존 재하게 된다. 따라서 지수 함수에 모듈러를 소수로 정의하면 결과가 1(곱셈의 항등원)이 되는 수가 한 개 이상 존재한다. 지수 함수에 대한 a와 모듈러 p(prime number)는 고정되어 있으며, n은 독립변수이다. 모듈러는 7이고 a값은 1에서 6까지 변한다. n의 값이 0일 때 an은 전부 1이고, 6(mod-1)이 되었을 때 다시 an이 전부 1이 된다. 이 경우를 일반화하면 다음 식과 같다. a(n+(p-1)) = an*ap-1=an (p = prime number) 이것을 a가 0인 경우를 제외하고 모든 a에 대해서 표현하면, 다음과 같은 페르 마의 정리(Fermat’s Theory)가 유도된다. ap = a mod p 이런 지수함수에서 an이 1인 경우와 p-1인 경우를 제외하고 나머지 수는 난수 형태로 배열된다. 따라서 모듈러로 매우 큰 수를 사용해서 배열의 randomness 를 증가시키면 an값으로부터 n을 구하기가 매우 어렵게 된다. 공개 키 암호는 이런 지수함수의 복잡한 성질을 이용한다. RSA 알고리즘 공개키 방식의 대표적인 암호화 알고리즘은 RSA(Ron Rivest, Adi Shamir, Len Adleman)다. RSA는 나머지(mod)연산과 지수연산의 복잡성에 착안해서 만들어졌으며 이를 식으로 표현하면 다음과 같다. C = Me mod n M = Cd mod n = (Me)d mod n = Med mod n 여기서 M은 평문 C의 암호문을 의미한다. e는 암호화를 위한 공개키이고 d는 해독을 위한 비밀키이다. n은 나머지 연산을 위한 모듈러(modular)로서 서로 다른 두 소수의 곱으로 표현되는 수이다. 임의의 두 소수를 p, q라고 하면 n=p ×q가 성립한다. 암호화를 위해 n은 공개된다. 메시지 해독을 위해선 p, q가 필요한데 n을 인수 분해하여 이를 찾는 것은 거의 불가능하다. 이렇게 RSA는 매우 큰 수의 인수 분해는 어렵다는 것에 근거한 암호 기법이다. 메시지 인증 (Message Authentication) ‘인증되었다’ 라는 말은 의심스러운 소스에서 전달된 메시지가 진짜인 것으 로 확인되었을 때 사용되는 말이다. 인증이란 서로 주고받은 데이터가 확실한 가에 대한 일종의 보증이다. 메시지 인증은 전송중의 에러와 크래커에 의한 데 이터 변조를 검출하는데 사용된다. NMS는 manager와 agent 사이의 주고받는 관리 메시지에 인증코드가 삽입되어 메시지의 무결성(integrity)을 보장한다(그 림 10 참조). 메시지 인증 방법 MAC(Message Authentication Code) 비밀키를 사용하여 작고 고정된 길이의 인증코드를 만드는 방식이다. 송신자와 수신자는 서로 같은 비밀키를 공유하고 있다. 송신자는 메시지를 전 송할 때마다 메시지와 키를 사용하여 메시지 인증코드(MAC)를 만들고, 이 인 증코드를 메시지 원본에 붙여서 보낸다. 수신자는 받은 메시지에서 인증코드 부분을 따로 떼어내고, 수신한 메시지 원본을 송신자와 동일한 방법을 사용하 여 인증코드를 만들어낸다. 수신한 인증코드와 만들어낸 인증코드를 비교하여 메시지의 무결성을 확인한다. Message Digest(Oneway Hash function) 다음은 단방향 해쉬함수를 사용하는 방법이다. 송신자는 해쉬함수를 사용하여 가변길이의 메시지 M을 고정된 길이의 해쉬코드 H(M)로 변환하고, 원본 메시 지에 붙여서 전송한다. 이런 방법을 메시지 다이제스트라고 한다. Simple Hash function 가변의 길이에서 메시지 다이제스트를 추출하는 가장 간단한 방법은 XOR를 사용하는 것이다. 가령 입력이 n비트 일 때의 메시지 다이제스트는 그림 11과 같다. 메시지 인증 알고리즘 ·MD5(Message Digest 5) MD5는 Ron Rivest에 의해 개발된 메시지 다이제스트 알고리즘으로, RFC1321 표준이다. MD5는 NMS와 웹 브라우저, 전자메일 등 네트워크를 사용하는 응 용프로그램의 메시지 인증에 사용된다. MD5 알고리즘은 임의의 길이의 메시지 를 입력받아 128비트의 메시지 다이제스트를 만들어내며, 이 때 입력은 512비 트(64byte) 단위로 진행된다. 전체 동작은 그림 12와 같다. ① Append Padding bits 입력받은 k비트의 메시지를 512비트 단위의 블록으로 자른다. 마지막 블록의 경우 64비트가 길이 정보에 사용되기 때문에 메시지 영역은 448바이트가 되어 야 한다. 마지막 부분의 길이는 모듈러 연산자를 사용하여 구해진다(length = 448 mod 512). 그리고 모자라는 길이만큼 패딩(padding)되어 채워진다. ② Append Length 마지막 블록의 64비트에 메시지원본(original) k의 길이를 채워 넣는다. 메시지 길이는 모듈러 연산을 사용하여 k mod 264의 길이만 저장된다. 이 단계를 지 나면 512비트 단위의 블록이 생성된다. (Y1, Y2, . . ., YL-1) ③ Initialize MD buffer 이 해쉬 함수의 결과는 128비트로 출력된다. 결과 버퍼는 네 개의 32비트 레지 스터(A, B, C, D)로 표현되는데 이것은 다음과 같이 16진수 IV(Initial Value)로 초기화된다. A = 6 7 4 5 2 3 0 1 B = E F C D A B 8 9 C = 9 8 B A D C F E D = 1 0 3 2 5 4 7 6 이를 word 단위로 바꾸면 다음과 같다. word A: 01 23 45 67 word B: 89 ab cd ef word C: fe dc ba 98 word D: 76 54 32 10 ④ 512비트 단위의 메시지 처리 개별 512비트에 관한 연산은 32비트씩, 64(16×4)단계를 거쳐 512비트를 처리한 다(그림 13 참조). F, G, H, I 함수 32비트 워드 세 개를 입력받아 메시지 다이제스트를 하는 함수다. 128비트의 ABCD버퍼 중에서 한 함수에 96(32×3)비트가 사용된다. 각 함수는 다음과 같 은 논리연산을 수행한다. F(X, Y, Z) = (X and Y)or(not(X) and Z) [X, Y, Z = 32bit] G(X, Y, Z) = (X and Z) or (Y and not(Z)) H(X, Y, Z) = (X xor Y) xor Z I(X, Y, Z) = Y xor (X or not(Z)) Table T 해쉬함수의 randomness를 증가시키기 위해 32비트의 랜덤 값을 사용한다. 전 체가 64단계이므로 다음 식을 사용하여 64개의 테이블 값을 만든다(리스트 3 참조). T[i] = 232 * abs(sin(i)) Step form 512비트를 처리하는 전체 64과정의 각각의 단계는 다음과 같은 형태이다(표 4 참조). a <- b + ((a + f(b,c,d) + X[k] + T[i]) <<< s 실제 코드에서 이들이 정해지는 형태는 리스트 4와 같다. ⑤ Output 모든 L의 512비트 블록의 계산이 끝나면 128비트의 메시지 다이제스트가 나온 다. 전체 알고리즘의 sudo 코드 MD5 알고리즘의 전체적인 sudo 코드를 살펴보면 리스트 5와 같다. MD5 Generator의 구현 앞서 배운 MD5 알고리즘을 사용하여 실제로 메시지 다이제스트를 만드는 MD5 Generator 프로그램을 구현해 보자. 프로그램은 비주얼 C++ 프로그램을 사용하여 제작했다. 동작방식은 상단에 메시지 원본을 기입하고 ‘변환시작’ 버튼을 누르면 하단 에 메시지 다이제스트 된 결과가 출력된다. 실제 소스는 리스트 6과 같다. MDString이 구현되는 부분은 제공되는 소스를 참고하기 바란다. 다음 호에서 는 SNMP의 다음 버전인 SNMPv2와 RMON 등에 관해 살펴본다. 리스트 3 : 테이블의 내용 /* Round1 */ T[1] = 0xd76aa478 T[2] = 0xe8c7b756 T[3] = 0x242070db T[4] = 0xc1bdceee T[5] = 0x4787c62a T[6] = 0xa8304613 T[7] = 0xfd469501 T[8] = 0x698098d8 T[9] = 0x8b44f7af T[10] = 0x8b44f7af T[11] = 0xffff5bb1 T[12] = 0x895cd7be T[13] = 0x6b901122 T[14] = 0xfd987193 T[15] = 0xa679438e T[16] = 0x49b40821 /* Round2 */ T[17] = 0xf61e2562 T[18] = 0xc040b340 T[19] = 0x265e5a51 T[20] = 0xe9b6c7aa T[21] = 0xd62f105d T[22] = 0x2441453 T[23] = 0xd8a1e681 T[24] = 0xe7d3fbc8 T[25] = 0x21e1cde6 T[26] = 0xc33707d6 T[27] = 0xf4d50d87 T[28] = 0x455a14ed T[29] = 0xa9e3e905 T[30] = 0xfcefa3f8 T[31] = 0x676f02d9 T[32] = 0x8d2a4c8a /* Round3 */ T[33] = 0xfffa3942 T[34] = 0x8771f681 T[35] = 0x6d9d6122 T[36] = 0xfde5380c T[37] = 0xa4beea44 T[38] = 0x4bdecfa9 T[39] = 0xf6bb4b60 T[40] = 0xbebfbc70 T[41] = 0x289b7ec6 T[42] = 0xeaa127fa T[43] = 0xd4ef3085 T[44] = 0x4881d05 T[45] = 0xd9d4d039 T[46] = 0xe6db99e5 T[47] = 0x1fa27cf8 T[48] = 0xc4ac5665 /* Round4 */ T[49] = 0xf4292244 T[50] = 0x432aff97 T[51] = 0xab9423a7 T[52] = 0xfc93a039 T[53] = 0x655b59c3 T[54] = 0x8f0ccc92 T[55] = 0xffeff47d T[56] = 0x85845dd1 T[57] = 0x6fa87e4f T[58] = 0xfe2ce6e0 T[59] = 0xa3014314 T[60] = 0x4e0811a1 T[61] = 0xf7537e82 T[62] = 0xbd3af235 T[63] = 0x2ad7d2bb T[64] = 0xeb86d391 리스트 4 : 실제 코드에서 정해진 형태 /* F, G, H and I are basic MD5 functions.*/ #define F(x, y, z) (((x) & (y)) | ((~x) & (z))) #define G(x, y, z) (((x) & (z)) | ((y) & (~z))) #define H(x, y, z) ((x) ^ (y) ^ (z)) #define I(x, y, z) ((y) ^ ((x) | (~z))) /* ROTATE_LEFT rotates x left n bits.*/ #define ROTATE_LEFT(x, n) (((x)<<(n))|((x)>>(32-(n)))) /* FF, GG, HH, and II transformations for rounds 1, 2, 3, and 4. Rotation is separate from addition to prevent recomputation.*/ #define FF(a, b, c, d, x, s, ac) { \ (a) += F ((b), (c), (d)) + (x) + (UINT4)(ac); \ (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define GG(a, b, c, d, x, s, ac) { \ (a) += G ((b), (c), (d)) + (x) + (UINT4)(ac); \ (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define HH(a, b, c, d, x, s, ac) { \ (a) += H ((b), (c), (d)) + (x) + (UINT4)(ac); \ (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } #define II(a, b, c, d, x, s, ac) { \ (a) += I ((b), (c), (d)) + (x) + (UINT4)(ac); \ (a) = ROTATE_LEFT ((a), (s)); \ (a) += (b); \ } 리스트 5 : MD5 알고리즘의 sudo 코드 /* Process each 16-word block. */ For i = 0 to N/16-1 do /* Copy block i into X. */ For j = 0 to 15 do Set X[j] to M[i*16+j]. end /* of loop on j */ /* Save A as AA, B as BB, C as CC, and D as DD. */ AA = A, BB = B, CC = C, DD = D /* Round 1. */ /* Let [abcd k s i] denote the operation a = b + ((a + F(b,c,d) + X[k] + T[i]) <<< s). */ /* Do the following 16 operations. */ [ABCD 0 7 1] [DABC 1 12 2] [CDAB 2 17 3] [BCDA 3 22 4] [ABCD 4 7 5] [DABC 5 12 6] [CDAB 6 17 7] [BCDA 7 22 8] [ABCD 8 7 9] [DABC 9 12 10] [CDAB 10 17 11] [BCDA 11 22 12] [ABCD 12 7 13] [DABC 13 12 14] [CDAB 14 17 15] [BCDA 15 22 16] /* Round 2. */ /* Let [abcd k s i] denote the operation a = b + ((a + G(b,c,d) + X[k] + T[i]) <<< s). */ /* Do the following 16 operations. */ [ABCD 1 5 17] [DABC 6 9 18] [CDAB 11 14 19] [BCDA 0 20 20] [ABCD 5 5 21] [DABC 10 9 22] [CDAB 15 14 23] [BCDA 4 20 24] [ABCD 9 5 25] [DABC 14 9 26] [CDAB 3 14 27] [BCDA 8 20 28] [ABCD 13 5 29] [DABC 2 9 30] [CDAB 7 14 31] [BCDA 12 20 32] /* Round 3. */ /* Let [abcd k s t] denote the operation a = b + ((a + H(b,c,d) + X[k] + T[i]) <<< s). */ /* Do the following 16 operations. */ [ABCD 5 4 33] [DABC 8 11 34] [CDAB 11 16 35] [BCDA 14 23 36] [ABCD 1 4 37] [DABC 4 11 38] [CDAB 7 16 39] [BCDA 10 23 40] [ABCD 13 4 41] [DABC 0 11 42] [CDAB 3 16 43] [BCDA 6 23 44] [ABCD 9 4 45] [DABC 12 11 46] [CDAB 15 16 47] [BCDA 2 23 48] /* Round 4. */ /* Let [abcd k s t] denote the operation a = b + ((a + I(b,c,d) + X[k] + T[i]) <<< s). */ /* Do the following 16 operations. */ [ABCD 0 6 49] [DABC 7 10 50] [CDAB 14 15 51] [BCDA 5 21 52] [ABCD 12 6 53] [DABC 3 10 54] [CDAB 10 15 55] [BCDA 1 21 56] [ABCD 8 6 57] [DABC 15 10 58] [CDAB 6 15 59] [BCDA 13 21 60] [ABCD 4 6 61] [DABC 11 10 62] [CDAB 2 15 63] [BCDA 9 21 64] /* Then perform the following additions. (That is increment each of the four registers by the value it had before this block was started.) */ A=A + AA, B=B + BB, C=C + CC, D=D + DD end /* of loop on i */ 리스트 6 : MD5 Generator 소스 CString m_Msg; //메시지 원본 CString m_MD5; //메시지 다이제스트 void CMD5GeneratorDlg::OnButton1() { // TODO: Add your control notification handler code here char *source; unsigned char md_digest[16]; char buffer[100]; int k; source = (LPSTR)(LPCTSTR)m_Msg; MDString(source,md_digest); //메시지 다이제스트를 수행하는 함수 for(k=0; k<16;k++){ sprintf(buffer,”%02x “,md_digest[k]); m_MD5 = m_MD5 + buffer; } UpdateData(FALSE); } 제 목:[9912]네트워크 정복의 첫걸음!(5) [265] 1999-12-02 18:14 플러그인 프로그래밍(2) 비트맵 플러그인 뷰어 지난 호에서는 플러그인의 개념, 자바 / ActiveX와의 차이, 플러그인에서 사용 되는 함수 등을 살펴보았다. 이번 호부터 2회에 걸쳐 비트맵 플러그인 뷰어를 만들어보기로 한다. 이 작업을 마치면 플러그인 프로그래밍에 대한 개념이 쉽 게 와닿을 것이다. 프로젝트 생성부터 차근차근 설명해나갈 것이므로 비주얼 C++을 접해보지 않은 독자도 두려워할 필요는 없다. 선희덕 한국자원연구소 sunhee@kis.kigam.re.kr 아직 우리나라는 플러그인 프로그래밍이 확산되지 않아서 참고문헌이나 샘플 프로그램을 찾기가 그리 쉽지는 않다. 필자도 예전에 그래픽 플러그인 뷰어를 만들 때 일반 플러그인(ex, 나모 hwp 뷰어, tiff 뷰어 등)의 인터페이스를 구현 하는 부분에서 애를 먹은 기억이 난다. 이 글에 포함된 여러 예제들이 플러그인을 개발하고자 하는 독자들에게 지름길 을 제공할 수 있었으면 하는 바램이다. 웹에서의 이미지 표준 웹에서 이미지의 표준은 gif와 jpg이다. 이를 제외한 tif, bmp, pcx 등의 그래픽 파일은 다운로드를 받아야 하거나 헬프 애플리케이션이라고 불리는 일반 윈도 우 프로그램이 로드되어 그림을 보여준다. 이런 이유로 웹의 표준 포맷이 아닌 파일들을 보려고 하면 수많은 애플리케이션이 실행되어 있는 것을 보게 된다. 이와는 반대로 윈도우의 표준 이미지 포맷은 bmp이다. 문제는 웹의 이미지 표 준과 윈도우 이미지 표준이 서로 다르다는데 있다. 이제 이러한 bmp 파일을 지원하는 플러그인을 만들어 웹브라우저를 빠져나가 지 않고 bmp 그림을 볼 수 있는 프로그램을 만들어 보자. 플러그인 표준 인터페이스 플러그인 프로그램은 대체적으로 다음과 같은 인터페이스를 갖추고 있다. 그림 1에서 보듯이 일단 툴바가 필요하다. 툴바에는 이미지를 설명해주는 툴팁 이 있어야 하고 스피드 메뉴를 지원해주는 팝업 메뉴 역시 필요하다. 요즘에는 익스플로러 스타일인 플랫 툴바를 만들어줄 필요도 있다. 이를 정리하면 최소한 툴바, 팝업 메뉴 정도는 플러그인 인터페이스에 있어야 하고 이외에 클라이언트 화면을 좀 더 예쁘게 꾸밀 수도 있다. 이것은 순전히 윈도우 API 프로그래밍과 관계된 것이므로 그와 관련된 함수를 찾아서 프로그 래밍을 하기 바란다. 프로젝트 구조 이러한 비트맵 뷰어 프로그램을 만들기 위해서는 표 1과 같은 파일이 사용된 다. 이 소스 중에서 가장 중요한 것은 PlugWnd.h, Plug Wnd.cpp 파일이다. 이 파일에서 플러그인에 쓰일 클래스와 자료구조, 멤버 함수가 선언되기 때문이다. 프로젝트 만들기 File-New를 선택하여 Win32 Dynamic-Link Library를 선택한다. 파일명은 WebBmpView로 하고 OK 버튼을 누르면 파일이 하나도 없는 빈 프로젝트가 생성된다. 플러그인 프로그램은 윈도우 API를 기본으로 하기 때문에 Non-MFC 프로그래밍이 더 효과적이다. 프로젝트 관련 파일 추가 이제 지난 호에서 설명했던 플러그인 SDK의 Common 폴더에 있는 npwin.cpp 파일을 프로젝트에 추가하자. 참고로 프로젝트 추가는 ‘Project’의 ‘add To Project’ → ‘Files’를 차례로 선택하면 된다. 다음으로 Include 폴더를 현재 자신이 만든 WebBmpView 폴더 안에 그대로 복사한다. 또한 Examples\WinTemplates\Source안의 WinTem p.c 파일을 WebBmp.cpp로 이 름을 바꾸어 프로젝트에 추가한다. 다음에는 Examples\WinTemplates\Windows 안의 resource.h, WinTemp.rc, WinTemp.def 등 세 개의 파일을 추가한다. WinTemp.rc는 Web Bmp.rc로, Win Temp.def는 WebBmp.def로 이름을 바꾸어 추가해야 한다. 리소스 파일 수정 플러그인 SDK에서 복사한 리소스 파일은 샘플 리소스이기 때문에 프로젝트에 맞게 바꾸어야 한다. ① 버전 설정 비주얼 스튜디오 통합환경에서 리소스 탭을 누르면 기본적으로 Version이라는 것만 나온다. Version 부분은 신중하게 설정해야 한다. 다음은 특히 주의해야할 부분이다(그림 2 참조). · Version의 리소스의 언어 세팅은 반드시 English(U.S)이어야 한다. · Version은 Key와 Block Header 두개로 분리되어 있다. Block Header의 Langauge ID는 영어(미국), Code page는 Windows, Multilingual로 한다. · FileExtents는 지원할 플러그인 확장자 타입이다. bmp|bmp로 한다. · FileOpenName은 오픈할 파일 확장자의 설명을 나타낸다. 반드시 위에서 작 성한 File Extens의 개수와 일치해야 한다. 2개로 했기 때문에 여기서도 BMP Image(*.bmp)|BMP Image(*.bmp)\0\0로 한다. · MIMEType은 image/x-bmp|image/bmp로 하자. bmp MIME 타입은 이렇게 잡혀 있기 때문에 그대로 써야 한다. ② 툴바 비트맵 만들기 리소스 탭에서 ‘팝업 메뉴 / Insert’를 선택하면 대화상자에 Bitmap이 나타 난다. 이것을 선택하면 비트맵 이미지를 그릴 수 있는 에디터가 나온다. 48x16 의 이미지를 만든다. 즉 16픽셀짜리 이미지 3개를 만드는 것이다. ID명은 IDB_BIT MAP1으로 한다. ③ 다이얼로그 만들기 이번에는 Dialog를 선택하여 대화상자를 하나 만들어보자. ID명은 IDD_About 으로 한다. 일단 두개의 버튼이 나오는데 Cancel 버튼은 없앤다. 그리고 Edit 박스 두 개를 놓는다. 두 개의 Edit 박스의 속성에 모두 Multiline을 체크하고 아래 Edit 박스는 Border 속성을 체크하여 움푹 들어가게 한다(그림 3 참조). ④ 팝업 메뉴 만들기 이번에는 Menu를 선택하여 새로운 메뉴 리소스를 만들고, ID는 CONTEXTMENU로 한다. 메뉴는 표 2와 같이 구성한다. 참고로 팝업 속성을 체크하면 서브 메뉴가 생성된다. ⑤ 리소스 심볼 만들기 리소스는 각각 ID라는 것을 가지고 있다. 이 ID는 자신을 나타내는 식별자라 할 수 있다. 툴바 버튼에 해당하는 리소스 심볼들을 만들기 위해서는 리소스 탭에서 팝업 메뉴 중 Resource Symbols를 선택하면 된다. 이를 선택하면 그림 4와 같은 화면이 나온다. 여기에서 New를 눌러 새로운 리소스 심볼을 만들어 주면 된다. · 툴바에 쓰일 세 가지 버튼의 리소스 심볼을 만든다. IDB_SAVE : 101 IDB_GOTOURL : 102 IDB_ABOUT : 103 IDB_SEP : 105 · 툴바에 대한 리소스 심볼을 만든다. ID_TOOLBAR : 200 ⑥ 스트링 테이블 만들기 툴바에는 툴팁이라는 것이 붙는다. 이 툴팁의 내용은 직접 프로그램 코드에서 도 할 수 있지만 스트링 테이블로 만들면 이후 내용을 변경할 때 이 부분만 바 꾸어 간단히 처리할 수 있다는 점이 장점이다. 스트링 테이블을 만들기 위해서 는 일반 리소스를 만들 때와 같이 팝업 메뉴에서 Insert를 눌러 String Table 을 선택한다. 툴팁에 들어갈 내용은 툴바 리소스 심볼과 연결되어야 한다. 툴바 리소스 심볼은 앞에서 IDB_SAVE, IDB_ GOTOURL, IDB_ABOUT 세 개를 만들었다. IDB _SEP는 툴바에서 쓰일 분리자 역할을 하기 때문에 툴팁이 필요 없다. 이 세 개의 리소스 심볼에 스트링을 붙여주면 된다. 다음으로 스트링 그 리드를 더블 클릭하면 프라퍼티 화면이 나오는데 여기에 툴바 버튼 리소스 심 볼을 선택하고 툴팁의 내용을 적어주면 된다(그림 5 참조). 이로써 리소스 설정 작업은 끝났다. 코딩 레퍼런스 비트맵에 대해서는 이미 다른 책에서도 많이 다루므로 자세한 설명은 피하고 주로 플러그인 인터페이스를 구성하기 위한 코딩을 주로 설명하겠다. 참고로 이번 호에서는 Jason Summers의 비트맵 처리루틴을 사용하였다. 플러그인 인스턴스 처리 클래스(PlugWnd.h) 비트맵 처리를 위한 클래스를 구성하는 파일이다. 이 파일에는 자료 구조 및 멤버 함수가 포함된다. 멤버 함수에 대한 설명은 필요한 부분만 다음에 설명하 기로 하고 여기에서는 멤버 변수가 어떻게 사용되는지에 대해 설명할 것이다. 리스트 1을 참고하기 바란다. 이제부터 살펴볼 부분은 플러그인의 뼈대가 되는 자료구조이다. 나머지 부분은 현재 플러그인의 상황에 맞게 선언하면 된다. NPWindow* fWindow; uint16 fMode; HWND fhWnd; // 플러그인 다큐먼트 핸들 WNDPROC fDefaultWindowProc; NPP instance; // 플러그인 인스턴스 핸들 ① NPWindow Structure 브라우저 클라이언트의 크기에 관한 자료구조이며 API의 Rect 타입과 유사하 다. typedef enum { NPWindowTypeWindow = 1, // 윈도우가 있는 플러그인 NPWindowTypeDrawable // 윈도우가 없는 플러그인 } NPWindowType; typedef struct _NPWindow { void* window; // OS 플랫폼 핸들 uint32 x; // left 위치 uint32 y; // top 위치 uint32 width; // 윈도우의 width uint32 height; // 윈도우의 height NPRect clipRect; #ifdef XP_UNIX void* ws_info; #endif NPWindowType type; // 플러그인이 윈도우가 있는지 없는지를 지정한다. } ② WNDPROC fDefaultWindowProc; 이벤트 핸들러를 지정하는 콜백 함수를 저장한다. ③ uint16 fMode; 현재 플러그인이 embed 모드로 되어 있는지 아니면 풀모드(즉, html에 포함되 지 않고 파일 자체가 플러그인에 실행될 경우)인지 저장하는 변수이다. NP_EMBED : embed 태그에 의해 플러그인이 로드 NP_FULL : 파일 자체가 플러그인에 로드 ④ HWND fhWnd; 플러그인 다큐먼트의 윈도우 핸들로 이벤트 콜백 함수에서 이벤트를 다룰 때 쓰인다. ⑤ NPP instance; 플러그인 인스턴스 핸들. typedef struct _NPP { void* pdata; // 플러그인 데이터 포인터 void* ndata; // 넷스케이프 데이터 포인터 } NPP_t; typedef NPP_t* NPP; 이 자료구조를 보면 알 수 있듯이 플러그인 인스턴스로 선언한 CPluginWindow 클래스 인스턴스를 pdata에 넣어주어야 한다. 이것은 NPP_New 함수의 처음 부분을 보면 알 수 있다. This = new CPluginWindow(mode, instance); instance->pdata = This; 리스트 1 : 플러그인 인스턴스 처리 클래스 #include #include // 툴바 컨트롤을 포함하기 위한 헤더 파일 #include “npapi.h” // 플러그인 API 헤더 파일 class CPluginWindow { public: NPWindow* fWindow; uint16 fMode; HWND fhWnd; // 플러그인 다큐먼트 핸들 WNDPROC fDefaultWindowProc; // 메시지 처리 콜백 함수 NPP instance; // 플러그인 인스턴스 핸들 char url[2048]; // 비트맵 파일의 URL int status; // 현재 비트맵 파일이 로드되었는가 여부 (ST_LOADED : 로드완료, ST_NOTLOADED : 아직 안됨 HANDLE hdib; // 비트맵을 저장한 메모리 핸들 int diballoc; // hdib에 할당된 바이트 수 int dibused; // DIB로 읽어온 바이트 수 int streamend; // 스트림 사이즈 BITMAPFILEHEADER fileheader; int imgwidth,imgheight, imgbpp, imgcompr, palettesize; HWND hPluginWnd; // 플러그인 윈도우 핸들 HWND hToolbar; // 툴바 윈도우 핸들 HMENU hPopupMenu; // 메뉴 핸들 }; 플러그인 인스턴스 파일(webbmp.cpp) 플러그인은 멀티쓰레드 방식을 사용한다. 즉 여러 개의 웹브라우저에서 같은 플러그인이 로드된다고 해도 매번 프로세스가 생성되는 것이 아니라 쓰레드가 늘어나는 것이다. 따라서 NPP_Initialize는 처음으로 플러그인이 로드될 때 실 행하고 NPP_Shutdown은 모든 플러그인이 종료되었을 때 발생한다. NPP_New 함수는 쓰레드가 생성될 때마다 호출된다. 그러므로 위에서 만든 클 래스에 인스턴스를 할당하기 위해서는 NPP_New에서 새로운 인스턴스를 할당 해야 한다. 반대로 NPP_Destroy는 브라우저가 종료될 때마다 생성된 쓰레드를 종료한다. 그러므로 생성된 클래스 인스턴스도 여기에서 해제시켜주어야 한다. NPP_SetWindow 함수는 플러그인 생성시 플러그인 화면을 그려주는 역할을 한다. 여기에서 툴바를 생성해주면 된다. 비트맵 파일을 브라우저에서 보여주기 위해서는 클라이언트에 일단 파일 내용 이 저장되어야 한다. 이러한 파일 저장 기능은 다행히 브라우저 기능에 포함되 어 있다. 당연히 플러그인에서도 사용이 가능하다. 파일로 저장하기 위해서는 NPP_StreamAsFile을 쓰면 되고 스트림에 저장해 쓰려면 NPP_NewStream이 라는 함수에서 스트림을 읽어오고 NPP_Write 함수를 이용하여 메모리에 스트 림을 저장하는 방법이 있다. 파일로 저장하는 것보다 스트림을 이용해 직접 메모리에 저장하면 좀더 빠른 속도를 얻을 수 있다. 저장된 스트림을 삭제하기 위해서는 NPP_DestroyStream이라는 함수를 사용한다. 이제 플러그인 인스턴스 파일에 서 사용되는 함수들을 살펴보기로 하자. ① NPP_Initialize : 처음으로 프로세스가 생성되었을 때 호출한다. 이 파일에서 는 현재 DLL 인스턴스의 핸들을 구하는 것이 중요하다. DLL 함수의 이름은 DLLFILENAME에서 정의되어 있다. #define DLLFILENAME “npbmpvw.dll” hInst=GetModuleHandle(DLLFILENAME); ② NPP_New : 쓰레드가 생성될 때마다 호출해 새로운 클래스 인스턴스를 만 들어준다. 이 함수는 눈여겨 볼 필요가 있다. 바로 여기에서 embed 태그의 파 라미터를 처리한다. 이와 같은 태그가 들어오면 argc = 4 argn = { “src”, “height”, “width”, “loop”} argv = { “movie.avi”, “100”, “100”, “true”} 와 같이 파라미터 값이 설정된다. 그렇기 때문에 현재 플러그인에 로드될 파일 명을 구하려면 argv[0] 하면 된다. 일단 이 함수에서는 각 브라우저에 따른 플 러그인 인스턴스를 생성하고 플러그인 클래스의 멤버 변수를 초기화한다(리스 트 2 참조). ③ NPP_NewStream : 비트맵 내용의 스트림을 읽어온다. 또한 URL의 정보를 플러그인 클래스 CPluginWindow의 URL에 저장하고 만약에 이전에 사용한 객 체가 남아있을 경우 이를 메모리에서 제거하고 스트림을 읽는다. NPError NPP_NewStream(NPP instance,NPMIMEType type,NPStream *stream, NPBool seekable,uint16 *stype) { .... Strncpy(This->url,stream->url,2048); if(This->hdib) { GlobalFree(This->hdib); This->hdib=NULL; This->diballoc=0; } This->status=ST_NOTLOADED; This->streamend=stream->end; ... } ④ NPP_Write : 읽어온 스트림의 내용을 메모리로 저장한다. 위의 NPP_NewStream 함수가 해당 URL에서 비트맵의 스트림 읽기를 초기화하는 반면 파일의 모든 내용을 읽어서 플러그인 사용할 수 있도록 구성하는 부분이 바로 이 함수가 하는 일이다. ⑤ NPP_DestroyStream : 스트림을 해제한다. 쓰레드가 종료될 때마다 호출된 다. ⑥ NPP_SetWindow : 플러그인 화면이 새로 생기거나 움직일 때, 또는 파괴될 때 윈도우를 다시 그려주는 함수이다. 이 함수에서 가장 중요한 부분은 윈도우 메시지 부분을 처리하는 콜백 함수를 지정해주는 부분이다. 이 부분을 설정해 주지 않으면 플러그인은 어떤 메시지에도 반응하지 않는다. 이는 윈도우 API로 작성할 때와 비슷하다. 윈도우에서 사용할 아이콘, 클래스명, 크기 등을 지정하 고 메시지처리 함수와 플러그인에서 사용되는 툴바 부분을 넣어주어야 한다. NPError NPP_SetWindow(NPP instance, NPWindow* window) { ... // 제일 중요한 함수. 플러그인에서 이벤트 처리를 위해 콜백 함수를 지정한 다. // 지정된 콜백 함수는 PlugWindowProc 함수이다. This->fDefaultWindowProc = (WNDPROC)SetWindowLong ((HWND)window->window, GWL_WNDPROC, (LONG)PluginWindowProc); ... // 윈도우 공용 컨트롤을 초기화한다. 이 안에서 툴바를 생성한다. This->InitControl(This->fhWnd, This); return result; } 리스트 2 : NPP_New 함수 NPError NPP_New(NPMIMEType pluginType,NPP instance, uint16 mode, int16 argc,char* argn[],char* argv[],NPSavedData* saved) { CPluginWindow* This; // 새로운 플러그인 인스턴스를 생성한다. This = new CPluginWindow(mode, instance); instance->pdata = This; // 플러그인 인스턴스 멤버 변수에 초기값을 넣는다. This->fWindow = NULL; This->fMode = mode; This->fhWnd = NULL; This->fDefaultWindowProc = NULL; This->instance = instance; This->hdib=(HANDLE)0; This->diballoc=0; This->dibused=0; This->status=ST_NOTLOADED; .... } 이벤트 처리 콜백 함수 플러그인도 일반 애플리케이션처럼 대부분의 메시지를 처리할 수 있다. 이 작 업을 위해 필요한 것이 콜백 함수이다. 콜백 함수를 지정해주기 위해서는 다음 과 같이 선언해야 한다. LRESULT CALLBACK PluginWindowProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam); 이러한 형식은 이미 많이 보았을 것이다. 이는 API로 프로그래밍을 할 때 이벤 트 핸들러를 만드는 형식과 같다. 이 함수는 실제로 사용자가 플러그인 화면에 서 마우스를 누른다든지 팝업 메뉴, 툴바 등을 선택할 때의 반응을 처리하는 루틴이다(리스트 3 참조). a리스트 3 : 이벤트 처리 콜백 함수 LRESULT CALLBACK PluginWindowProc( HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) { // 비트맵 처리 인스턴스를 얻어온다. PluginWindowProc은 일종의 외부함수이기 때문에 현재 플러그인 핸들을 얻어오기 // 위해서는 반드시 GetProp을 이용해야 한다. CPluginWindow* This = (CPluginWindow*) GetProp(hWnd, gInstanceLookupString); if(!This) return DefWindowProc (hWnd, Msg, wParam, lParam); switch(Msg) { // 오른쪽 마우스 버튼을 누르면 팝업 메뉴를 로드한다. case WM_CONTEXTMENU: This->ContextMenu(This,LOWORD(lParam), HIWORD(lParam)); // 플러그인 화면을 그린다. case WM_PAINT: { PAINTSTRUCT paintStruct; HDC hdc; RECT rect; HPEN oldpen; HBRUSH oldbrush; // 플러그인 화면의 디바이스 컨텍스트를 얻어온다. hdc = BeginPaint( hWnd, &paintStruct ); GetClientRect(hWnd,&rect); oldpen=(HPEN)SelectObject(hdc, GetStockObject(NULL_PEN)); oldbrush=(HBRUSH)SelectObject (hdc,GetStockObject(WHITE_BRUSH)); Rectangle(hdc,rect.left,rect.top, rect.right+1,rect.bottom+1); // 비트맵을 플러그인 화면에 그린다. This->PaintBitmap(This, hdc, &rect); SelectObject(hdc,oldpen); SelectObject(hdc,oldbrush); // 얻어온 디바이스 컨텍스트 핸들을 해제한다. EndPaint( hWnd, &paintStruct ); } // 화면 리사이즈시에 발생하는 이벤트 case WM_SIZE : //브라우저 사이즈가 변했을 경우 플러그인 크기도 변경시킨다. pluginObj->OnSize(hWnd); break; // 툴바 버튼을 눌렀을 때 발생하는 이벤트 case WM_COMMAND : { switch(LOWORD(wParam)){ // 비트맵 파일 저장 버튼을 눌렀을 때 발생하는 함수 case IDB_SAVE : { This->SaveImage(This); break; } // About 대화상자 버튼을 눌렀을 때 발생하는 함수 case IDB_ABOUT : { This->OnAbout(hWnd, This); break; } // URL 이동 대화상자 버튼을 눌렀을 때 발생하는 함수 case IDB_GOTOURL : { char url[100] = “http://geophy.kigam.re.kr”; pluginObj->OnGotoURL(This, url); return 0; } default : break; } } // 디폴트 메시지 처리 함수 default : return CallWindowProc(This->fDefaultWindowProc, hWnd, Msg, wParam, lParam); } // switch return 0; } 마치며 이번 호에서는 Webbmp.cpp 파일까지만 살펴보았다. 다음 호에서는 플러그인 프로그램의 핵심인 PlugWnd.cpp 파일을 분석하고 디버그와 실제 브라우저의 설정 등을 살펴보도록 하겠다. 이 글을 읽고 과연 프로그램이 어떻게 돌아갈까 궁금한 독자는 포함된 소스 파 일을 통해 먼저 경험해보기 바란다. 사용법은 간단하다. 프로젝트의 압축을 풀 고 컴파일을 한 다음 넷스케이프 폴더의 Plugins에 NPBmpVw.dll 파일에 넣어 두고 넷스케이프를 실행하면 된다. 플러그인의 기능을 확인해보고 싶다면 탐색 기에서 비트맵 파일을 하나 선택한 다음 넷스케이프로 드래그해서 옮겨보기 바 란다. 플러그인의 멋진 기능을 확인할 수 있을 것이다. 제 목:[0001]네트워크 정복의 첫 걸음!(6) [284] 2000-01-03 15:49 네트워크 정복의 첫 걸음!(6) Remote Monitoring MIB-II에 의한 SNMP 관리체제는 단일 네트워크 개체를 관리하는 개념이다. 하지만 인터넷의 확장에 따라 네트워크 관리 개념은 하나의 서브 네트워크 전 체를 관리하는 RMON(원격 모니터링)으로 확대되고 있다. 이번 호에서는 RMON의 개념과 이를 이용한 네트워크 관리 방법 등을 살펴보자. 노정민 한국항공대학교 항공통신정보공학과 대학원 hmask@esc.cl.hangkong.ac.kr 네트워크 모니터링 네트워크 자원(Network Resource)을 안전하고 효율적으로 이용하기 위해서는 네트워크의 상태를 측정할 수 있는 도구가 필요하고, 여기서 측정된 데이터를 확인하고 분석하여 적당한 네트워크 관리를 수행하는 유능한 관리자가 필요하 다. 네트워크의 상태를 분석하는 부분은 관리자(Manager)의 역할이고, 이보다 선행되어야 할 일이 관리하고자 하는 네트워크의 정보를 얻는 일일 것이다. 이 런 네트워크 정보를 수집하는 일을 하는 도구를 에이전트(Agent)라고 부른다. 에이전트는 네트워크의 충돌 횟수, 길이 초과 패킷 개수, CRC 에러가 난 패킷 의 개수 등과 같은 네트워크의 상태 정보를 인터페이스로부터 얻어내고, 네트 워크에 돌아다니는 패킷들을 분석하여 패킷의 개수, 길이별 패킷 분포, 호스트 통계 정보 등을 수집한다. 그리고 에이전트가 수집한 네트워크 정보를 받아서 네트워크 관리자가 분석한다. 기존의 MIB-II를 사용해서 네트워크를 감독하는 방법은 그림 1처럼 네트워크 장치에 에이전트를 설치하고 관리자와 주기적으로 폴링을 사용해서 정보를 교 환한다. 하지만 이런 방법은 각각의 네트워크 시스템과 일일이 정보를 주고받 기 때문에 네트워크의 부하가 너무 많고, 전체 네트워크 정보를 얻을 수도 없 다. 따라서 이를 극복하기 위한 다른 방안이 필요하다. RMON이란? 일반적으로 LAN은 모든 패킷을 방송(broadcast)하기 때문에 한 서브네트워크 에서 목적지 다른 주소의 패킷을 읽기도 한다. 이를 위해서는 네트워크 카드의 설정 부분을 모든 패킷을 읽도록 "promiscuous" 모드로 바꾸면, LAN을 지나다 니는 모든 패킷의 내용을 읽어들인다. 박스 --------------------- promiscuous 모드와 스위칭 허브 LAN의 특성상 네트워크의 개체들은 모든 패킷을 방송(broadcast)하기 때문에, 네트워크 카드를 'promiscuous' 모드로 설정해두면 서브네트워크를 지나다니는 모든 패킷을 관찰할 수 있다. 이런 아이디어에서 출발한 프로그램들이 LAN Aanalyzer인데, 이를 오용한 것이 'sniffer'이다. 하지만 스위칭 허브를 사용하여 네트워크를 여러 세그먼트로 쪼개면 MAC 계 층에서 다른 세그먼트의 목적지 패킷은 걸러주기(filtering) 때문에, 어느 정도 위험은 막을 수 있다. ------------------------------------ 따라서 이 모드에서 동작하는 에이전트는 한 서브네트워크내의 전체 트래픽과 에러 통계, 충돌 횟수, 퍼포먼스 통계 등을 파악할 수 있으며, 사전에 입력된 관리 설정에 의해 패킷을 걸러낼 수도 있다. 이처럼 매니저가 에이전트와 동일 한 네트워크에 존재하지 않더라도 에이전트에게 네트워크 정보를 요구하면, 다 른 네트워크의 정보를 얻을 수 있는 것을 RMON(Remote network MONitoring)이라고 한다. 한 세그먼트의 네트워크 정보를 수집하는 RMON 에이전트는 RMON probe라 고 부르기도 한다. RMON의 동작 원리 RMON을 이용한 네트워크 구성은 그림 2와 같다. 관리자는 Ethernet B에 있지 만 Ethernet A의 망 정보를 RMON 에이전트를 통해 얻을 수 있다. RMON 에 이전트는 한 서브네트워크 전체에서 발생하는 트래픽을 파악한다. 즉, 전체 발 생 트래픽, 세그먼트에 연결된 각 호스트의 트래픽, 호스트들간의 트래픽 발생 현황을 알려준다. 이처럼 동작하기 위해서 RMON 에이전트는 전체 통계 데이터, 이력(history) 데이터, 호스트 관련 데이터, 호스트 매트릭스(matrix)와 사전에 문제 예측 및 제거를 위해서 특정 패킷을 필터링(filtering)하는 기능이 필요하고, 임계치 (threshhold) 설정과 이에 도달하면 자동으로 알려주는 경보(alarm) 기능, 이벤 트(event) 발생 기능을 보유하고 있어야 한다. RMON MIB RMON은 네트워크 관리를 위해 마련된 특정한 프로토콜은 아니다. RMON은 전체 네트워크 관리를 위해 정해놓은 MIB이며, RMON MIB의 정보 교환은 SNMP를 사용한다. RMON의 표준은 RFC1757에 정의되어 있으며, 관련된 RFC는 표 1과 같다. RFC 번호 제목 RFC 1271 Remote Monitoring(obsolete) RFC 1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC 1757 Remote Network Monitoring MIB RFC 2021 Remote Network Monitoring MIB II RFC 2074 RMON Protocol Identifier RFC 2613 RMON Extensions for Switch Networks 표 1. RMON과 관련한 RFC RMON의 목적 RMON MIB에서는 RMON이 갖추어야할 목표를 다음과 같이 제시하고 있다. Offline 동작 이것은 RMON 에이전트가 관리자와의 통신에 영향을 받지 않고 정보를 수집 하기 위한 것으로 동작방식은 그림 3과 같다. RMON Probe는 서브네트워크의 정보를 수집하고, 이를 관리하는 매니저는 전 화 라인을 거쳐서 다른 네트워크에 있으며 이 둘 사이의 정보 교환은 필요할 때마다 수행한다. 이렇게 Offline 동작으로 폴링에 의한 네트워크 부하를 줄일 수 있고, 매니저가 고장일 때도 상관없이 네트워크 정보를 수집할 수 있다. Proactive Monitoring 모니터가 충분한 자원을 가지고 있다면, 모니터에 주어진 자원에 따라 인터넷 의 특정한 부분에 장애가 발생했을 때 네트워크를 진단하고 성능 자료를 관리 해서 장애 및 장애에 대한 기록을 관리자에게 보고할 수 있어야 한다. 문제 발견 및 보고 모니터는 네트워크 자원의 오류나 관리자가 정한 특정 이벤트가 발생했을 경우 에 그 이벤트를 로그로 남기고, 관리자에게 보고할 수 있어야 한다. 부가가치 자료 모니터는 수집한 자료에 의미있는 가치를 부여할 수 있어야 한다. 즉 관찰하는 서브네트워크의 가장 많은 트래픽과 오류를 발생시키는 호스트들을 집중 관찰 한다. 따라서 네트워크에 오류가 발생했을 때, 이 문제를 해결할 수 있는 세밀 한 정보를 관리자에게 줄 수 있다. 복수의 관리자 보통 인터넷 관리는 안정성을 위해서 여러 개의 관리자를 사용한다. 모니터는 이렇게 관리자들이 보내는 명령을 모두 처리해야 한다. 하지만 이때 모니터의 시스템 용량에 따라서 관리자 명령대로 수행하지 못할 수도 있다. RMON의 테이블 관리 RMON MIB 그룹은 모두 테이블 형태이다. 대부분의 그룹은 해당 객체들을 생 성하는데 필요한 각종 자료(기록 시간 간격, 호스트 그룹의 호스트 수, 자료의 생성인 등)를 가지고 있는 제어 테이블과 실제 필요한 자료를 수집하는 데이터 테이블로 구성된다. RMON에서 사용하는 데이터형 RMON은 수집하는 데이터의 내용을 표시하기 위해서 기본적인 SNMP의 데이 터형 외에 리스트 1과 같은 데이터형을 추가했다. 리스트 1. RMON에 추가된 데이터형 --------------------------------------------------------------- -- textual conventions OwnerString ::= DisplayString -- By convention, objects with this syntax are declared as having -- SIZE (0..127) EntryStatus ::= INTEGER { valid(1), createRequest(2), underCreation(3), invalid(4) } -- The status of a table entry. --------------------------------------------------------------- 먼저 OwnerString은 데이터를 수집하고 관리하는 개체를 기술하는데 사용되는 문자열로서 보통 전화번호, 관리 스테이션 이름, 전자우편주소 등으로 나타낸 다. 제어 테이블은 단순하게 크기를 제한하거나 수집할 자료의 인터페이스를 지시 하고, 제어 테이블을 포함해서 자료 테이블을 만들고 삭제할 수 있는 "상태 (Status)" 객체를 정의한다. 이것은 EntryStatus로 구성되는데, 이 상태 객체를 변경해서 테이블을 만들거나 수정하고 자료 수집과 삭제를 할 수 있다. 관리 테이블의 상태는 표 2와 같다. 상태 번호 내용 valid 1 정상상태로서, 관리테이블의 내용을 수정할 수 없다 createRequest 2 테이블을 만들기 위해 요구하고 있는 상태 underCreation 3 테이블을 만들고 있는 상태로서, 테이블의 내용을 수정 할 수 있다 invalid 4 'underCreation'동안만 존재하는 개체들이 생성이 끝난 다 음에도 계속 존재하는 경우 표 2. 관리테이블의 상태 RMON 테이블의 구조 RMON에서 사용하는 제어 테이블과 데이터 테이블의 상관 관계를 리스트 2의 예를 통해 살펴보자. 먼저 rmonCtrlTable이란 이름으로 정한 제어 테이블은 다 음의 같이 구성된다. [1] rmonCtrlIndex : rmonCtrlTable의 행을 구분하는 색인이다 [2] rmonCtrlParameter : 제어를 의해 사용되는 파라미터 [3] rmonCtrlOwner : 테이블의 제어 권한을 가진 개체 [4] rmonCtrlStatus : 테이블의 제어 상태 리스트 2. 제어 테이블과 데이터 테이블의 상관 관계 --------------------------------------------------------------- rmonCtrlTable OBJECT-TYPE SYNTAX SEQUENCE of rmonCtrlEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " 제어 테이블입니다." ::= { ex 1 } rmonCtrlEntry OBJECT-TYPE ACCESS not-accessible STATUS mandatory DESCRIPTION " 데이터 테이블을 제어하는 파라미터의 집합" INDEX { rmonCtrlIndex } ::= { rmonCtrlTable 1 } rmonCtrlEntry ::= SEQUENCE { rmonCtrlIndex INTEGER, rmonCtrlParameter Counter, rmonCtrlOwner OwnerString, rmonCtrlStatus EntryStatus } --------------------------------------------------------------- 그리고 데이터 테이블의 이름은 rmonDataTable로 정하자. 테이블의 구성은 리 스트 3과 같고 rmonDataCtrlIndex와 rmonDataIndex를 사용해서 테이블의 객 체를 구분한다. 리스트 3. 데이터 테이블의 구성 --------------------------------------------------------------- rmonDataTable OBJECT-TYPE SYNTAX SEQUENCE OF rmonDataEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " 데이터 테이블" ::= { ex1 2 } rmonDataEntry OBJECT-TYPE SYNTAX rmonDataEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "단일 데이터 테이블 엔트리" INDEX { rmonDataCtrlIndex, rmonDataIndex } ::= { rmonDataTable 1 } rmonDataEntry ::= SEQUENCE { rmonDataCtrlIndex INTEGER, rmonDataIndex INTEGER, rmonDataValue Counter } --------------------------------------------------------------- [1] rmonDataCtrlIndex : 데이터 제어 집합의 색인, 제어 테이블의 rmonCtrlIndex와 같다 [2] rmonDataIndex : 데이터의 행을 구분하는 색인 [3] rmonDataValue : 테이블의 실제 데이터 값 실제 객체의 내용을 추가해서 두 테이블 사이의 관계를 나타내면 그림 4와 같 다. 제어 테이블에는 세 개의 관리자가 등록되어 있다. 보통 첫 번째 관리자의 이 름은 에이전트 자신을 나타내며 'monitor'로 표시한다. 데이터 테이블에는 rmonDataValue가 rmonDataCtrlIndex와 rmonDataIndex로 구분 표시되어 있다. 데이터 테이블의 rmonDataCtrlIndex값은 제어 테이블의 rmonCtrlIndex를 참조 해서 만들기 때문에 두 개의 값이 항상 일치해야 한다. RMON MIB 그룹 RFC1757에는 그림 5와 같이 9개의 RMON MIB 그룹이 정의되어 있다. RMON 에이전트를 설계할 때 9개의 그룹을 전부 구현하는 것이 어렵기 때문 에, 이 중에서 필요한 그룹만 구현하는 것이 일반적이다. 하지만 한 그룹을 구 현할 때는 그 그룹내의 객체를 모두 구현해야 한다. 가령 Host Group을 구현 하려면 반드시 이와 관련된 HostControlTable, HostTable, HostTimeTable 모 두를 구현해야 한다. 통계(The Ethernet Statistics Group) · RMON 에이전트가 각각 모니터링 하는 인터페이스(NIC)에 대해서 측정한 통계자료 모음이다. 한 세그먼트 내에서 발생한 패킷/바이트 수, 브로드캐스트/ 멀티캐스트 수, 충돌(collision)수 및 패킷 길이별 수, 각종 오류(프래그먼트, CRC Alinment, jabber, 길이 미달, 길이 초과)에 대한 통계를 제공한다. 통계치 는 유효한 entry가 생성될 때 0으로 초기화되고 free running counter 형태를 취한다. 이 통계 그룹은 오직 이더넷 인터페이스에만 정의된다. 각각 이더넷 인 터페이스에 하나의 etherStatsEntry가 대응된다. 이력(The History Control Group) · 주기적으로 트래픽 및 오류 등에 관한 정보를 제공한다. 이력은 데이터를 주기적으로 수집하는 동안의 누적된 수치를 제공한다. 그 수치는 다른 통계 치 의 값들과 비슷하다. 즉 이력에서의 etherHistoryPkts와 통계에서의 etherStatsPkts는 비슷한 값을 갖게된다. 이 자료를 통해 시간대별 이용 현황 및 다른 세그먼트와 비교가 가능하다. · 이력 정보를 관리하기 위한 제어 테이블(historyControlTable), 제어 개체 (historyControlEntry)와 이력 테이블(etherHistoryTable), 이력 개체 (etherHistoryEntry)가 리스트 4와 같이 정의된다. 리스트 4. 이력 테이블 정의 --------------------------------------------------------------- --이력(history) 테이블 historyControlTable OBJECT-TYPE SYNTAX SEQUENCE OF HistoryControlEntry ACCESS not-accessible STATUS mandatory DESCRIPTION " 이력 정보를 제어하는 항목들" ::= { history 1 } historyControlEntry OBJECT-TYPE SYNTAX HistoryControlEntry ACCESS not-accessible STATUS mandatory INDEX { historyControlIndex } ::= { historyControlTable 1 } HistoryControlEntry ::= SEQUENCE { historyControlIndex INTEGER (1..65535), --제어 색인 historyControlDataSource OBJECT IDENTIFIER, --색인 소스 OID historyControlBucketsRequested INTEGER (1..65535), --수집 횟수 historyControlBucketsGranted INTEGER (1..65535), --샘플링 간격 historyControlInterval INTEGER (1..3600), --데이터 수집 간격 historyControlOwner OwnerString, --소유주 historyControlStatus EntryStatus } --상태 --데이터 테이블 etherHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF EtherHistoryEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of Ethernet history entries." ::= { history 2 } etherHistoryEntry OBJECT-TYPE SYNTAX EtherHistoryEntry ACCESS not-accessible STATUS mandatory INDEX { etherHistoryIndex , etherHistorySampleIndex } ::= { etherHistoryTable 1 } EtherHistoryEntry ::= SEQUENCE { etherHistoryIndex INTEGER (1..65535), etherHistorySampleIndex INTEGER (1..2147483647), etherHistoryIntervalStart TimeTicks, --이력 이 시작된 시간 etherHistoryDropEvents Counter, -- 버려진 횟수 etherHistoryOctets Counter, --이력 전 체 바이트 수 etherHistoryPkts Counter, --이력 패 킷 수 etherHistoryBroadcastPkts Counter, --브로드 캐스트 패킷 수 etherHistoryMulticastPkts Counter, --멀티캐 스트 패킷수 etherHistoryCRCAlignErrors Counter, -- CRC 에러 횟수 etherHistoryUndersizePkts Counter, -- 최소 길이 미만의 패킷 수 etherHistoryOversizePkts Counter, -- 최대 길이를 초과한 패킷 수 etherHistoryFragments Counter, -- 패킷 분할 횟수 etherHistoryJabbers Counter, -- 잘못된 패킷 수 etherHistoryCollisions Counter, -- 충돌횟 수 etherHistoryUtilization INTEGER (0..10000) } --------------------------------------------------------------- · 보통 짧은 주기와 긴 주기를 갖는 두 개의 이력 제어 개체(history control entries)를 갖기를 권장한다. 일반적으로 30초의 짧은 폴링(short term polling) 주기와 30분의 폴링(long term) 주기를 갖는다. · 이력의 활용도(utilization)을 구하는 방법은 다음과 같다(96 : 프레임 간격 (interframe gap), 64 : 비트 초기화(bit preamble)). Utilization = (Packet×(96+64))+(Octets×8) Interval×10^{7 × 100% 경보(The Alarm Group) · 주기적으로 통계치를 확인한 후, 설정된 임계 치에 도달하면 이벤트를 발생 시켜 관리자에 보고한다. 이런 기록은 에이전트가 보유하고 있다. 기준치는 절 대값 및 상대값으로 정할 수 있고, 계속적인 경보 발생을 막기 위해서 상한치 와 하한치를 설정해서 넘나드는 경우에만 경보가 발생하게 한다. 그림 6을 참 조하기 바란다. · 경보 그룹은 이벤트 그룹을 구현하기 위한 필요조건이다. 호스트(The Host Group) · 송신지와 수신지 MAC 주소 리스트를 관리하면서 새 호스트를 발견한다. 각각의 주소에 대해서 통계치를 가지고 있으며 세그먼트에 연결된 각 장비가 발생시킨 트래픽, 오류 수를 호스트별로 관리한다. HostControlTable은 기능 (function)이 어떤 인터페이스에서 수행되는지를 제어하고 해당 프로세스에 관 한 정보를 유지한다. 그리고 하나의 인터페이스는 hostControlEntry에 각각 할 당되고, 수집되는 정보는 hostTable과 hostTimeTable에 저장된다. 각 테이블의 구조는 그림 7과 같다. · hostTable은 인터페이스에서 발견된 각각의 주소에 대한 개체를 갖고 있고, 각각의 개체 는 해당 호스트에 관한 통계 데이터를 갖고 있다. 이 테이블은 호스트의 MAC 주소가 키(key)가 된다. · hostTimeTable은 hostTable과 동일한 형태의 데이터와 호스트를 가지고 있 어야 한다. 하지만 테이블의 색인 키는 호스트 주소가 아니고 hostTimeCreationOrder를 이용하며, 발견 된 순서대로 엔트리를 테이블에 삽입한다. MAC주소를 사용하지 않고 순서 값 을 사용하기 때문에 다음 색인을 예상할 수 있으며 새로운 개체가 추가되었을 때 쉽게 발견할 수 있는 이점이 있다. 상위 N개의 호스트(The Host Top "N" Group) · 호스트 테이블에서 발견된 호스트 중에서 일정시간 동안 가장 많은 트래픽 을 발생시킨 호스트를 찾아 보고한다. 관리자는 보고하는 방법을 설정하기 위 해서 얼마나 많은 호스트를 보고할 것인지, 언제 샘플링을 시작하고 끝낼 것인 지, 원하는 종류의 자료(입/출력 패킷, 바이트, 외부 오류, 브로드캐스트/멀티캐 스트 패킷) 등과 같은 요소를 선택한다. 보고할 준비가 되면 hostTopNTable에 엔트리가 생성된다. 트래픽 매트릭스(The Matrix Group) · MAC 주소를 기준으로 그림 8과 같이 두 호스트간에 발생한 트래픽 및 오 류에 대한 정보를 수집한다. 이 정보를 이용해서 특정 호스트에 가장 많은 사 용자가 누구인지를 대략 알 수 있다(2회 연재에서 소개한 'e-Watch' 프로그램 을 사용해 호스트 쌍을 살펴본 경우). · 매트릭스 그룹은 matrixControlTable, matrixSDTable과 matrixDSTable로 구성된다. 이 테이블은 두 호스트 사이에서 통신하는데 대한 통계치를 저장한 다. 만약 수신한 패킷에 의해 새로운 통신 관계가 인지되면 매트릭스 테이블에 새 개체를 추가한다. · 매트릭스 그룹에서 사용하는 제어 테이블과 정보 테이블이 리스트 5와 같이 정의되어 있다. 리스트 5. 매트릭스 그룹의 제어 및 정보 테이블 정의 --------------------------------------------------------------- matrixControlTable OBJECT-TYPE SYNTAX SEQUENCE OF MatrixControlEntry ACCESS not-accessible STATUS mandatory ::= { matrix 1 } matrixControlEntry OBJECT-TYPE SYNTAX MatrixControlEntry ACCESS not-accessible STATUS mandatory INDEX { matrixControlIndex } ::= { matrixControlTable 1 } MatrixControlEntry ::= SEQUENCE { matrixControlIndex INTEGER (1..65535), matrixControlDataSource OBJECT IDENTIFIER, matrixControlTableSize INTEGER, --테이블 크기 matrixControlLastDeleteTime TimeTicks, --테이블이 삭제된 시간 matrixControlOwner OwnerString, --테이블 소유주 matrixControlStatus EntryStatus --테이블 상태 --------------------------------------------------------------- 필터(The Filter Group) · 관리자가 특정한 패킷의 동향을 감시하기 위해서 이용한다. 이를 이용해서 특정패킷의 발생 여부나 빈도를 알 수 있고, 경보와 사건 기능을 이용해서 임 계치를 초과하는 사건이 발생했음을 알 수 있다. · 필터에는 두 가지 종류가 있다. 먼저 데이터 필터(data filter)는 수신하는 데이터를 미리 정한 패턴과 비교한다. 그리고 상태 필터(status filter)는 패킷의 상태(valid, CRC, 길이)를 비교해서 패킷을 걸러낸다. · 필터링 정책에 따라서 필터는 여러 개의 채널을 가지게 된다. 한 채널에 관 계된 각각의 필터는 그림 9와 같이 AND로 묶고, 한 필터 내의 필터 내용들은 OR로 합성된다. 패킷 수집(The Packet Capture Group) · 망에 발생한 패킷을 수집해서 관리자가 분석할 수 있도록 한다. 관리자는 필터 그룹을 동일하게 구현하여 패킷의 전부 또는 일정한 길이만 보관하고 읽 을 수 있도록 패킷 수집 필터링을 설정할 수 있다. · 패킷 수집 그룹은 필터 그룹과 함께 구현되어야 한다. 수집된 패킷은 captureBufferTable 내의 엔트리에 저장된다. 이벤트(The Event Group) · 이벤트 그룹은 이벤트를 생성하고 통지한다. eventTable의 각 엔트리는 이 벤트의 파라미터를 기술한다. 트랩 발생 및 기록 보관은 선택적이다. 경보와 연 관되어 사건이 발생하면 사건 기록 및 트랩 발생은 관리자가 사전에 설정할 수 있다. 엔트리는 MIB 이외의 상황에 의해 발생할 수도 있다. 이벤트 발생의 예 는 그림 10과 같다. 예를 들어 채널이 활성화되거나 사라질 때도 이벤트가 발생한다. 이벤트가 발 생하면 그 곳에서 로그가 생성되기도 하고 SNMP TRAP을 이용하여 통지 메 시지가 전달될 수도 있다. 이런 경우 eventCommunity 객체에서 trap 메시지 를 위한 community를 제공한다. Enterprise and specific trap field는 이벤트가 발생하는 상황에 의해 결정된다. risingAlarm과 fallingAlarm 두 개의 trap이 정의되어 있다. 이벤트 정의 형태는 리스트 6과 같다. 리스트 6. 이벤트 정의 형태 --------------------------------------------------------------- eventTable OBJECT-TYPE SYNTAX SEQUENCE OF EventEntry ACCESS not-accessible STATUS mandatory ::= { event 1 } eventEntry OBJECT-TYPE SYNTAX EventEntry ACCESS not-accessible STATUS mandatory INDEX { eventIndex } ::= { eventTable 1 } EventEntry ::= SEQUENCE { eventIndex INTEGER (1..65535), eventDescription DisplayString (SIZE (0..127)), eventType INTEGER, //이벤트 종류 eventCommunity OCTET STRING (SIZE ( 0..127)), //이벤트에 사용 할 암호 eventLastTimeSent TimeTicks, //최근에 이벤트가 보 내진 시각 eventOwner OwnerString, //이벤트 소유주 eventStatus EntryStatus //이벤트 상태 } --------------------------------------------------------------- RMON 데이터의 활용 RMON을 이용해서 수집한 자료들은 다음 용도로 활용될 수 있다. 트래픽 패턴 분석 통계, 이력(history), 호스트, 매트릭스 그룹에서 수집한 자료를 이용해서 지정 한 서브네트워크에 대한 트래픽 패턴을 분석할 수 있다. 이를 사용해서 에러가 발생하는 원인을 유추해 낼 수 있으며, 시간대별 트래픽 분석자료는 로드 밸런 싱 등에 사용될 수 있다. 지능형 RMON 에이전트 RMON 에이전트가 에러나 충돌 등 네트워크 성능에 영향을 미칠 수 있는 자 료를 사전에 기록해서 발생한 문제에 대해 능동적으로 대처하게 한다. 이때는 경보와 이벤트 기능을 활용해서 임계치(threshold value)를 상황에 맞게 설정해 주는 것이 좋다. 네트워크 구성 변경 자료 통계, 매트릭스 자료를 사용해서 충돌이 많이 나는 장치를 재배치하거나 네트 워크 장비의 사용률에 따라 대역폭을 조정하는 근거로 사용될 수 있다. Web-based RMON 원거리에 있는 네트워크의 정보를 수집하기 위해서 RMON을 사용한다. 특정 관리 프로그램을 사용하여 에이전트로부터 정보를 얻어올 수도 있다. 하지만 각 PC에 RMON 관리자를 설치해야 하는 부담이 있다. 인터넷이 광범위하게 활용되고 있는 요즘에 웹 브라우저가 설치되지 않은 PC 는 거의 없다. 이 웹브라우저를 사용하여 RMON 에이전트의 정보를 얻어올 수 있다면 각 관리자들의 부담을 덜 수 있을 것이다. 관리자 기능을 수행하는 웹사이트를 접속하면 자바 애플릿이나 CGI프로그래밍을 이용하여 서버로부터 에이전트의 정보를 화면에 보여준다. 관리자가 접속한 웹 서버에는 에이전트로 부터 정보를 얻어와 제공해 주는 서버 프로그램이 대몬 프로세서로 수행되고 있어야 한다. 그림 11은 웹을 기반으로 해서 RMON이 동작할 수 있는 구조를 나타낸 것이다. RMON Agent와 RMON MIB는 기존의 관리 구조와 동일하다. 이 구조는 특정한 RMON 관리 소프트웨어가 필요없고 웹서버와 관리자 기능 을 하는 CGI나 애플릿이 서버에만 존재하면 가능하다. 각 PC마다 관리자 소프 트웨어를 설치하지 않고 웹서버에 있는 프로그램을 실행하고 결과인 통계 자료 만 받아서 브라우저에서 보여주기만 하면 된다. 이것은 CGI, Java, ActiveX 등 을 이용해서 구현할 수 있다. RMON 관련 라이브러리 libpcap 라이브러리 시스템과 독립적인 사용자 레벨의 패킷 캡쳐(capture) 라이브러리로서 다음 사 이트에서 구할 수 있다. ftp://ftp.ee.lbl.gov/libpcap-0.4.tar.Z 이것은 BSD 패킷 캡쳐 구조를 기반으로 만들어 졌다. ethernet, PPP 등 다양 한 네트워크에서 사용할 수 있는 소스가 있으며, promiscuous 모드로 동작해서 네트워크 모니터링을 하는 구조도 알 수 있다(pcap_snoop.c). libpcap 라이브러리는 4.4BSD, BSD/386, NetBSD, FreeBSD, DEC OSF/1, Linux, Solaris, SUNOS 등 대부분의 UNIX 시스템에서 사용할 수 있다. BPF(BSD Packet Filter), tcpdump BSD 기반의 패킷 필터로서 libpcap 라이브러리를 사용하는 프로그램이다. 동작 구조는 그림 12와 같이 Kernel 레벨에서 후킹을 사용해서 프로토콜 스택과는 별도로 지나다니는 패킷을 읽어들인다. 주어진 인터페이스에서 Multiple process도 모니터링 할 수 있으며, 각 프로세서는 자기만의 필터를 정의한다. 그림 12는 Network Monitor와 RARP daemon을 같은 네트워크 상에서 모니터 링 하는 것을 나타낸다. 현재 BPF의 기능은 tcpdump 프로그램 안에 내장되어 있다(tcpdump.2.2.1). 프 로그램은 다음 사이트에서 구할 수 있다. ftp://ftp.ee.lbl.gov/bpf 위 사이트에서는 이를 사용한 paper도 구할 수 있다. ftp://ftp.ee.lbl.gov/bpf/bpf-usenix93.ps ftp://ftp.ee.lbl.gov/bpf/bro-usenix98-revised.ps Beholder RFC1271의 RMON 초기 모델을 구현한 프로그램이다. 소스를 자유롭게 사용할 수 있으며 UNIX, Linux 등에서 사용할 수 있다. Beholder는 다음 사이트에서 구할 수 있다. ftp://dnpap.et.tudelft.nl/pub/btng 이외에도 상용 제품으로 RMON1과 RMON2를 지원하는 프로그램들이 출시되 어 있다. RMON mailing list RMON 메일링 리스트는 다음과 같다. rmonmib@cisco.com 이상으로 6회에 걸친 NMS 연재를 마치도록 하겠다. 지금까지 소개한 내용을 실제 네트워크 관리에 사용해 보기 바라며, 본 필자가 소개한 것 외에도 TMN 등 통신망 관리에 사용되는 개념들이 많이 있으니 참고하기 바란다.