강좌
클라우드/리눅스에 관한 강좌입니다.
리눅스 분류

fwtk, ipfwadm (리눅스 방화벽 ) 1, 2, 3

작성자 정보

  • 웹관리자 작성
  • 작성일

컨텐츠 정보

본문

icon01.giftitle08.gif


이수준 외 BIT NETWORK 67 기
VIRUSAWALL & SSL APPLICATION 팀

 

본 프로젝트는 리눅스상에서 공개된 방화벽 프로그램인 TIS사의 FWTK 프로그램을 중심으로 진행하였다. 이번 호에서는 FWAK를 설치하기 위해서 먼저 익혀야 할 배경 지식들 즉 방화벽과 리우팅의 개념에 대해 개략적으로 알아 보고 실제적으로 리눅스에서 라우터와 베스천 호스트를 만드는 방법을 자세히 적어보고자 한다. 그리고 다음 호에서는 FWTK 설치와 베스천 호스트를 운영하는 방법, 그리고 본 프로젝트에서 실제로 구축한 시스템에 대해 간략히 소개를 하는 것으로 기사를 마칠까 한다.

 

방화벽의 개요

인터넷에 대한 관심이 고조됨에 따라 인터넷에 연결하여 다양한 서비스를 제공받으려는 사용자들이 점점 증가하고 있는 추세이다. 실제로 인터넷에 접속이 가능한 사용자들은 인터넷을 통해 다양한 형태의 정보와 서비스를 제공받고 있다.
그러나, 이와 함께 인터넷을 경유한 불법 사용자나 해커들의 침입으로 인한 피해도 크게 늘어나고 있고, 그 수법 또한 전문적이고 다양해지고 있다. 인터넷으로부터의 불법 사용자나 해커의 침입을 막기 위한 대책으로 각각의 시스템이 가지고 있는 자체 보안 능력에 의존하는 방법이 현재까지 많이 이용되어 왔으나, 현재와 같이 네트워크에 연결된 시스템의 숫자가 폭발적으로 증가하는 현실에서는 많은 수의 시스템 각각을 일일이 점검하고 거기에 맞는 보안 대책을 마련하여 적용하는 일은 쉬운 일이 아니다.

특히 내부 네트워크상에 여러 시스템들이 존재할 경우에는 모든 시스템에 동시에 보안 대책을 적용하지 않으면 내부 네트워크는 결코 안전하다고 보기 어려우며, 각각의 시스템 마다 적용된 보안 정책이 다를 수 있으므로 보안 정책을 일괄적으로 적용시켜 관리하기란 매우 어렵다. 이러한 문제점을 해결하기 위해서 내부 네트워크와 외부 네트워크의 연결점에서 내부 네트워크 상의 시스템들을 보호할 수 있는 네트워크 구성 요소가 필요하게 되었고, 이러한 기능을 담당하는 시스템이 바로 방화벽 시스템이다. 따라서 내부 시스템 각각에 대해 적용하던 보안 정책을 네트워크 상의 한 곳에서 적용시켜 관리할 수 있게 되었으며, 내부 시스템에 대한 보안 수준을 높일 수 있게 된다.

 

방화벽이란?

외부 네트워크로부터의 침입에 대해 내부 네트워크를 보호하기 위한 네트워크 구성 요소 중의 하나로, 외부의 불법 사용자의 침입으로부터 내부의 전산 자원을 보호하기 위한 정책 및 이를 지원하는 하드웨어와 소프트웨어를 총칭한다. 내부 네트워크가 외부 네트워크(주로 인터넷을 의미)에 연결되어 있지 않을 경우에는 방화벽은 불필요하다.

 

방화벽의 주요 기능

방화벽은, 일반적으로 네트워크 서비스별로 해당 서비스를 요구한 호스트의 IP 주소와 포트 번호, 사용자 인증에 기반을 두고 외부 침입을 차단하게 된다. 허용된 네트워크 사용자에게 원하는 서비스를 제공하면서 허용되지 않은 사용자에게는 서비스를 차단하고, 해당 서비스의 허용 또는 실패에 대한 기록을 남긴다.

*외부 네트워크와 연결된 유일한 창구 (Gateway)
*서비스 접속 및 거부
*사용자 인증 포함
*내외부 상호 접속된 네트워크에 대한 트래픽 감시, 기록

 

방화벽의 보안 정책

내부 자원을 보호하기 위한 정책은 크게 다음의 두 가지로 요약할 수 있다.

*명백히 금지되지 않은 것은 허용한다.
*명백히 허용되지 않은 것은 금지한다.

대부분 방화벽 시스템은 기본 보안 개념으로 "명백히 허용되지 않은 것은 금지한다" 의 정책을 따른다. 즉, 보안 규칙에 명백히 허용(설정)되지 않은 네트워크와 호스트가 내부 자원에 접근하는 것을 금지한다.

 

방화벽의 종류

패킷 필터링(Packet Filtering) 방식

패킷 필터링 방식은 네트워크의 OSI 모델에서 네트워크층(IP 프로토콜)과 전송층(TCP 프로토콜)에서 패킷을 필터링 하는 기능으 ㄹ하면서, 패킷에 대한 경로 배정을 위한 자체 프로토콜을 함께 사용하는 형태의 방화벽 시스템이다. 패킷 필터링 방식의 방화벽은 스크리닝 라우터로 구성할 수도 있으며, 베스천 호스트와 패킷 필터링 소프트웨어로도 구현할 수 있다.

어플리케이션 프락시(APPlication Proxy) 방식

어플리케이션 프락시 방식의 방화벽은, OSI 7 계층 네트워크 모델에서 제 7계층인 어플리케이션 계층에 방화벽 기능을 구현하게 된다. 이렇게 구현된 게이트웨이는 각 서비스별로 프락시 데몬이 있기 때문에 프락시 게이트웨이 또는 응용 게이트웨이라고 부르기도 한다. 어플리케이션 프락시 방식의 게이트웨이는 각 서비스별 프락시가 서비스 요구자의 IP 주소 및 포트를 기반으로 네트워크 접근 제어를 수행하며, 아울러 사용자 인증 및 기타 부가적인 서비스를 지원할 수 있다.

서킷 게이트웨이(Circuit Gateway) 방식

