[보안] 패킷 필터링에 대한 좋은글

패킷 필터링에 대한 좋은글  

      

  작성자 : 홍석범  

  작성일 : 2001/08/13 17:27  

  조회수 : 17  

        

  리눅스 월드 7월호에 실린글입니다.

작성 : 조대원

패킷 필터링을 위한 각 프로토콜과 인터넷 서비스 이해

* 1부 인터넷 서비스별 패킷 필터링 이해하기

이제 이 사회에서 인터넷에 관한 무엇인가를 전혀 듣지않고 산다는것은 거

의

불가능에 가까워졌다.

그정도로 인터넷은 우리의 사회에서 아주 대중화가 되었으며 신문, 뉴스

심지어는 패션잡지에서도 우리는 인터넷에 관해 언급하는것을 볼수가 있

다.

인터넷은 정보에 대한 혁신적인 기술적 진보를 가져다 주었으며 이로 인해

서

정보 접근의 방법에 혁명적인 방식을 제공하였다.

이러한 기술적 진보때문에 국가 단체, 연구소 그리고 일반 기업에서도 자

료를

인터넷에 연결되어진 컴퓨터에 저장 하기 시작했으며 이러한 정보를 자신

들의

필요에 따라서 거리적으로 멀리 떨어져 있는 곳까지 인터넷을 통하여 서

로

공유할수가 있었다.

하지만 모든 기술에는 순기능이 있으면 그것에 대한 역기능도 있는것처럼

인터넷은 또한 혁명적인 방식으로 개인, 또는 단체의 공개되어지기를 꺼리

는

정보를 훼손하고, 파손할 수 있는 능력을 제공하기도 한다.

이렇게 인터넷의 대중적 확산으로 일반 대중 매체가 인터넷의 매력에 취

해

있을때 기술 분야에서는 보안 문제로 주제를 옮겨가고 있으며, 이 문제에

사로

잡히게 되었고 이러한 문제를 해결하기위한 방안으로 방화벽이라는 개념

이

등장하게 되었다.

방화벽(Firewall)이란 본래 빌딩공사에서 불이 건물의 다른 부분으로 번지

는

것을 막기위해 설계된 것으로 컴퓨터에서 방화벽도 이와 유사한 원리로 설

계되어

진다.

컴퓨터 방화벽의 목적은 내부 네트웍과 인터넷 너머에 있는 외부 네트웍

을

분리하여 내부 네트웍과 외부 네트웍의 직접적인 연결을 통제, 차단하고

허가된

외부로 부터의 내부 접근과 내부로 부터의 외부 접근을 허용하는 것이다.

방화벽을 구성하는 방법에는 어떤 하드웨어를 사용 할 것인가, 어떤

소프트웨어를 사용 할 것인가, 어떤 인증 시스템을 사용 할 것인가에 따

라

여러가지 방법이 있지만 여기서는 이 모든 방화벽의 근간이 되며 꼭 방화

벽뿐만

아니라 개별 호스트 보안에서도 유용하게 사용되어 질 수 있는 패킷 필터

링에

대해 GNU/LINUX kernel 2.4에서 netfilter로 제공하는 iptables을 예로

GNU/LINUX Box에서 패킷 필터링 머쉰을 설게 할 수 있게 설명하고자 한

다.

여기서는 단순히 iptables을 사전식으로 설명하거나 iptables 스크립트를

설명하는 형식으로 글을 쓰지는 않을 것이다.

이 글의 주 목적은 각 인터넷 서비스별로 패킷 필터링의 특성을 이해하고

독자적으로 패킷필터링을 구축 할 수 있게끔 하는것이다.

물론 뒤에서 iptables 스크립트를 예제로 보이겠지만 ‘절대로’ 이 예제를

그대로 쓸 생각은 하지 말기를 바란다.

** 패킷 필터링을 지원하는 machine에서 공통적으로 고려되어져야 할 사

항

자세하게 들어가기에 앞서 기본적으로 고려되어야 할 사항을 먼저 간단하

게

언급하기로 하겠다.

패킷필터링을 설계하기전에 기본적인 보안 정책(-P)을 정해야만 한다.

1) 막아야 하는 연결을 제외하고는 모든 접근을 허용한다.(ACCEPT)

2) 허용하는 연결을 제외하고는 모든 접근을 막는다.(DROP)

이는 전체 보안 정책과도 일맥상통한다.

사용자과 경영자의 입장에서는 보안이라는 관점을 제대로 이해 할 수가 없

기

때문에 1) 정책이 더욱 명확하게 보일것이다.

하지만 보안이라는 관점에서 본다면 명확하게 디폴트가 거부인 방침이 올

바른

선택이 될 것이다.

보안의 관점을 제대로 이해하지 못하는 사용자와 경영자를 설득하는 것도

어떻게

보면 관리자의 업무중에 하나라고 볼 수도 있을것이다.

허가되지 않은 초기 접속 요구(–syn 옵션)를 차단한다.

초기 접속 요구라는 것은 tcp protocol 에만 존재하는 제어 신호 bit로-

SYN

패킷이라 부르고 SYN 플래그가 설정되어있으며 FIN, ACK 플래그는 설정되

지 않은

패킷을 말한다. udp에는 이 제어 신호 bit가 없다. 자세한 사항은 tcp/ip

서적을

보기 바란다- 이 bit가 들어 있는 패킷이 임의 포트로 들어온다는 것은 외

부에서

tcp protocol로 컴퓨터에 접속을 시도한다는 의미이다.

이 제어 신호 bit가 허용되지 않는다면 그 다음에 도착하는 패킷들은 모

두

버려진다.

예를 들어 외부 서버에 대한 내부 클라이언트 접속은 허용하면서 패킷 필

터링

머신에서 작동 중인 내부 서버에 대한 외부 클라이언트 접속은 허용하지

못하도록 했으면 할 때가 있다.

이를 위한 자연스런 방법은 서버로 들어오는 TCP 패킷을 모두 봉쇄하는 것

이다.

하지만 TCP접속은 양방향이므로 한쪽 접속을 봉쇄한다면 나가는 접속을

허용한다고 하더라도 그 접속 자체가 의미가 없어진다.

이에 대한 해결책으로서 초기 접속 요구 패킷만 봉쇄하는 방법을 사용한

다.

이 초기 접속 요구 제어 비트는 위에서 보인 예처럼 TCP접속을 한 방향으

로만

허용할 필요가 있을때나 허가 되지 않은 서비스로의 모든 TCP 접속, 특정

주소에서 오는 모든 TCP 접속을 거부할때 패킷 필터링에서 유용하게 사용

될수

있다.

이 초기 접속 요구가 들어 있는 패킷의 허용과 거부의 결정이 보안에 상당

한

영향을 미칠 수가 있기때문에 패킷 필터링을 설계 할 때 이 초기 접속 요

구에

관한 허가와 거부의 결정은 특별히 신경을 써야 한다.

참고

———————————————————————

–

tcp는 접속 기반(connection-oriented) 프로토콜이다.

tcp는 각 호스트가 통신하기 전에 먼저 통신하는 호스트 사이에

종단간의(end-to-end) 접속을 만든다.

이 종단간의 접속을 만들기 위해 handshake라 불리는 제어 정보가 전송되

고

이 제어 정보에 대한 응답을 받음으로 종단간의 접속이 이루어진다.

tcp가 사용하는 handshake의 종류에는 세 개의 제어 정보가 교환되기 때문

에

3단계 handshake(Tree-way handshake)라 불린다.

Host A Host B

|————–| |————–|

| SYN —|—————————|——| |

| | | v |

| | | SYN.ACK |

| | | | |

| |——|—————————|——- |

| v | | |

| ACK.data | | |

| | | | |

| ——-|————————-> | 데이타전송 |

|————–| |————–|

위에 그림은 3단계 handshake의 가장 간단한 형태를 보여준다.

호스트 A는 호스트 B로 “Synchronize sequence numbers(SYN)” 비트를 설정

한

제어 정보를 보내면서 접속을 요구한다.

이 제어 정보는 호스트 B에게 A가 접속을 시작하기를 바라고 있음을 알려

주고,

호스트 A가 그들의 시작 번호로 어떤 일련 번호(sequence number)값을 사

용할

지를 알려준다.

호스트 B는 A에 “Acknowledgment(ACK)”와 SYN 비트가 설정된 제어 정보를

보내는

것으로 응답한다.

B의 제어 정보는 A의 제어 정보를 받았음을 알리고, 호스트 B가 사용할 시

작

일련 번호를 A에 알려 준다.

마지막으로, 호스트 A는 B의 제어 정보를 받았음을 알리는 제어 정보를 보

내고,

첫번째 실제 데이타를 전송한다.

———————————————————————

–

1023 이하의 포트에서 돌아가는 데몬들은 특별히 신경을 써야 한다.

0-1023 포트는 루트에 의해 운영되는 데몬이 사용하도록 예약되어 있다.

우리가 익히 들어 알고 있는 데몬-웹 서버, 메일 서버, 도메인 네임 서

