#44u61l5f :: TCP 통신 차단 기법을 이용한 인터넷 서비스 차단 2

예제 프로그램 작성 및 테스트
TCP 패킷을 스니핑하고 RST 패킷을 송신하여 TCP 세션을 끊어 버리는 예제를 만들어 보자. 예제는 WinPcap 패킷 캡처 드라이버를 기반으로 하고 있기 때문에, 우선 WinPcap 사이트(http://winpcap.polito.it)에서 드라이버를 다운받아 설치하기 바란다.
예제를 컴파일하기 위해서는 델파이 환경에서 WinPcap을 사용할 수 있는 Snoop 컴포넌트를 설치해야 한다(http://www.snoopanalyzer.com). 드라이버와 컴포넌트가 설치되면 델파이에서 <화면 2>와 같은 폼을 작성하고 <리스트 1, 2, 3>에 있는 소스를 이용해 프로그램을 작성하도록 한다. 프로그램을 실행하여 <화면 3>과 같이 웹 브라우저를 실행하여 웹 사이트가 차단되는지를 확인해 본다. 예제는 이달의 디스켓을 참고하기 바란다.

원하는 패킷만 차단하기
WinPcap이라는 패킷 캡처 드라이버는 필터라는 기능을 제공하여 모든 패킷을 전부 스니핑하는 것이 아니라 자신이 원하는 패킷만을 스니핑할 수 있다. 이 필터 기능을 이용해 특정 서비스만을 차단할 수도 있다.

<화면 4>는 포트 번호가 4661번 및 4662번인 패킷만을 스니핑해서 P2P 서비스를 차단하는 예제를 보여 주고 있다. <표 3>에서는 유명한 인터넷 서비스에 대해 차단하거나 제한할 수 있는 간단한 필터들을 정리해 보았다. 이 필터들은 정확한 내용도 아니고 100% 차단되지는 않으며 대부분 필자의 경험적인 내용이다.

요즘 인터넷 서비스는 차단하는 방식을 우회하여 접속이 가능할 수 있도록 점점 지능화되어 가는 추세에 있기 때문에 단순한 IP나 포트 번호만을 판별해 차단하기는 점점 힘들어지고 있다. 특히 MSN 메신저 서비스는 접속이 불가능한 네트워크 환경인 경우 80번 포트(HTTP)까지 사용하기 때문에 단순히 IP나 포트 번호 정보만을 이용해서는 안 되며, 응용 프로그램 레이어의 내용까지 검토해 봐야 차단이 가능한 실정이다.

각종 인터넷 서비스 차단하기
지능화되어 있는 인터넷 서비스를 차단하려면 결국 각각의 서비스별로 별도의 프로그래밍을 하여 차단할 수밖에 없다. 가장 널리 쓰이고 있는 MSN 메신저를 예로 들어 간략하게 설명해 보고자 한다.
MSN 서비스는 우선 1863 포트 번호를 이용하여 서버에 접속을 시도한다. 1863 포트 번호를 이용하여 서버로 접속되지 않는 경우 다시 포트 번호 80번을 사용하여 접속을 시도하여 HTTP 프로토콜로 통신한다. 일반적으로 회사나 공공기관에서 HTTP 통신을 차단하기가 현실적으로 어렵다는 점을 이용한 것이다.
하지만 이런 경우에도 이 패킷이 일반적인 웹 통신인지 아니면 MSN 패킷인지를 구별할 수 있는 방법이 여러 가지가 있는데 가장 좋은 방법 중 하나가 User-Agent 값을 확인해 보는 것이다. MSN에서 HTTP 통신을 하는 경우 User-Agent 부분에 ‘MSN Messenger’라는 문자열이 포함되어 있다. 이 스트링이 포함된 HTTP 통신인 경우 RST 패킷을 보내는 방법을 이용하면 된다.
개인적으로 ‘회사에서 쓸려고 하는데 이런 서비스를 막아주는 프로그램 좀 만들어 주세요’라는 요청을 많이 받는 편이다. ‘단순히 IP나 포트로만 막을 수 없다면 결국에는 TCP 레이어 위에 있는 응용 프로그램 레이어의 내용까지 봐야 합니다’라고 응답을 하는데, 기본적인 TCP의 성격이나 전문적인 프로그래밍의 실력을 갖추고 있는 네트워크 관리자를 보유하고 있는 업체가 드문 편이라서 어려움을 많이 겪을 것이다. 이번 연재를 통해 네트워크 관리자들에게 조금이나마 도움이 됐으면 하는 바람이다. 연재와 관련된 프로그램 등의 자료는 필자의 개인 홈페이지(http://www.gilgil.co.kr)에 올려놓고 있으므로, 관심 있는 독자는 한번 들러주기를 바란다.
개인적인 생각으로 TCP/IP라는 프로토콜이 엉터리라고 보지는 않지만 오랜 기간을 거쳐서 충분히 검토되어 온 완벽한 프로토콜이라고 보기도 어렵다. 오히려 많은 네트워크 벤더들이 OSI 모델보다는 TCP/IP 모델을 기반으로 하는 제품들을 출시해 왔기 때문에 TCP/IP가 세계적으로 표준화된 프로토콜이 되어 버렸다고 보는 것이 맞을 것이다.
사실 내부적으로 보면 현재 잘 사용하지 않는 필드들도 있으며, 결국 이러한 필드 사용의 축적은 네트워크 장비를 복잡하게 하고 쓸모없는 네트워크 트래픽만을 야기한다고 해도 틀린 말은 아닐 것이다(큰 문제가 될 정도로 심각하지는 않지만). 그렇다고 해서 우리나라에서 TCP를 대처하는 새로운 프로토콜을 만들어 보자는 현실성 없는 얘기를 하는 것은 아니다.
IPv6 인터넷 환경은 점차 확산되고 있다. 새로 접해야 하는 표준 프로토콜에 대해 어떤 것이 옳고 그른지 판단하기 위해, 개선적인 방향으로 나아가기 위해, 이미 만들어진 그들만(?)의 프로토콜을 이해하기 위해 스니핑을 사용하는 행위 자체가 단지 해킹의 범주만은 아니라는 인식이 일반화되어야 한다는 것이 필자의 바람임을 조심스럽게 얘기해 본다.
정리 | 전만환 | mhjun@korea.cnet.com

연재를 마치며
3회에 걸친 JMX 연재를 마치게 됐다. 이번 호에 완성한 관리 시스템도 쓸만한 관리 시스템이 되기에는 아직 부족한 점이 많다. 여러 가지 에러 감지 기능이나 MBean의 기능을 사용하기 위해 다양한 메쏘드에 대해 파라미터를 넣을 수 있도록 하는 기능, MBean에서 주기적으로 알려오는 수치를 그래프로 표시하는 기능 등을 추가하면 좀 더 완성도 있는 관리 시스템이 되리라 생각한다.

정리 | 김세미 | semsem@korea.cnet.com

이+달+의+디+스+켓
JMX03.zip http://www.imaso.co.kr

참+고+자+료

? JINI 홈페이지 : http://wwws.sun.com/software/jini/
? JMX 홈페이지 : http://java.sun.com/products/JavaManagement/index.html
? Java Management eXtensions(JMX) Remote API 1.0 Specification : http://jcp.org/en/jsr/detail?id=160는 객체지향, 이벤트 처리 방식 모델을 제공한다. 객체라는 용어는 자바나 C++ 같은 프로그래밍 언어를 공부하면서 많이 들었을 것이다. 이 개념이 드라이버에도 적용되는 것이다. 객체는 WDF의 기본이 되는 것으로 드라이버, 장치, 큐 등을 나타낼 때 사용한다. 객체는 프로퍼티(properties), 메쏘드(methods), 이벤트(events)를 가진다.
프로퍼티는 오브젝트의 속성을 말하는 것으로 WDM의 객체 필드(object field)를 직접 접근하는 방식을 대체한다. 즉 드라이버는 ValueName WdfObjectGetValueName(WDFOBJECT Object)와 같은 형식의 함수들을 사용해 WDF 객체의 프로퍼티에 대한 값을 get/set한다.
메쏘드는 해당 객체에 대한 오퍼레이션을 수행한다. 예를 들면 WDF 기본 큐 객체(default queue object)를 생성하는 방식은 다음과 같다.

Status = WdfDeviceCreateDefaultQueue(Device, &attributes, &Queue);

객체의 이벤트는 드라이버에 여러 가지 상태 변화(state change)를 알려주는 방법이다. 즉 어떤 요청의 도착이라든지 시스템의 전원 상태(power state) 변화, 또는 인터럽트 등의 상태 변화가 발생할 때마다 프레임워크는 드라이버에 이벤트를 통해 알려준다.
이벤트는 객체의 각각의 종류에 영향을 줄 수 있다. 프레임워크는 각각의 이벤트를 위한 기본적인 행동이 정의되어 있다. device-specific 행동을 위해 드라이버는 기본값(defaults)을 재정의할 수 있는 콜백 루틴을 포함한다. 그리고 WDF의 각각의 객체는 WDM 드라이버의 장치 확장(device extension)과 같은 컨텍스트 메모리를 가질 수 있어 객체에 필요한 내용을 별도의 공간에 따로 저장해 둘 수도 있다.
객체는 몇 가지 특징을 가진다. 크게 ▲계층적인 구조를 가지고 부모와 자식처럼 관계를 가질 수 있고 ▲객체는 포인터가 아닌 핸들을 통해 기본적으로 접근이 이루어지며 ▲필요하면 WDM에서 사용했던 객체를 구할 수도 있다. 그렇기 때문에 WDF에서 사용되는 오브젝트를 이해하는 것은 그만큼 중요하다. 먼저 객체들은 어떤 것들이 있는지 살펴보자. 다음 핵심 객체들은 모든 드라이버에서 공통적으로 사용된다.

◆ WDFDRIVER, WDFDEVICE, WDFQUEUE, WDFREQUEST

부가적인 유틸리티 객체는 다음과 같다.

◆ WDFDPC, WDFWORKITEM, WDFTIMER, WDFDMAENABLER, WDFIOTARGET, WDFWMIDATABLOCK

WDFDRIVER 객체
WdfDriverCreate 함수에 의해 만들 수 있으며 WDF를 초기화한다. 다른 WDF DDI를 호출하기 전에 먼저 만들어야 한다. 기본적으로 WDFDRIVER 객체는 두 개의 이벤트를 제공한다.

◆ EvtDriverDeviceAdd : 드라이버가 지원하는 장치들이 감지(detect)될 때마다 호출되는 콜백 함수다.
◆ EvtDriverUnload(옵션) : 모든 WDFDEVICE가 다 제거되고 드라이버가 언로드될 때 호출된다. WDF에서 특별히 Unload 루틴을 등록할 일은 거의 없다..

WDFDEVICE 객체
WDM 드라이버 모델의 DEVICE_OBJECT를 포함하는 객체로서 대부분의 작업을 할 때 타켓이 되며 대부분의 WDF 객체의 부모 객체가 된다. FDO 또는 PDO로 설정할 수 있다.

WDFREQUEST 요청 객체
WDF에서 WDM의 IRP를 대신해서 표현하는 객체다. 이것은 I/O 요청으로 드라이버에 보낼 I/O 요청을 표현한다. 또한 드라이버에서 만들어 다른 드라이버에 I/O 요청을 보낼 수도 있다. 객체 프로퍼티는 IRP 필드들을 나타낸다. 다른 WDF 객체와 같이 참조 횟수(reference count)를 가지고 컨텍스트 메모리도 존재한다. 그리고 요청에 대해 완료될 때 자식들의 리소스들은 자동으로 해제된다.

WDFQUEUE 큐 객체
WDF로부터 드라이버에 요청을 큐잉(queuing)하거나 제공하는 객체로 세 가지 요청 동시성(concurrency) 모델이 존재한다.

◆ 직렬, 단일 요청 모델 : 기존의 Start I/O 모델과 같은 형태로 하나의 I/O 요청이 끝날 때까지 다른 I/O 요청은 큐에서 기다리는 형태다.
◆ 병렬 모델 : I/O 요청이 도착하면 바로 드라이버에 전달된다. 따라서 동시에 여러 개의 I/O 요청을 동시에 처리할 수 있게 된다.
◆ 수동 모델 : 드라이버가 원할 때 WDFQUEUE로부터 요청을 가져올 수 있다.

I/O 요청 처리와 파이프라인의 관계
WDF에서 요청이 처리되는 과정은 그 이전 WDM의 디스패치 루틴(dispatch routine)을 통한 처리 방식과는 여러 가지로 달라졌다. 논리적으로 여러 개의 스테이지(stage)로 구성되어 있는 파이프라인을 통해 흐르게 된다(<그림 3>). 드라이버에 이벤트를 알려주고 다음 스테이지로 요청을 보낸다. 그리고 자신들의 처리 결과에 따라 요청을 완료한다. 스테이지의 종류는 다음과 같다.

◆ PnP·전원 스테이지 : PnP와 전원 요청을 처리한다.
◆ WMI 스테이지 : 이벤트 추적(event tracing)을 포함해 WMI 요청을 처리한다.
◆ I/O 스테이지 : 대부분의 I/O 요청(open, close, clean up, Read, write, device I/O 제어)을 처리한다.
◆ I/O 타겟 스테이지 : 다른 드라이버에 요청을 보낸다.
이 중에서 우리가 가장 많은 관심을 가질 부분은 I/O 스테이지다. 이 부분은 WDM 드라이버 모델의 주 함수(major function) 코드 중에 애플리케이션 관련 부분의 디스패치 루틴과 같은 기능을 한다고 볼 수 있다. 내용은 예제를 통해 보면 쉽게 이해할 수 있을 것이다.

실습 예제
이번 호에서 살펴볼 예제(이달의 디스켓)는 간단한 WDF 커널 모드 드라이버의 골격만 가진 것으로 실제 하드웨어를 제어하는 작업은 하지 않는다. 대신 WDF 드라이버가 어떻게 처리하는지, 어떻게 객체를 가지고 처리하는지에 대한 내용을 보여주는 예제라고 보면 된다. 예제 컴파일은 기사의 컴파일 관련 부분을 따라하면 쉽게 컴파일을 할 수 있을 것이다. 드라이버 설치는 제어판의 새 하드웨어 추가 마법사에서 Hellowdf.inf 파일을 통해 설치할 수 있다.

기존 드라이버 모델의 개념을 숙지하자
우리는 지금까지 WDF라는 새로운 드라이버 개발 모델에 대한 내용을 살펴봤다. 현재 WDF는 피드백을 받아 업데이트되는 중이다. 앞으로 새로운 드라이버 개발 모델이 될 WDF는 드라이버 개발에 큰 변화를 불러올 것으로 본다. 대신 WDF 모델이 기존 드라이버 모델의 단점을 수용하다 보니 기존 드라이버 모델의 여러 개념을 숙지해야 정확히 이해할 수 있다는 것을 명심해야 할 것이다. 이번 호의 내용에 대해 궁금한 점이 있는 독자들은 데브구루(http://www.devguru.co.kr)의 질의 응답 코너를 이용해서 추가 정보를 얻기 바란다.

(0)

(0)

Posted by Dual

« 2012/02 »
Sun	Mon	Tue	Wed	Thu	Fri	Sat
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29

« 2012/02 »

Sun

Mon

Tue

Wed

Thu

Fri

Sat

Trackbacks List