앞에서 알아 본 어플리케이션 프락시 방식의 방화벽에서는, 각 서비스마다 프락시가 존재하지만, 서킷 게이트웨이 방식의 방화벽에서는 OSI 7계층의 네트워크 모델에서 4계층과 5계층에 해당되는 부분에 TCP Proxy 와 UDP proxy가 존재하게 된다.
본 프로젝트에서는 패킷 필터링 방식과 어플리케이션 프락시 방식을 연결하여 보안의 강도를 높이고자 하였다. 뒤에 소개될 시스템 구성도에서 보듯이 라우터에서 IP 레벨에서 패킷

 

라우터와 라우팅 테이블

필터링을 해주고 여길 통과한 패킷은 배스천 호스트에서 어플리케이션 레벨에서 통제하도록 구성하였다.

 

라우팅과 라우터의 개념

라우팅 개념을 이해하기 위해서는 TCP/IP 프로토콜에 대한 이해가 있어야만 한다. 라우팅이란 패킷을 전송하기 위한 경로를 선택하는 과정을 말하고 라우터란 다른 어드레스 체계를 가진 네트워크 사이에서 통신을 가능하게 하는 기기를 말한다. 인터넷은 라우터라고 불리는 컴퓨터에 의해 상호 연결된 여러 물리적인 망들로 구성되어 있다. 즉 어떤 망의 컴퓨터(호스트)에서 인터넷에 접속하고자 한다면 하나 이상의 라우터를 거쳐야만 하는 것이다. 한 호스트상의 응용 프로그램이 통신하고자 할 때, TCP/IP 프로토콜은 하나 이상의 IP 데이터그램을 만든다. 호스트는 데이터그램을 어디로 송신하여야 하는지를 선택할 때 자신의 라우팅 테이블을 참조해서 경로 설정을 해야만 한다. 그림으로 나타내면 위와 같다.

 

라우팅의 종류

라우팅의 종류는 라우팅 테이블을 어떻게 작성하느냐에 따라서 크게 정적 라우팅과 동적 라우팅으로 나뉜다.

*정적 라우팅(static routing)
라우팅 테이블을 직접 작성하는 것이다. 이 방법은 망 구조가 복잡하지 않는 소규모 망에서 주로 쓰는 방법이다. 쉘상에서 route라는 명령으로 작성하면 된다.

*동적 라우팅(dynamic routing)
이 방법은 라우터 사이의 망 도달성 정보를 정확하게 자동적으로 교류하는 방식으로 라우터들 간에 라우팅 테이블을 주고 받아 자신의 라우팅 테이블을 수정하는 방식이다. 이 때 쓰

 

라우터와 네트웍간의 연결

는 라우팅 프로토콜로는 RIP, OSPE등 여러가지 종류가 있다. 여기서는 이글의 범위를 벗어나므로 더 이상 언급하지 않겠다. PC로 라우터를 만들었을 경우에는 routed라는 프로그램을 실행시키면 동적 라우팅을 할 수가 있다.
지금까지 방화벽과 라우팅의 개념을 개략적으로 살펴보았다. 지금부터는 실제적으로 어떻게 베스천 호스트와 라우터를 셋팅하는지 살펴보자.

실제 구현 방법

*리눅스에서 2개의 랜카드를 셋팅하는 방법

라우터이든 베스천 호스트이던 간에 일단 먼저 해야 할 일은 PC에 랜카드 2개를 설치하는 일이다. 이것은 랜카드의 종류가 같던 다르던 상관 없다. 중요한 것은 랜카드의 IRQ와 I/O주소가 PC의 IRQ와 I/O 주소가 일치하게 세팅 해 주어야 한다는 것이다. 물론 랜카드끼리의 충돌을 피하기 위해선 랜카드의 IRQ와 I/O 주소는 서로 달라야 한다. 이 문제는 랜카드 공급 업체에서 공급해 준 드라이버 디스켓에 IRQ를 조절해 주는 프로그램이 있을 것이므로 이를 이용해 해결하면 된다. 구체적인 방법을 소개하자면 랜카드를 PC에 꼽은 다음 제일 먼저 해야 할 일은 구입 업체에서 제공한 프로그램을 이용해 PnP기능을 제거하는 것이다. 그런 다음 윈도우95에서 제어판 -> 시스템 -> 장치관리자 -> 컴퓨터의 등록정보를 선택하면 현재 시스템에서 쓰고 있는 IRQ와 I/O주소 상태를 알 수 있을 것이다. 이것을 참고로 시스템에서 사용되지 않는 IRQ와 I/O를 메모한 다음 구입 업체에서 제공한 프로그램을 이용

[표1] 수정된 lilo.conf

해 프로그램을 이용해 랜카드의 IRQ와 I/O주소를 거기에 맞게 설정하면 된다. 테스트해서 성공적으로 끝났다면 설정된 각각의 랜카드의 IRQ와 I/O를 메모해 두길 바란다. 이제 리눅스로 부팅해 보자. 우선 커널이 자신의 랜카드를 지원하도록 컴파일 해야 한다. 컴파일 옵션 중에서 Network device support 부분에서 자신의 랜카드를 선택하면 된다. 커널 컴파일이 제대로 끝났다면 부팅될 때 랜카드를 선택하면 된다. 커널 컴파일이 제대로 끝났다면 부팅될 때 랜카드 설정 부분이 나타날 것이다. 쉘상에서는 dmesg라는 명령으로 확인할 수 있다. 다음으로 해야할 작업은 /etc/lilo.conf를 [표1]과 같이 수정해야 한다.
이제 각각 인터페이스(eth0, eth1)에 IP adress를 할당하고 라우팅 테이블에 추가시키는 방법을 알아보자.

dislevel#ifconfig eth0 inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255 up
dislevel#ifconfig eth1 inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255 up
dislevel#route add net 192.168.1.0 eth0
dislevel#route add net 192.168.2.0 eth1

지금까지는 리눅스에서 랜카드 2개를 설정하는 방법을 알아보았다. 이젠 베스천 호스트와 라우터를 만드는 방법을 알아보겠다.

*리눅스를 베스천 호스트로 만드는 방법

리눅스를 베스천 호스트로 만드려면 커널 컴파일을 다시 한번 해야 한다. Network device support 부분은 앞에서 설명했으므로 생략하고 Network options 부분에서 설정해 주어야 할 부분은 <화면1>과 같다.

