ToyBSD WeBlog (포기하지 않으면 실패는 없다)

http://taz.net.au/postfix/mrtg/

NOTE:?This hack needs the File:?:Tail perl module by Matija Grabnar.
Download it from CPAN and install it first.
See 'man CPAN' for more info about installing CPAN modules.

DOWNLOAD

---

You need to download the following three scripts:

update-mailstats.pl
mailstats.pl
mrtg-mailstats.pl

save them all in /usr/local/bin and make them executable.

if you save them in a different directory then you will have to edit the
following line in mrtg-mailstats.pl:

HOWTO

---

1. run the update-mailstats.pl program in the background like so:

(you probably want to write a wrapper script to restart it in case it
ever gets killed.)

this updates a file called /tmp/stats.db (adjust to suit your needs)
with the inbound and outbound mail stats.

the logic of this script is extremely simple (and probably far from
perfect):

if the line contains "status=sent" then figure out the transport from
the "relay=" part of the line. if relay= contains "[" then assume it's
an IP address, and transport is smtp. otherwise, transport is whatever
the "relay=" bit says.

if line contains "smtpd.*client=" then we've received a message via
smtp. if line contains "pickup.*(sender|uid)=" then we've received a
message from a local user.

very simple, mostly works. i'm sure there are cases which it doesn't
catch. if you can improve it, let me know.

to tell the truth, it doesn't matter if it's 100% accurate or not.
the point is to give a pretty graph of some meaningless numbers to
management types. they love it

2. if you want to see the raw data, use the mailstats.pl script:
3. add lines like the following to your mrtg.cfg:

this runs the mrtg-mailstats.pl programs which totals the RECEIVED and
SENT lines output by mailstats.pl and then outputs it in a form
suitable for MRTG. it keeps the previous RECEIVED and SENT counts in
/tmp/mailstats.old

위와 같이 하면 성공.

update-mailstats.pl & 을 실행했을때, 아래와 같은 에러 메세지를 출력한다면,
Can't locate File/Tail.pm in @INC.....

# wget http://search.cpan.org/CPAN/authors/id/M/MG/MGRABNAR/File-Tail-0.98.tar.gz# tar xvfz File-Tail-0.98.tar.gz# cd File-Tail-0.98# perl Makefile.PL# make# make test# make install하여, File-Tail을 설치를 해준다...

http://www.kr.freebsd.org/~cjh/freetime/os/freebsd/pse/200206/

프로그램세계 2002년 6월분

ipfw/natd 로 방화벽과 인터넷 게이트웨이 만들기
최준호, Korea FreeBSD Users Group <cjh at kr.FreeBSD.org>

---

이번달에는 FreeBSD로 간단한 방화벽과 로컬 인터넷 서버를 만드는 방법에 대해 알아보자. FreeBSD는 기초적이면서도 고급 활용이 가능한 뛰어난 패킷 필터 시스템을 두가지 갖고 있다.
이달의 FreeBSD 소식
공지/소식
-stable 트리는 4.6을 위한 코드 프리즈 단계에 들어갔다. 4.6의 릴리즈 예정일은 6월 1일인데, 실제 릴리즈는 이보다는 조금 늦을 것으로 전망된다.

5.0-?DP1이 4월 8일에 릴리즈되었다. 5.0-?DP1은 올해 말에 있을 5.0 릴리즈의 새로운 기능을 사용자에게 미리 맛보이기 위한 프리 릴리즈의 성격을 갖고 있으며, FTP 설치 또는 ISO 파일을 다운로드할 수 있다.
5.0-?DP1은 i386, alpha, sparc64용의 세가지 플랫폼으로 릴리즈되었다. i386과 alpha는 각 FTP 미러의 /pub/FreeBSD/releases/{i386,alpha}/5.0-?DP1 디렉토리 또는 /pub/FreeBSD/releases/{i386,alpha}/ISO-IMAGES 디렉토리에서 구할 수 있으며, sparc64 버전은 /pub/FreeBSD/development/sparc64 디렉토리에서 별도로 구할 수 있다.

코어의 잇단 사임; 2000년에 선출한 코어 팀 중 Satoshi Asami가 일신상의 이유로 사임한 이래 최근에 Jordan Hubbard, Michael Smith가 연속적으로 코어 팀을 사임하였다. 최근에 FreeBSD 개발진 사이에서 프로젝트의 운영 방향이나 방식을 놓고 여러가지 논란이 있던 중이었으며, 세명이 사임함에 따라 규칙에 의해 올해로 예정되어 있던 코어 팀 선출을 앞당길 예정이다.
시스템 업데이트
inetd_enable의 기본값이 다시 YES가 되어서, 기본적으로 inetd가 뜨게 된다. 물론 /etc/inetd.conf는 계속 모두 주석처리되어 있으므로 기본적으로 뜨는 대몬은 없다.

sendmail_enable의 기본값이 YES가 되어서, 시스템을 설치하면 sendmail이 동작한다.

sendmail 시작 스크립트에서 서로 다른 MTA를 띄울 수 있도록 되었다. 현재로서는 /etc/rc.sendmail이 sendmail을 띄울 수 있도록 하지만, rc.conf의 mta_start_script를 바꾸면 다른 MTA의 시동 스크립트를 사용할 수 있다.

