From owner-svn-doc-all@FreeBSD.ORG Wed Feb 19 21:58:48 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F09C8860; Wed, 19 Feb 2014 21:58:48 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB16818A8; Wed, 19 Feb 2014 21:58:48 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1JLwm0i086029; Wed, 19 Feb 2014 21:58:48 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1JLwmfL086028; Wed, 19 Feb 2014 21:58:48 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402192158.s1JLwmfL086028@svn.freebsd.org> From: Dru Lavigne Date: Wed, 19 Feb 2014 21:58:48 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43998 - head/en_US.ISO8859-1/books/handbook/firewalls X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 21:58:49 -0000 Author: dru Date: Wed Feb 19 21:58:48 2014 New Revision: 43998 URL: http://svnweb.freebsd.org/changeset/doc/43998 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:22:40 2014 (r43997) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Wed Feb 19 21:58:48 2014 (r43998) @@ -1508,26 +1508,28 @@ block drop out quick on $ext_if from any IPFILTER, also known as - IPF, is a cross-platform, open source firewall which - has been ported to several operating systems, including &os;, NetBSD, OpenBSD, and - &solaris;. - - IPFILTER is a kernel-side firewall and - NAT mechanism that can be controlled and - monitored by userland programs. Firewall rules + IPF, is a cross-platform, open source + firewall which has been ported to several operating systems, + including &os;, NetBSD, OpenBSD, and &solaris;. + + IPFILTER is a kernel-side + firewall and NAT mechanism that can be + controlled and monitored by userland programs. Firewall rules can be set or deleted using ipf, NAT rules can be set or deleted using - ipnat, run-time statistics for the kernel parts of - IPFILTER can be printed using - ipfstat, and - ipmon can be used to log IPFILTER - actions to the system log files. - - IPF was originally written using a rule processing logic - of the last matching rule wins and only used - stateless rules. Since then, IPF has been enhanced to include - the quick and - keep state options. + ipnat, run-time statistics for the + kernel parts of IPFILTER can be + printed using ipfstat, and + ipmon can be used to log + IPFILTER actions to the system log + files. + + IPF was originally written using + a rule processing logic of the last matching rule + wins and only used stateless rules. Since then, + IPF has been enhanced to include the + quick and keep state + options. For a detailed explanation of the legacy rules processing method, refer to The IPF FAQ is at http://www.phildev.net/ipf/index.html. - A searchable archive of the IPFilter mailing list is - available at http://marc.info/?l=ipfilter. This section of the Handbook focuses on - IPF as it pertains to FreeBSD. - It provides examples which uses - rules that contain the quick and - keep state options. + IPF as it pertains to FreeBSD. It + provides examples which uses rules that contain the + quick and keep state + options. + Enabling <application>IPF</application> @@ -1553,9 +1556,10 @@ block drop out quick on $ext_if from any enabling - IPF is included in the basic &os; install as a kernel - loadable module, meaning that a custom kernel is not needed in - order to enable IPF. + IPF is included in the basic + &os; install as a kernel loadable module, meaning that a + custom kernel is not needed in order to enable + IPF. kernel options @@ -1581,35 +1585,37 @@ block drop out quick on $ext_if from any kernel options - For users who prefer to statically compile IPF support - into a custom kernel, refer to the instructions in . The following kernel options are - available: + For users who prefer to statically compile + IPF support into a custom kernel, + refer to the instructions in . + The following kernel options are available: options IPFILTER options IPFILTER_LOG options IPFILTER_LOOKUP options IPFILTER_DEFAULT_BLOCK - where options IPFILTER enables support for - IPFILTER, options IPFILTER_LOG enables IPF - logging using the ipl packet logging - pseudo device for every rule that has the - log keyword, - IPFILTER_LOOKUP enables IP pools in - order to speed up IP lookups, and options IPFILTER_DEFAULT_BLOCK changes - the default behavior so that any packet not matching a - firewall pass rule gets blocked. - - To configure the system to enable IPF - at boot time, add - the following entries to - /etc/rc.conf. These entries will also enable logging and - default pass all. To change the - default policy to block all without - compiling a custom kernel, remember to add a - block all rule at the end of the - ruleset. + where options IPFILTER enables support + for IPFILTER, + options IPFILTER_LOG enables + IPF logging using the + ipl packet logging pseudo device for + every rule that has the log keyword, + IPFILTER_LOOKUP enables + IP pools in order to speed up + IP lookups, and options + IPFILTER_DEFAULT_BLOCK changes the default + behavior so that any packet not matching a firewall + pass rule gets blocked. + + To configure the system to enable + IPF at boot time, add the following + entries to /etc/rc.conf. These entries + will also enable logging and default pass + all. To change the default policy to + block all without compiling a custom + kernel, remember to add a block all rule at + the end of the ruleset. ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -1619,17 +1625,16 @@ ipmon_flags="-Ds" # D = # v = log tcp window, ack, seq # n = map IP & port to names - If NAT - functionality is needed, also add these lines: + If NAT functionality is needed, also + add these lines: gateway_enable="YES" # Enable as LAN gateway ipnat_enable="YES" # Start ipnat function ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat Then, to start IPF now: - + &prompt.root; service ipfilter start - @@ -1640,8 +1645,8 @@ ipnat_rules="/etc/ipnat.rules" # rule The bi-directional exchange of packets between hosts comprises a session conversation. The firewall ruleset processes both the packets arriving from the public Internet, as well as the - packets produced by the system as a response to them. - Each TCP/IP service is predefined by its + packets produced by the system as a response to them. Each + TCP/IP service is predefined by its protocol and listening port. Packets destined for a specific service originate from the source address using an unprivileged port and target the specific service port on the @@ -1693,7 +1698,7 @@ ipnat_rules="/etc/ipnat.rules" # rule There is a way to build IPF rules that utilize the power of script symbolic substitution. For more information, see - . + . IPFILTER @@ -1728,196 +1733,205 @@ ipnat_rules="/etc/ipnat.rules" # rule - ACTION - - The action keyword indicates what to do with the packet - if it matches the rest of the filter rule. Each rule - must have an action. The following - actions are recognized: - - block indicates that the packet - should be dropped if the selection parameters match the - packet. - - pass indicates that the packet should - exit the firewall if the selection parameters match the - packet. - - + ACTION + + The action keyword indicates what to do with the + packet if it matches the rest of the filter rule. Each + rule must have an action. The + following actions are recognized: + + block indicates that the packet + should be dropped if the selection parameters match the + packet. + + pass indicates that the packet + should exit the firewall if the selection parameters + match the packet. + + - - IN-OUT - - A mandatory requirement is that each filter rule - explicitly state which side of the I/O it is to be used - on. The next keyword must be either in - or out and one or the other has to be - included or the rule will not pass syntax checks. - - in means this rule is being applied - against an inbound packet which has just been received on - the interface facing the public Internet. - - out means this rule is being applied - against an outbound packet destined for the interface facing - the public Internet. - - + + IN-OUT + + A mandatory requirement is that each filter rule + explicitly state which side of the I/O it is to be used + on. The next keyword must be either + in or out and one + or the other has to be included or the rule will not + pass syntax checks. + + in means this rule is being + applied against an inbound packet which has just been + received on the interface facing the public + Internet. + + out means this rule is being + applied against an outbound packet destined for the + interface facing the public Internet. + + - - OPTIONS - - - These options must be used in the order shown - here. - - - log indicates that the packet header - will be written to the &man.ipl.4; packet log pseudo-device - if the selection parameters match the packet. - - quick indicates that if the selection - parameters match the packet, this rule will be the last - rule checked, and no further processing of any following - rules will occur for this packet. - - on indicates the interface name to - be incorporated into the selection parameters. Interface - names are as displayed by &man.ifconfig.8;. Using this - option, the rule will only match if the packet is going - through that interface in the specified direction. - - When a packet is logged, the headers of the packet are - written to the &man.ipl.4; packet logging pseudo-device. - Immediately following the log keyword, - the following qualifiers may be used in this order: - - body indicates that the first 128 - bytes of the packet contents will be logged after the - headers. - - first. If the log - keyword is being used in conjunction with a keep - state option, this option is recommended so that - only the triggering packet is logged and not every packet - which matches the stateful connection. - - + + OPTIONS + + + These options must be used in the order shown + here. + + + log indicates that the packet + header will be written to the &man.ipl.4; packet log + pseudo-device if the selection parameters match the + packet. + + quick indicates that if the + selection parameters match the packet, this rule will be + the last rule checked, and no further processing of any + following rules will occur for this packet. + + on indicates the interface name + to be incorporated into the selection parameters. + Interface names are as displayed by &man.ifconfig.8;. + Using this option, the rule will only match if the + packet is going through that interface in the specified + direction. + + When a packet is logged, the headers of the packet + are written to the &man.ipl.4; packet logging + pseudo-device. Immediately following the + log keyword, the following qualifiers + may be used in this order: + + body indicates that the first 128 + bytes of the packet contents will be logged after the + headers. + + first. If the + log keyword is being used in + conjunction with a keep state option, + this option is recommended so that only the triggering + packet is logged and not every packet which matches the + stateful connection. + + - - SELECTION - - The keywords described in this section are used to - describe attributes of the packet to be checked when - determining whether or not rules match. There is a - keyword subject, and it has sub-option keywords, one of - which has to be selected. The following general-purpose - attributes are provided for matching, and must be used in - this order: - - + + SELECTION + + The keywords described in this section are used to + describe attributes of the packet to be checked when + determining whether or not rules match. There is a + keyword subject, and it has sub-option keywords, one of + which has to be selected. The following general-purpose + attributes are provided for matching, and must be used + in this order: + + - - PROTO - - proto is the subject keyword which - must include one of its corresponding keyword sub-option - values. The sub-option indicates a specific protocol to be - matched against. - - tcp/udp | udp | tcp | icmp or any - protocol names found in /etc/protocols - are recognized and may be used. The special protocol - keyword tcp/udp may be used to match - either a TCP or a UDP - packet, and has been added as a convenience to save - duplication of otherwise identical rules. - - + + PROTO + + proto is the subject keyword + which must include one of its corresponding keyword + sub-option values. The sub-option indicates a specific + protocol to be matched against. + + tcp/udp | udp | tcp | icmp or any + protocol names found in + /etc/protocols are recognized and + may be used. The special protocol keyword + tcp/udp may be used to match either a + TCP or a UDP + packet, and has been added as a convenience to save + duplication of otherwise identical rules. + + - - SRC_ADDR/DST_ADDR - - The all keyword is equivalent to - from any to any with no other match - parameters. - - from | to src to dst: the - from and to - keywords are used to match against IP addresses. Rules - must specify both the source and - destination parameters. any is a special - keyword that matches any IP address. Examples include: - from any to any, from 0.0.0.0/0 - to any, from any to - 0.0.0.0/0, from 0.0.0.0 to - any, and from any to - 0.0.0.0. - - There is no way to match ranges of IP addresses which - do not express themselves easily using the dotted numeric - form / mask-length notation. The - net-mgmt/ipcalc port may be used to ease - the calculation. Additional information is available at the - utility's web page: http://jodies.de/ipcalc. - - + + SRC_ADDR/DST_ADDR + + The all keyword is equivalent to + from any to any with no other match + parameters. + + from | to src to dst: the + from and to + keywords are used to match against IP addresses. Rules + must specify both the source and + destination parameters. any is a + special keyword that matches any IP address. Examples + include: from any to any, + from 0.0.0.0/0 to any, from + any to 0.0.0.0/0, from 0.0.0.0 to + any, and from any to + 0.0.0.0. + + There is no way to match ranges of IP addresses + which do not express themselves easily using the dotted + numeric form / mask-length notation. The + net-mgmt/ipcalc port may be used to + ease the calculation. Additional information is + available at the utility's web page: http://jodies.de/ipcalc. + + - - PORT - - If a port match is included, for either or both of - source and destination, it is only applied to - TCP and UDP packets. - When composing port comparisons, either the service name - from /etc/services or an integer port - number may be used. When the port appears as part of the - from object, it matches the source port - number. When it appears as part of the - to object, it matches the destination - port number. An example usage is - from any to any port = 80 - - Single port comparisons may be done in a number of ways, - using a number of different comparison operators. Instead - of the = shown in the example above, - the following operators may be used: !=, - <, >, - <=, >=, - eq, ne, - lt, gt, - le, and ge. - - To specify port ranges, place the two port numbers - between <> or - >< - - + + PORT + + If a port match is included, for either or both of + source and destination, it is only applied to + TCP and UDP + packets. When composing port comparisons, either the + service name from /etc/services or + an integer port number may be used. When the port + appears as part of the from object, + it matches the source port number. When it appears as + part of the to object, it matches the + destination port number. An example usage is + from any to any port = 80 + + Single port comparisons may be done in a number of + ways, using a number of different comparison operators. + Instead of the = shown in the example + above, the following operators may be used: + !=, <, + >, <=, + >=, eq, + ne, lt, + gt, le, and + ge. + + To specify port ranges, place the two port numbers + between <> or + >< + + - - TCP_FLAG - - Flags are only effective for TCP - filtering. The letters represent one of the possible flags - that can be matched against the TCP - packet header. - - The modernized rules processing logic uses the - flags S parameter to identify the TCP - session start request. - - + + TCP_FLAG + + Flags are only effective for TCP + filtering. The letters represent one of the possible + flags that can be matched against the + TCP packet header. + + The modernized rules processing logic uses the + flags S parameter to identify the TCP + session start request. + + - - STATEFUL - - keep state indicates that on a pass - rule, any packets that match the rules selection parameters - should activate the stateful filtering facility. - - - + + STATEFUL + + keep state indicates that on a + pass rule, any packets that match the rules selection + parameters should activate the stateful filtering + facility. + + + @@ -2332,8 +2346,9 @@ EOF - Disable IPFILTER in the system startup scripts by - adding ipfilter_enable="NO"to + Disable IPFILTER in the + system startup scripts by adding + ipfilter_enable="NO"to /etc/rc.conf. Then, add a script like the following to @@ -2383,7 +2398,7 @@ sh /etc/ipf.rules.script - In IPF, when a packet arrives at the firewall from the LAN + In IPF, when a packet arrives at the firewall from the LAN with a public destination, it passes through the outbound filter rules. NAT gets its turn at the packet and applies its rules top down, where the first @@ -2402,7 +2417,7 @@ sh /etc/ipf.rules.script - NAT will automatically translate the + NAT will automatically translate the private LAN IP address for each system on the LAN to the single public IP address as packets exit the firewall bound for the public Internet. It also performs the reverse @@ -2510,18 +2525,19 @@ sh /etc/ipf.rules.script0/32 which uses the IP address assigned to IF. - - <acronym>NAT</acronym> for a Large LAN + + <acronym>NAT</acronym> for a Large LAN - For networks that have large numbers of systems on the LAN - or networks with more than a single LAN, the process of - funneling all those private IP addresses into a single public - IP address becomes a resource problem that may cause problems - with the same port numbers being used many times across many - connections, causing collisions. This section describes two ways to - relieve this resource problem. + For networks that have large numbers of systems on the + LAN or networks with more than a single LAN, the process of + funneling all those private IP addresses into a single + public IP address becomes a resource problem that may cause + problems with the same port numbers being used many times + across many connections, causing collisions. This section + describes two ways to relieve this resource problem. - The first method is to assign ports to use. A normal NAT rule would look like: + The first method is to assign ports to use. A normal + NAT rule would look like: map dc0 192.168.1.0/24 -> 0/32 @@ -2541,7 +2557,8 @@ sh /etc/ipf.rules.scriptmap dc0 192.168.1.0/24 -> 0/32 portmap tcp/udp auto - The second method is to use a pool of public addresses. In very large LANs there comes a point where there are + The second method is to use a pool of public addresses. + In very large LANs there comes a point where there are just too many LAN addresses to fit into a single public address. If a block of public IP addresses is available, these addresses can be used as a pool, and @@ -2564,19 +2581,20 @@ sh /etc/ipf.rules.scriptmap dc0 192.168.1.0/24 -> 204.134.75.0/24 - - Port Redirection + + Port Redirection - A common practice is to have a web server, email server, - database server, and DNS server each segregated to a different - system on the LAN. In this case, the traffic from these - servers still has to undergo NAT, but there - has to be some way to direct the inbound traffic to the - correct server. For example, a web server operating on LAN - address 10.0.10.25 - and using a single public IP address of - 20.20.20.5, would - use this rule: + A common practice is to have a web server, email server, + database server, and DNS server each segregated to a + different system on the LAN. In this case, the traffic from + these servers still has to undergo NAT, + but there has to be some way to direct the inbound traffic + to the correct server. For example, a web server operating + on LAN address 10.0.10.25 and using a + single public IP address of 20.20.20.5, would use this + rule: rdr dc0 20.20.20.5/32 port 80 -> 10.0.10.25 port 80 @@ -2589,17 +2607,17 @@ sh /etc/ipf.rules.script rdr dc0 20.20.20.5/32 port 53 -> 10.0.10.33 port 53 udp - + - - FTP and <acronym>NAT</acronym> + + FTP and <acronym>NAT</acronym> - FTP has two modes: active mode and passive mode. The - difference is in how the data channel is acquired. Passive - mode is more secure as the data channel is acquired by the - ordinal ftp session requester. For a good explanation of FTP - and the different modes, see http://www.slacksite.com/other/ftp.html. + FTP has two modes: active mode and passive mode. The + difference is in how the data channel is acquired. Passive + mode is more secure as the data channel is acquired by the + ordinal ftp session requester. For a good explanation of + FTP and the different modes, see http://www.slacksite.com/other/ftp.html. IPNAT has a built in FTP proxy option which can be specified on the NAT map @@ -2797,9 +2815,9 @@ LOG_ERR - packets which have been logged - In order to setup IPFILTER to log all data to - /var/log/ipfilter.log, first - create the empty file: + In order to setup IPFILTER to + log all data to /var/log/ipfilter.log, + first create the empty file: &prompt.root; touch /var/log/ipfilter.log @@ -2896,7 +2914,7 @@ LOG_ERR - packets which have been logged the next being the ICMP message and sub-message type, separated by a slash. For example: ICMP 3/3 for a port unreachable message. - +