여기서 눈여겨 볼 부분은 IP forwarding을 OFF로 셋팅해야 한다는 것이다. 왜냐하면 베스천 호스트에서는 모든 패킷을 일단 차단한 다음 Application Gateway별로 규칙에 부합하는 패킷만을 통과시키도록 정책을 쓰기 때문이다.

*리눅스를 라우터로 만드는 방법

베스천 호스트의 차이점을 말한다면 IP 패킷을 forwarding 하느냐, 하지 않는냐에 있다. 즉 라우터는 IP forwarding 을 해야하고 베스천 호스트는 해서는 안된다. 그렇기 때문에 베스천 호스트 만들 때에는 설정했던 컴파일 옵션 중 IP forwarding 부분을 ON 시켜주면 된다. 그리고 추가로 윗그림에서 IP:optimize as router not host 부분을 y로 하면 된다. 커널 컴파일이 끝났으면 routed라는 프로그램을 실행시키면 된다.

<화면1> 커널 컴파일 옵션에서 네트웍 부분 세팅

Router를 위한 IP Packet Filter

이번에는 라우터에 패킷을 필터링 하는 기능을 구현해 보자. 패킷 필터링은 인터넷에 연결된 사설 네트워크에서 인터넷으로 나가거나 사설 네트워크로 들어오는 패킷들의 IP 주소, 포트 번호 등을 기준으로 패킷을 걸러내 허용된 패킷만 받아들이거나 전달되도록 하는 것을 말하며, 일반적으로 다음과 같은 과정을 따라 패킷을 필터링하게 된다.

*패킷과 연관되는 필터링 규칙이 있는가를 검사한다.

*처음 발견된 걸맞는 필터링 규칙에 따라 패킷을 처리한다.

*다음과 같은 3가지 정책중 규칙에 설정된 정책에 따라 패킷을 처리한다.

-Accept : 패킷을 통과 시킨다.
-Deny    : 패킷을 그냥 버린다.
-Reject  : 패킷을 버리고 ICMP Destination Unreachable 메시지를 패킷 송신자(sender)에게
               보낸다.

*각 규칙에 걸맞는 패킷 수와 그 바이트를 셈한다.

*패킷에 관한 정보를 기록한다.

*걸맞는 필터링 규칙이 없을 경우에는 기본(default)정책에 따라 패킷을 처리한다.

리눅스에서는 이러한 패킷 필터링의 기능을 ipfwadm이라는 프로그램을 가지고 쉽게 구현 할 수 있다 알짜 레드햇을 설치 하였다면 아마 이 프로그램이 기본으로 설치되어 있을 것이다. 만약 설치 되어있지 않다면 다음 URL에서 최신 버전을 구할 수 있을 것이다.

Router와 Packet Filter 개념도

http://www.xos.nl/linux/ipfwadm
ftp://ftp.xos.nl/pub/linux/ipfwadm/

프로그램을 설치하는 것은 별 어려움이 없으리라 본다. 자 그럼 이제 본론으로 들어가서, 우리가 제일 먼저 해야 할 것은 패킷 필터링에 있어서 기본 정책을 세우는 것이다. 일반적으로 기본 정책을 수립하는데 다음과 같은 두가지 철학이 있다.

*명시적으로 허가되지 않은 것은 금지한다.
*명시적으로 금지되지 않은 것은 허가한다.

즉, 기본 정책으로는 일반 모든 패킷을 허용하고 보안상 문제가 되는 패킷들에 대해서는 금지하는 방법과 보안상 문제가 없다고 생각되는 패킷들만 허용하고 나머지 모든 패킷들을 금지하는 방법이 있다. 일반적으로 두번째 방법을 많이 사용한다. 따라서 여기서도 두번째 방법을 가지고 설명을 하겠다. 패킷 필터링의 기본 정책은 다음과 같은 명령으로 설정할 수 있다.

Ipfwadm -I -p deny
Ipfwadm -O -p deny

여기서 -I는 들어오는(input) 패킷을 의미하고 -O는 나가는(output) 패킷을 의미한다. 전달(forward)되는 패킷의 경우는 -F 을 이용하여 정책을 세울 수 있다. -p는 기본 정책(default policy)을 설정하는 옵션이다. 위 두 명령은 들어오고 나가는 모든 패킷에 대하여 기본적으로 패킷을 버리도록 설정이 되어 있다. 이 상태에서는 어떤 패킷도 현재 호스트에 들어오지도 나가지도 않는다. 따라서 어떤 네트워크 서비스도 이용할 수 없다. localhost에 대한 ping 명령을 내려보면 아래 그림과 같을 것이다. 그럼 다시 ping이 가능하게 하려면 어떻게 하면 될까? 다음과 같이 기본 정책을 다시 바꾸면 될 것이다.

Localhost에 대한 ping 예제

ipfwadm -I -p accept
ipfwadm -O -p accept

하지만 다른 서비스는 다 무시하고 ping만 가능하게 하라면 이 방법으론 안될 것이다. 다음과 같이 하면 ping이 제대로 동작할 것이다.

ipfwadm -I -a accept -P icmp
ipfwadm -O -a accept -P icmp

여기서 -a 옵션은 새로운 필터링 규칙을 추가한다는 것을 나타내고 뒤에 나오는 accept는 허용 규칙을 추가한다는 뜻이고, -P icmp은 프로토콜(protocol) icmp를 의미한다. ping프로그램이 사용하는 프로토콜이 icmp이므로 icmp를 사용한 패킷을 보내고 받을 수 있도록 하면 된다. 여기서 주의 할 점은 'P'가 대문자 라는 것이다.
필터링 규칙이 제대로 설정 되었는지 알아보려면, 다음과 같이 하면된다.

ipfwadm -I -l --- Input packet Filtering rule list 출력
ipfwadm -O -l --- Output packet Filtering rule list 출력

그러면 Input packet과 Output packet에 대한 필터링 규칙을 보여준다.