/etc에 많은 부분이 MFC되었으므로, -stable로 업데이트하는 사용자는 mergemaster에 새로 생긴 -C 옵션을 사용하면 기본값과 다른 사용자의 rc.conf를 보여준다. 기본값이 바뀐 옵션등을 주의해서 살펴보자.

-stable의 기본 ?XFree86 시스템에 기존의 3.3.6에서 4.2.0로 바뀌었다. 이에 따라 6월 1일에 릴리즈 예정인 4.6-RELEASE에서는 기본적으로 ?XFree86 4.2.0이 포함될 예정이며, 이에 따라 설치 프로그램도 많이 바뀔 예정이다.
보안 업데이트
다음은 이달의 보안 권고 사항이다. 02:23의 stdio 버그, 02:20의 syncache 버그 등은 매우 중요하므로, 4.5-RELEASE 사용자는 RELENG_4_5 브랜치를 사용하여 업데이트하도록 하자. 현재 4.5-RELEASE p4 까지 나와 있다.
FreeBSD-SA-02:23.stdio.asc
FreeBSD-SA-02:22.mmap.asc
FreeBSD-SA-02:21.tcpip.asc
FreeBSD-SA-02:20.syncache.asc
FreeBSD-SA-02:19.squid.asc

FreeBSD와 방화벽
방화벽이란
일반적으로 방화벽(firewall)이라 함은 인터넷 상에 위치하여 외부 네트워크로부터 내부 네트워크를 보호하는 시스템을 의미한다. 여러가지 방식의 방화벽에 존재할 수 있지만 크게 패킷 필터링을 통한 방화벽 시스템과 어플리케이션 수준의 방화벽 시스템으로 나눌 수 있다. IP 수준의 패킷을 판별하여 선별적으로 통과시키는 것을 패킷 필터링 방화벽이라고 하며, 특정 어플리케이션 프로토콜(HTTP, SMTP, POP 등)을 이해하여 특정 프로토콜의 대리자(proxy)로 동작할 수 있는 것을 어플리케이션 수준 방화벽이라고 할 수 있다. 다른 종류도 있지만 이 글에서는 이 두가지에 대해서만 생각해 보자.
패킷 필터 방화벽의 장점은 보통 패킷(이더넷 프레임도 포함할 수 있다) 수준에서 필터링 여부가 결정되기 때문에 실제 서버까지 전달되지 않는다는 장점이 있다. 하지만 모든 패킷을 처리해야 하고, TCP/UDP 수준까지는 패킷 필터에서 이해하는 경우가 많지만(엄밀히 말하면 그건 IP 패킷 필터 방화벽의 수준을 넘어서는 일이기는 하다) 실제 어플리케이션 프로토콜에 대해서는 무지하기 때문에 단순히 오고가는 패킷의 주소만으로 필터 여부를 판정해야 하기 때문이다.

어플리케이션 수준 방화벽은 HTTP 프록시와 같이 특정 프로토콜을 이해하여 적절한 수준의 대리 접속을 해 주는 것으로, 상용 또는 공개의 방화벽 툴킷을 사용하거나 squid와 같은 웹 프록시 시스템에 포함되어 있다. 사용자 기반 인증 등 여러가지 다양한 능력을 수행할 수 있다는 장점이 있지만 사용자는 사용하고자 하는 프로토콜별로 서로 다른 프록시를 사용해야 하고, 각 프로토콜마다 별도의 프록시 서버가 개발되어야 한다는 단점이 있다.

일반적으로 사무실이나 가정에서 사용하는 소규모 네트워크의 경우 어플리케이션 수준 프록시로 사용할 정도의 일은 웹 프록시 정도가 대부분일 것이다(SOCKS와 같은 어플리케이션 수준 방화벽 프록시 시스템을 사용하지 않는다면).

패킷 필터 방화벽은 생각보다 간단한데, 다음과 같은 규칙을 사용하는 것이 대부분이다. IP 패킷은 기본적으로 다음과 같이 정의될 수 있다. 패킷 헤더에는 기본적으로 다음과 같은 정보가 기록되어 있으므로 이를 이용한다.

필터링 규칙은 이 조건을 지정하는 것이다. 즉 1.2.3.4의 80번 포트로 가는 모든 패킷을 막고 싶다면 규칙은
와 같이 지정될 수 있으며, 2.3.4.5에서 들어오는 모든 접속을 허가하고 싶다면 다음과 같이 규칙을 만들 수 있다.
대부분의 패킷 필터 방화벽은 위와 같은 규칙을 나름대로의 문법에 맞게 사용하면 가능하다.
NAT
NAT(Network Address Translation)은 ?IPv4 인터넷 주소의 고갈과, 실제 인터넷에서 연결되어 있지만 외부에서 분리된 사설 네트워크를 구성하기 위해서 사용하는 기법이다. 구체적으로는 그 이름에서도 알 수 있듯이 네트워크 주소를 변환하는 방법으로 이루어지며, 운영체제에 따라 이름이 조금씩 다르기도 한데, BSD 운영체제에서는 보통 NAT라고 부르고, 리눅스에서는 IP 매스커레이드(IP Masquerade)라고 부르는 것이 보통이다. NAT나 IP 매스커레이드나 같은 말이므로 혼동하지 말자.
일반적으로 NAT 공인 IP 와 사설 IP 사이에서 일종의 라우터로 동작할 수 있으며, 내부 네트워크의 패킷이 외부로 나갈 때에는 지정된 매핑 방법에 의해 패킷의 주소를 다시 쓰게 된다. 들어오는 패킷의 경우, 사설 IP 대역의 경우 ?IPv4 주소를 갖지만 라우팅이 될 수 없는 주소로 정의되어 있으므로, 외부 네트워크에서 내부 네트워크로 패킷이 직접 도달할 수는 없다.

