글쓴이 : 좋은진호 ( http://coffeenix.net/ )

조회수 : 8073

	[ 이전화면 / 수정 ]   비밀번호 :
	------------------------------------------------------------------------- 출처 : http://www.optro.co.kr/~silpapa/?page=view&ctn=tips&id=218&num=1 제목: IPFW How-To 번역 문서 - part 1 글쓴이: Daemonize [홈페이지] 　　　글쓴시간: 04/02/25 18:08 　　　읽은수: 446 ------------------------------------------------------------------------- 미완성 문서입니다. 시간 날때마다 조금씩 조금씩 해석할려고 합니다. 관리자님이 "대략 조치 안타" 라고 판단되시면 지워주세요. 큭. 원문은 www.defcon1.org 에 가시면 잘 보실수 있습니다. 그리고 고수님들의 아낌없는 지적도 감사. 1. Packet Filters 에 대한 일반적 소개 Ipfw(8) 은 ipfirewall(4) 의 명령행 프로그램으로 FreeBSD 에서 가장 보편적인 IP 필터링, Traffic 조정 도구이며 FreeBSD 에서 기본적으로 다룰 수 있습니다. (방화벽 자체는 커널 기본설정에 비활성화 되어 있습니다. ) Ipfw 룰(rules)의 논리적 작용은 다른 packet filter 들과 유사합니다. 단 IPFilter 의 경우 룰(rules)을 다룸에 있어 다소 비효율적이며, 최적화 시키는데 많은 노력을 필요로 합니다. (익숙해졌다하더라도 ipf(8)에 쓰이는 quick 이라는 키워드가 매번 전체 룰셋(ruleset) 을 건너뛰지 않도록 주의해야 합니다.) 이렇게 말하는 것이 ipf(8) 의 효용을 깍아내리는 것은 아니며 그 나름대로 장점을 가지고 있습니다. 특별히 한쪽에 없는 기능을 필요로 한다든지 하지 않는다면 어떤 패킷 필터링 툴을 사용할 것인지 최종적으로 결정하는 것은 개인적 선택입니다. 그럼에도 불구하고 우리는 나중에 두 툴에 대해 철저한 비교작업을 할 것입니다. 서술한대로 ipfirewall(4)은 패킷 필터링 방화벽 (packet filtering firewall)을 의미합니다. 이는 패킷에 기초한 연결을 감시할뿐만 아니라 FreeBSD 4.0 에서 보듯 근본적인 연결 지향적(connection oriented) 필터링에 의해 작동하는 것을 의미합니다. 양쪽모두에서 하나 혹은 그 이상의 넷트웍 인터페이스를 통한 필터링이 행해집니다. 이것은 '투명(transparent)'하게 이루어지는데 말하자면 어떤 것이 블록당하기 전까지는 방화벽이 있었는지 알지 못한다는 뜻입니다. 방화벽 구축은 많은 형태를 뛰고 있지만 크게 두 가지 정책으로 나뉠 수 있습니다. 열린 방화벽은 기본적으로 모든 패킷의 통과를 허용하고 원치 않는 것만을 블록합니다. 반면에 닫힌 방화벽은 기본적으로 모든 패킷을 막고 원하는 패킷만 통과시킵니다. 후자가 좀 더 타이트한 방화벽 설정이지만 구성하기가 까다롭습니다. 왜냐하면 자신도 알지 못한 채 자신이 원하는 트래픽까지 쉽게 막을 수 있기 때문입니다. 2. IPfirewall 활성화하기 Ipfirewall(4)은 두 가지 방법으로 활성화할 수 있습니다. 적절한 옵션을 커널 설정 파일에 넣고 커널을 재빌드하거나 혹은 커널에 kldload(8)을 통해 ipfw.ko 모듈을 동적으로 로딩하면 됩니다. 두 가지 방법 모두 ipfirewall 의 기본적 구동에 충분합니다만, 전자의 방법만이 로깅(logging)등의 추가적인 설정 옵션을 제공해 줍니다. 동적(dynamically)으로 ipfw 을 로딩시키려면 간단히 다음 명령을 내리면 됩니다. # kldload ipfw # 정적(statically)으로 ipfirewall 을 활성화시키려면 다음에 해당하는 내용이 커널 설정 파일에 들어가야 합니다. options IPFIREWALL 그러고나서, 커널을 재빌드하고 재부팅하면 ipfirewall(4)이 정적(statically) 으로 활성화 됩니다. 하지만, 보이는 것처럼 그리 간단한 문제는 아닙니다. 관리자는 콘솔앞에 있을 때만 위와 같은 일을 할 수 있습니다. 방화벽을 효율적으로 하기 위해선 좀더 추가적인 옵션이 필요합니다. 위에서 말한 방화벽 정책 (열린 혹은 닫힌)을 상기한다면 기본 방화벽 정책이 닫힌 정책 (Closed)일때 상황이 왜 그리 복잡해지는가를 깨달을 수 있습니다. 그런 연유로, 어떠한 추가 작업없이 단순히 ipfirewall(4)를 활성화시킨다면 모든 네트웍 트래픽이 블록되는데, 이것이 곧 원격으로 ipfirewall(4)를 활성화시켰을 때 재앙이 될 수 있습니다. 재앙은 피해질수 있습니다만 그럼에도 불구, 정적이든 (statically) 동적이든(dynamically)간에 ipfirewall(4)를 원격에서 활성화시키는 것은 결코 권장하지 않습니다. 어쨋든 원격지에서 ipfirewall(4)를 동적으로 로딩시키고자 한다면, 다음 명령을 권장합니다. #kldload ipfw && ipfw -q add 65000 allow all from any to any # 이것은 모든 트래픽을 막는 대신 허용하는 룰을 취하며, 따라서 원격지 컴퓨터에서 차단당하지 않습니다. 비슷하게, 네트웍에 연결된 로컬머신에서 당신의 연결을 끊고 싶지 않을때 권장합니다. ipfirewall(4)을 원격으로 커널에서 정적으로(statically) 활성화시키는 일은 추가적인 작업을 필요로 합니다. 이전에 말한 옵션을 커널 설정 파일에 집어넣고 커널을 재빌딩했다면, rc.conf 파일에 적어도 두가지의 ipfirewall(4) 옵션을 추가해 주어야 합니다. 이것은 컴퓨터가 재부팅돼었을때, 디폴트로 설정된 닫힌 방화벽 정책에 의해 사용자가 블록당하는 일을 막기 위함입니다. firewall_enable="YES" firewall_type="OPEN" /etc/rc.firewall 에는 여러가지 방화벽 정책이 있습니다만, 나중에 살펴보기로 하겠습니다. 지금 초보자에게 있어 열린(Open) 정책이 좋은 방편입니다. 다른 방법으로 커널 설정 파일에 다음의 옵션을 추가해 줌으로써 ipfw(8)의 열린(Open) 정책을 커널에 활성화 시킬수 있습니다. options IPFIREWALL_DEFAULT_TO_ACCEPT 이 경우, 위의 rc.conf 파일 옵션은 커널의 기본적인 설정에 의해, 우리가 열린(Open) 정책을 활성화 시키는데 있어 /etc/rc.firewall 을 필요로 하지 않는 것과 비슷하게 필요하지 않습니다. 그러나 커널에 이와 같은 기능을 활성화시켰다 하더라도, 어쨋든 /etc/rc.conf 파일에 옵션을 추가하는 일은 좋은 방법입니다. 왜냐하면 후에 정해진 룰셋(ruleset)을 사용하기 위해 /etc/rc.firewall 을 사용하게 될 수 있기 때문입니다. 이것은 커널에 동적으로(dynamically) 로딩시켰을때에도 동일하게 적용되며 이후에 재부팅후에도 자동적으로 ipfw.ko 모듈이 로딩되게 됩니다. /etc/rc.conf 파일의 방화벽 활성화 기능은 ipfw.ko 모듈을 로딩하는 편리한 방법을 제공합니다. 커널에 정적으로 ipfirewall(4)를 활성화시켰을때 쓸 수 있는 추가적인 옵션으로 인해 사용자는 적어도 현재의 FreeBSD 디자인상 ipfirewall(4)을 활성화시키는 데 있어 이것이 더 나은 방법이라 깨달을 것입니다. IPFIREWALL_DEFAULT_TO_ACCEPT 와 더불어, options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=# 를 사용할 수 있습니다. IPFIREWALL_VERBOSE 는 'log' 키워드를 가진 모든 룰에 의해 패킷 활동 (packet activity)을 syslogd(8)에 자세하게 보고하게 함으로써 ipfirewall(4)를 통한 트래픽 기록을 가능하게 해줍니다. 이건 나중에 더 명확하게 설명하겠습니다. IPFIREWALL_FORWARD는 ipfirewall(4)의 'fwd' 커맨드에 의한 다른 호스트로의 패킷 포워딩을 가능하게 하며 이것은 나중에 좀 더 깊게 다뤄질 것입니다. IPFIREWALL_VERBOSE_LIMIT=# 은 특정한 룰에 의한 패킷 기록에 대해 한계를 명확히 정합니다. 이것에 의해 syslogd(8)와 (나중에 볼 /etc/syslog.conf 에 비활성화 되어있지않다면) 사용자 콘솔은 ipfirewall(4) 의 작동에 의해 점령당하지 않게 됩니다. '#' 은 작동하고 있는 룰에 대한 기록의 연속적 횟수로 대신합니다. 만약 IPv6 를 활성화 시켰다면 IPv6 패킷에 대해 그에 상응하는 방화벽의 활동이 다음의 옵션으로 적용됩니다. options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREAWLL_DEFAULT_TO_ACCEPT 추가로, ipfirewall(4)와 관련하여 4가지 옵션이 커널에 더 설정될 수 있지만, 여기서는 다루지 않습니다. 왜냐하면 그것들은 기본적인 방화벽의 작용에 필요하지 않으며 좀 더 복잡한 routing 상황과 관련이 있기 때문입니다. 2.1 rc.firewall and OPEN firewalls 사용자가 방화벽 타입(firewall type)을 어떻게 정했는지에 상관없이 만약 firewall_enable="YES" 가 rc.conf 파일에 추가되어 시스템이 재부팅되었을 경우, rc.conf 파일로 부터 /etc/rc.firewall 이 시작되며 그것으로부터 다음 두 행이 실행됩니다. ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 {fwcmd} 는 사용자가 ipfw(8)을 조용히(quietly) 구동시킬 것인지 (-q 옵션) 혹은 그렇지 않은지에 따라 rc.firewall 스크립트의 전반부에 정의되어 있습니다. 처음 룰은 루프 백 디바이스 (lo0)를 통한 모든 트래픽을 허용하며 두번째 룰은 localhost 네트웍을 겨냥한 모든 트래픽을 막습니다. 처음 룰은 로컬 머신의 IPC (inter-process communication) 트래픽을 허용하는데 반드시 필요하며, 두번째 룰은 외부의 모든 패킷이 루프백 디바이스 장치 주소인 localhost 주소로 가는 것을 허용하지 않음으로써 사용자의 로컬 트래픽을 보호하게 됩니다. 만약 이 두 룰이 없고 방화벽이 기본 설정이 닫힌 정책(Closed policy) 이라면 다른 것 보다 RPC(3) 서비스가 작동하지 않는 걸 보게 될 것입니다. 다음, 사용자가 rc.conf 파일에 "OPEN" 이라는 방화벽 형태를 지정했을 땐 다음 라인이 활성화됩니다. ${fwcmd} add 65000 pass all from any to any 이것은 로컬호스트를 향한 것을 제외한 모든 외부의 트래픽을 허용하고 모든 내부 트래픽의 외부 전달을 가능케 합니다. 커널에 IPFIREWALL_DEFAULT_TO_ACCEPT 를 추가하는 것도 동일한 작용을 합니다. 커널에 열린(OPEN) 정책을 가능하게 하였다면 #65535 rule은 "deny ip from any to any" 대신 "allow ip from any to any" 를 자동으로 취하고 추가로 열린 정책에 관한 rc.firewall 파일에 있는 #65500 rule 을 불필요하게 만들 것입니다. 그런 연유로 커널엔 열린 정책으로 하되 다른 어떠한 룰을 허용하지 않고 싶다면 방화벽 타입(firewall type)을 "UNKNOWN"으로 정하는 것이 바람직합니다. 만약 예를 들어 단순히 방화벽을 시험하거나 어떻게 작동하는지를 관찰하고자 한다면 방화벽 타입을 이처럼 open 으로 하는 걸로 충분하며 섹션 3으로 넘어가도 됩니다. 하지만 rc.firewall 에 있는 미리 정해진 ruleset 을 사용하거나 자신만의 특정한 rulesets 을 만들고자 한다면 두 옵션 (OPEN or UNKNOWN)만으론 불충분합니다. 2.2 ruleset 로딩하기 ruleset 과 관련하여 사용할 수 있는 방법은 크게 두 가지 다른 방법이 있습니다. rc.firewall 에 미리 정해진 것을 사용하든지, 혹은 자신만의 것을 만드는 것입니다. 저자는 두가지 이유로 후자를 추천합니다. - 일반적 참고 파일로 존재하는 rc.firewall 파일을 건드리지 않고 당신의 기호에 맞게 방화벽 룰을 정할 수 있다. - ipfw(8) 구문에 익숙해져야 하는데 그렇게 함으로써 ipfw(8)을 더 편하게 사용할 수 있다. 2.2.1 미리 정해진 Firewall Types 물론, 최종적 결정은 관리자 마음이죠. 누군가 미리 만들어진 rulesets 을 사용하고자 한다면 rc.firewall 파일을 잘 읽어보고 그것들을 활성화 시키기 전에 그것들에 익숙해져야 합니다. 어떤 rulesets 을 로딩할 것인지는 rc.conf 파일의 firewall_type=" " 에 의해 정해집니다. "OPEN" 타입과 별도로 세가지 사용가능한 타입이 있습니다. "CLIENT" 이 ruleset 은 몇 가지 기본적 rules 를 가능하게 합니다. 그것은 로컬 네트웍 (NAT 뒤에 있는 사설 네트웍이 될 수도 있습니다.) 으로 부터 자신으로의 모든 트래픽을 허용합니다. mail, DNS, NTP 패킷들을 네트웍 내외부로 허용하며 사설 네트웍 (private network) 외부에 있는 어떠한 호스트로 부터의 내부 호스트들 사이의 TCP 연결 초기화를 허용하지 않습니다. 이것은 특별한 프록시가 없다면 vanilla NAT 설정하에서 불가능할 것입니다. 이 설정은 default open 이나 default closed 정책 모두에게 유효합니다. "SIMPLE" 이 ruleset 은 다소 역설적입니다. CLIENT ruleset 보다 더 복잡하고 처음에 직관적으로 이해하려면 일정한 internet RFC 지식을 필요로 합니다. 그것은 임의의 내부 호스트와 같은 주소를 가지는 외부 패킷의 침입에 의한 spoofing 을 막을려고 합니다. RFC 1918 에 정의된 모든 private-net 주소를 가진 패킷의 유입이나 누출(leaking in or out)을 막을 것이며 Manning internet draft (http:www.ietf.org/internet-drafts/draft-manning-dsua-03.txt)에 정의된 모든 추가적인 라우팅 불가한 네트웍 (additional non-routable networks)을 막을 것입니다. 또한 그럼에도 불구하고 mail,www,DNS,NTP 트래픽과 fragmented 된 패킷을 통과시킬 것이며 외부 호스트에 의해 연결을 초기화할려는 의도 (attempts for connexions to be initiated) 를 막을뿐만 아니라 CLIENT 처럼 이러한 모든 시도를 기록할 것입니다. "CLOSED" 이것은 어떠한 룰(rules)을 가능하게 하는 건 아니라서 기술적으로 보자면 ruleset 은 아닙니다. 사실 그것은 우리가 하지말도록 경고받았던 모든 일들을 다 막아주며 모든 트래픽을 보류하는 기본적인 폐쇄 정책을 허용하는 것입니다. (앞서 설명했던 lo0을 통한 트래픽은 제외됩니다.) 그것은 사용자가 커널에 기본 열린 정책 (default open policy) 를 가능하게 하지 않았다면 모든 IP 서비스를 반드시 막아줍니다. 이렇게 하진 마세요. 2.2.2 Custom Firewall Types 사용자가 자신만의 ruleset 을 사용하기로 결정했다면 rc.conf 파일의 firewall_type 옵션의 것 대신 하나의 파일을 정해야 합니다. 예를 들어, rc.conf 파일에 다음과 같이 썻다고 생각합니다. firewall_enable="YES" firewall_type="/etc/rc.firewall.rules" 이것은 사용자가 특정한 ipfirewall(4) ruleset 을 /etc/rc.firewall.rules 파일에 정의할 수 있게 허용하고 부팅시마다 그것을 작동시킵니다. 더 나아가, ruleset 을 빠르게 적용시키고자 한다면 rc.conf 파일에 다음행을 추가할 수 있습니다. firewall_quiet="YES" 이 파일에 나온 ruleset 형식은 rc.firewall 에서 볼 수 있던 것들과는 약간 다를 겁니다. rc.firewall 은 자신이 스스로 실행되도록 고안된 sh(1) 스크립트이기 때문이죠. ipfirewall(4) rule 파일은 유일하게 ipfw(8)에 의해서만 실행되어집니다. 근본적 차이점은 rc.firewall 파일에는 {fwcmd} 라는 쉘 변수가 정의되있는 반면 ipfirewall(4) rule 파일에는 그에 상응하는 것을 볼 수 없다는 점입니다. 간단하게 자신만의 룰들 뿐입니다. 후에 우리가 예시 파일을 만들어 볼때 단계적으로 더 알아보겠습니다. 3. Basic Ipfw(8) Rule Syntax (기본적인 ipfw 문법) ipfw(8) 문법은 매우 간단합니다. 어떠한 룰이라도 콘솔에서 ipfw(8) 명령으로 실행가능합니다. 문법을 들여다보기전에 먼저, 현재 활성화된 ipfirewall(4) 룰을 어떻게 나열할 수 있는지 대강 알아보겠습니다. 3.1 룰 나열하기 (Listing Rules) 가장 간단하게, 다음과 같이 하면 됩니다. ipfw list 이는 룰 넘버에 의해 정렬된 모든 룰들을 보여줍니다. 어떠한 패킷이 특정한 룰에 의해 매치된 가장 최근 시간을 덧붙여 표시하기 위해서는 다음의 명령을 사용합니다. ipfw -t list 혹은 ipfw show 둘 모두 같은 방식으로 같은 정보를 보여줍니다. 처음 컬럼이 rule number 이고, 그 다음이 룰에 매치되어 나간(outgoing) 패킷들의 숫자입니다. 계속해서 룰에 매치된 들어온(incoming) 패킷의 수이고 끝으로 룰 자체가 나옵니다. 3.2 기본 명령과 작용 고정 필터링 ruleset (stateless filtering ruleset) 을 작성함에 있어 사용 가능한 여러 옵션들에 대해 조금씩 알아보겠습니다. 예시된 보기에서 방화벽 조절 유틸 (/sbin/ipfw)을 제외한 룰만을 언급할 것인데 만약 명령행에서 수동으로 동일한 룰을 설정하기 위해서는 ipfw 을 선행하여 사용해야 합니다. 그렇게 하지 않는다면 ipfw(8)에 전달될 룰을 구성하고자 할때 다음과 같이 사용할 수 있습니다. add 1000 allow all from any to any 이것은 가장 단순한 룰의 예입니다. OPEN 방화벽 타입을 논한 섹션 2.1 에서 룰 넘버를 제외하면 전에 벌써 보았던 것이죠. * rc.firewall 파일의 그 룰에 사용된 "pass" 라는 지시자 (parameter)는 "allow" 및 "permit" 이라는 것들과 동의어이며 서로 바꿔 쓸 수 있습니다. 위 룰에서는 모든 출발지 (any source)에서 비롯된 모든 패킷들을 어떠한 목적지(any destination)를 향하든 통과시킨다는 얘기입니다. 대부분의 상황에서 ipfirewall(4) 은 특정한 패킷이 어떤 룰에 들어맞는 순간 ruleset 검사가 거기서 멈추게 됩니다. 우리가 본 것처럼, 가장 단순한 형태의 ipfw(4) 문법은 [command] [rule #] [action] [proto] from [source] to [destination] 입니다. 중요한 명령은 "add" 와 "delete" 입니다. 말 그대로 입니다. 룰 넘버는 (rule number) 는 0부터 시작해서 65535 번에서 끝납니다. 마지막 룰 넘버는 커널의 기본 방화벽 정책에 의해 항상 정의됩니다. 룰셋 (ruleset) 탐색은 (보통) 가장 먼저 매치된 시점에서 멈추기 때문에 괜찮습니다. 그래서 만약 거의 끝인 룰 ( 두번째 부터 마지막까지) 의 넘버가 65000 이고 그것이 rc.firewall 에 모든 패킷을 허용하도록 정의돼어 있다면 마지막 룰 (65535)이 닫힌 커널 방화벽 정책일지라 하더라고 기본적으로 모든 패킷을 통과시키게 됩니다. 왜냐하면 마지막 룰은 결코 도달할 수 없기 때문이죠. "action" 은 여러 가지가 될 수 있습니다. "allow" | "pass" | "permit" - 이 "action" 을 갖고 있는 룰 (rule)과 매치되는 모든 패킷은 방화벽을 통과하도록 허용되고 ruleset 탐색은 종료됩니다. "deny" | "drop" - 이 "action" 을 포함하는 룰과 매치되는 모든 패킷은 방화벽에 의해 조용히 블록되고 (blocked) ruleset 탐색은 종료됩니다. add 1100 deny all from any to any 이것은 어떤 곳에서 오든 어떤 곳으로 가든 모든 패킷을 거부합니다. "reset" - 이 "action" 을 포함하는 룰과 매치되는 모든 패킷은 블록되고 ipfirewall(4) 은 그 패킷을 보낸 곳 (source) 에 TCP reset (RST) 메시지를 보내려고 시도합니다. ruleset 탐색은 종료됩니다. 당연히 이것은 오로지 TCP 패킷에게만 해당되기 때문에 프로토콜은 "tcp" 가 되어야만 합니다. 이 "tcp" 는 오로지 TCP 패킷과 매치될뿐, 모든 IP 패킷을 의미하는 "all" 을 의미하지 않습니다. 이러한 action 은 그렇지 않다면 filtered port 뒤에 있는 서비스를 발견할 수 있는 넷트웍 스캐너 (network scanner) 를 속이는데 때때로 유용합니다. 반면에 ipfirewall(4) 이 RST 패킷으로 응답하게 끔 된 특정한 IP 와 포트로 대용량의 패킷이 전달되면 (flooded) 커다란 짐이 될 수 있고 따라서 당신의 대역폭 사용량을 배로 하게 됩니다. add 1200 reset tcp from any to any 이것은 어디에서 와서 어디로 가든 ( from any to anywhere) 모든 TCP 패킷을 거부하고 각각 TCP RST 응답 패킷을 패킷의 전송지 (source) 로 보낼 것입니다. "count" - 이 action 을 포함하는 룰과 매치되는 모든 패킷은 ipfirewall(4) 에게 패킷 카운터 (packet counter) 를 증가시켜줄 것을 요청하게 됩니다. ruleset 탐색은 계속 됩니다. add 1300 count all from any to any 이것은 이 룰에 대한 패킷 카운터 (packet counter) 를 증가시키는데, 이것은 전송지와 목적지에 상관없이 (coming from anywhere and going anywhere) 모든 패킷과 매치됩니다. "skipto [number]" - 이 action 을 포함하는 룰과 매칭되는 모든 패킷은 ipfirewall(4) 에게 [number]에 의해 지시된 넘버와 동일하거나 혹은 그와 큰 번호로 시작되는 ruleset 으로 ruleset 탐색을 계속 할 것을 요구합니다. add 1400 skipto 1800 all from any to any 이것은 처음으로 이 룰과 만나는 모든 패킷에 대해 1800 번 룰까지의 ruleset 탐색을 생략합니다. 3.3. Specifying Protocols ( 프로토콜 정하기 ) "proto" 는 매칭을 원하는 프로토콜입니다. "ip" 나 "all" 키워드는 모든 프로토콜에 상응하는 캐치된 프로토콜을 의미합니다. 결코 프로토콜은 한두가지가 아니지만 흔히 자주 매치되는 패킷 프로토콜 (matched packet protocols) 은 icmp, udp, 그리고 tcp 입니다. 룰에 매칭될 수 있는 모든 프로토콜을 보고 싶다면 'more /etc/protocols' 하십시요. 3.4 Specifying the Source and Destination Address (전송지와 목적지를 정하기) "source" 와 "destination" 은 같은 형식을 취합니다. /etc/hosts 에 정의되거나 혹은 dns 를 통하여 정의된 이름(name) 이 될 수 도 있고, IP 주소 (address) 나 bitmask (혹은 netmask)를 포함한 네트웍 주소 (network address) 가 될 수도 있으며 만약 프로토콜이 tcp 혹은 udp 라면 선택적으로 하나나 그 이상의 포트 번호를 동반할 수 있습니다. 예를 들어 이름 (name) 이나 IP 를 사용하는 것은 직관적입니다. add 1000 allow all from myhost to hishost add 1100 deny all from 10.0.0.5 to any 처음 룰은 "myhost" 에서 "hishost" 로 가는 모든 트래픽을 허용하고, 두번째 룰은 10.0.0.5 에서 임의의 목적지로 향하는 모든 패킷을 거부합니다. 일단 어떤 패킷이 이것들 중하나에 걸리게 되면, 그 패킷에 대한 ruleset 탐색은 멈추게 되고 그 패킷에 매치되는 룰에 정해진 action 에 따라 통과하거나 버려집니다. (passed or dropped) 이것이 호스트 기반 (host based filtering) 필터링의 간단한 예입니다. 즉 어떤 패킷이 어떤 호스트로 부터 전달되고 혹은 어떤 호스트에게 전해지는가에 따라 필터링이 되는 것을 의미합니다. 네트웍 기반 필터링 (network based filtering) 은 이와 유사하게 작동하며 다음 예와 같이 bitmask 나 netmask 를 사용한 네트웍 인식이 이루어집니다. add 2000 allow all from 192.168.0.0/16 to any add 2100 deny all from any to 10.0.0.0:255.0.0.0 처음 룰은 IP 범위가 192.168.0.0 - 192.168.255.255 에 해당되는 모든 트래픽을 허용합니다. 이것을 명시하기 위해 bitmask 를 사용합니다. bitmask 는 매치되는 패킷에 대하여 얼마나 많은 네트웍 주소 (192.168.0.0) 의 비트 (bits) 가 동일하게 적용되는지 명확히 합니다. 위 예에서 보자면 32 비트 주소에서 처음 16 비트가 같고 (remain the same), 앞의 16 비트가 처음의 두 8 비트인 192.168 로 되기 때문에 192.168 이라는 앞의 두 8비트를 가진 모든 전송 주소 (source)와 매치되는 모든 주소는 이 룰과 매치됩니다. 두번째 룰은 넷마스크 (netmask) 를 이용하여 이와 비슷한 작업을 합니다. 넷마스크는 지정된 네트웍 주소에서 얼마나 많은 bits 가 룰과 매칭되는 지를 가리킵니다. 위의 예 두번째 룰에서 넷마스크는 255.0.0.0 입니다. 처음 8 비트는 높은 비트 (high bits)로 정해집니다. 다시 말하자면 처음 8비트가 높게 정해졌습니다. (set high) 이것은 ipfw(8)에게 네트웍 주소 (10.0.0.0) 의 처음 8비트를 가진 패킷만을 매치시켜야 한다고 지정합니다. 네트웍 주소의 처음 8비트는 10이기 때문에, 처음 8비트가 10 인 목적지 주소 (10.0.0.0 과 10.255.255.255 사이의 모든 주소)를 가진 모든 패킷들이 이 룰에 매치되고 action 에 따라서 버려지게 됩니다. 룰과의 매치는 (rules matches) 는 "not" 이라는 키워드에 의해 반대로 설정될수 있습니다. 예를 들어 다음의 ipfw(8) 명령행에서 192.168.0.3 에서 오지 않은 모든 패킷은 버려지게 됩니다. add 1000 deny all from not 192.168.0.3 3.4 Introduction to Bitmasks and Netmasks (비트마스크와 넷마스크에 대한 소개) 비트마스크(bitmask) 와 넷마스크(netmask)의 기본 원리는 간단합니다만 가끔씩 초보 유저들에게 혼동을 일으킵니다. 이진 숫자에 대한 지식을 필요로 하기 때문이죠. 이진 형태로 된(binary form) IP 주소는 더 많은 걸 가르쳐줍니다. 그러나 십진법과 이진법의 혼란스러운 개념은 쉽게 초보자를 당황하게 만듭니다. 잠시 간단한 참고로, 다음의 테이블은 기본 C class에 대응하는 비트마스크와 넷마스크에 의해 어떠한 네트웍 영역이 지정되는지, 그리고 보다 더 대규모의 네트웍을 위한 추가적인 비트마스크/넷마스크에 대한 간단한 예를 보여줍니다. Bitmask Netmask Total IPs / Usable IPs (비트마스크) (넷마스크) (총 IP 수) / (사용가능한 IP 수) 32 255.255.255.255 1 1 31 255.255.255.254 2 1 30 255.255.255.252 4 2 29 255.255.255.248 8 6 28 255.255.255.240 16 14 27 255.255.255.224 32 30 26 255.255.255.192 64 62 25 255.255.255.128 128 126 24 255.255.255.0 256 254 …… 22 255.255.252.0 1024 1022 20 255.255.240.0 4096 4094 16 255.255.0.0 65536 65534 12 255.240.0.0 1048576 1048574 8 255.0.0.0 256^3 (256^3)-2 0 0.0.0.0 (all IPs)256^4 (256^4)-2 보면 일정한 패턴이 있습니다. 총 IP 수는 2의 제곱형태이고 사용가능한 IP 수는 거기에서 2를 뺀 것입니다. 이것은 모든 IP 네트웍/서브넷은 네트웍과 브로드캐스트 (network and broadcast)에 할당된 2개의 IP를 갖고 있기 때문입니다. 넷마스크의 마지막 8비트는 255에서 시작하여 2의 제곱형태로 감소하며 반면에 비트마스크는 1의 제곱형태로 감소합니다. 왜냐하면 2진법에서는 십진법에서처럼 10으로 나누지 않고 2로 나누어 나머지를 우측에서부터 좌측으로 써 나가기 때문입니다. 이런 패턴은 모든 넷마스크와 비트마스크에 동일하게 적용됩니다. 위에서 보았던 테이블/패턴을 가지고 간단한 예로 다음에 의해 지정되는 IP 영역을 알아보기로 합시다. 172.16.100.32/28 우선 네트웍 주소는 172.16.100.32 임을 알 수 있으므로 서브넷은 그 주소로부터 시작됨을 알 수 있습니다. 둘째, 비트마스크 28은 마지막 4비트(32-28)가 낮게 정해지고 (set low) 28 비트가 높게 설정 (set high) 되어 있음을 알게 됩니다. 낮게 설정된 비트가 훨씬 적기 때문에 그것들을 사용해 계산해 보기로 하죠. 모든 비트는 2가지 값을 가지기 때문에 2^4 은 얼마나 많은 호스트가 이 비트마스크에 의해 설정되는지 지정합니다. 이 경우에서는 172.16.100.32 + 16 = 172.16.100.48 이므로 IP 영역은 172.16.100.32 – 172.16.100.48 입니다. 테이블을 본다면 16개의 IP가 비트마스크 28에 상응한다는 것을 알 수 있으므로, 그것을 이용해 계산할 수도 있습니다. 하지만 자신만의 힘으로 계산하는 것이 훨 낫습니다. 한번 배워서 계속 써 먹으니까요. 3.4.2 Specifying Ports and Port Ranges (포트와 포트 범위 설정) 사용자는 역시 호스트와 더불어 포트 기반 필터링 (port-based filtering)과 네트웍 기반 필터링 (network-based filtering)을 할 수 있습니다. 포트는 목적지나 전송지 주소 다음에 간단히 지정할 수 있습니다. 포트 범위는 대쉬 (dash)나 콤마, 혹은 비트마스크를 사용하여 정할 수 있습니다. 가장 중요한 것은 모든 프로토콜이 포트와 관련(port-sensitive) 되지 않기 때문에 포트를 지정할 때 모든 프로토콜을 사용할 수 없다는 점입니다. add 1000 allow tcp from any to 172.16.0.5 25 add 1100 allow tcp from any to 172.16.0.5 1021-1023 add 1200 allow tcp from any to 172.16.0.5 21,22,23 add 1300 deny udp from any to 192.168.0.5 1024:8 처음 룰(rule) 에서는 172.16.0.5의 25 번 포트를 향한 모든 TCP 패킷이 매치됩니다. 두번째 룰에서는 172.16.0.5 로 향하는 1021번에서 1023번 까지의 포트들을 향한 패킷이 매치됩니다. 세번째는 172.16.0.5 의 21,22,23 번 포트를 향한 패킷이 매치됩니다. 마지막은 호스트 192.168.0.5 의 1024에서 1028번 까지의 포트를 향한 UDP 패킷이 매치됩니다. 마지막 룰은 포트를 지정하기에 비트마스크를 사용하였기 때문에 다소 헷갈리기 쉽습니다. 1024 포트는 10 비트를 포함합니다. 비트마스크는 192.168.0.5를 향한 1024 포트의 마지막 8비트에 해당되는 모든 포트들을 가리킵니다. 10 – 8 을 해서 2 비트가 되고 그 이 비트가 2^2 로 해서 4개의 포트가 되는 것입니다. 시작을 1024 로 해서 4개의 포트에 해당하는 패킷이 매치되는 것이죠. 포트에 비트마스크를 사용하는 것은 잘 쓰이지 않고 IP 주소에 덧붙이는 비트마스크나 넷마스크보다 더 헷갈릴 수 있습니다. 왜냐하면 포트에서의 비트수는 마스크 앞에 지정된 포트에 따라 변하기 때문입니다. 그러므로, 대쉬(dash)를 사용하거나 콤마로 분리하여 포트를 지정하는 걸 추천합니다. 4. Advanced ipfw(8) Rule Syntax (고급 ipfw 문법) 위에서 대략적으로 살펴본 ipfw(8)의 룰 설정법이 많은 단순한 상황에 대처할 수 있지만 보다 더 복잡한 상황들, 예를 들어 시스템이 한 개 이상의 네트웍 인터페이스를 가지고 있다든가, 특정한 매치상황에 대해 특별한 반응을 하길 원한다든지 혹은 트래픽 흐름 (traffice flow)에 대해 더 많은 조정을 하고 싶은 경우에 상당히 모자랍니다. 다음과 같이 ipfw(8) 에 대한 구문을 확장시켜 봅시다. [command] [rule #] [action] [log [logamount number]] [proto] from [source] to [destination] [interface-spec] [options] 새로운 기능들을 포함하는 부분을 이번 섹션에서 다룰 겁니다. 또한 전에 설명하지 않았던 추가적인 “action” 을 알아보기로 하겠습니다. 구문 (syntax)이 상당히 어렵게 보이지만 찬찬히 뜯어보고 피곤하지 않도록 조금씩 알아보기로 하죠. 4.1 “unreach” Action 우선 새로운 “action” 을 소개합니다. “unreach [code]” – 이 action 을 지닌 룰에 매치되는 모든 패킷은 ICMP unreach code 를 내보내고 (response) 그 뒤로 ruleset 검색을 멈추게 됩니다. 사용가능한 unreach code 는 숫자나 혹은 이름으로 지정됩니다. 다음은 ICMP unreach code 를 간략히 나열하고 그에 대응하는 이름을 써 놓은 것입니다. 이것들이 무엇에 사용되는지 알지 못한다면 쓸 필요는 없습니다. net 0 net-prohib 9 host 1 host-prohib 10 protocol 2 tosnet 11 port 3 toshost 12 needfrag 4 filter-prohib 13 srcfail 5 host-precedence 14 net-unknown 6 precedence-cutoff 15 host-unknown 7 isolated 8 4.2 Interface and Flow Control (인터페이스와 흐름 제어) 섹션 3 의 ipfw(8) 기본적 문법 설명에서 빠진 중요한 기능은 인터페이스와 흐름 제어 (interface and Flow control) 입니다. 즉, 여러 개의 인터페이스(interface)를 가지고 있을 때 (multihomed) 어떤 인터페이스를 통과하는 패킷을 매치시킬 것인지 그리고 어떠한 방향으로 이동하는 패킷을 매치시킬 것인지를 지정할 수 있는 기능입니다. 지금까지는 방향(direction)으로 전송지와 목적지 주소 (source and destination address)를 대강 (loosely) 사용했는데, 패킷이 방화벽을 통과할 때 진짜 들어오는지 나가는지에 대해 어림짐작하는 그런 방법은 신뢰할 수 없는 방법입니다. 만약 단순히 들어오거나 혹은 나가는 패킷만을 매치시키길 원한다면 “in” 과 “out” 키워드를 사용하면 됩니다. 둘 모두 위에서 살펴본 문법 구문중 “interface-spec” 부분에 대응하며 따라서, 임의의 옵션들보다 앞서 모든 룰의 마지막 부분에 사용합니다. 예를 들어 임의의 곳에서 와서 임의의 곳으로 가는 (coming in from anywhere and going anywhere) 모든 패킷을 매치시키고자 할 때 다음과 같이 사용합니다. add 1000 allow all from any to any in 특별한 인터페이스를 통과하는 패킷을 매치시키고자 한다면 “via” 옵션과 뒤따르는 인터페이스 이름을 사용하면 됩니다. 예를 들어, 사용자가 PCI 3Com 3c59x 를 가지고 있다면 그 인터페이스 디바이스명은 xl0 이 됩니다. 정확히 임의의 전송지와 임의의 목적지를 가진 그 인터페이스로 유입되는 모든 패킷들을 매치시키고자 할 때 다음과 같이 써주면 충분합니다. Add 1100 allow all from any to any in via xl0 혹은 아마 여러 인터페이스를 가지고 있고 (multihomed system) 임의의 장치를 통과하여 나가는 모든 패킷을 매치시키고자 한다면 다음과 같이 합니다. add 1200 allow all from any to any out via any 눈치 챘을지 모르지만, 방화벽 룰을 나열할 때 룰상으론 “in” “out” 키워드를 “via” 와 함께 사용했다 하더라도 실제로 보이는 것은 “in”이나 “out” 중 무엇을 사용했는가에 따라 “via” 가 아니고 “recv” 나 “xmit” 이 됩니다. 다음을 봅시다. (root@nu)~># ipfw add 7000 allow all from any to any out via xl0 (root@nu)~># ipfw list | grep 7000 07000 allow ip from any to any out xmit xl0 (root@nu)~># 사실은, “in” 이나 “out” 키워드를 쓸 때 “via” 대신 “recv” 나 “xmit” 을 쓸 도 있습니다만 그렇게 하는 것은 필요하지도 않을 뿐더러 초보자에게 다소 혼란을 줄 수 있습니다. 모든 경우에 있어, 이러한 옵션들은 방화벽으로 유입되거나 나가거나 혹은 특정한 인터페이스를 통과하는 패킷을 명확히 필터링함으로써 다중 인터페이스를 가진 시스템이나 보편적으로 모든 시스템상의 네트웍 트래픽에 대한 보다 강력한 통제를 가능하게 해 줍니다. 4.3 Matching specific ICMP and TCP Packet Types (특정한 ICMP 와 TCP 패킷 타입을 매칭시키기) ICMP, TCP, 그리고 IP 패킷은 다양한 타입을 지닙니다. 이러한 타입들은 각각의 패킷이 정한 여러가지의 flag 에 의해 정의됩니다. 우리는 다음에 보게 되는 ipfw(8) 옵션들 중 하나를 룰의 끝에 사용함으로써 그러한 타입들 중 하나를 매치시킬 수 있습니다. 4.3.1 icmptypes “icmptypes [type]” – 이것은 특정한 ICMP 패킷 [type] 을 매칭시키며, 역으로 “!” 가 [type] 앞에 놓인다면 이 타입에 해당하지 않는 모든 ICMP 패킷을 매치할 것입니다. 현재 매치 가능한 15 개의 다른 ICMP 패킷 타입이 존재하며 정확한 숫자에 의해 기술됩니다. 범위를 정하고자 한다면 dash 나 콤마로 분리된 형태로 서술될 수도 있습니다. 15 가지 ICMP 타입은 다음과 같습니다. 0-Echo Reply 3-Destination Unreachable 4-Source Quench 5-Redirect 8-Echo Request 9-Router Advertisement 10-Router Silicitation 11-Time-to-Live Exceeded 12-IP header bad 13-Timestamp Request 14-Timestamp Reply 15-Information Request 16-Information Reply 17-Address Mask Request 18-Address Mask Reply 이러한 ICMP 타입이, (정확히는 type 3), “unreach” action 으로 발생되는 Unreach code 와 어떻게 대응하는가 하면 간단히 type 3이 모든 Unreach code 와 매치합니다. ICMP 패킷을 필터링하는 것은 ping 을 컨트롤하는데 매우 유용하며, 특히 내부 호스트들이 외부로 핑을 가능하게 하는 반면 외부 호스트에서 내부의 게이트웨이나 혹은 어떤 또 다른 내부 호스트로 핑을 불가하게 하고자 할 때 유용합니다. 1000 allow icmp from any to any out icmptypes 8 1100 allow icmp from any to any in icmptypes 0 1200 deny icmp from any to any in icmptypes 8 처음 룰은 type 8 (echo request) 형태를 취하는 모든 icmp 패킷의 외부 전송을 허용합니다. 두번째 룰은 type 0 (echo reply) 의 모든 icmp 패킷의 유입을 허용하고 마지막 룰은 type 8 의 모든 icmp 패킷의 유입을 막습니다. 간단히 말해서, 이것은 echo requests 의 외부 전송을 허락하지만 들어오는 모든 echo requests 의 유입을 막게 되죠. 그렇게 함으로써 방화벽 내부의 호스트들은 외부의 임의의 호스트로 ping 을 사용할 수 있고 반면에 외부의 호스트들은 방화벽 내부의 어떠한 곳에도 ping을 사용할 수 없게 됩니다. 당연히 이러한 옵션은 지정된 프로토콜이 “icmp” 일때만 사용가능합니다. 4.3.2 tcpflags, setup and established “tcpflags [flag]” – 이것은 뒤따르는 flags 중 하나를 헤더에 포함하는 모든 TCP 패킷과 매치되며 역으로 “!” 가 [flag] 앞에 붙을 경우 그 [flag] 를 포함하지 않는 모든 TCP 패킷과 매치됩니다. fin - Request for connexion termination syn - Request for connexion initiation rst - Reset Connexion psh - Push Flag ack - Acknowledgement urg - Indicate Urgent OOB data SYN 플래그는 TCP 연결 초기화를 위해 전송되는 것으로 매우 중요한 역할을 합니다. 상당히 중요하기 때문에, 특별히 SYN 플래그 셋(SYN flag set) 을 가진 TCP 패킷을 매치하기 위하여 별도의 ipfw(8) 옵션이 존재합니다. 이것이 “setup” 이라 불리는 것입니다. 당연히 이 옵션은 프로토콜이 “tcp” 로 지정되었을 때 사용가능합니다. “setup” – 이 옵션을 포함하는 어떠한 룰도 SYN flag set 을 가진 모든 TCP 패킷과 매치됩니다. 예를 들어, 만약 내부로 전송되는 모든 TCP SYN 패킷을 거부하고자 한다면 다음가 같이 하면 됩니다. Add deny tcp from any to any in tcpflags syn 혹은 add deny tcp from any to any in setup 양쪽 모두, 같은 작용이 일어납니다: “어떤 곳”에서 오든 “어떤 곳”으로 가든(from “any”destined to “any”) 모든 TCP SYN 패킷이 매치되어 거부됩니다. “tcpflags” 에 대해 위에서 말한 것처럼, 이 옵션은 지정된 프로토콜이 “tcp” 인 룰에 대해서만 사용가능합니다. “established” – TCP 연결 초기화 (“setup”) (TCP connexion initiation)에 대한 요청을 가리키는 특별한 옵션이 존재하는 것처럼, 이미 서로 개설된 TCP 연결 (already established TCP connexion)과 매치되는 특별한 옵션이 있습니다. 그것은 TCP 연결을 컨트롤하는데 있어 가장 중요한 부분이기에, “established” 와 “setup” 은 신속한 룰 설정(quick rule formation) 에 사용할 수 있습니다. 이 옵션들을 가지고 (혹은 그들과 대응되는 “tcpflags” 형태) 우리는 TCP 연결 활동에 대한 몇몇 단순한 제어를 하게 됩니다. 이것은 stateful firewall (가변적 방화벽) 기능에 가장 기초가 되는 부분이고 후에 좀더 자세하게 알아볼 것입니다. 4.3.3. ipoptions “ ipoptions [flag]” – 마지막으로 우리는 SSSR (Strict Source Route), LSRR (Loose Source Route), RR (Record Packet Route), 그리고 TS (Timestamp)라 불리는 특정한 IP 패킷 플래그들을 매치시킬 수 있습니다. 만약 이러한 IP 옵션들이 무엇인지 알지 못한다면 특별히 그들에 대한 매치가 필요하지 않을 것입니다. 4.4 Catching Fragmented Packets (조각난 패킷 잡아내기) 조각난 패킷(fragmented packets) 은 ipfw(8)의 “frag” 옵션과 매치됩니다. 대부분의 경우 조각난 패킷은 막아져야 (blocked) 합니다. 많은 수의 조각난 패킷을 받았다는 것은 DoS (Denial of Service) 공격을 의미할 수도 있습니다. FreeBSD 와 대부분의 다른 UNIX 그리고 UNIX-like 시스템은 그러한 공격에 쓰러지지는 않겠지만 Windows 시스템은 종종 매우 취약한 (vulnerable) 모습을 보입니다. 따라서 사용자가 방화벽 내부 네트웍상에 하나나 그 이상의 Windows 시스템을 가지고 있을 경우 조각난 패킷을 막을 것을 충고합니다. 조각난 패킷을 매치시키기 위해 “frag” 옵션을 사용할 경우, 따라야 할 두 지침이 있습니다. 우선, “tcpflags” 와 함께 “frag” 옵션은 같이 사용할 수 없습니다. 둘째, 만약 임의의 TCP 혹은 UDP 포트를 지정했다면 역시 “frag” 옵션을 사용할 수 없습니다. 이 같은 기준을 지켰다면 우리는 쉽게 내부로 향하는 조각난 패킷을 막을 수 있습니다. 4.5 UID and GID Based Filtering (UID 와 GID 기반 필터링) Ipfilter 가 가지지 못한 강력한 기능중 하나가 UID/GID 기반 필터링(UID/GID-based filtering) 입니다. Ipfirewall(4) 은 패킷을 그 자신이 발생되는 (arriving from) 프로세스의 UID 나/혹은 GID 에 따라서 필터링 할 수 있습니다. 당연히 이것은 로컬 호스트 (localhost) 상의 프로세스에서 기인한 패킷들을 매칭시키고자 할 때 사용할 수 있습니다. 하지만 여전히 강력한 기능을 발휘합니다. 사용되는 옵션은 “uid” 와 “gid”이며 그 뒤에 우리가 필터링하고자 하는 UID/GID 혹은 사용자나 그룹명이 뒤따르게 됩니다. 한가지 가능성 있는 사용법이라면 shell server 상의 IP 가상 호스트 ( IP vhosts  on a shell server) 사용을 제한하는 것입니다. 만약 하나나 그 이상의 가상호스트를 자신을 제외한 다른 어떤 사람도 사용하지 않는 것이 확실할 경우 그 가상호스트로부터 사용자 자신의 트래픽을 제외한 모든 사람의 트래픽을 막기 위해 UID-기반 필터링을 사용할 수 있습니다. add allow tcp from any to 172.168.0.10 in add allow tcp from 172.168.0.10 to any out uid george add deny tcp from 172.168.0.10 to any 위 룰들에 따르면 오로지 george 라는 유저만이 외부와 TCP 연결을 개설하기 위해 (to establish TCP connecxions to the outside) aliased IP (IP vhost) 172.168.0.10 을 사용할 수 있게 됩니다. 다른 어떠한 사람도 바인드 봇 (bind bots), IRC chat 클라이언트를 위해 혹은 TCP 를 필요로 하는 연결(대부분 그렇지만)을 개설하기 위해 그 아이피를 사용할 수 없습니다. 마찬가지로, UDP 프로토콜도 UID/GID 기반 필터링과 함께 사용할 수 있습니다. 그러나 그 외 다른 프로토콜은 불가합니다. 또 다른 UID/GID 기반 필터링의 용도라면 호스트나 네트웍 기준 (per-host or per-network basis)과는 정반대로 사용자 기준 (per-user basis)으로 대역폭(bandwidth) 을 제한하는 것입니다. 그렇게 함으로써 예를 들어 빠른 FTP 계정을 가진 일련의 사용자 그룹을 단순히 조정하여 그들의 GID 를 한정하여 가질 수 있고, 또 이와는 반대로 많은 대역폭을 필요로 하지 않는 쉘 유저들의 그룹도 설정함으로써 그들 모두가 속한 GID 에 따라 대역폭을 조절 (cap the bandwidth)할 수 있습니다. 그러한 GID 기반 대역폭 조절 (GID-based bandwidth capping)은 ipfirewall(8)의 트래픽 조절 기능(traffic shaping facilities) 을 알아본 뒤 후에 예시해보기로 하겠습니다. 보안상의 이유로, 특정 사용자의 트래픽을 기록하고 싶을 때 마찬가지로 UID 기반 필터링이 편리합니다. 간단히 말해서, 하나나 그 이상의 사용자들에 대해 방화벽 작용을 달리 하고자 한다면 (conduct filrewall behaviour differently) UID/GID 기반 필터링 (UID/GID-based filtering) 이 편리합니다. 일반적으로 어떠한 룰이 매치되게 되면 ruleset 탐색은 멈추기 때문에, UID/GID가 매치되는 룰은 다른 연이은 룰 (other sweeping rule)이 그 트래픽과 매치되기 전에 작용해야 합니다. 그래서 UID/GID 기반 필터링을 가능하게 하는 자신만의 ruleset 을 작성하고자 한다면 이것을 항상 염두에 두어야 합니다.