그럼 이번에는 Telnet 서비스가 가능하도록 해보자. Telnet 서비스는 밖으로 Telnet을 통해 나가는 경우와 밖에서 Telnet을 통해 들어오는 경우, 두 가지가 있다. 먼저 Telnet 서비스를 통하여 밖으로 나가는 경우를 보자. Telnet 서비스를 이용할 경우 TCP 프로토콜을 사용하며, Telnet 서버는 24번 포트를 사용하여 클라이언트의 접속을 기다린다. Telnet 클라이언트는 1024~65535범위 안에서 임의의 포트를 사용하여 Telnet 서버에 연결을 하게 된다. 따라서 Telnet을 이용할 때 전송되는 패킷들의 Source address와 Port는 다음과 같이 요약할 수 있다.

-클라이언트에서 서버로 가는 패킷

    Source                     Destination
Address    Port               Address     Port
Cllent IP   1024-65535    Server IP    24

-서버에서 클라이언트로 가는 패킷

Source                     Destination
Address    Port         Address    Port
Server IP    24          Cllent IP    1024-65535

따라서, 아래와 같이 필터링 규칙을 추가 해주면 된다. 대소문자에 유의하기 바란다.

ipfwadm -O -a accept -P tcp -S 192.168.37.1 1024:65535
        \ D 192.168.22.0/24 telnet
ipfwadm -I -a accept -k -P tcp -S 192.168.22.0/24
telnet \-D 192.168.37.1 1024:65535

여기서 -S 192.168.37.1은 패킷은 발송지 주소(Source Address)를 나타낸다. (호스트 IP는 192.168.37.1로 가정) 1024:65535을 Port 번호의 범위를 나타낸다. -D 192.168.22.0/24는 목적지 주소(Destination Address)를 나타낸다. 여기서 192.168.22.0는 네트워크 주소를 나타내고 /24는 netmask 255.255.255.0을 의미한다. 24라는 수는 netmask가 차지하는 상위 비트수를 나타낸다. 위에서 보는 것처럼 TCP 프로토콜에 대해서는 항상 IP address 와 Port 번호를 함께 설정해 주어야 하는데, 이때 IP address 가 호스트일 때는 IP주소만 적고, 네트워크일 때는 netmask를 함께 써주어야 하며, 포트 번호를 생략하게 되면 모든 포트로 설정된다. -k 옵션은 ACL 비트가 포함된 TCP 패킷을 의미한다.

위와 같이 설정하면 호스트 192.168.37.1에서 192.168.22.0 네트워크로만 Telnet 서비스를 이용할 수 있다. 만약 모든 네트워크로만 Telnet 서비스를 사용가능 하도록 지정하고 싶을땐 192.168.22.0/24를 any/0으로 수정하면 된다. 수정할 때는 앞의 규칙을 삭제하고 새로운 규칙을 다시 설정해야 한다. 필터링 규칙 삭제는 -d 옵션을 사용하여 삭제하고자 하는 규칙을 설정하면 된다.

ipfwadm -I -d accept -P tcp -S 192.168.37.1 1024:65535
        \ -D 192.168.22.0/24 telnet
ipfwadm -I -d accept -k -P tcp -S 192.168.22.0/24
        telnet \-D 192.168.37.1 1024:65535

모든 필터링 규칙을 삭제하고 처음부터 다시 설정하고 싶다면 다음 명령어를 사용하면 된다.

ipfwadm -I -f
ipfwadm -O -f

이번에는 외부의 호스트가 호스트 192.168.37.1로 Telnet 접속을 할 수 있게 하여 보자. 명령어는 앞에서 한 것과 매우 유사하다. Source Address와 Destination address 그리고 Port번호를 반대로 설정하면 된다.

ipfwadm -O -a accept -k -P tcp -S 192.168.37.1 telnet
        \ -D 192.168.22.0/24 1024:65535
ipfwadm -I -a accept -P tcp -S 192.168.22.0/24 1024:
        65535 \-D 192.168.37.1 telnet

위와같이 설정하면 192.168.22.0 네트워크에 속하는 호스트들만 호스트 192.168.37.1의 Telneet 서버스를 사용할 수 있게 된다. 이상으로 Telnet 접속의 2가지 경우에 대하여 접속을 제어하는 것에 관하여 알아보았다.

다음으로 우리가 자주 사용하는 FTP에 대한 필터링 규칙을 설정하여 보자. 한가지 주의할 점은 Telnet은 하나의 연결(connection)을 사용하지만 FTP는 두 개의 연결을 가지고 있다는 것이다. 하나는 FTP 명령을 사용하기 위한 연결이고 다른 하나는 데이터를 전송하기 위한 연결이다. 따라서 FTP에 대한 필터링 규칙은 다음과 같다.

ipfwadm -I -a accept -k -P tcp -S any/0 ftp \
        -D 192.168.37.1 1024:65535
ipfwadm -O -a accept -P tcp -S 192.168.37.1
         1024:65535 \-D any/0 ftp
ipfwadm -I -a accept -P tcp -S any/0 ftp-data \
        -D 192.168.37.1 1024:65535
ipfwadm -O -a accept -k -P tcp -S 192.168.37.1
        1024:65535 \-D any/0 ftp-data

그외 다른 서비스들도 Telnet 이나 FTP와 마찬가지로 네트워크상에서의 패킷의 발신지 포트와 목적지 포트에 유념하여 필터링 규칙을 설정한다면 특정 패킷을 허용 또는 차단 할 수 있다. 하지만 모든 서비스에 관하여 패킷 필터링의 기능을 설정하는 것은 쉬운 일이 아니다. 각 서비스가 사용하고 있는 프로토콜과 포트 번호를 정확히 알아야 하며, 필터링 규칙이 매우 복잡해진다. 필터링 규칙을 세우는데 있어서 다음과 같은 점을 유의하기 바란다.

⇒ 필터링 규칙의 순서를 정하라.
⇒ 현재의 패킷에 적용될 수 있는 규칙이 여러 개 있다면 그중 먼저 설정된 규칙이 적용된다.
⇒ 가능한한 여러 개의 포트 번호를 묶어서 설정하라.
    - 패킷에 대한 필터링 규칙을 점검하는데 CPU time이 소요되기 때문이다.
⇒ 시스템이 시작될 때 필터링 규칙이 설정되게 하라.
    - 시스템이 시작되고 네트워크 장비가 설정되기 전에 필터링 규칙이 설정되도록 하는 것이
       이상적이다.