NAT의 원리
따라서 NAT 서버가 정해진 규칙에 따라 패킷의 도착 주소를 다시 쓰게 된다. 간단하게 생각하면 다음과 같다. 내부에서 외부로 나가는 다음 패킷을 가정해 보자.
이 경우 NAT서버는 포트를 하나 할당하고 여기에 이를 기록한 다음 보내는 주소를 바꾸어 쓴다. 할당받은 포트가 50000번이라고 해 보자.
이렇게 하면 이 패킷의 응답으로 들어오는 패킷은 다음의 주소를 가지므로,
NAT서버는 아까 할당되었던 포트 번호를 기억하고 있다가 내부 네트워크로 패킷을 보낼 때 포트에 할당되었던 주소로 바꾸어 쓴다.
이렇게 하여 내부에서 외부로 통신이 가능하다. 단 외부에서는 내부 주소로 라우팅이 불가능하므로 들어올 수 없는데, 이는 포트 전송(port forwarding) 이라는 기법을 사용하면 가능하다. 즉 NAT 서버의 특정 포트를 내부 네트워크의 특정 IP:?포트로 매핑하는 것이다. 즉 다음과 같이 설정되었을 때,
211.46.52.100:40000을 향해 들어오는 패킷은 모두 192.168.1.10:80 으로 보내고, 돌아가는 패킷은 그 반대로 처리하면 된다.
대부분의 NAT 서버는 위의 두 기능을 모두 수행할 수 있다. 다만 FTP등과 같이 포트를 서버에서 할당하는 경우 등에는 문제가 발생할 수 있으므로, 특별한 처리를 하는 것이 보통이다.
FreeBSD의 내장 패킷 필터 시스템
FreeBSD는 두가지의 패킷 필터 방화벽 시스템이 기본 시스템에 포함되어 제공된다. 하나는 FreeBSD 고유의 ipfw(8)이며, 두번째는 Darren Reed씨의 멀티플랫폼 지원의 ipfilter(8)이다. 두가지는 각각 장단점이 있는데, 간단히 정리해 보면 다음과 같다.
항목 ipfw ipfilter
이식성 FreeBSD전용 멀티플랫폼
규칙적용 먼저 맞는 순 가장 나중에 맞는 순
사용 모듈 모듈
NAT natd(8) 대몬 내장(ipnat으로 제어)
TCP 상태 필터링 가능 가능
규칙 그룹 없음 있음
패킷 전송 가능 가능
브리지 지원 가능 불가능
대역폭 제어 가능(dummynet) 불가능
?IPv6 지원 가능(ip6fw) 불가능
표: ipfw와 ipfilter * ipfilter는 리눅스, 솔라리스, FreeBSD, ?NetBSD, OpenBSD, IRIX 등에서 모두 동일하게 동작한다.

FreeBSD 사용자라면 ipfw에 익숙해지는 편이 좋을 것이다. ipfilter로 기본적인 방화벽 사용은 가능하지만, 조금 더 고급 기능인 대역폭 제어나 이더넷 브리지 지원 등이 되지 않기 때문이다. ipfw는 FreeBSD 2.0에서 처음 등장하였으며, 2.2.8에서 대역폭(dummynet)지원을, 4.0부터 TCP 상태 제어가 가능하였으며, 4.4 릴리즈부터 모듈로 읽어들이는 일이 가능해졌다. 또한 ip6fw(8)명령을 사용하여 ?IPv6 패킷도 필터링이 가능하다(?IPv6은 NAT가 필요 없으므로 natd에서는 지원하지 않는다). ipfilter
ipfilter는 오픈 소스이면서도 외부인에 의한 첨삭을 임의로 허용하지 않는 (저자에게 미리 알려야 한다) 라이센스 때문에 OpenBSD에는 논쟁 끝에 ipfilter를 기본 소스 트리에서 제외시키고 pf라고 하는 독자적인 패킷 필터 시스템을 만들었다. pf는 ipfilter와 동일한 인터페이스를 갖는다. 실제로 OpenBSD 3.0부터는 ipfilter대신 pf가 포함되어 릴리즈되었는데, Darren씨는 pf를 빼고 ipfilter를 넣은 OpenBSD 3.0 배포본을 별도로 릴리즈하기도 하였다.

ipfilter 홈페이지: http://www.ipfilter.org