버, ssh

서버, 텔넷 서버…-들은 대부분 루트의 권한으로 0-1023 포트에서 시작된

다.

보통 1023 이하 포트에서 운영되는 데몬 프로그램은 위에서 말한 초기 접

속

신호에 반응하여 접속을 요구하는 상대편 클라이언트나 또는 다른 서버에

응답을

하게 된다.

즉 1023 이하 포트에서 운영되는 서비스를 허가 한다는것은 일종에 패킷

필터링에 허가된 틈구멍을 낸다는 말과 같다.

그렇기때문에 정말 필요한 서비스에 한에서만 심사숙고 하여 제한된 범위

에서

허가를 해야 할 것이다.

1023 이상 포트는 클라이언트 프로그램이 서버와 접속을 할때 랜덤하게

선택되어져 사용된다.

그렇기때문에 0-1023 포트처럼 중요하게 생각되지 않을 수도 있다.

그러나 몇몇 보안에 위험한 데몬들은 이 상위 포트에서 운영이 되기때문

에 이

1023 상위 포트 역시 초기 접속 신호등 주위 깊게 신경을 써야 할 것이

다.

** 패킷 필터링시 고려되어져야 할 각 protocol 특성

여기서는 각 프로토콜별로 패킷 필터링에서 고려되어져야 할 특성들을 알

아보고

각 패킷 필터링 시스템마다 틀린 순서에 의한 규칙 적용을 알아 보겠다.

*** TCP

tcp는 인터넷 서비스에서 가장 공통적으로 사용되는 프로토콜이다.

tcp는 두 종단간에 신뢰성 있는 양방향 접속을 제공한다.

서버는 동일한 접속을 통해 클라이언트에 응답을 할 수 있다.

즉 질의나 응답을 위해 클라이언트가 서버로 하나의 접속을 설정하면 서버

에서

클라이언트로 회신을 하기 위해 또 다른 접속을 설정 할 필요가 없다.

tcp 접속을 차단 하려면 위에서 초기 접속 요구를 설명 할 때 말한것 처

럼 단지

접속의 첫번째 패킷만을 차단하면 된다.

이 초기 접속 요구가 들어있는 패킷이 차단되면 그 접속에서 뒤에 오는 어

떤

패킷도 데이터 스트림으로 조립될수가 없다.

만일 패킷 필터링을 제공하는 라우터를 구입 할 경우 그 machine이 tcp 초

기

접속 제어 신호 bit를 제어 할 수 있는가 없는가가 구매의 중요 요인으로

작용

할 수 있을것이다.

패킷 필터링에서 초기 접속 요구 tcp 패킷을 제어 할 수 있으면 내부 클라

이언트

프로그램은 외부 서버로 접속을 허용하고 외부 클라이언트는 내부 서버로

접속을

차단 할 수가 있다.

이는 초기 접속 요구 tcp 패킷이 단지 아웃바운드되는 것만을 허용하고

인바운드되는 것을 허용하지 않으면 된다.

공격자는 초기 접속 요구 패킷의 제어 bit를 속임으로 이 패킷 필터링을

피해가기란 tcp 프로토콜 특성상 상당히 어렵다.

*** UDP

udp는 적은 오버헤드를 가진 tcp의 대안이다.

udp는 tcp와 같이 신뢰성 있는 양방향 접속을 제공하지 못한다.

따라서 tcp와 같은 신뢰성 보장을 위한 알고리즘이 필요가 없기때문에

오버헤드가 적다.

udp 패킷은 구조에 있어서 tcp 패킷의 구조와 아주 유사하다.

udp 패킷 헤더에는 tcp와 마찬가지로 출발지 주소, 목적지 주소, 출발지

포트

번호, 목적지 포트 번호등을 포함하고 있다.

하지만 udp는 tcp와 같은 초기 접속 요구 제어 비트를 가지고 있지 않다.

초기 접속 요구 제어 비트는 신뢰성 있는 데이터 전송을 보장하기 위한

tcp

알고리즘의 일부분이다.

그렇기때문에 패킷 필터링 시스템은 들어오는 udp패킷 헤더를 조사하여

그

패킷이 외부 클라이언트에서 내부 서버로 들어오는 첫번째 패킷인지, 또

는 외부

서버에서 내부 클라이언트로 회신되는 응답인지를 결정 할 방법이 없다.

물론 일부 상용 방화벽 제품에는 외부로 나가는 udp 패킷을 기억하는 능력

을

가지고 있어 이에 대응하는 응답 패킷만을 허용하는 메카니즘을 제공하기

도

한다.

하지만 여기서는 리눅스 패킷 필터링 시스템만을 다루것이므로 이 문제는

여기서

넘어가기로 하겠다.

서비스중 보안에 취약한 서비스-RPC기반 서비스들-대부분이 UDP기반으로

서비스가 된다.

이때문에 인바운드되는 UDP기반의 패킷은 엄격하게 통제되어야만 한다.

*** ICMP

icmp는 IP 상태와 제어를 위해 사용되는 프로토콜이다.

icmp는 tcp나 udp와는 달리 출발지 또는 목적지 포트가 없다.

대신 정의된 icmp메시지 유형 코드의 집합이란것이 제공된다.

패킷 필터링 시스템은 이 icmp의 메시지 유형 필드를 보고 icmp 패킷을 필

터링

하게된다.

icmp 메시지 유형

echo-reply (pong) – 0 : 호스트가 echo-request에 응답하는 것

destination-unreachable – 3 : 패킷이 목적지에 도달 할 수 없을때

사용하는 신호

source-quench – 4 : 송신측에 전송 속도를 늦추라는 신호

redirect – 5 : 호스트에게 라우터가 보내는 신호

echo-request (ping) – 8 : ping을 실행 할 때 호스트가 보내는 신호

time-exceeded (ttl-exceeded) – 11 : traceroute에서 사용하는 신호

parameter-problem – 12 : 패킷 헤더에 문제가 생겨 헤더를 전달

할 수 없을때 보내는 신호

icmp는 인바운드와 아웃바운드에 따라 허용하고 차단하여야 할 것이 경험

상 거의

정해져 있다고 할 수 있다.

인바운드

echo-reply : 허용(ping에 대한 응답 신호)

destination-unreachable : 허용(나가는 traceroute 탐침에 대한 응답 신

호)

source-quench : 허용

redirect : 거부

echo-request : 거부

time-exceeded : 허용(나가는 traceroute 탐침에 대한 응답 신호)

parameter-problem : 허용

아웃바운드

echo-reply : 거부(ping에 대한 응답을 할 필요가 없음)

destination-unreachable : 거부(내부 네트웍을 조사하는 데 도움을 줄

수 있다)

source-quench : 허용

redirect : 허용

echo-request : 허용(ping을 사용하기 위해)

time-exceeded : 거부(들어오는 traceroute 탐침에 대한 거부)

parameter-problem : 허용

필터링 정책에 위반되는 모든 패킷에 대해 ICMP오류코드

-destination-unreachable-를 회신한다는 것은 공격자가 당신의 필터링 시

스템을

탐침할 수 있는 기회를 부여하게 될 것이다.

일반적으로 좋은 결과를 예상 할 수 있을때만 icmp 메시지를 허용하는 것

이

좋다.

*** RPC

사실 RPC(Remote Procedure Call)는 엄밀히 말하면 IP 그 자체가 아니라

TCP 나

혹은 UDP에 기반한 서비스이다.

하지만 TCP 와 UDP 처럼 RPC도 NFS,NIS같은 다양한 애플리케이션 프로토콜

에

의해 범용 전송 프로토콜처럼 사용된다.

그렇기때문에 다른 프로토콜과 같이 여기서 RPC기반의 서비스 특성을 알아

보도록

하겠다.

NFS,NIS같은 RPC기반의 서비스들은 네트웍 보안의 관점에서 본다면 상당

히

취약한 서비스이다.

NFS 서버에 엑세스 권한 획득 한 공격자는 시스템에 있는 어떠한 파일도

읽을

수 있으며 NIS 서버에 대한 엑세스 권한 획득 한 공격자는 패스워드 파일

을 얻어

그것을 근거로해서 패스워드 크랙킹 공격같은 2차 공격의 수단을 얻을 수

있다.

그래서 RPC 기반의 서비스들은 공격자들에게 가장 매력이 있는 공격 대상

이 되며

관리자들에 있어서는 보안 설정에서 가장 신경을 써야 할 서비스이다.

이렇게 보안의 관점에서 상당히 위험한 서비스임에도 밑에서 설명을 하겠

지만

패킷 필터링을 적용하는데 상당한 어려움이 따른다.

그럼 먼저 RPC의 특성을 알아보고 어떤점이 패킷 필터링을 어렵게 하는지

알아

보도록 하겠다.

TCP와 UDP 패킷 헤더에는 프로토콜 포트 번호를 나타내기 위해 2바이트 필

드를

가진다.

이는 TCP와 UDP 를 위해 할당된 포트 번호가 65,536개만 가능하다는 것을