⇒ 호스트 이름이나 네트워크 이름을 사용하지 마라.
    - ipfwadm에서는 호스트 이름이나 네트워크 이름을 사용할 수 있으나 될 수 있으면
       IP 주소를 사용하는 것이 더 좋다.
⇒ 현재 운영 중인 시스템에 필터링 규칙을 설정할 경우 다음과 같은 순서로 하라.
    -기본 필터링 규칙을 deny로 설정하라.
    -모든 필터링 규칙을 제거한다. (ipfwadm의 -f 옵션사용)
    -새로운 필터링 규칙을 설정한다.
    -기본 필터링 규칙을 원하는 값으로 설정하라.

IP traffic accounting

리눅스에서 ipfwadm을 이용하면 받은 패킷과 보낸 패킷의 수를 셈하여 IP 트래픽을 계산할 수 있다. 로컬 호스트이 IP주소가 192.168.37.1 이고 WWW 서비스를 제공하고 있다면, 다음 명령은 이부로 부터의 WWW 서비스를 이용하는 사람들의 http 패킷을 계산한다.

ipfwadm -A -a -d -W ethl -P tcp -D 192.168.37.1 www

여기서 -A 옵션은 패캣의 수를 세(Account)는 옵션이고, -b옵션은 양방향(bi-directional)의 패킷 모두를 계산하라는 것이다. 192.168.37.1(80)로 들어오는 패킷이나 나가는 패킷의 수만을 계산하고 싶다면,

ipfwadm -A in -a -W ethl -P tcp -D 192.168.37.1 www
ipfwadm -A out -a -W ethl -P tcp -S 192.168.37.1 www

위 명령과 같이 -A 옵션 다음에 방향(in/out)을 지정하고 목적지 또는 발송지 주소를 적어 줌으로서 원하는 패킷의 수만을 계산할 수 있다. -W ethl 은 인터페이스를 의미한다.

기타 다른 옵션들에 대해서는 man ipfwadm 해서 찾아보기 바란다. 알짜 래드햇의 경우 번역된 맨 페이지가 나오므로 쉽게 알 수 있을 것이다.


icon01.giftitle09.gif

이수준 외 BIT NETWORK 67 기
VIRUSAWALL & SSL APPLICATION 팀

 

지난 호에서는 Linux Firewall을 구축하기 위한 방화벽과 라우팅 개념, 라우터, 베스천 호스트에 대해서 알아보았다. 이번 호는 계속해서 FWTK의 설치와 구성, 운영 방법 등에 대해 알아보기로 한다.

 

TIS Firewall Toolkit의 개요

TIS Firewall Toolkit은 하나의 통합된 방화벽 패키지가 아니라 방화벽 소프트웨어를 제작하는데 필요한 여러가지 도구들의 모음이? TIS Firewall Toolkit으로 구축이 가능한 방화벽 호스트는 프락시(proxy)방식의 방화벽 호스트이다. 따라서 각각의 네트워크 서비스 별로 프락시를 두고 이 프락시들이 방화벽의 기능들을 수행하게 되는 것이다. TIS Firewall Toolkit이 제공하는 프락시들은 원격 로그인 프락시, 파일 전송 프락시, 전자 우편 프락시 등이 있으며, 아울러 다양한 형태의 사용자 인증을 위한 인증 서버를 별도로 두고 있다. 이 모든 응용 프로그램들은 소스 코드의 형태로 제공되므로 사용자가 약간의 프로그램 개발 경험만 있다면 쉽게 컴파일하여 사용할 수 있고, 아울러 사용자의 지식에 따라 새로운 형태의 기능을 추가로 개발하여 사용할 수 있다.

TIS Firewall Toolkit은 fwtk.tar.Z의 단일 파일 형태로 배포되고 있다. 파일을 입수하고 압축을 해제한 후 유닉스의 tar 명령어를 이용하여 풀면 <그림 2.1>과 같은 형태의 디렉토리를 볼 수 있다. 물론 각각의 디렉토리 내에는 해당 프로그램이나 도구의 소스 파일이 존재

 

                         fwtk
                         
  |

                         
  |

        auth----|----tools

     config----|           |----admin

    ftp-gw----|           |            |----flog

   http-gw----|           |            |----netscan

           lib----|           |            |----portscan

     netacl----|           |            |----progmail

  plug-gw----|           |            |----reporting

rlogin-gw----|           |----client

      smap----|           |            |----gate-ftp

    smapd----|           |            |----misc

     tn-gw----|           |----server

      x-gw----|                         |----aix-auth

                                                |----ftpd

                                                |----login-sh

                                                |----login-ts

                                                |----syslog

                                                              |---- x-gw


TIS Toolkit 디렉토리 구조

한다. TIS Firewall Toolkit은 여러가지의  프락시를 제공하고 있으며, 실제 방화벽을 구축할 때 이들 프락시를 선택적으로 설치할 수 있다. 여기서는 각 프락시들의 기능을 간단히 살펴보기로 하겠다.

 

접근 제어의 사용

netacl은 서버에서 사용되는 다양한 TCP 기반의 서비스에 대한 접근의 정도를 결정해 주는 네트워크 접근 제어 프로그램이다. 예를 들면, 만약 어떤 인가된 사용자에 대해 방화벽 시스템으로의 telnet접근을 허용하고 싶다면 netacl과 적당한 규칙을 적용하여 해당 기능을 가능토록 할 수 있다. 물론 ftp와 rlogin서비스에도 마찬가지로 적용할 수 있다.

 

telnet 프락시

telnet 프락시인 수-gw는 원하는 서버로의 telnet 서비스에 대한 유일한 경로를 제공하는데, 많은 네트워크 환경에서 시스템 관리자가 내부망으로 방화벽 호스트를 통한 telnet접근을 허용하지 않을 때 사용한다. netacl과는 다르게 telnet 프락시는 방화벽으로의 직접 접근을 제공하지 않는다. 즉, netacl을 경유하는 telnet은 방화벽 호스트로의 접근이 허용되지만 프락시를 경유하는 telnet은 단지 로깅 제어를 갖는 경로만을 제공받게 되는 것이다.