ipfw로 방화벽 만들기
이번에는 ipfw를 사용한 방화벽 만들기에 도전해 보자. ipfilter의 경우는 이번에 소개하지 않지만, 기본적인 문법만 다를 뿐 원리는 같으므로 동일하게 설계한 네트워크를 ipfilter로도 구현할 수 있다.
ipfw 설정하기
ipfw를 모듈로 읽어들일 수 있다고 하였지만, 기본적인 ipfw 설정은 커널에서 해 주는 편이 좋다. 다음은 기본적인 ipfw 관련 커널 옵션이다. 다음 설정을 커널 설정 파일(/sys/i386/conf/커널설정파일명)에 추가해 주기 바란다. 아래 옵션은 기본 커널인 GENERIC에 포함되어 있지 않으므로, 자세한 내용은 /sys/i386/conf/LINT 파일을 참고하기 바란다.
# ipfw 방화벽 코드를 사용한다. ipfw.ko 를 읽어들이는 것과 동일하다.
# 방화벽 코드는 커널에서 포함시키는 것이 보안상 안전하다.
options IPFIREWALL
# ipfw의 로그를 syslogd(8)을 통해 출력하도록 한다.
options IPFIREWALL_VERBOSE
# 해당되는 패킷이 많으면 메시지가 너무 많으므로 한도를 정한다.
options IPFIREWALL_VERBOSE_LIMIT=100
# ipfw의 패킷 전송 기능을 사용할 수 있도록 한다.
options IPFIREWALL_FORWARD
# ipfw는 기본적으로 모든 패킷을 거부하도록 되어 있다.
# 이를 기본적으로 모든 패킷을 허용하는 것으로 바꾼다.
options IPFIREWALL_DEFAULT_TO_ACCEPT

# ?IPv6 방화벽 코드를 사용한다.
# 나머지 옵션은 IPFIREALL_*의 그것과 동일한 의미이다.
options ?IPV6FIREWALL
options IPV6FIREWALL_VERBOSE
options IPV6FIREWALL_VERBOSE_LIMIT=100
options IPV6FIREWALL_DEFAULT_TO_ACCEPT

# divert(4)는 패킷의 방향을 주소에 관계없이 특정 포트로 바꾸어주는
# 인터페이스이다. 이는 NAT에서 패킷을 다시 쓰기 위한 방법으로 사용할
# 수 있으며, NAT를 사용하기 위해서는 반드시 포함되어야 한다.
# ipfw를 모듈로 읽어들이는 경우 이 옵션을 주고 빌드해야만 NAT를 사용할
# 수 있다.
options IPDIVERT

기본적으로 방화벽을 사용하려면 IPFIREWALL 옵션을, NAT를 사용하려면 IPDIVERT 옵션을 추가하면 된다. 투명 프록시 등의 기능을 이용하려면 IPFIREWALL_FORWARD를 추가하면 된다.
모듈로 읽어들이려는 경우에는 /modules/ipfw.ko 를 읽어들이도록 하면 된다. 대역폭 제어 기능을 활용하려면 dummynet.ko도 읽어들여야 한다는 점도 잊지 말자.

ipfw 명령
ipfw는 명령행으로 규칙을 추가할 수 있고, 파일로 만들어진 규칙을 읽어들이도록 할 수도 있다. 가령 규칙이 한 행에 하나씩 쓰여진 파일이 있다면
와 같이 읽어들일 수 있다.
규칙을 명령행으로 하나씩 추가하려면, 번호와 함께 add/delete를 사용할 수 있다.

이렇게 하면 500번 규칙에 allow ip from any to any 가 추가된다. 같은 번호에 두개 이상의 규칙이 있을 수 있다는 점에 주의하자. 해당 번호의 규칙을 지우고 싶다면
하면 된다. 현재의 규칙 목록을 보려면
하면 되며, 규칙에 일치된 패킷의 수와 바이트 수까지 알고 싶다면 다음과 같이 한다.
규칙을 모두 지우려면
로 지울 수 있다.
ipfw의 규칙 문법
ipfw는 매우 간단하고 직관적인 문법을 갖고 있다. 기본적으로는 각 패킷을 어떻게 처리할 지의 규칙을 기술해 주면 되며, 규칙은 다음과 같이 구성되어야 한다.
각 규칙에는 번호가 있다(1 ~ 65535).
규칙은 번호가 낮은 순서부터 적용된다.
가장 먼저 일치한 규칙이 바로 적용되고 그 다음 규칙은 넘어간다.
65535 번 규칙은 기본 규칙으로 모든 패킷에 적용된다. (IPFIREWALL_DEFAULT_TO_ACCEPT 옵션을 주었으면 모두 허가, 아니면 모두 거부이다)
즉 ipfw의 문법 처리는 규칙을 순서대로 나열해 주는 것이다.
ipfw 규칙의 기본적인 문법은 다음과 같다.

prob 확률
확률은 0에서 1 사이의 값으로 패킷이 통과할 확률을 정한다. 이는 가상의 네트워크 환경을 흉내내거나, 일부러 패킷을 확률적으로 버려야 할 때 사용할 수 있다.

