[ Home | Freetime works | FreeBSD | KFUG ]
프로그램세계 2002년 6월분
이달의 FreeBSD 소식공지/소식
시스템 업데이트
보안 업데이트다음은 이달의 보안 권고 사항이다. 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 |
패킷 필터 방화벽의 장점은 보통 패킷(이더넷 프레임도 포함할 수 있다) 수준에서 필터링 여부가 결정되기 때문에 실제 서버까지 전달되지 않는다는 장점이 있다. 하지만 모든 패킷을 처리해야 하고, TCP/UDP 수준까지는 패킷 필터에서 이해하는 경우가 많지만(엄밀히 말하면 그건 IP 패킷 필터 방화벽의 수준을 넘어서는 일이기는 하다) 실제 어플리케이션 프로토콜에 대해서는 무지하기 때문에 단순히 오고가는 패킷의 주소만으로 필터 여부를 판정해야 하기 때문이다.
어플리케이션 수준 방화벽은 HTTP 프록시와 같이 특정 프로토콜을 이해하여 적절한 수준의 대리 접속을 해 주는 것으로, 상용 또는 공개의 방화벽 툴킷을 사용하거나 squid와 같은 웹 프록시 시스템에 포함되어 있다. 사용자 기반 인증 등 여러가지 다양한 능력을 수행할 수 있다는 장점이 있지만 사용자는 사용하고자 하는 프로토콜별로 서로 다른 프록시를 사용해야 하고, 각 프로토콜마다 별도의 프록시 서버가 개발되어야 한다는 단점이 있다.
일반적으로 사무실이나 가정에서 사용하는 소규모 네트워크의 경우 어플리케이션 수준 프록시로 사용할 정도의 일은 웹 프록시 정도가 대부분일 것이다(SOCKS와 같은 어플리케이션 수준 방화벽 프록시 시스템을 사용하지 않는다면).
패킷 필터 방화벽은 생각보다 간단한데, 다음과 같은 규칙을 사용하는 것이 대부분이다. IP 패킷은 기본적으로 다음과 같이 정의될 수 있다. 패킷 헤더에는 기본적으로 다음과 같은 정보가 기록되어 있으므로 이를 이용한다.
송신: IP주소, 포트, [프로토콜 종류: TCP/UDP 등, 플래그] 수신: IP주소, 포트, [프로토콜 종류: TCP/UDP 등, 플래그]필터링 규칙은 이 조건을 지정하는 것이다. 즉 1.2.3.4의 80번 포트로 가는 모든 패킷을 막고 싶다면 규칙은
송신: IP: 모두, 포트: 모두, 수신: IP: 1.2.3.4, 포트: 80, 동작: 거부와 같이 지정될 수 있으며, 2.3.4.5에서 들어오는 모든 접속을 허가하고 싶다면 다음과 같이 규칙을 만들 수 있다.
송신: IP: 2.3.4.5, 포트: 모두, 수신: IP: 모두, 포트: 모두, 동작: 허가대부분의 패킷 필터 방화벽은 위와 같은 규칙을 나름대로의 문법에 맞게 사용하면 가능하다.
일반적으로 NAT 공인 IP 와 사설 IP 사이에서 일종의 라우터로 동작할 수 있으며, 내부 네트워크의 패킷이 외부로 나갈 때에는 지정된 매핑 방법에 의해 패킷의 주소를 다시 쓰게 된다. 들어오는 패킷의 경우, 사설 IP 대역의 경우 IPv4 주소를 갖지만 라우팅이 될 수 없는 주소로 정의되어 있으므로, 외부 네트워크에서 내부 네트워크로 패킷이 직접 도달할 수는 없다.
NAT의 원리따라서 NAT 서버가 정해진 규칙에 따라 패킷의 도착 주소를 다시 쓰게 된다. 간단하게 생각하면 다음과 같다. 내부에서 외부로 나가는 다음 패킷을 가정해 보자.송신: 192.168.1.100:30000 수신: 211.46.62.18:80이 경우 NAT서버는 포트를 하나 할당하고 여기에 이를 기록한 다음 보내는 주소를 바꾸어 쓴다. 할당받은 포트가 50000번이라고 해 보자. 송신: 211.46.52.100:50000 [외부 포트 50000 -> 192.168.1.100:30000] 수신: 211.46.62.18:80이렇게 하면 이 패킷의 응답으로 들어오는 패킷은 다음의 주소를 가지므로, 송신: 211.46.62.18:80 수신: 211.46.52.100:50000NAT서버는 아까 할당되었던 포트 번호를 기억하고 있다가 내부 네트워크로 패킷을 보낼 때 포트에 할당되었던 주소로 바꾸어 쓴다. 송신: 211.46.62.18:80 수신: 192.168.1.100:30000이렇게 하여 내부에서 외부로 통신이 가능하다. 단 외부에서는 내부 주소로 라우팅이 불가능하므로 들어올 수 없는데, 이는 포트 전송(port forwarding) 이라는 기법을 사용하면 가능하다. 즉 NAT 서버의 특정 포트를 내부 네트워크의 특정 IP:포트로 매핑하는 것이다. 즉 다음과 같이 설정되었을 때, 211.46.52.100:40000 -> 192.168.1.10:80211.46.52.100:40000을 향해 들어오는 패킷은 모두 192.168.1.10:80 으로 보내고, 돌아가는 패킷은 그 반대로 처리하면 된다. 대부분의 NAT 서버는 위의 두 기능을 모두 수행할 수 있다. 다만 FTP등과 같이 포트를 서버에서 할당하는 경우 등에는 문제가 발생할 수 있으므로, 특별한 처리를 하는 것이 보통이다. |
| 항목 | ipfw | ipfilter |
|---|---|---|
| 이식성 | FreeBSD전용 | 멀티플랫폼 |
| 규칙적용 | 먼저 맞는 순 | 가장 나중에 맞는 순 |
| 사용 | 모듈 | 모듈 |
| NAT | natd(8) 대몬 | 내장(ipnat으로 제어) |
| TCP 상태 필터링 | 가능 | 가능 |
| 규칙 그룹 | 없음 | 있음 |
| 패킷 전송 | 가능 | 가능 |
| 브리지 지원 | 가능 | 불가능 |
| 대역폭 제어 | 가능(dummynet) | 불가능 |
| IPv6 지원 | 가능(ip6fw) | 불가능 |
FreeBSD 사용자라면 ipfw에 익숙해지는 편이 좋을 것이다. ipfilter로 기본적인 방화벽 사용은 가능하지만, 조금 더 고급 기능인 대역폭 제어나 이더넷 브리지 지원 등이 되지 않기 때문이다. ipfw는 FreeBSD 2.0에서 처음 등장하였으며, 2.2.8에서 대역폭(dummynet)지원을, 4.0부터 TCP 상태 제어가 가능하였으며, 4.4 릴리즈부터 모듈로 읽어들이는 일이 가능해졌다. 또한 ip6fw(8)명령을 사용하여 IPv6 패킷도 필터링이 가능하다(IPv6은 NAT가 필요 없으므로 natd에서는 지원하지 않는다).
ipfilteripfilter는 오픈 소스이면서도 외부인에 의한 첨삭을 임의로 허용하지 않는 (저자에게 미리 알려야 한다) 라이센스 때문에 OpenBSD에는 논쟁 끝에 ipfilter를 기본 소스 트리에서 제외시키고 pf라고 하는 독자적인 패킷 필터 시스템을 만들었다. pf는 ipfilter와 동일한 인터페이스를 갖는다. 실제로 OpenBSD 3.0부터는 ipfilter대신 pf가 포함되어 릴리즈되었는데, Darren씨는 pf를 빼고 ipfilter를 넣은 OpenBSD 3.0 배포본을 별도로 릴리즈하기도 하였다.
ipfilter 홈페이지: http://www.ipfilter.org |
# 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 /etc/ipfw.conf와 같이 읽어들일 수 있다.
규칙을 명령행으로 하나씩 추가하려면, 번호와 함께 add/delete를 사용할 수 있다.
ipfw add 500 allow ip from any to any이렇게 하면 500번 규칙에 allow ip from any to any 가 추가된다. 같은 번호에 두개 이상의 규칙이 있을 수 있다는 점에 주의하자. 해당 번호의 규칙을 지우고 싶다면
ipfw del 500하면 된다. 현재의 규칙 목록을 보려면
ipfw list하면 되며, 규칙에 일치된 패킷의 수와 바이트 수까지 알고 싶다면 다음과 같이 한다.
ipfw -a list규칙을 모두 지우려면
ipfw -f flush로 지울 수 있다.
ipfw 규칙의 기본적인 문법은 다음과 같다.
[prob 확률] 동작 [log [logamount 숫자]] 패킷타입 from 송신처 to 수신처 [인터페이스 정보] [옵션]
확률은 0에서 1 사이의 값으로 패킷이 통과할 확률을 정한다. 이는 가상의 네트워크 환경을 흉내내거나, 일부러 패킷을 확률적으로 버려야 할 때 사용할 수 있다.
동작에는 크게 다음과 같은 것이 있다. 실제 동작은 이보다 더 자세하며, 그 정보에 대해서는 매뉴얼 페이지를 참고하자.
| allow | 패킷 통과를 허가한다. |
| deny | 패킷 통과를 거부한다. |
| unreach | 패킷 통과를 거부하고 정해진 코드의 ICMP 통지를 한다. |
| reset | 패킷 통과를 거부하고 TCP RST를 보낸다. |
| divert | 정해진 포트의 divert(4) 소켓으로 보낸다. NAT에서 사용. |
| fwd | 패킷을 정해진 주소와 포트로 전달한다. |
규칙에 일치하는 경우 로그를 남긴다. 로그의 크기는 logamount로 제한할 수 있으며, 커널 옵션 IPFIREWALL_VERBOSE_LIMIT와 sysctl MIB net.inet.ip.fw.verbose_limit에서 정한 숫자보다 우선한다.
패킷의 종류로, 보통 ip, tcp, udp, icmp 등이 사용된다. 자세한 패킷 종류 목록은 /etc/protocols를 보자.
이는 패킷을 보낸 곳과 갈 곳을 나타내는데, TCP/IP 시스템에서는 보통 IP 주소와 포트로 표현된다. 문법은 다음과 같다.
any | me | [not] <주소/마스크> [포트]
| any | 모든 주소 |
| me | 이 컴퓨터의 주소 |
| 주소/마스크 |
세가지 표현이 가능하다.
|
| 포트 |
포트는 여러개(쉼표로 구분) 또는 -를 사용하여
범위 지정이 가능하다. 번호 대신 smtp, ssh와 같은
이름을 사용할 수도 있는데, 자세한 포트 이름은
/etc/services를 보자.
|
패킷이 지나가는 인터페이스를 지정할 수 있다.
| in | 들어오는 패킷 |
| out | 나가는 패킷 |
| via ifX | ifX(fxp0와 같은 인터페이스명)을 지나는 패킷 |
옵션은 여러가지가 있으나, 가장 눈여겨 볼 것은 keep-state 옵션이다. 이는 TCP 또는 UDP의 접속 상태를 유지할 수 있는 동적 규칙을 생성하게 한다. 동적 규칙은 일정 시간 이후 사라진다.
| established | TCP에서 RST나 ACK 비트가 지정된 경우에 해당 |
| setup | TCP에서 SYN만 있고 ACK 비트가 없는 경우에 해당 |
위 두 옵션은 TCP 연결을 확립하는 과정의 상태를 나타낸다. 즉 특정 조건에 해당하는 TCP 연결만 허가 또는 거부하고 싶을 때 keep-state와 연계하여 사용할 수 있다.
deny ip from any to any
deny tcp from 211.45.78.3 to any
allow tcp from any to 211.45.78.100 http
allow tcp from 211.44.63.0/24 to any ssh
divert 8668 ip from any to any via tun0
fwd 192.168.1.1,3128 tcp from 192.168.1.0/24 to any 80 via tun0
정책 수신 송신 타입 옵션 ------------------------------------------------------------------------- 허가 192.168.2.0/24 192.168.1.100:80 TCP * 허가 192.168.2.0/24 192.168.1.100:22 TCP * 거부 * 192.168.1.100:1-1023 IP * 허가 * * ICMP 0,3,8,11 거부 * * ICMP * 허가 * * * *패킷을 모두 허가하는 방법은 두가지가 있다. 하나는 allow ip from any to any 규칙을 맨 마지막에 넣어 주는 것이고, 두번째는 IPFIREWALL_DEFALULT_TO_ACCEPT를 사용하는 것인데, 60000번 정도에 allow ip from any to any를 넣어 주면 커널 옵션에 관계없이 사용할 수 있다.
위의 규칙 정리를 기반으로 하여 다음과 같은 내용으로 /etc/ipfw.conf를 만든다.
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 add allow tcp from 192.168.2.0/24 to 192.168.1.100 80,22 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마지막의 allow ip from any to any는 가장 뒷부분에 넣기 위해 일부러 60000번의 규칙을 부여하였다.
파일에 있는 내용을 한번에 적용하려면 위에서처럼
ipfw -f flush ipfw /etc/ipfw.conf라고 해 보자. 이후에 원하는 대로 패킷 전송이 제어되고 있으면 성공이다. 단 잘못되는 경우 되돌리려면 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 파일에 로깅되는 패킷이 표시된다. 제한이 있지만 초반부에 패킷을 분석하는데는 좋을 것이다.
firewall_enable="YES" firewall_type="/etc/ipfw.conf"방화벽 사용 옵션을 YES라고 하고, type에 규칙 파일을 적어주면 시작시에 ipfw 설정을 하게 된다. firewall_type에는 여러가지가 있는데, open, client, simple, closed, UNKNOWN 등의 미리 만들어진 규칙이 있다. 이에 대해서는 /etc/rc.firewall 앞부분의 주석을 읽어보자.
rc.conf에 필요한 부분을 설정하였으면 재부팅하고, 규칙이 제대로 설정되었는지 살펴본다.
다음과 같은 환경에서 NAT를 구축한다고 생각해 보자.
------------------------------
외부 네트워크(211.99.82.0/24)
------------------------------
|
| 211.99.82.1 (fxp0)
NAT 게이트웨이(FreeBSD)
| 192.168.1.1 (fxp1)
|
------------------------------
내부 네트워크(192.168.1.1/24)
------------------------------
이 경우, FreeBSD 서버에는 랜 카드가 두장이 있고, 내부 네트워크의 PC는
모두 허브에 연결되어 있어야 한다. 내부 네트워크에 있는 PC는 게이트웨이를
192.168.1.1로 잡으면 된다.
NAT를 사용하기 위해서는 먼저 ipfw 환경이 구축이 되어 있고, NAT를 위한 규칙을 추가한 다음에 natd를 적절한 옵션으로 실행하면 된다.
# 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.confnatd를 실행시에도 동작하게 하려면 /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 환경에서 꼭 필요한 옵션이며, 실제로는 다음과 같은 명령을 실행하는 것과 동일하다.
sysctl net.inet.ip.forwarding=1다시 부팅해서 NAT가 제대로 동작하는지 확인해 보자. NAT가 제대로 동작하는지 확인하기 위해서는 다음 사항을 점검하면 된다.
# 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 anyfirewall_type에 위에서처럼 open 등의 정해진 타입이 아니라 별도의 설정 파일을 사용하더라도 NAT를 위해 divert 규칙을 추가할 필요는 없다. /etc/rc.firewall은 방화벽을 사용하고(firewall_enable), NAT를 사용하는 경우(natd_enable) 자동적으로 50번 규칙을 추가한다.
NAT가 동작하면 여러가지 재미있는 일을 할 수 있다. 로컬 DNS 캐시를 만들 수도 있고, DHCP서버를 사용하여 네트워크 자동 설정, squid를 이용한 웹 프록시 등 다양한 활용이 가능하므로 재미있게 사용해 보자.
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에서 사용하던 것과 그대로 사용할 수 있다. 이 방법을 잘 응용하면 반복되는 작업을 매크로를 사용하여 편리하게 사용할 수 있다.
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 환경 구축 예에서, 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 으로 접속하는 것과 동일하다.
여러개의 포트를 여러 주소로 연결하려면 설정 파일을 두는 편이 좋다.
options BRIDGE그리고, /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 를 통한 패킷 필터링을 할 수 있는데, 이는 소규모 네트워크에서의 패킷 필터 방화벽을 만드는데 아주 편리하게 사용할 수 있다.
다음과 같은 구성을 생각해 보자.
-----------------------------
외부 네트워크
-----------------------------
|
------
라우터
------
| 211.99.82.1
|
| fxp0
----------------
브리지 (FreeBSD)
----------------
| fxp1: 211.99.82.2
|
------------------------------
내부 네트워크(211.99.82.0/24)
------------------------------
즉, 내부 네트워크와 라우터 사이에 브리지 방화벽을 설치하는 것으로,
기존 네트워크 구성을 변경할 필요 없이 브리지 형태의 방화벽 추가가 가능하다.
브리지는 반드시 IP를 가질 필요는 없지만, 그렇게 하면 콘솔에서만 접속이
가능하므로 안쪽에는 IP를 갖도록 한다.
남은 것은 적절한 규칙을 만드는 일인데, DaemonNews의 다음 기사를 참고하면 비교적 쉽게 만들 수 있을 것이다. 이 기사는 ipfilter를 기준으로 쓰여 있지만, ipfw 방화벽 규칙으로 변환하는 것은 어렵지 않다.
Daemon News : OpenBSD bridge without IPs using IPF Tutorial
http://www.daemonnews.org/200103/ipf_bridge.html
이 기능을 사용하기 위해서는 커널 옵션에 다음을 추가하거나 dummynet.ko를 읽어들여야 한다.
options DUMMYNET설정은 ipfw 매뉴얼 페이지에 자세히 나와 있는데, 간단한 몇가지 예제만 들어보기로 하자. 먼저 대역폭 제어를 할 규칙을 정한다.
ipfw add pipe 1 ip from 192.168.2.0/24 to any이 경우 파이프 1번이 192.168.2.0/24 네트워크에서 다른 쪽으로 가는 패킷 모두에 대해 적용된다. 그 다음에는 pipe 1을 설정한다.
ipfw pipe 1 config bw 128kbit/s이렇게 하여 pipe 1의 대역을 128kbit 로 제한할 수 있다. pipe는 번호를 붙여 여러개를 만들 수 있다. 확률로 패킷을 버리려면 다음과 같이 한다.
ipfw pipe 1 config plr 0.05이 경우 5%의 확률로 해당 규칙에 맞는 패킷을 버린다.
[ Home | Freetime works | FreeBSD | KFUG ]