방화벽 시스템의 관리자는 종종 방화벽 호스트의 원격 관리를 위한 접근 경로와 프락시 telnet을 구축해야 하는 딜레마에 빠질 수가 있는데, 이는 /etc/services 파일과 /etc/inetd. Conf 파일을 수정하여 실제의 telnetd를 telnet의 표준 TCP포트와는 다르게 설정하고, 프락시를 telnet 의 표준 TCP포트에 설정함으로써 해결할 수 있다. 아울러, 이 경우에는 보안을 위해 netcal등의 접근 제어가 필요하다.

tn-gw의 동작은 매우 간단하다. 방화벽 호스트로의 표주 telnet포트로 들어오는 telnet접근이 감지되면 tn-gw프로그램이 기동되며, tn-gw에서는 프락시로의 해당 접근이 혀용된 호스트로부터 온 것인지를 판별하여 허용/거부를 결정하게 된다.

 

rlogin 프락시

rlogin 프락시인 rlogin-gw는, telnet 서비스가 아닌, rlogin 서비스를 제공한다는 점을 제외하면 telnet 프락시와 동일한 동작 메커니즘을 가지고 있다. 그러나 일반적으로는, 방화벽 호스트를 통하는 접근의 경우에 rlogin 서비스를 허용하지 않는 것이 바람직하다. 이는 rlogin 서비스 자체가 많은 보안상의 허점을 내포하고 있기 때문이다. 따라서 방화벽 호스트로의 원격 로그인 서비스는 telnet으로 국한하도록 권한다.

 

FTP 프락시

FTP 프락시인 ftp-gw는, 방화벽 호스트를 통과하는 사설 네트워크 또는, 공용 네트워크로의 FTP 트래픽을 허용하는데, telnet 프락시와 마찬가지로 방화벽으로 표준 FTP포트를 경유하는 FTP 접근이 감지되면 프락시의 수행이 시작된다. 방화벽 호스트로 사용되는 시스템이 FTP 서비스를 제공하게 하는 것은 별로 좋지 않은 생각이다. 가장 좋은 방법은 별도의 FTP 서버를 운용하는 것이지만, 시스템의 원격 관리를 위해 FTP 서비스가 필요할 경우, telnet 서비스의 경우와 마찬가지로 /etc/services 파일과 /etc/inetd.conf 파일을 수정하여 실제의 ftpd를 FTP의 표준 TCP 포트에 설정하여 사용할 수 있다. 물론, 이 경우에도 netcal등의 접근 제어가 필요하다.

 

sendmail 프락시

방화벽 호스트르 메일의 올바른 전송을 위해서는 smap과 smapd로 불리는 2개의 프락식 필요하다. 이중에 smap은 SMTP의 최소 버전만을 구현한 클라이언트의 기능을 담당하게 되는데, 네트워크로부터 메시지를 받아들여 이를 디스크에 저장함으로서 후에 smapd가 메시지를 받아들여 이를 디스크에 저장함으로서 후에 smapd가 저장된 메시지를 재전송하도록 하는 역할을 수행한다. 프락시로 동작되는 smap은, chroot된 상태에서 non-privileged프로세스로 수행되도록 설계되어 있으므로 일반적인 privileged 메일러에 비해 높은 수준의 보안성을 제공하게 된다.

Smapd 데몬은, smap에 의해 저장된 메일의 저장 영역을 주기적으로 검사하여 수집된 메일의 수신자에게 해당 메일을 전달하도록 하는 역할을 수행하게 되는데, 이 때 메일의 전송은 sendmail이라는 MAT(Mail Transfer Agent)에 의해 이루어지며 전송이 완료된 메일 메시지는 삭제된다. 만일 메일전송이 불가능할 경우 smapd는 메일이 저장되어 있는 영역을 재구성하여 후에 있을 재 전송에 대비하게 된다.

 

HTTP 프락시

HTTP 프락시인 http-gw는, 방화벽 호스트를 통과하는 HTTP요구에 대해, 보다 간략화된 메커니즘을 제공한다. 또한 Gopher나 Gopher+등의 Gopher 클라이언트들에 대한 요구를 지원하며, Gopher 클라이언트로부터의 FTP요구와 WWW 클라이언트로부터 전달된 HTTP, Gopfer, Gopher+ 및 FTP 요구를 지원한다.

HTTP 프락시는 또한 넷스케이프나 익스플로러등의 프락시옵션이 있는 웹 브라우져를 지원할 수 있다. 만약 프락시 옵션을 제공하지 않는 웹 브라우져를 사용할 때는 사용자의 URL설정시 프락시를 경유하도록 하여야만 한다.

 

X Windows 프락시

x-gw 는, tn-gw와 rlogin-gw 접근 제어하에서 사용자-레벨의 X Windows 인터페이스를 가능케하는 X-Windows 프락시이다. 따라서 x-gw는 단독 실행이 불가능하며 반드시 tn-gw나 rlogin-gw를 통해 방화벽 호스트로의 접근이 허용되었을 경우에만 사용할 수 있다.

 

인증 서버

TIS Flrewall Toolkit는 광범위한 사용자 인증 메커니즘을 포함하고 있다. TIS인증 서버는 두가지 컴푸넌트로 구성되어 있는데, 첫번째가 실제 서버 그 자체이며 두번째가 인증서버를 구성하고 인증 서버와 상호 동작을 하는 사용자 인증 관리자이다.

authsrv로 불리는 인증 서버는, 내부 사용자 데이터베이스를 가지면서 다양한 종류의 사용자 인중 프로세스를 지원하도록 설계되어 있는데, 사용자 정보를 가지고 있는 사용자 데이터 베이스는 다음과 같은 내용으로 구성된다.

① 사용자의 로그인 ID
② 사용자의 그룹
③ 사용자의 이름
④ 최근의 성공적인 인증 정보

패스워드로는 내부 사용자를 위한 plaintext 형식과 그 외 사용자를 위한 암호화된 형식을 모두 사용할 수 있는데, plaintext형식의 패스워드는 내부의 허가된 사용자들만이 사용해야 하며, 외부망 등 인가되지 않은 네트워크로부터의 사용자들에게 의해서는 사용되지 않는 것이 바람직하다. 따라서 방화벽 시스템 관리자는 외부 네트워크의 사용자들에게는 암호화된 패스워드만을 제공하여 네트워크 스니핑 등의 공격으로부터 내부 망을 보호해야 할 것이다.
authsrv 데이터베이스에 등록된 사용자들은 각기 다른 그룹에 속할 수 있으며, 각 그룹 관리자들만이 해당 그룹의 사용자들을 관리할 수 있다. authsrv는 또한 다음관 같이 다양한 형태의 사용자 인증 도구들을 지원하도록 구성되어 있다.