동작
동작에는 크게 다음과 같은 것이 있다. 실제 동작은 이보다 더 자세하며, 그 정보에 대해서는 매뉴얼 페이지를 참고하자.

allow 패킷 통과를 허가한다.
deny 패킷 통과를 거부한다.
unreach 패킷 통과를 거부하고 정해진 코드의 ICMP 통지를 한다.
reset 패킷 통과를 거부하고 TCP RST를 보낸다.
divert 정해진 포트의 divert(4) 소켓으로 보낸다. NAT에서 사용.
fwd 패킷을 정해진 주소와 포트로 전달한다.

log ?logamount 숫자
규칙에 일치하는 경우 로그를 남긴다. 로그의 크기는 logamount로 제한할 수 있으며, 커널 옵션 IPFIREWALL_VERBOSE_LIMIT와 sysctl MIB net.inet.ip.fw.verbose_limit에서 정한 숫자보다 우선한다.

패킷 타입
패킷의 종류로, 보통 ip, tcp, udp, icmp 등이 사용된다. 자세한 패킷 종류 목록은 /etc/protocols를 보자.

송신처와 수신처
이는 패킷을 보낸 곳과 갈 곳을 나타내는데, TCP/IP 시스템에서는 보통 IP 주소와 포트로 표현된다. 문법은 다음과 같다.

any 모든 주소
me 이 컴퓨터의 주소
주소/마스크 세가지 표현이 가능하다.
211.45.78.6 (단일 IP)
211.45.78.6/24 (C 클래스)
211.45.78.6:255.255.255.0 (C 클래스)
포트 포트는 여러개(쉼표로 구분) 또는 -를 사용하여 범위 지정이 가능하다. 번호 대신 smtp, ssh와 같은 이름을 사용할 수도 있는데, 자세한 포트 이름은 /etc/services를 보자.
21,23,6000-6010
ssh
인터페이스 정보
패킷이 지나가는 인터페이스를 지정할 수 있다.

in 들어오는 패킷
out 나가는 패킷
via ifX ifX(fxp0와 같은 인터페이스명)을 지나는 패킷

옵션
옵션은 여러가지가 있으나, 가장 눈여겨 볼 것은 keep-state 옵션이다. 이는 TCP 또는 UDP의 접속 상태를 유지할 수 있는 동적 규칙을 생성하게 한다. 동적 규칙은 일정 시간 이후 사라진다.

established TCP에서 RST나 ACK 비트가 지정된 경우에 해당
setup TCP에서 SYN만 있고 ACK 비트가 없는 경우에 해당

위 두 옵션은 TCP 연결을 확립하는 과정의 상태를 나타낸다. 즉 특정 조건에 해당하는 TCP 연결만 허가 또는 거부하고 싶을 때 keep-state와 연계하여 사용할 수 있다.

몇가지 예를 들어 보자.
외부에서 오는 모든 접속을 차단
211.45.78.3에서 오는 TCP 패킷을 차단
외부에서 211.45.78.100(이 호스트의 주소라 가정)의 HTTP 연결을 허가
211.44.63.0/24 대역에서의 ssh 접속을 허가
8868(NAT 대몬 포트)로 tun0장치에서 지나가는 모든 패킷을 divert 소켓으로 전송
192.168.1.0/24에서 외부 HTTP로 접속하는 모든 패킷을 192.168.1.1의 3128 포트로 전송(port forwarding)
ipfw는 모든 네트워크 인터페이스에 영향을 미치는데, 루프백 장치(lo0)도 예외는 아니라는 점을 명심하자.
기본적인 방화벽 만들기
이제 기본적인 지식을 익혔다면 간단한 방화벽을 만들어 보자. 방화벽을 만들기 전에 할 일은 그 정책을 정하는 일이다. 다음의 내용을 사전에 미리 생각해 두면 된다.
허가할 규칙 목록
거부할 규칙 목록
그 외 정책(NAT, 포트 전송 사용)
기본 규칙(허가 또는 거부)
ipfw는 매우 직관적인 문법을 허가하므로, 먼저 규칙을 잘 만들어 놓으면 그대로 ipfw 규칙으로 옮겨 적으면 된다. 가령 다음과 같은 예를 들어 보자.
서버 네트워크

네트워크 IP: 192.168.1.100, 넷마스크: 255.255.255.0 (24)
내부 네트워크에서 웹 서버, ssh 대몬 서비스
나머지 특권 있는 포트(1-1023)의 서비스는 거부
ping(ICMP)는 0, 3, 8, 11번만 응답 (echo reply, destination unreachable, echo request, time-to-live exceeded)
나머지 연결은 허가

규칙 정리

패킷을 모두 허가하는 방법은 두가지가 있다. 하나는 allow ip from any to any 규칙을 맨 마지막에 넣어 주는 것이고, 두번째는 IPFIREWALL_DEFALULT_TO_ACCEPT를 사용하는 것인데, 60000번 정도에 allow ip from any to any를 넣어 주면 커널 옵션에 관계없이 사용할 수 있다.

ipfw 규칙 파일
위의 규칙 정리를 기반으로 하여 다음과 같은 내용으로 /etc/ipfw.conf를 만든다.