나타낸다.

이 포트 번호는 현존하는 모든 서비스와 애플리케이션 각각에 교유한 포

트

번호를 부여 할 수 있을만큼 그리 충분한 수는 아니다.

RPC는 이러한 한계를 해결하기 위해 각각의 RPC기반 서비스에 고유한 4바

이트

“RPC 서비스 번호”를 부여 함으로 tcp와 udp에서의 포트 번호 부족 문제

를

해결하였다.

이것은 4,294,967,296개의 포트 번호를 가질 수 있으며 서로 다른 서비스

가 이

각각의 고유한 포트 번호를 부여 할 수 있다.

그런데 위에서도 말한것 처럼 RPC는 TCP와 UDP 위에서 구축이 되는 서비스

이다.

그렇기때문에 RPC 서비스 번호는 RPC에서만 통용이 되는 서비스 번호일뿐

RPC기반에 서비스가 실질적으로 서비스되어지기 위해서는 RPC 서비스 번호

를

특별한 TCP 혹은 UDP 포트에 매핑하는 방법이 필요하며 이 매핑 방법을 제

공하는

것이 포트매퍼(portmapper)라 불리는 서버이다.

RPC관렬 서버중에서 이 포트매퍼가 유일하게 특별한 TCP 혹은 UDP 포트

번호-포트 번호 111을 사용한다-에서 실행되도록 보장된 서버이다.

RPC기반의 서비스에서 서버와 클라이언트가 서로 접촉하는 방법을 보면

NFS 와

NIS와 같은 RPC기반의 서버를 시작하게 되면 그것은 스스로 임의의 TCP 혹

은 UDP

포트를 할당한다.

그리고 RPC기반의 서버들은 포트매퍼 서버에 접속하여 자신이 가지고 있

는

고유한 RPC 서비스 번호를 서버가 시작되면서 임의로 할당한 TCP 혹은

UDP 포트

번호와 매핑을 시킨다.

그 후 NFS 나 NIS등 RPC기반의 서버에 접촉하고자 하는 RPC기반의 클라이

언트

프로그램은 자신이 접속 할 서버가 RPC 서비스 번호를 어떤 임의의 포트

번호에

할당했는지를 모르기때문에 먼저 그 컴퓨터에 있는 포트매퍼 서버에 접촉

한다.

포트매퍼는 액세스하고자는 하는 서버의 고유한 RPC서비스 번호를 말하며

접촉하는 클라이언트에게 현재 그 RPC기반의 서버가 매핑되어 있는 TCP 혹

은

UDP 포트 번호로 응답을 하게 된다.

그리고 클라이언트는 포트매퍼로부터 얻은 포트 번호에서 그 서버와 접촉

을 하고

나중에는 포트매퍼의 개입이 없이 직접적으로 그 서버와 대화를 계솎 할

수

있다.

참고

———————————————————————

–

실제로 NFS서버의 대부분은 포트 2049를 사용한다.

하지만 NFS가 모든 방식에서 항상 그 포트를 사용할 것이라고는 추측할 수

는

없다.

RFC 1094인 NFS 프로토콜 규약에서도 “NFS 프로토콜은 현재 UDP포트 번호

2049를

사용한다.

이것은 공식적으로 부여된 포트가 아니다. 따라서 프로토콜의 이후 버젼

은 RPC

포트매핑 기능을 사용한다” 라고 되어 있다.

———————————————————————

–

위의 설명을 보면 알겠지만 RPC 기반의 서비스는 서버가 처음 시작하여 임

의로

할당한 TCP 혹은 UDP 포트 번호를 포트매퍼를 통해 자신이 가지고 있는 고

유한

RPC 서비스 번호와 매핑을 시키는 것과 클라이언트가 포트매퍼에 접속을

하여

서버가 임의로 할당한 포트 번호를 알아서 다시 그 포트 번호로 서버와

통신한다는 점만을 빼면 그 후에 통신을 일반 TCP나 UDP 통신과 틀리지 않

다.

그런데 이 포트 매핑이란 방식이 그 서비스가 사용 할 포트가 항상 고정되

어

있는것이 아니라 컴퓨터가 재부트될때마다 매번 변경되기 때문에 RPC 기반

의

서비스를 패킷 필터링으로 통제하기란 매우 어렵다.

단순히 포트매퍼에대한 접속만을 차단하는걸로는 충분하지가 않다.

이미 포트 매핑이 이루어지 상태에서 공격자는 포트매퍼로 접속하는 단계

를

건너뛰고 공격하기 위한 RPC서버로 부터의 응답을 기대하면 모든 TCP 혹

은 UDP

포트로 접촉-이를 포트 스캔이라고 한다-을 시도 할 수 있기때문이다.

참고

———————————————————————

–

RPC 기반의 서비스를 보호하기 위해 포트매퍼의 차단만으로는 충분하지 않

지만

일부 포트매퍼는 공격자의 클라이언트를 위해 프락시로 사용될 수 있는 가

능성이

존재하기 때문에 여전히 허가되지 않은 접속으로 부터 보호되어져야 한

다.

———————————————————————

———-

그렇다면 RPC 기반 서비스를 보호하기 위한 방법으로 무엇이 있을까?

가장 좋은 방법은 RPC기반 서비스를 사용하지 않는것이다.

하지만 만약 RPC기반의 서비스를 사용하여야 한다면 모든 외부 네트웍으

로

부터 DNS,NTP등 UDP를 사용하는 몇몇 서비스를 위해 특별하게 엄격히 통제

된

허가를 제외하고는 모든 UDP프로토콜을 차단하는 방법으로 RPC기반의 서비

스를

보호해야 할 것이다.

경험적 관찰에서 대부분의 위험한 RPC기반의 서비스는 오직 UDP를 통해서

만

제공되고 있다고 판명되었기 때문이다.

** 인터넷 서비스별 특성 이해와 패킷 필터링 구축

우선 간단하게 iptables의 옵션을 알아보도록 하겠다.

이 문서는 iptables의 howto문서가 아니기때문에 가장 기본적인 옵션만을

간단하게 소개하기로 하겠다.

자세한 사항은 man 페이지나 netfilter homepage

를 확인해보기 바란다.

———————————————————————

–

-N : 새로운 체인 만들기

-X : 비어있는 체인을 제거하기

-P : 미리 만들어진 체인의 정책을 바꾸기

-L : 어떤 체인의 규칙들을 나열하기

-F : 체인으로부터 규칙들을 지우기

-Z : 체인내의 모든 규칙들의 패킷과 바이트의 카운드를 0 으로 만들기

-A : 체인에 새로운 규칙을 추가하기

-I : 체인의 어떤 지점에 규칙을 삽입하기

-R : 체인의 어떤 지점의 규칙을 교환하기

-D : 체인의 어떤 지점의 규칙을 제거하기

-D : 체인에서 일치하는 첫번째 규칙을 제거하기

-s : 출처 주소

-d : 목적지 주소

-p : 프로토콜(tcp, udp, icmp)

-i : 패킷이 들어오는 인터페이스 ( input, foward )

-o : 패킷이 나가는 인터페이스 ( foward, output )

-f : 분절

-j : 점프

–syn : 밑에서 자세히 설명하겠음

–dport : 목적지의 포트 정의

–sport : 출발지의 포트 정의

———————————————————————

–

iptables는 먼저 등록 된것이 효력을 발생한다.

모든 것을 거부하는 설정이 먼저오게 되면 나중에 포트를 여러주는 설정

이 와도

효과가 없다.

그러므로 허용하는 정책이 먼저오고 나중에 거부하는 정책이 와야 한다.

잘못된 예)

iptables -A INPUT -p tcp –dport 0:1023 -j DROP

iptables -A INPUT -p tcp –dport 80 -j ACCEPT

이 겨우 먼저 1023 밑에 포트를 모두 거부하고 다음에 80번 포트를 열어주

는

설정 이다.

하지만 이 설정은 먼저 온 거부 설정때문에 패킷이 이미 거부된 상태여서

효력이 없다.

올바른 예)

iptables -A INPUT -p tcp –dport 80 -j ACCEPT

iptables -A INPUT -p tcp –dport 0:1023 -j DROP

만약 컴퓨터가 NIC가 2개 달린 게이트웨이고 내부 네트웍이 사설 ip로 운

영이

된다면 -i, -o 옵션으로 NIC를 지정하여 패킷 필터링을 설정하는것이 좋

다.

게이트웨이에서 출발지 주소와 출발지 포트로만 패킷 필터링을 하게 된다

면

사설 IP를 가장하고 들어오는 위조된 패킷을 감지하는데 취약점을 갖는

다.

그러나 NIC에 의한 패킷 필터링을 함으로서 패킷 필터링 머신이 위조된 패

킷을

감지할 수 있다.

*** SMTP

인터넷 서비스의 가장 기본이 되는 서비스가 아닐까 한다.

하지만 메일 서버는 임의의 호스트에서 임의의 데이터를 받는 서비스이기