① 내장 plaintext 패스워드
② Bellcore 사의 S/Key
③ Security Dynamics사의 SecurID
④ Enigma Logics사의 Silver Card
⑤ Digital Pathways사의 SNK004 Secure Net Key

위의 인증 도구들 중, Plaintext 패스워드와 Bellcore사의 S/Key 는 현재 별도의 하드웨어 추가 없이도 무료로 사용 할 수 있다.

 

기타 서비스를 위한 프락시

일반적으로 네트워크 트래픽의 80% 이상이 위에서 언급된 서비스 (telnet 과 rlogin, FTP, sendmail 및 HTTP)로 이루어져 있다. 그러나 여기에 언급되지 않은 Network News Transfer Protocol(NNTP)과 Post Office Protocol(POP)등의 서비스는 어떻게 처리해야 할까?
TIS Firewall Toolkit에서는 이에 대한 해결책으로 플러그 보드 형태의 연결을 위한 plug-gw 프락시를 제공하고 있다.

 

TIS Firewall Toolkit의 입수

먼저 http://www.tis.com/에 접속하면 다운로드 방법을 비롯하여 TIS Firewall Toolkit 을 다운로드 받으려 할 경우에 send라는 단어를 내용으로 한 메일을 fwtk-request@tis.com 에게 보내라는 내용의 안내글이 나오 있으므로 그대로 따르기 바란다. 하루나 이틀 후에 TIS Firewall Toolkit을 다운로드 받을 수 있는 FTP 사이트와 디렉토리를 알려주는 전자 메일이 TIS 사로부터 전송되어 도착되므로, 해당 사이트와 디렉토리로 FTP 로그인하여 파일을 받아오면 TIS Firewall Toolkit을 입수할 수 있다. 이와 함께 TIS에서는 TIS Firewall Toolkit과 관련된 문서들을 모아 fwtk-doc-only_tar.tar.Z라는 별도의 파일로 제공하고 있다. 보통의 경우, 이 문서 파일도 프로그램 파일과 동일한 디렉토리 상에서 압축을 풀고 tar를 해제하여 사용에 참조하게 된다.

 

베스천 호스트의 구축

 

베스천 호스트 사용자 계정의 삭제

꼭 필요한 경우가 아니면 베스천 호스트 내의 사용자 계정은 모두 삭제시켜야 한다. 사용자 계정이 존재하지 않는 베스천 호스트가 보다 높은 수준의 보안 수준을 제공할 수 있기 때문인데, 이에 대한 이유는 다음과 같다.

① 계정 자체가 보안상의 취약성을 내포하고 있다.
② 계정 관리를 위한 서비스들이 보안상의 취약성을 내포하고 있다.
③ 머신의 안정성과 신뢰성을 감소시킬 수 있다.
④ 사용자에 의해 베스천 호스트의 방어력이 감소될 수 있다.
⑤ 공격의 감지가 어려워진다.

 

베스천 호스트의 구축 순서

일반적인 운영체제를 사용하는 베스천 호스트를 구축은 다음의 순서에 따라 이루어 진다.

① 머신의 자체 보안 수준을 높인다.
② 필요없는 모든 서비스를 중지시킨다.
③ 기능 제공을 원하는 서비스를 설치하고 수정.
④ 원하는 동작 상태의 환경으로 머신을 재구성
⑤ 기준에 적합한지 보안 감사 도구를 동작
⑥ 감사 결과에 따라 머신을 네트워크에 연결시켜 사용

 

방화벽 환경 구축을 위한 준비

방화벽 환경 구축을 위한 첫번째 단계는, 앞서 언급된 바와 같이 불필요한 서비스를 중지시키는 것이다.