마지막의 allow ip from any to any는 가장 뒷부분에 넣기 위해 일부러 60000번의 규칙을 부여하였다.
파일에 있는 내용을 한번에 적용하려면 위에서처럼

라고 해 보자. 이후에 원하는 대로 패킷 전송이 제어되고 있으면 성공이다. 단 잘못되는 경우 되돌리려면 ipfw -f flush 를 사용해야 하는데, 콘솔이 아닌 네트워크 연결 상태에서는 기본 규칙이 거부의 경우 네트워크가 바로 끊어지므로 방화벽 설정은 되도록이면 콘솔에서 해야 한다.
제대로 되고 있는지 살펴보는 좋은 방법은 list옵션에 -a를 주는 것이다. 첫번째 열은 규칙 번호, 두번째는 이 규칙에 해당한 패킷 수, 세번째는 이 규칙에 해당한 총 전송량(바이트)이다.

# ipfw -a list
00100 1466 82308 allow ip from any to any via lo0
00200 0 0 deny ip from any to 127.0.0.0/8
00400 0 0 deny ip from 127.0.0.0/8 to any
00500 383 44797 allow tcp from 192.168.2.0/24 to 192.168.1.100 80,22
00600 0 0 deny ip from any to 192.168.1.100 1-1023
00700 41 2296 allow icmp from any to any icmptype 0,3,8,11
00800 0 0 deny icmp from any to any
60000 31011 2814393 allow ip from any to any
65535 0 0 allow ip from any to any

로그 기능을 사용하도록 하였다면 콘솔이나 /var/log/secure, /var/log/messages 파일에 로깅되는 패킷이 표시된다. 제한이 있지만 초반부에 패킷을 분석하는데는 좋을 것이다.
시스템 설정
이제 만들어진 규칙을 적용하고 시스템을 다시 부팅할 때 그 규칙이 바로 적용되도록 해 보자. /etc/rc.conf에 다음과 같이 적는다.
firewall_enable="YES"
firewall_type="/etc/ipfw.conf"

방화벽 사용 옵션을 YES라고 하고, type에 규칙 파일을 적어주면 시작시에 ipfw 설정을 하게 된다. firewall_type에는 여러가지가 있는데, open, client, simple, closed, UNKNOWN 등의 미리 만들어진 규칙이 있다. 이에 대해서는 /etc/rc.firewall 앞부분의 주석을 읽어보자.
rc.conf에 필요한 부분을 설정하였으면 재부팅하고, 규칙이 제대로 설정되었는지 살펴본다.

natd로 기본적인 NAT 환경 구축하기
이번에는 NAT 환경에 대해서 알아보자. 보통은 집이나 소규모 사무실, 교육장과 같은 환경에서 공인 IP가 모자랄 경우 NAT를 사용해서 네트워크를 구축할 수 있다. 이 경우 내부 네트워크는 외부 라우팅이 불가능한 사설 IP 대역을 사용해야 한다. 사용할 수 있는 사설 IP 대역은 ?RFC1918에 정의되어 있으며, 다음과 같다.
10.0.0.0 ~ 10.255.255.255 (10/8 prefix)
172.16.0.0 ~ 172.31.255.255 (172.16/12 prefix)
192.168.0.0 ~ 192.168.255.255 (192.168/16 prefix)
일반적으로 많이 사용하는 것은 10.0.0.1/8 이나 192.168.0.0/24이다. 아무 영역이나 사용할 수 있으므로 편리한 대로 이용하자.
다음과 같은 환경에서 NAT를 구축한다고 생각해 보자.

| 211.99.82.1 (fxp0)
|
이 경우, FreeBSD 서버에는 랜 카드가 두장이 있고, 내부 네트워크의 PC는 모두 허브에 연결되어 있어야 한다. 내부 네트워크에 있는 PC는 게이트웨이를 192.168.1.1로 잡으면 된다.
NAT를 사용하기 위해서는 먼저 ipfw 환경이 구축이 되어 있고, NAT를 위한 규칙을 추가한 다음에 natd를 적절한 옵션으로 실행하면 된다.

natd
natd는 ipfw와 연계되는 NAT 대몬으로, NAT를 사용하려면 항상 실행해 두어야 한다. 자세한 옵션은 natd(8) 매뉴얼 페이지에서 읽어보자. 보통 일반적인 NAT서비스를 위해서는 별도 옵션 없이 인터페이스만 지정해서 그대로 실행하면 된다. 그 이전에 NAT를 위한 특별한 규칙이 ipfw 방화벽에 추가되어야 한다. 이 규칙은 가장 앞부분에 있어야 한다.
# ipfw add 50 divert 8668 ip from any to any via fxp0
이 경우 장치명은 공인 IP가 부여된 인터페이스명(여기서는 fxp0)이라는 점에 주의하자. 8868은 NAT가 리스닝하는 포트 명으로, 이 규칙은 fxp0를 통해 지나다니는 패킷을 natd로 divert 소켓을 사용하여 전송하고, natd는 받은 패킷을 적절히 다시 쓰게 된다. 이제 natd를 실행하자.
# /sbin/natd -n fxp0
그리고 나서 내부 네트워크에서 외부 접속이 가능한지 확인해 보자. natd의 옵션은 명령행으로 줄 수도 있지만, 별도의 설정 파일에 주는 것도 가능하다. 만약 다음과 같은 옵션을 사용하고 싶다면
# /sbin/natd -same_ports -unregistered_only -interface fxp0
설정 파일로 옵션을 한 줄에 하나씩 쓰고 그것을 사용할 수 있다. 아래 파일을 /etc/natd.conf라고 하자(옵션의 의미는 natd 매뉴얼을 읽어보자).
same_ports
unregistered_only
interface fxp0