때문에

불행히도 상당히 위협을 받는 서비스 중 하나이다.

서버는 외부의 임의의 호스트로 부터 메일 전달과 관련된 명령을 직접 받

는다.

이는 서버가 안전하지 않으면 잘못된 퍼미션을 공격자에게 모두 허용할 수

가

있다는 말이다.

또한 메일 서버가 수신한 메일을 임시 저장소인 수신 큐에 저장 하면 중

간

전달 대리인-procmail같은-은 이를 사용자 mail함에 써 넣어야 하기 때문

에

특별한 권한을 필요로 한다.

물론 전달 대리인이 외부와 직접 통신을 할 필요는 없으나 역시 전달 대리

인이

잘못될 경우 공격자의 불법적인 엑세스를 허용하게 된다.

그리고 가끔 수신되 데이터에 대해 원하지 않는 내부 프로그램을 실행시

킬 수

있다.

메일 서버에 대한 공격으로 크게 3가지 방법이 있다.

명령 채널 공격 : 서버는 외부와 통신을 하기때문에 외부에서 악의를 가

진

공격자는 명령으로 공격을 할 수가 있다.

데이터 위주 공격 : 복잡하고 공격하기 위한 사전 정보도 얻기가 어려워

다른

공격 방법에 비해 그리 많은 편은 아니지만 전달 대리인이 메시지 내용으

로

위협을 받을 수 있다.

명령행 버그 : 명령을 수행할 수 있는 사용자의 잘못된 사용을 유도하는

공격이다.

이 모든 공격을 패킷 필터링만으로는 완벽하게 막을 수 있는 방법은 없

다.

최선의 방법으로는 방화벽을 구성하여 패킷 필터링과 더불어 메일 게이트

웨이

서버와 내부 메일 서버를 따로 두어 실질적인 메일 서버인 내부 메일 서버

와

외부 호스트가 직접 통신을 못하도록 막는것이 좋은 방법일것이다.

SMTP는 TCP 기반의 25번 포트를 사용하는 서비스이다.

SMTP 송신자는 1023 이상의 포트 번호를 랜덤하게 선택하여 사용한다.

서버로 들어오는 메일

iptables -A INPUT -P tcp ! –sport 0:1023 –dport 25 -j ACCEPT

iptables -A OUTPUT -p tcp –sprot 25 -j ACCEPT

클라이언트에서 나가는 메일

iptables -A OUTPUT -p tcp –dport 25 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 25 ! –dport 0:1023 -j

ACCEPT

*** pop

SMTP가 서버와 서버 사이에 메일을 교환하는데 사용되는 프로토콜이라면

POP는

개인 사용자의 메일함이 있는 컴퓨터의 클라이언트와 실질적으로 메일을

받아

들이는 메일 서버가 통신하는 프로토콜이다.

이 서비스는 특히 사용자의 컴퓨터가 가끔 네트웍에 연결되어지는 경우에

유용하게 사용된다.

인터넷을 통해 POP 서비스를 사용할 때 인증에 대한 중요한 보안 문제가

있다.

표준 POP 클라이언트는 패스워드를 클리어 텍스트로 서버에 보내게 된다.

이는 패킷 스니핑의 위험이 있으면 대부분 POP 패스워드는 로그인 패스워

드가

같기 때문에 이를 스니핑 한 공격자는 메일이 아닌 사용자의 권한을 얻을

수가

있다.

물론 kerberos나 일회용 패스워드를 지원하는 POP도 있지만 이는 많이 사

용되고

있지 않으며 이런 변형된 클라이언트와 서버를 찾는것도 그리 수월한 일

은

아니다.

만약 이러한 스니핑이 걱정이 되거나 메일 송수신에 암호화의 방법이 없다

면

사용자가 인터넷을 통해서 POP 서버에 접속하는것을 허가하면 않된다.

pop 서버는 pop2(포트 번호 109)와 pop3(포트 번호 110)가 있는데 현재는

pop3가

가장 일반적으로 사용된다.

pop는 TCP 기반의 서비스이며 클라이언트는 1023 이상의 포트 번호를 랜덤

하게

선택하여 사용한다.

pop 서버로 들어오는 접속

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 110 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 110 -j ACCEPT

클라이언트에서 pop 서버로 나가는 접속

iptables -A OUTPUT -p tcp –dport 110 -j ACCEPT

iptables -A INPUT -p tcp ! –syn -sport 110 ! –dport 0:1023 -j

ACCEPT

*** FTP

FTP(File Transfer Protocol)은 예전부터 인터넷에서 ascii, 텍스트, 포스

트

스크립트, 사운드, 비디오 파일등과 같은 여러가지 유형의 파일을 전송하

는 데

사용하는 프로토콜이었습니다.

요즘은 웹에 밀려 그 사용이 많이 줄은 감이 있지만 아직도 인터넷에서 파

일

전송의 실질적인 표준으로 자리 잡고있는 프로토콜이다.

하지만 패킷 필터링 구현시 FTP 구현 메카니즘의 문제로 보안의 문제점을

가지고

있다.

여기 이 문제점을 알아보고 이 문제점에 대한 해결방법을 알아 보도록 하

자.

FTP는 클라이언트와 서버사이에 명령과 결과를 전달하기 위해 포트 21번

을

사용하는 “명령 채널” 접속과, 실제 파일과 디렉토리 목록을 전달하기 위

해 포트

20번을 사용하는 “데이타 채널” 이라는 두 가지 분리된 TCP 접속을 사용한

다.

클라이언트는 다른 서비스와 마찬가지로 명령과 데이터 채널 모두 1023번

이상의

포트를 사용한다.

그럼 실제 접속이 이루이지는 과정을 그림과 같이 설명해보겠다.

FTP 세션이 시작되면 클라이언트는 서버에 접속하기 전에 명령과 데이터

채널 두

개에 1023번 이상의 자체 포트를 할당한다.

이 두 포트중 하나는 먼저 서버와 명령 채널 접속을 위해 사용되고, FTP

의 포트

명령으로 서버에게 클라이언트가 데이터 채널을 위해 자체 할당한 두 번

째 포트

번호를 전달한다.

그리고 나면 서버는 데이터 채널 접속을 위해 클라이언트가 알려온 데이

터

채널로 초기 접속을 시도한다.

이 데이타 채널 접속은 위의 다른 서비스에서 보인것처럼 클라이언트가 서

버에

접속을 하고 응답을 받는게-이 상태에서는 클라이언트가 서버에게 SYN 플

레그가

있는 초기 접속 패킷을 받을 필요가 없다.위의 다른 서버스의 경우 초기

접속은

클라이언트에서 하고 서버는 이에 대한 응답만을 한다.- 아니라 클라이언

트가

서버로 접속을 요청하면 요청을 받은 서버가 클라이언트로 데이터 채널을

개방하기 위해 SYN 플레그가 있는 초기 접속 패킷으로 접속을 시도한다.

이를 후위(backwards) 접속이라고 하는데 이런 접속은 내부에서 외부로의

TCP

접속은 보장하고 외부에서 내부로의 접속을 차단하는, 단방향 접속을 위

해 “접속

시작 단계” 패킷 필터링을 시도하는 사이트를 상당 곤란하게 만든다.

이유는 내부 클라이언트의 접속에 대한 응답으로 외부 FTP서버는 내부

클라이언트에 초기 접속을 시도 해 오기때문이다.

밑에 그림은 이러한 FTP접속의 단계를 잘 보여주고 있다

일반 FTP 접속 모드

FTP 서버 FTP 클라이언트

———– ———–

| | | |

| | | |

| | | |

| 20 21| |5150 5151|

–|—–|– –|—–|–

| | 1: 포트 5151 | |

| |<—————————————-|

| | | |

| | 2: OK | |

| |———————————->| |

| | | |

| | 3: 데이터 채널 | |

|———————————————->|

| | | |

| | 4: 수신 확인 | |

|<———————————————-|

| | | |

1: 클라이언트는 서버에 대한 명령 채널을 열고 서버에게 두 번째 포트 번

호를

말한다.

2: 서버는 수신 여부를 확인한다.

3: 서버는 클라이언트의 두 번째 포트에 대한 데이터 채널을 연다.

4: 클라이언트는 수신 여부를 확인 한다.

이러한 보안의 문제점때문에 대부분의 FTP 서버와 많은 FTP 클라이언트는

다른 서비스들 처럼 클라이언트가 서버에 명령과 데이터 채널을 개방하도

록

허용하는 모드를 지원한다.

이 말은 명령과 데이터 채널 개방을 위해 클라이언트에서 서버로 초기 접

속을

시도하고 서버는 이에대한 응답만을 한다는 것이다.

이런 모드를 “수동 모드(passive mode)” 도는 “PASV mode” 라고 한다.

FTP 클라이언트와 FTP 서버 모두가 수동 모드로 연결을 시도한다면 일반

모드

대신에 수동 모드로 접속을 할 수 있고 이렇게 함으로써 모든 접속은 내