① /etc/inetd.conf 파일을 수정
② /etc/re,/etc/rc2.d/* 등의 시스템 시작 스크립트를 수정
③ 운영체제 구성을 수정하여 불필요한 커널 기반 서비스들을 제거

 

네트워크 허용 테이블

방화벽 소프트웨어가 정상적으로 설치되었을 경우,/usr/local/etc/netperm-table 의 파일로 존재하는 네트워크 허용 테이블 (Network Permission Table)은, TIS Firewall Toolkit 기반 방화벽 프로그램의 요소들(neactl, smap, smapd, ftp-gw, tn-gw 및 plug-gw등)을 위한 중요한 환경 구성 파일이다.

TIS Firewall Toolkit의 프락시가 동작을 시작하면, 네트워크 허용 테이블로부터 환경 구성과 접근 허용 정보를 읽어와, 메모리에 데이터베이스 형태로 저장하고 이후 사용에 대비한다. 접근 허용/구성 파일은 접근 규칙에 따라 만들어지는데, 각각의 접근 규칙들은 해당 규칙이 적용되는 어플리케이션 프락시로 명명되며, "어플리케이션 프락시명: 접근 규칙"과 같이 콜론(:)을 사용하여 표시한다. 또한 동일한 접근 규칙이 적용되는 여러 어플리케이션 프락시들은 "어플리케이션 프락시명 1, 어플리케이션 프락시명 2: 접근 규칙"과 같이 콤마(,)를 사용하여 한꺼번에 표시할 수도 있고 "*"등의 기호도 사용이 가능하다. 특정 어플리케이션 프락시가 환경 정보를 추출할 경우에는, 자신에게 해당되는 규칙만을 추출하여 순서대로 적용하게 되는데, 다음의 리스트에 smap과 smapd에 적용되는 접근 규칙의 예를 보여주고 있다.

# sample rules for smap
smap, smapd: userid   4
smap, smapd: directory  /mail/inspool
smap:         timeout  3600

어플리케이션 프락시가 자신을 위한 접근 규칙을 발견하면, 해당 규칙은 내부적으로 공백 문자 단위의 문자열로 구분되어 이후 사용에 대비한다. 일반적으로 첫번째 단어가 규칙을 나타내고, 다음에 이어지는 단어들이 해당 규칙에 적용되는 옵션 파라미터를 나타낸다.

앞의 smap 클라이언트와 smapd서버의 예를 보면, userid 항목은 해당 어플리케잇ㄴ이 실행될 때의 사용자 ID를 나타내며, directory 항목은 파일의 위치를, 그리고 timeout 항목은 최대 대기 시간을 나타내게 된다.

접근 규칙을 나타내는 문자열에는 여러가지의 다양한 의미들이 적용 가능한데, 한 예로 permit-hosts혹은 deny-host로 시작할 경우에는 접속을 허용, 혹은 거부할 호스트의 IP어드레스가 동반되며 여기에 해당하는 호스트들은 접속을 허용, 혹은 거부하도록 운용 된다.

# sample rules for netacl    
netacl - in.ftpd:      permit-hosts 202.30.113.5 -exec/usr/sbin/in.ftpd
netacl-in. ftpd:      permit-hosts 203.68.35.112 -exec/usr/sbin/in.ftpd
netacl-in.ftpd:       deny-hosts unknown
netacl-in.ftpd:       deny-hosts *

네트워크 허용 테이블을 만들 때 고려되어야 할 약속들이 몇 개 있는데, 이러한 약속들은 파일의 일관성을 약속하며, 보다 더 이해하기 쉽고 관리가 편한 규칙 목록을 만들 수 있도록 도와준다. 이해를 쉽게 하기 위해, 규칙에 호스트의 이름이나 발신지 호스트의 IP 어드레스가 설정되고 패턴 매칭에 따른 허용 호스트를 판단하는 경우를 예로 들어 보자.

netaci-in.ftpd: permit-hosts 202.30.113.5 -exec/usr/sbin/in.ftpd

위와 같은 규칙이 적용된 상태에서 접속 요구가 들어오게 되면, 규칙의 부합 여부를 판단하기 위해 원격 머신의 IP어드레스가 사용될 것이다. 다음은 도메인 이름으로 허용 규칙을 작성하였을 경우를 살펴보자.

netaci-in.ftpd: permit-hosts*.nca.or,kr -exec/usr/sbin/in.ftpd

접근 규칙에 원격 머신의 IP 어드레스가 아닌 도메인 이름이 사용된 경우, DNS 스푸핑(spoofing)의 가능성에 의해 방화벽 호스트의 보안성이 취약해질 수 있으므로 사용을 남용하지 않도록 권고한다.

어플리케이션 프락시가 IP 어드레스를 도메인 이름으로 바꾸기 위한 리버스 룩업(reverse lookup)시도가 실패하는 경우 호스트 이름은 "unknown"으로 설정되며, 이외의 경우 원격 시스템의 호스트 이름을 반환받게 된다. 아울러 도메인 이름 찾기가 방화벽 호스트에 의해 수행될 경우, 리버스 룩업에 의해 반환되는 도메인 이름을 알아내기 위한 작업은 안전을 보장받을 수 있게 되며, 이러한 환경 구성으로 DNS 스푸핑을 막을 수 있다. 만일 IP 어드레스가 DNS시스템 내에 위치할 수 없다면, 호스트 이름은 "unknown"으로 설정 되고 경고가 로그되는데, 이와 같이 방화벽은 유효한 DNS 매핑을 가지지 않은 호스트에 대해서도 동작하는 규칙을 허용한다. 즉, 인터넷 상에서 어떤 호스트도 방화벽을 통과하도록 한다거나, 혹은 리버스 DNS 어드레싱이 잘 구성되어 있을 경우 특정 서비스에 접근 하도록 하는 것이 가능하다는 뜻이 될 수 있다.

 

네트워크 접근 제어

TIS Firewall Toolkit 기반의 방화벽에서는 네트워크 접근제어의 기능을 위해 netacl이라 불리는 프로그램을 제공한다. Netacl프로그램은 inetd데몬에 의해 기동되게 되며, 원격 사용자/시스템으로부터의 서비스 요구를 허용하거나 거부하는 기능을 담당 한다. Inetd.conf파일에서 netacl을 설정할 경우에, netcal이 오직 하나의 인수를 취한다는 것은 매우 중요한데, 이 인수로는 시작하고자 하는 서비스의 이름이 사용된다. 아울러 이외의 인수들은 netcal이 기동하는 서비스가 사용하게 되는데, inetd.conf파일에 대한 아래의 예를 참조하시기 바란다.

ftp  stream tcp nowait root /usr/local/etc/netacl /usr/sbin/in.ftpd

위와 같이 구성되었을 경우, ftp 서비스 접속 요구가 inetd에 의해서 받아들여지게 되면, netcal 프로그램이 /usr/sbin/in.ftpd를 인수로 하여 동작을 시작하게 된다. ftpd 데몬이 시작되기 전에 netacl은, 해당 요구가 netperm-table 내 접속 규칙에 부합되는지를 검사하여 ftpd데몬의 실행 여부를 판단하게 된다. 통상적으로 규칙의 이름은 netacl- 과 해당 서비스의 이름을 조합하여 사용하게 되는데, 서비스가 in.ftpd일 경우에는 neta치-in.ftpd로 규칙의 이름을 설정되어야만 한다.

netacl-in. ftpd: permit-hosts 202.30.113.5 -exec/usr/sbin/in.ftpd

 

서비스

키워드

설 명

netacl

permit-hosts IP 어드레스
또는 호스트이름

접속을 허용하고자 하는 호스트를
나타낸다.

deny-hosts IP 어드레스
또는 호스트이름

접속을 거부하고자 하는 호스트를
나타낸다.
서비스 거부 정보는 syslogd에 의해
기록된다.

-exec 실행파일 [arg]

요청 서비스 처리를 위한 프로그램을
나타낸다.
이 옵션은 반드시 마지막에 사용되어야 하며, 반드시 사용되어야 한다.

-user 사용자 ID

숫자로 표시된 UID나 /etc/passwd
내에 기록된 사용자 이름으로, 프로그램이 기동될 때 사용되어야 한다.

-chroot rootdir

관련자료

댓글 0
등록된 댓글이 없습니다.

공지사항


뉴스광장


  • 현재 회원수 :  60,056 명
  • 현재 강좌수 :  35,910 개
  • 현재 접속자 :  261 명