그러면 natd를 다음과 같이 실행할 수 있다.
# /sbin/natd -f /etc/natd.conf
natd를 실행시에도 동작하게 하려면 /etc/rc.conf에 다음과 같이 지정한다.
firewall_enable="YES"
firewall_type="open"
natd_enable="YES"
natd_interface="fxp0"
natd_flags="-f /etc/natd.conf"
gateway_enable="YES"

위의 두개는 방화벽을 사용하기 위한 것이고(firewall_type은 자신이 사용하는 것이 있다면 그것을 사용해야 한다), natd_flags에는 옵션을 지정한다. gateway_enable은 인터페이스간 패킷 전송을 가능하게 하는 것이다. 이는 ipfw + nat 환경에서 꼭 필요한 옵션이며, 실제로는 다음과 같은 명령을 실행하는 것과 동일하다.
다시 부팅해서 NAT가 제대로 동작하는지 확인해 보자. NAT가 제대로 동작하는지 확인하기 위해서는 다음 사항을 점검하면 된다.
ipfw를 사용 가능한지
커널 옵션에 IPDIVERT가 추가되어 있는지
natd가 실행되고 있는지
net.inet.ip.forwarding sysctl MIB가 1로 지정되어 있는지
방화벽 규칙에 divert 8668이 추가되어 있는지
가장 간단한 형태(firewall_type="open")으로 만들어진 경우 방화벽 규칙은 다음과 같이 나타나야 한다.
# ipfw list
00050 divert 8668 ip from any to any via fxp0
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
00300 deny ip from 127.0.0.0/8 to any
65000 allow ip from any to any
65535 allow ip from any to any

firewall_type에 위에서처럼 open 등의 정해진 타입이 아니라 별도의 설정 파일을 사용하더라도 NAT를 위해 divert 규칙을 추가할 필요는 없다. /etc/rc.firewall은 방화벽을 사용하고(firewall_enable), NAT를 사용하는 경우(natd_enable) 자동적으로 50번 규칙을 추가한다.
NAT가 동작하면 여러가지 재미있는 일을 할 수 있다. 로컬 DNS 캐시를 만들 수도 있고, DHCP서버를 사용하여 네트워크 자동 설정, squid를 이용한 웹 프록시 등 다양한 활용이 가능하므로 재미있게 사용해 보자.

고급 활용
이제 ipfw + natd 방화벽에 대해서 알아보았으니, 조금 더 고급 처리 방법에 대해 알아보자.
cpp를 이용 매크로 처리
ipfw.conf는 전처리기(preprocessor)를 통한 처리가 가능하다. 가령 다음과 같이 /etc/rc.conf에 지정해 두었다면,
firewall_enable="YES"
firewall_type="/etc/ipfw.conf"
firewall_flags="-p cpp"