부

클라이언트에 의해 개방이 되기 때문에 접속 시작 단계 필터링 문제를 피

할 수

있다.

그럼 실제 접속이 이루이지는 과정을 그림과 같이 설명해보겠다.

수동 모드로 클라이언트가 접속을 시도하면 처음에는 일반 모드에서처럼

자신이

사용할 두 개의 TCP 포트를 할당하고 첫번째 포트로 FTP서버와 연결을 시

도한다.

그러나 첫번째 포트로 FTP 서버와 연결이 이루어지면 일반 모드에서 처럼

데이터

채널 개방을 위해 포트 명령으로 클라이언트 자신의 두 번째 포트를 서버

에게

말해주는 것이 아니라 PASV라는 명령으로 서버가 데이타 채널을 위해 사용

할

포트를 질의한다.

이렇게 함으로써 서버는 데이터 채널로 개방할 자신의 두 번째 포트를

할당하고-구조적 메카니즘의 이유로 서버는 20번 포트를 사용하지 않고

1023번

이상의 랜덤한 포트를 사용한다.

그러나 클라이언트의 두 번째 포트를 서버에게 말해주는 포트 명령을 보내

는

대신에 클라이언트는 PASV명령을 보낸다.

이렇게 함으로써 서버는 데이터 채널에 대한 자신의 두 번째 포트를

할당하고-구조적인 이유로 서버는 일반 모드에서처럼 20번 포트를 사용하

는 것이

아니라 1023번 이상 임의의 포트를 사용한다.- 클라이언트에게 할당된 포

트의

번호를 회신한다.

그리고 나면 클라이언트는 서버가 알려준 1023번 이상의 임의의 데이터 포

트로

데이터 접속을 하게 된다.

수동 FTP 접속 모드

FTP 서버 FTP 클라이언트

————– ———–

| | | |

| | | |

| | | |

| 20 21| |5150 5151|

–|———– –|—–|–

| | 1: PASV | |

| |<———————————-| |

| | | |

| 3267 | 2: 3267 확인 | |

| | |———————————->| |

| | | | |

| | | 3: 명령 채널 | |

| |<———————————————|

| | | | |

| | | 4: 수신 확인 | |

| |———————————————>|

| | | | |

1: 클라이언트는 서버에 대한 명령 채널을 열고 서버에게 두 번째 포트 번

호를

질의한다.

2: 서버는 데이터 채널을 위한 포트를 할당한다.

클라이언트에게 포트 번호를 말한다

3: 클라이언트는 서버의 두 번째 포트에 대한 데이터 채널을 연다

4: 서버는 수신 여부를 확인한다.

모든 FTP 클라이언트가 수동 모드를 지원하는 것은 아니다.

하지만 클라이언트가 수동 모드를 지원하지 않는다면 문서나 메뉴얼에서

이것을

언급할 것이다.

보통 www브라우져의 내장 FTP 클라이언트가 수동 모드를 사용한다.

만약 사원들이 사용하는 FTP 클라이언트의 수동모드 지원이 의심된다면 모

든

사원에게 FTP 클라이언트로 브라우져를 사용하도록 교육을 시킬 수도 있

을

것이다.

하지만 수동 모드는 그렇게 오랬동안 사용되던 기술이 아니기때문에 아직

도 수동

모드를 지원하는 서버에서 많은 문제점이 보고 되고있다.

만약 일반 모드 전송으로 작동하는 서버과 클라이언트가 수동 모드 전송

을 시도

한다면 주기적으로 다운되는 현상을 발견할 수 있을것이다.

만약 패킷 필터링을 통해 일반 모드의 FTP 통신을 허용하여야 한다면, 패

킷

필터링 룰에 클라이언트에 대해 데이터 채널에 대한 특별한 예외를 만들어

야할

것이다.

이렇게 패킷 필터링 룰에 특별한 예외를 만든다면 외부의 공격자가 자신

의 20번

포트-하지만 컴퓨터에서 이것이 FTP 데이터 채널이라는 것을 보증할 방법

은

없다.-에서 클라이언트의 1023번 이상의 알려진 위험한 서비스 포트-예를

들면 X

window 나 open window 서비스 같은-로 접속을 시도할 위험성이 있게 된

다.

그러므로 꼭 특별한 예외를 만들어야 할 상황이라면 1023 번 이상의 위험

한

서비스 포트로의 제한을 두어야 할 것이다.

정상 모드 FTP 서버로 들어오는 접속

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 21 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 21 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 20 -j ACCEPT

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 20 -j ACCEPT

수동 모드 FTP 서버로 들어오는 접속

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 21 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 21 -j ACCEPT

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

iptables -A OUTPUT -p tcp ! –sport 0:1023 ! –dport 0:1023 -j

ACCEPT

정상 모드 FTP 클라이언트에서 나가는 접속

iptables -A OUTPUT -p tcp –dport 21 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 21 ! –dport 0:1023 -j

ACCEPT

iptables -A INPUT -p tcp –sport 20 ! –dport 0:1023 -j ACCEPT

-> 데이터 채널 생성. 이 부분이 특별한 예외 상황에 해당한다.

iptables -A OUTPUT -p tcp –dport 20 -j ACCEPT

수동 모드 FTP 클라이언트에서 나가는 접속

iptables -A OUTPUT -p tcp –dport 21 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 21 ! –dport 0:1023 -j

ACCEPT

iptables -A OUTPUT -p tcp ! –sport 0:1023 ! –dport 0:1023 -j

ACCEPT

iptalbes -A INPUT -p tcp ! –syn ! –sport 0:1023 ! –dport 0:1023 –

j ACCEPT

*** NNTP

NNTP는 인터넷을 통해서 유즈넷 뉴스를 주고 받는데 사용되는 프로토콜이

다.

뉴스 서버와 서버 사이의 통신을 할때나 사용자가 뉴스를 읽을 수 있도록

클라이언트가 뉴스 서버에 접속 할때 모두 이 NNTP 을 이용한다.

하지만 실제로 뉴스 서버를 구축하는 사례는 극히 드물기 때문에 여기서

는

클라이언트의 입장에서만 패킷 필터링을 살펴보도록 하겠다.

NNTP는 TCP 기반의 서비스로 NNTP 서버는 119번 포트를 사용하고 클라이언

트는

다른 서비스의 클라이언트와 마찬가지로 1023번 이상의 포트를 랜덤하게

사용한다.

클라이언트만을 고려한다면 어떠한 서비스든 외부의 목적 포트를 보고 패

킷

필터링을 설계한다면 수월할 것이다.

뉴스 클라이언트 패킷 필터링

iptables -A OUTPUT -p tcp –dport 119 -j ACCEPT

iptables -A INPUT -p tcpt ! –syn –sport 119 ! –dport 0:1023 -j

ACCEPT

*** HTTP

이제 인터넷은 월드 와이드 웹(WWW)을 빼고는 더 이상 이야기가 안 될 정

도로

최근 인터넷의 폭발적인 성장 뒤에는 웹이 존재했다.

1993년 최초의 GUI 웹브라우져 NCSA Mosaic의 등장 이후로 인터넷 www의

양적

증가는 SMTP, FTP, Telnet등 인터넷의 다른 어떤 종류의 서비스보다 폭발

적으로

성장했다.

그럼 HTTP 패킷 필터링 특성을 알아보자.

HTTP 역시 TCP기반의 서비스이다.

일반적으로 서버는 80번 포트를 사용하고 클라이언트는 1023번 이상의 상

위

포트를 랜덤하게 할당하여 사용한다.

하지만 하나의 컴퓨터에서 외부 사용자와 내부 사용자가 하나의 서버를 이

용하여

서로 다른 데이타 집합에 엑세스 권한을 부여하기 위해서나 개인 사용자

가

자신의 서버를 운영하도록 할수 있게 하기위하여 잘 알려진 포트말고 다

른

포트를 사용하여 서버를 운영할 수도 있다.

참고

———————————————————————

–

UNIX 컴퓨터에서 1023 이하의 포트는 root에 의해 사용되도록 예약이 되어

있다.

권한이 없는 일반 사용자는 이 일반 포트로 자신의 서버를 운영할 수가 없

으므로

자신의 서버를 운영하려 한다면 1023 이상의 포트를 사용하여야 한다

———————————————————————

–

대부분의 서버들은 표준 포트를 사용하고 있으며 다른 포트를 사용하더라

도 웹의

경우 쉽게 알 수있는 포트-81, 800, 8000, 8080-를 사용한다.

만약 표준 포트가 아닌 다른 포트로도 서비스를 한다면 이는 패킷 필터링

의

관점에서 상당히 복잡해질것이다.

서버로 들어오는 HTTP

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 80 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 80 -j ACCEPT

클라이언트에서 나가는 HTTP

iptables -A OUTPUT -p tcp –dport 80 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 80 ! –dport 0:1023 -j

ACCEPT

*** finger

finger 서비스는 사용자를 서로 찾을 수 있도록 하기 위한 목적으로 처음

에는