ipfw.conf는 C 전처리기(cpp)를 사용하여 다음과 같이 사용할 수 있다.
/*

• my ipfw.conf
  
• /
  
  

#define ALLOW_SSH(ipaddr) add allow tcp from ipaddr to any 22
#define ALLOW_WWW(ipaddr) add allow tcp from ipaddr to any 80

add allow ip from any to any via lo0
add deny ip from any to 127.0.0.0/8
add deny ip from 127.0.0.0/8 to any

ALLOW_SSH(192.168.2.0/24)
ALLOW_WWW(192.168.4.11)

add deny ip from any to 192.168.1.100 1-1023
add allow icmp from any to any icmptype 0,3,8,11
add deny icmp from any to any
add 60000 allow ip from any to any

이 예제에서, IIF, ALLOW_SSH등의 매크로는 C에서 사용하던 것과 그대로 사용할 수 있다. 이 방법을 잘 응용하면 반복되는 작업을 매크로를 사용하여 편리하게 사용할 수 있다.
패킷 포워딩
IPFIREWALL_FORWARD 옵션을 사용하면 패킷 포워딩을 쉽게 구현할 수 있다. 위의 natd 예제에서, 게이트웨이 서버에 squid나 wwwoffle와 같은 웹 프록시가 설치되어 있고, 3128 포트에서 투명 프록시 모드로 사용 가능하다고 생각해 보자. 이 포트로 웹 트래픽을 강제로 보내기 위해 다음 규칙을 ipfw에 추가할 수 있다.
add 30 fwd 192.168.1.1,3128 tcp from 192.168.1.0/24 to any 80 via fxp0

이렇게 하면 192.168.1.0/24 네트워크에서 외부의 HTTP 포트에 접속하는 모든 패킷은 192.168.1.1:3128 포트로 연결된다. 이곳에 투명 프록시가 존재하면 사용자는 별도로 프록시 설정 없이 자동으로 웹 프로시를 사용하게 된다.
NAT 사용시 외부에서 내부로의 접속
NAT 사용시 사설 IP 대역을 사용한다면, 외부에서는 내부로 접속이 불가능하다. 이 경우 NAT 서버의 특정 포트를 내부 서버의 특정 IP와 포트로 지정하여, 외부에서 내부로 접속이 가능하게 할 수 있다.
위 NAT 환경 구축 예에서, 192.168.1.100에서 웹 서버에 80번 포트로 동작하는 경우, 외부에서 접속하기 위해서는 먼저 게이트웨이의 공인 IP인 211.99.82.1 에 적당한 포트를 지정해야 한다. 가령 8080번이라고 하면, natd 옵션에 다음을 추가한다.

/sbin/natd -n fxp0 -redirect_port tcp 192.168.1.100:80 8080

이렇게 하면 211.99.82.1:8080 으로 접속하는 것은 192.168.1.100:80 으로 접속하는 것과 동일하다.
여러개의 포트를 여러 주소로 연결하려면 설정 파일을 두는 편이 좋다.

브리지
이더넷 브리지는 두 동일한 이더넷 환경(같은 서브넷)을 이어주는 다리 역할을 하며, 구체적으로는 서로 오가는 패킷을 그대로 전달해 주는 역할을 한다. FreeBSD에서는 브리지 구현을 사용할 수 있으며, 이를 위해서 커널 옵션에 다음을 추가한다.
그리고, /etc/sysctl.conf에 다음과 같이 지정하면 브리지 설정을 할 수 있다. 브리지 설정이라면 연결할 두 네트워크 장치를 지정하는 것이다.
# 브리지 사용
net.link.ether.bridge=1
# 브리지에서 ipfw 패킷 필터 사용 가능
net.link.ether.bridge_ipfw=1
# 브리지로 연결할 두 네트워크 장치 지정
net.link.ether.bridge_cfg=fxp0:0,fxp1:0

또한 브리지에서 ipfw 를 통한 패킷 필터링을 할 수 있는데, 이는 소규모 네트워크에서의 패킷 필터 방화벽을 만드는데 아주 편리하게 사용할 수 있다.
다음과 같은 구성을 생각해 보자.

------
즉, 내부 네트워크와 라우터 사이에 브리지 방화벽을 설치하는 것으로, 기존 네트워크 구성을 변경할 필요 없이 브리지 형태의 방화벽 추가가 가능하다. 브리지는 반드시 IP를 가질 필요는 없지만, 그렇게 하면 콘솔에서만 접속이 가능하므로 안쪽에는 IP를 갖도록 한다.
남은 것은 적절한 규칙을 만드는 일인데, ?DaemonNews의 다음 기사를 참고하면 비교적 쉽게 만들 수 있을 것이다. 이 기사는 ipfilter를 기준으로 쓰여 있지만, ipfw 방화벽 규칙으로 변환하는 것은 어렵지 않다.

Daemon News : OpenBSD bridge without ?IPs using IPF Tutorial
http://www.daemonnews.org/200103/ipf_bridge.html
대역폭 제어
ipfw와 dummynet(4)를 사용하면 방화벽으로 지나가는 패킷의 대역폭 제어가 가능하다. dummynet는 지나가는 패킷의 대역폭 제어나 확률 기반의 패킷 버림 등의 처리가 가능하므로, 악조건의 네트워크를 흉내내는 시뮬레이터의 역할을 할 수도 있다.
이 기능을 사용하기 위해서는 커널 옵션에 다음을 추가하거나 dummynet.ko를 읽어들여야 한다.

options DUMMYNET

설정은 ipfw 매뉴얼 페이지에 자세히 나와 있는데, 간단한 몇가지 예제만 들어보기로 하자. 먼저 대역폭 제어를 할 규칙을 정한다.
이 경우 파이프 1번이 192.168.2.0/24 네트워크에서 다른 쪽으로 가는 패킷 모두에 대해 적용된다. 그 다음에는 pipe 1을 설정한다.
이렇게 하여 pipe 1의 대역을 128kbit 로 제한할 수 있다. pipe는 번호를 붙여 여러개를 만들 수 있다. 확률로 패킷을 버리려면 다음과 같이 한다.
이 경우 5%의 확률로 해당 규칙에 맞는 패킷을 버린다.
끝으로
이번달에는 ipfw + natd를 사용하여 FreeBSD에서 방화벽과 NAT 네트워크 서버를 구축하는 방법에 대해 알아보았다. ipfw는 내장되어 있고 알기 쉬운 문법을 제공하므로 방화벽에 대한 기본적인 원리만 알면 누구나 쉽게 방화벽을 구축할 수 있다. 고가의 방화벽 장비를 구입하기 보다는 사무실 정도의 인터넷 환경이라면 조금 구식의 펜티엄 장비도 FreeBSD와 함께 훌륭한 방화벽와 인터넷 게이트웨이 역할을 할 수 있다. 주변에 방화벽이 필요한데 아직 없다면 FreeBSD로 한번 만들어 보자!