고안 되었으나 공격자에게 찾고자 하는것 이상의 정보-공격하고자 하는 호

스트에

유용한 사용자 이름, 현재 사용하지 않는 사용자 이름, 로그인한 시기등-

를

말해줄 수가 있다.

finger 서비스의 경우에는 서버를 운영하지 않더라도 “죽음의 핑”과 같은

데이타

위주의 공격 가능성이 존재한다.

일반 유닉스의 finger 클라이언트는 서버에서 들어오는 데이터에 어떠한

조치도

하지 않는다.

이러한 점을 이용하여 악의를 가진 finger 서버는 엄청난 데이터-사용자

터미널에 비프음 내기, 화면에 문자 출력 하기등-를 돌려주기도 한다.

하지만 가장 위험한 것은 이런 단순한 데이타 위주의 공격이 아니라 프로

그램

가능한 터미널에 프로그램한 데이타를 보내어 rm -rf /* 명령을 수행 시키

거나

패스워드 파일을 메일 보내도록 하는등 임의 명령을 실행 시킬 수가 있다

는

것이다.

물론 이런 위험이 가능한 터미널을 요즘은 그리 광범위하게 사용 하지는

않지만

아직까지도 소수나마 이런 위험성이 존재하는 터미널 에뮬레이터를 사용하

고 있다.

만약 나가는 finger 요청을 허용해야만할 경우라면 컨트롤 문자를 필터링

하고

데이터의 양을 제한 시킬 수 있는 GNU Project의 finger나 safe_finger등

대체

finger 사용을 고려하기 바란다.

하지만 이러한 대체 finger가 현재 사용 가능한 정보를 공격자에게 제공하

는

것을 막을 수 있는 향상된 보안을 제공하지는 않는다.

finger는 TCP 기반의 서비스이며 서버는 79번 포트 클라이언트는 1023번

이상을

랜덤하게 할당 해서 사용한다.

서버로 들어오는 finger 질의

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 79 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 79 -j ACCEPT

클라이언트에서 나가는 finger 질의

iptables -A OUTPUT -p tcp –dport 79 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 79 ! –dport 0:1023 -j

ACCEPT

*** whois

호스트, 네트웍, 도메인, internic같은 NIC등을 관리하는 사람에 대한 일

반적인

정보를 얻는데 사용된다.

일반적이 사이트에서는 whois 서버를 운영하지 않는다.

보통은 NIC의 서버에 접속하여 정보를 가져온다.

참고

———————————————————————

–

whois 클라이언트 프로그램은 보통 명령에서 서버를 명시하지 않는다.

프로그램 컴파일시 지정된 서버를 사용하여 서버에 접속을 질의를 한다.

———————————————————————

–

whois 클라이언트의 경우 알려진 보안 문제가 없기때문에 사용자나 관리자

가

사용한다면 굳이 막을 필요는 없지만 요즘은 대부분 NIC가 웹에서도

whois

서비스를 제공하기 때문에 whois 클라이언트를 굳이 설치하여 운영할 필요

가

없다고 보여진다.

whois는 TCP 기반 프로토콜이다.

서버는 43번 포틀를 사용하고 클라이언트는 1023 이상의 포트를 랜덤하게

할당해서 사용한다.

클라이언트에서 서버로 나가는 질의

iptables -A OUTPUT -p tcp –dport 43 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 43 ! –dport 0:1023 -j

ACCEPT

*** IRC

IRC(Internet Relay Chat)는 텍스트 기반의 실시간 대화를 제공하는 서비

스이다.

IRC 서버는 스패닝 트리(spanning tree)로 배열되고, 각 서버에 연결되어

있는

모든 클라이언트에게 메시지를 전달한다.

IRC에서 보안은 프로트콜 자체의 문제가 아니라 사용자와 사용 방법과 관

련된다.

-사실 회사에 일반 사원에게 IRC를 허용한다면 그것이 더 이상할 것이다-

모든 클라이언트는 서버가 로컬 자원-파일, 프로세스, 프로그램등-에 엑세

스하는

것을 허용을 한다.

이는 악의적인 서버가 사용자에 의해 잘못 설정이 되어있는 클라이언트들

에게

피해를 줄 수가 있다.

또한 악의적인 사용자가 다른 사용자에게 잘못된 명령을 내리도록 유도하

여

시스템을 파괴할 수도 있다.

이를 예방하기 위해서는 관리자가 사용자에게 교육을 시킴으로 막는 방법

밖에는

없다.

많은 IRC 클라이언트는 DCC(Direct Client Connections)라는 일대일 파일

전송

프로그램을 지원한다.

DCC는 초기 연결을 제외하고는 서버를 거치지 않고 두 IRC 클라이언트 사

이에

직접 TCP접속을 조정하고 설정하도록 함으로써 파일을 전송한다.

DCC 프로그램은 FTP 정상 모드처럼 외부 클라이언트 1023번 이상의 포트에

서

내부 컴퓨터 1023번 이상의 포트로의 TCP 초기 접속 허용을 요구하며 이

역시

보안에 문제가 된다.

내부 컴퓨터로 들어오는 1023번 이상의 포트로의 초기 접속 패킷을 막는다

면

DCC로 외부 클라이언트에서 내부 컴퓨터로 파일을 보낼수는 있으나 내부

컴퓨터에서 외부 클라이언트로 파일 전송은 허용되지 않는다.

DCC는 요즘 많이 사용하는 냅스터,소리바다,icq와 같은 P-to-P방식과 유사

하다

할 수 있다.

이는 다른 P-to-P 방식 역시 위와 같은 초기 접속요구의 보안 문제가 있음

을

나타낸다.

만약 DCC와 같은 P-to-P 방식의 접속을 허용해야만 한다면 패킷 필터링으

로는

한계가 있기때문에 프락싱같은 다른 방법을 강구하는것이 좋다.

IRC는 TCP 기반 서비스이다.

서버는 일반적으로 6667 포트를 사용하며 클라이언트는 1023번 이상의 포

트를

랜덤하게 할당하여 사용한다.

클라이언트는 DCC를 이용하기 위해 1023번 이상의 포트를 사용한다.

처음 파일 전송을 시도하는 클라이언트는 일반 IRC서버 채널을 통해 파일

을 받을

상대 클라이언트에게 파일 전송을 시도한다는 사실을 알린다.

처음 파일 전송을 시도하는 클라이언트에서 IRC 서버 채널을 통해 보내는

패킷에는 파일을 받을 상대 클라이언트가 접속하기를 원하는 포트 번호가

포함되어 있다.

만일 파일을 받을 상대 클라이언트가 이를 받아들인다면 응답하는 상대

클라이언트는 파일 전송을 시도하는 클라이언트가 접속하기를 원하는 포트

로

초기 접속 패킷으로 일대일 접속을 시도하여 TCP 접속을 개방한다.

외부에서 내부 서버로 접속

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 6667 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 6667 -j ACCEPT

내부에서 외부 서버로 접속

iptables -A OUTPUT -p tcp –dport 6667 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 6667 ! –dport 0:1023 -j

ACCEPT

내부 클라이언트가 DCC로 파일을 전송

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

iptables -A OUPUT -p tcp ! –sport 0:1023 ! –dport 0:1023 -j ACCEPT

외부 클라이언트가 DCC로 파일을 전송

iptables -A OUTPUT -p tcp ! –sport 0:1023 ! –dport 0:1023 -j

ACCEPT

iptables -A INPUT -p tcp ! –syn ! –sport 0:1023 ! –dport 0:1023 –

j ACCEPT

*** DNS

DNS(Domain Name System)는 호스트 이름을 실질적으로 ip 프로토콜이 이해

할 수

있는 IP주소로 또는 그 반대로 전환하는 분산 데이터베이스 시스템이다.

DNS는 다른 네트웍 서비스가 의존하는 TCP/IP 인터넷 환경에서 기본적인

네트웍

환경이다.

DNS 네트웍 활동에는 lookups와 zone transfer라는 두 가지 유형이 있다.

lookups는 DNS 클라이언트가 DNS서버에 정보 요청-도메인의 네임 서버, 주

어진

호스트명의 IP주소, 주어진 호스트의 메일 교환 요청-시 일어난다.

zone transfer는 보조 DNS서버가 주 DNS서버로부터 DNS zone에 대해 주 서

버가

책임지는 정보를 요청할 때 일어난다.

일반적으로 zone transfer는 내부 네트웍 환경의 모든 정보를 담고 있기

때문에

허락되지 않은 외부 호스트로의 zone transfer는 불허 한다.

외부에 HINFO 레코드등 내부 정보에 대한 어떤것도 보이지 않도록 하는것

이

좋다.

모든 보안의 기본은 내부 네트웍의 허가되지 않은 정보를 외부에 최대한

감추는것에 시작한다.

일반적으로 DNS lookups는 처음에는 UDP 프로토콜을 이용해서 실행된다.

UDP 전송이 실패할 경우 다시 TCP 프로토콜을 이용해서 재 시도한다.

-IBM의 AIX의 경우에는 처음부터 질의를 항상 TCP를 사용해서 한다-

DNS 서버는 TCP와 UDP로 53번 포트를 사용하며 클라이언트는 UDP와 TCP 모

두

1023번 이상의 포트를 랜덤하게 할당하여 사용한다.

단 서버대 서버 질의나 응답에서는 UDP의 경우에는 출발지나 목적지 모두

53번

포트를 사용하나 TCP의 경우에는 요청하는 서버는 1023번 이상의 포트를

사용한다.

클라이언트-서버 질의 : 출발지 포트 이상 1023, 목적지 포트 53

서버-클라이언트 응답 : 출발지 포트 53, 목적지 포트 1023 이상

서버-서버 질의와 응답 : UDP의 경우에 출발지, 목적지 모두 포트 53을 이

용,

TCP의 경우에는 요청하는 서버만 1023번 이상의 포트를 사용.

DNS zone transfer는 TCP를 통해서 이루어지며 통신은 보조 서버에서 1023

번

이상의 포트에서 주 서버의 53포트로 연결된다.

zone transfer가 이루어지기 전에 보조 서버는 언제 zone transfer를 해

야

할지를 알기 위해 주 서버에게 DNS질의를 해야 한다.

UDP를 통해 들어오는 질의

iptables -A INPUT -p udp ! –sport 0:1023 –dport 53 -j ACCEPT

iptables -A OUTPUT -p udp –sport 53 -j ACCEPT

TCP를 통해 들어오는 질의

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 53 -j ACCEPT

UDP를 통해서 나가는 질의

iptables -A OUTPUT -p udp -dport 53 -j ACCEPT

iptables -A INPUT -p udp –sport 53 ! –dport 0:1023 -j ACCEPT

TCP를 통해서 나가는 질의

iptables -A OUTPUT -p tcp –dport 53 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 53 ! –dport 0:1023 -j

ACCEPT

UDP를 통한 두 서버사이 통신

iptables -A INPUT -p udp –sport 53 –dport 53 -j ACCEPT

iptables -A OUTPUT -p udp –sport 53 –dport 53 -j ACCEPT

TCP를 통한 외부 서버로부터 내부 서버로 질의 또는 zone transfer 요청

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 53 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 53 ! –dport 0:1023 -j ACCEPT

TCP를 통한 내부 서버에서 외부 서버로 질의

iptables -A OUTPUT -p tcp –dport 53 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 53 ! –dport 0:1023 -j

ACCEPT

*** syslog

모든 공격 시도및 시스템 에러 발생등 시스템에 발생하는 모든 정보를 특

정

영역에 기록하는 서비스이다.

일반적으로 자신의 호스트에다 로그 메시지를 기록한다.

하지만 만약 호스트가 공격을 당해 공격자가 불법 권한을 획득하여 로그

파일을

조작한다면 이 기록을 보고 공격에 대한 취약점을 판별할 수가 없어 그 시

스템을

다시 인스톨-시스템이 공격당해 root 권한을 탈취당한다면 그 시스템은 다

시

인스톨하는 것이 좋다-하더라도 다음번에 또 같은 수법으로 공격당할 위험

성이

있다.

이런 이유로 로그 파일을 저장하는 서버(loghost)를 따로 지정하여 모든

로그를

이곳에서 보관하는 것도 좋은 방법이다.

loghost에서 syslogd를 실행 시킬때 -r 옵션을 주고 실행 하면 외부

호스트로부터의 기록도 받을 수 있어 loghost를 만들수 있다.

자세한 사항은 syslogd, syslog.conf, syslog man 페이지를 참고 하기 바

란다.

loghost 운영을 결정한다면 패킷 필터링등으로 외부에서 loghost로의 접속

을

완벽하게 차단 하여 공격자의 침입 시도를 불가능하게 하여야 한다.

공격자가 사이트의 loghost의 존재를 인지한다면 loghost에 계속 침입을

시도하여 서버의 기록 공간 부족 현상을 유도할 수 있으며 이로 인해서 메

시지

기록을 멈추게 하여 침입 증거를 없앨수도 있기때문이다.

syslog는 UDP기반 서비스이다.

syslog 서버-loghost-는 514 포트를 사용하며 클라이언트는 1023번 이상

의

포트를 랜덤하게 할당하여 사용한다.

syslog 서버는 외부 클라이언트의 접속에 대하여 절대로 응답 메시지를 보

내지

않으며 클라이언트에서 들어온 메시지를 다른 syslog 서버에 전달하도록

설정할

수가 있다.

클라이언트가 syslog 서버 접속

iptables -A INPUT -p udp ! –sport 0:1023 –dport 514 -j ACCEPT

iptables -A OUTPUT -p udp –dport 514 -j ACCEPT

syslog 서버에서 다른 syslog 서버로 메시지 전달

iptables -A INPUT -p udp –sport 514 –dport 514 -j ACCEPT

iptables -A OUTPUT -p udp –sport 514 –dport 514 -j ACCEPT

*** SNMP

SNMP(Simple Network Management Protocol)는 네트웍 장비-라우터,

브리지같은-를 원격으로 제어, 관리하는 표준 메카니즘이다.

SNMP기능을 가진 관리 컴퓨터에서 SNMP를 사용하는 네트웍 장비를 제어하

고

관리할 수 있다.

일반적으로 SNMP관리 컴퓨터는 SNMP서버-SNMP를 사용하는 네트웍 장비들-

와

연결하여 정보를 질의하거나 명령을 보내는 클라이언트로 사용된다.

보통은 관리 컴퓨터가 질의를 해야지만 SNMP를 사용하는 네트웍 장비-

SNMP

서버-는 정보를 관리 컴퓨터로 응답을 한다.

하지만 관리 컴퓨터의 질의를 기다릴 수 없는 실시간 정보의 경우에는

SNMP

서버는 일반SNMP 서버와는 별개인 SNMP 트랩서버와 접속하여 그 정보를

보고한다.

한 컴퓨터는 동시에 SNMP서버와 SNMP트랩서버로 운영될 수 있다.

일반적으로 외부에서 SNMP를 통해 네트웍을 관리하는것을 차단해야한다.

따라서 패킷 필터링으로 외부에서 내부로 들어오는 SNMP를 차단 시켜야한

다.

SNMP는 기본적인 보안을 제공하나는 이는 말그대로 기본적인 보안이며 패

킷

스니핑을 하는 공격자에 의해 쉽게 깨질 수가 있다.

SNMP는 UDP기반 서비스이다.

SNMP서버-SNMP를 사용하는 네트웍 장비들-는 TCP와 UDP 161번 포트를 사용

한다.

SNMP트랩서버-관리 컴퓨터-는 162번 TCP와 UDP 포트를 사용한다.

SNMP클라이언트는 일반서버와 트랩서버 모두와 통신하기 위해 일반적으로

1023번 이상의 포트를 랜덤하게 할당해서 사용한다.

외부에서 UDP를 이용하여 내부 SNMP서버와 접촉

iptables -A INPUT -p udp ! –sprot 0:1023 –dport 161 -j ACCEPT

iptables -A OUTPUT -p udp –sport 161 -j ACCEPT

외부에서 TCP를 이용하여 내부 SNMP서버와 접촉

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 161 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 161 -j ACCEPT

내부에서 UDP를 이용하여 외부 SNMP서버와 접촉

iptables -A OUTPUT -p udp –dport 161 -j ACCEPT

iptables -A INPUT -p udp –sport 161 ! –dport 0:1023 -j ACCEPT

내부에서 TCP를 이용하여 외부 SNMP서버와 접촉

iptables -A OUTPUT -p tcp –dport 161 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 161 ! –dport 0:1023 -j

ACCEPT

외부 SNMP서버가 UDP를 이용하여 내부 SNMP트랩서버와 접촉

iptables -A INPUT -p udp ! –sport 0:1023 –dport 162 -j ACCEPT

iptables -A OUTPUT -p udp –sport 162 -j ACCEPT

외부 SNMP서버가 TCP를 이용하여 내부 SNMP트랩서버와 접촉

iptables -A INPUT -p tcp ! –sport 0:1023 –dport 162 -j ACCEPT

iptables -A OUTPUT -p tcp –sport 162 -j ACCEPT

내부 SNMP서버가 UDP를 이용하여 외부 SNMP트랩서버와 접촉

iptables -A OUTPUT -p udp –dport 162 -j ACCEPT

iptables -A INPUT -p udp –sport 162 ! –dport 0:1023 -j ACCEPT

내부 SNMP서버가 TCP를 이용하여 외부 SNMP트랩서버와 접촉

iptables -A OUTPUT -p tcp –dport 162 -j ACCEPT

iptables -A INPUT -p tcp ! –syn –sport 162 ! –dport 0:1023 -j

ACCEPT

*** RIP

RIP(Routing Information Protocol)은 라우팅 프로토콜로 인터넷에서 IP보

다도

더 앞선 가장 오래된 프로토콜이다.

RIP는 제록스 네트웍 서비스 시스템에서 가져온 것이나 아직도 로컬 IP

네트웍에서 가장 많이 사용되는 프로토콜에 하나이다.

RIP는 UDP 기반 서비스이다.

RIP서버는 다른 서버의 브로드캐스트나 클라이언트의 요구에 대해 520번

포트를

사용하며 자신이 브로트캐스트를 내보낼때도 520번 포트를 사용한다.

RIP클라이언트는 다른 서비스와 마찬가지로 1023번 이상의 포트를 랜덤하

게

할당하여 사용한다.

외부 클라이언트가 내부 서버에 요청

iptables -A INPUT -p udp ! –sport 0:1023 –dport 520 -j ACCEPT

iptables -A OUTPUT -p udp –sport 520 -j ACCEPT

내부 클라이언트가 외부 서버에 요청

iptables -A OUTPUT -p udp –dport 520 -j ACCEPT

iptables -A INPUT -p udp –sport 520 ! –dport 0:1023 -j ACCEPT

외부서버가 내부서버에 브로드캐스팅

iptables -A INPUT -p udp –sport 520 –dport 520 -j ACCEPT

내부서버가 외부서버에 브로드캐스팅

iptables -A OUTPUT -p udp –sport 520 –dport 520 -j ACCEPT

*** ping

ping은 네트웍 문제 해결 도구로 사용되는 아주 편리하고 유용한 도구에

하나이다.

ping은 ICMP echo request 패킷을 상대편 호스트에 보내 그에 대한 응답

을 보고

상대편 호스트에 대한 상태를 판별 할수 있다.

상대 호스트는 핑에 대한 응답으로 ICMP echo-reply 패킷을 보내므로 응답

을

하게 된다.

ping은 네트웍 문제 해결에 많이 사용하지만 들어오는 ping을 허용할 경

우

보안의 위험이 있다.

ping의 가장 잘 알려진 위험으로는 “죽음의 핑”이라는 서비스 부인 공격

에

사용될 수 있다.

물론 다른 서비스로도 서비스 부인 공격을 할수가 있으나 ping의 경우 단

순한

명령행 옵션으로 네트웍을 마비시킬 수가 있어 그 위험의 정도가 더 심하

다고할

수가 있다.

그리고 ICMP echo-request를 보내고 ICMP echo-reply를 받는 사용자는 상

대

네트웍이 어떤 네트웍 주소를 가지고 있고, 얼마나 많은 컴퓨터가 있는지

를 알

수가 있다.

이는 공격자가 이 정보를 바탕으로 더 많은 공격을 할 수 있게끔 공격 사

전

정보를 제공할 수 있다.

일반적으로 들어오는 ping은 차단하고 나가는 ping을 허용하는것이 좋다.

ICMP 패킷의 경우 출발지 또는 목적지 포트 번호를 가지고 있지 않아 이런

걸로는

패킷 필터링을 할 수가 없다.

대신 ICMP 메시지 유형 코드를 가지고 있어 이를 가지고 패킷 필터링을

할 수가

있다.

들어오는 ping

iptables -A INPUT -p icmp –icmp-type echo-request -j ACCEPT

iptables -A OUTPUT -p icmp –icmp-type echo-reply -j ACCEPT

나가는 ping

iptables -A OUTPUT icmp –icmp-type echo-request -j ACCEPT

iptables -A INPUT -p icmp –icmp-type echo-reply -j ACCEPT

*** traceroute

traceroute는 패킷이 특정 IP 목적지에 도달하는데 지나가는 경로를 보여

주는

애플리케이션이다.

traceroute는 UDP 기반의 서비스이나 traceroute 탐침을 받은 호스트는

ICMP

destination-unreachable 과 time-exceeded 메시지 유형으로 응답을 하게

된다.

traceroute도 ping과 마찬가지로 일반적으로 아웃바운드 서비스만을 허용

하고

인바운드 서비스는 차단하는 방법으로 패킷 필터링을 구성하게 된다.

특히 인바운드되는 UDP패킷은 엄격하게 통제하여 NFS와 NIS같은 RPC기반

서비스를 보호하고 공격자가 traceroute를 사용하여 내부 호스트의 실제

할당된

주소를 알아 내는 것을 막아야 할 것이다.

만약 인바운드 traceroute 서비스를 허용할 경우 공격자는 NFS, NIS같은

UDP

기반 서비스를 공격하기 위하여 traceroute를 허용하는 패킷 필터링의

UDP 허용

규칙을 충분히 이용할 수가 있을 것이다.

traceroute의 경우 패킷 필터링 구성에서 특히 신경써야 할 부분이 있는

데

traceroute UDP패킷의 경우 출발지와 목적지 포트는 실행, 호출 또는 명령

행

인자에 의해 변할 수가 있다.

일반적으로 32768이상의 포트를 사용하나 이는 변할 수 있다.

나가는 traceroute 탐침

iptables -A OUTPUT -p udp ! –sport 0:32767 ! –dport 0:32767 -j

ACCEPT

iptables -A INPUT -p icmp –icmp-type destination-unreachable -j

ACCEPT

iptables -A INPUT -p icmp –icmp-type time-exceeded -j ACCEPT

들어오는 traceroute 탐친

iptables -A INPUT -p udp ! –sport 0:32767 ! –dport 0:32767 -j

ACCEPT

iptables -A OUTPUT -p icmp –icmp-type destination-unreachable -j

ACCEPT

iptables -A OUTPUT -p icmp –icmp-type time-exceeded -j ACCEPT

*** NTP

파일 공유 서비스-Samba, NFS-나 CVS(Current Version System)또는

loghost를

이용하여 여러 호스트에 서비스를 할 경우에는 여러 호스트의 정보를 서

로

연관시켜야 할 필요성이 있기 때문에 각 호스트를 단일 시간으로 통일을

해야 한다.

이럴경우 한 호스트를 시간 서버로 설정하여 각 호스트에 NTP(Network

Time

Protocol)를 이용하여 시간을 100ms또는 10ms이내로 정확하게 유지시킬 수

가

있다.

어떤 보안 프로트콜의 경우 정확한 시간 정보에 의존하여 “playback”공격

을

막기도 한다.

이런 경우 프로토콜은 현재 시간을 표시하여 통신을 하기 때문에 모든 통

신은

다른 날짜로 위조 될 수가 없다.

NTP는 UDP기반의 서비스이다.

NTP서버는 서버끼리 또는 NTP 클라이언트와 통신을 하기 위해 123포트를

사용하고 클라이언트는 1023번 이상의 포트를 랜덤하게 할 당하여 사용한

다.

이를 구분해 보면

NTP 클라이언트-서버 질의 : 출발지 포트 1023번 이상, 목적지 포트 123

NTP 서버-클라이언트 응답 : 출발지 포트 123번, 목적지 포트 1023번 이

상

NTP 서버-서버 질의 또는 응답 : 출발지와 목적지 포트 모두 123번

외부 클라이언트에서 내부 NTP서버로 들어오는 질의

iptables -A INPUT -p udp ! –sport 0:1023 –dport 123 -j ACCEPT

iptables -A OUTPUT -p udp –sport 123 -j ACCEPT

내부 클라이언트에서 외부 NTP서버로 나가는 질의

iptables -A OUTPUT -p udp –dport 123 -j ACCEPT

iptables -A INPUT -p udp –sport 123 ! –dport 0:1023 -j ACCEPT

두 서버 사이의 질의 또는 응답

iptables -A INPUT -p udp –sport 123 –dport 123 -j ACCEPT

iptablse -A OUTPUT -p udp –sport 123 –dport 123 -j ACCEPT

*** NFS/NIS

NFS와 NIS는 모두 선마이크로 시스템에서 처음 개발한 서비스지만 지금은

유닉스

시스템에서 거의 표준이 되어버린 서비스이다.

이 두 서비스는 RPC기반의 서비스인데 위 프로토콜 특성에서 설명한것 처

럼

RPC서비스는 패킷 필터링을 하는것이 매우 어려울 뿐더러 NFS의 경우에는

보안에도

상당한 취약점이 있다.

가장 좋은 방법은 이 두 서비스를 하지 않는 것이겠지만 그렇지 못할 경우

에는

인바운드되는 UDP 패킷을 패킷 필터링에서 엄격하게 제한하고 RPC서버와

클라이언트가 필요이상으로 서로를 신뢰하지 못하도록 하여야 한다.

지금까지 각 프로토콜과 인터넷 서비스별로 패킷 필터링 구축에 필요한 대

략의

특성을 알아보았다.

물론 이것이 패킷 필터링에 전부는 아니다.

보안은 네트웍의 편리와 상반되는 개념이다.

만일 너무 보안만을 강조하면 사용자들에게 불만이 생길것이다.

사이트에 따라 필요한 보안의 정도는 어디까지나 관리자의 책임이며 관리

자의

의무는 패킷 필터링등으로 시스템이 쉬운 공격 대상이 되지 않도록 하는

것이다.