From owner-svn-doc-all@FreeBSD.ORG Sat Feb 22 03:13:44 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 D4820876; Sat, 22 Feb 2014 03:13:44 +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 BF6F81FFA; Sat, 22 Feb 2014 03:13:44 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1M3DiCE012567; Sat, 22 Feb 2014 03:13:44 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1M3Dimg012566; Sat, 22 Feb 2014 03:13:44 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402220313.s1M3Dimg012566@svn.freebsd.org> From: Dru Lavigne Date: Sat, 22 Feb 2014 03:13:44 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44025 - 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: Sat, 22 Feb 2014 03:13:44 -0000 Author: dru Date: Sat Feb 22 03:13:44 2014 New Revision: 44025 URL: http://svnweb.freebsd.org/changeset/doc/44025 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 Sat Feb 22 02:43:03 2014 (r44024) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Feb 22 03:13:44 2014 (r44025) @@ -156,28 +156,27 @@ rulesets - A ruleset contains a group of rules which pass or - block packets based on the values contained in the packet. - 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 - 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 - destination address. All the above parameters can be used as - selection criteria to create rules which will pass or block - services. - - To lookup unknown port numbers, refer to - /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers - and do a port number lookup to find the purpose of a - particular port number. + A ruleset contains a group of rules which pass or block + packets based on the values contained in the packet. 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 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 destination address. + All the above parameters can be used as selection criteria to + create rules which will pass or block services. + + To lookup unknown port numbers, refer to + /etc/services. Alternatively, visit http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers + and do a port number lookup to find the purpose of a particular + port number. - Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. + Check out this link for port numbers used by Trojans http://www.sans.org/security-resources/idfaq/oddports.php. A firewall ruleset can be either exclusive or inclusive. An @@ -207,35 +206,34 @@ connections and only allows traffic which either matches an existing connection or opens a new, allowed connection. - Stateful filtering treats traffic as a bi-directional - exchange of packets comprising a session. When state is specified on a matching rule - the firewall dynamically generates - internal rules for each anticipated packet being exchanged - during the session. It has sufficient matching capabilities - to determine if a packet is valid for a session. Any packets - that do not properly fit the session template are - automatically rejected. - - When the session completes, it is removed from the - dynamic state table. - - Stateful filtering allows one to focus on blocking/passing - new sessions. If the new session is passed, all its - subsequent packets are allowed automatically and any impostor - packets are automatically rejected. If a new session is - blocked, none of its subsequent packets are allowed. Stateful - filtering provides advanced matching abilities capable of - defending against the flood of different attack methods - employed by attackers. + Stateful filtering treats traffic as a bi-directional + exchange of packets comprising a session. When state is + specified on a matching rule the firewall dynamically generates + internal rules for each anticipated packet being exchanged + during the session. It has sufficient matching capabilities to + determine if a packet is valid for a session. Any packets that + do not properly fit the session template are automatically + rejected. + + When the session completes, it is removed from the dynamic + state table. + + Stateful filtering allows one to focus on blocking/passing + new sessions. If the new session is passed, all its subsequent + packets are allowed automatically and any impostor packets are + automatically rejected. If a new session is blocked, none of + its subsequent packets are allowed. Stateful filtering provides + advanced matching abilities capable of defending against the + flood of different attack methods employed by attackers. - - When working with the firewall rules, be very - careful. Some configurations can + + When working with the firewall rules, be very + careful. Some configurations can lock the administrator out of the server. To be - on the safe side, consider performing the initial firewall - configuration from the local console rather than doing it - remotely over ssh. - + on the safe side, consider performing the initial firewall + configuration from the local console rather than doing it + remotely over ssh. + @@ -1685,23 +1683,22 @@ ipnat_rules="/etc/ipnat.rules" # rule &prompt.root; service ipfilter start - To load the firewall rules, specify the name of the ruleset file using ipf. - The following command can - be used to replace the currently running firewall + To load the firewall rules, specify the name of the + ruleset file using ipf. The following + command can be used to replace the currently running firewall rules: &prompt.root; ipf -Fa -f /etc/ipf.rules where flushes all the internal rules - tables and specifies the file containing the - rules to load. + tables and specifies the file containing + the rules to load. This provides the ability to make changes to a custom - ruleset and update the - running firewall with a fresh copy of the rules without having - to reboot the system. This method is convenient for testing - new rules as the procedure can be executed as many times as - needed. + ruleset and update the running firewall with a fresh copy of + the rules without having to reboot the system. This method is + convenient for testing new rules as the procedure can be + executed as many times as needed. Refer to &man.ipf.8; for details on the other flags available with this command. @@ -1716,37 +1713,40 @@ ipnat_rules="/etc/ipnat.rules" # rule rule syntax - This section describes the IPF rule syntax - used to create stateful rules. When creating rules, keep in - mind that unless the quick keyword appears - in a rule, every rule is read - in order, with the last matching rule - being the one that is applied. This means that even if the first rule to match a packet is a - pass, if there is a later matching rule - that is a block, the packet will be dropped. - Sample rulesets can be found in - /usr/share/examples/ipfilter. - - When creating rules, a # character is used to mark the - start of a comment and may appear at the end of a rule, to explain that rule's function, - or on its own line. Any blank lines are ignored. - - The keywords which are used in rules must be written in a specific - order, from left to right. Some keywords are mandatory while - others are optional. Some keywords have sub-options which may be - keywords themselves and also include more sub-options. The - keyword order is as follows, where the words shown in uppercase - represent a variable and the words shown in lowercase must - precede the variable that follows it: + This section describes the IPF + rule syntax used to create stateful rules. When creating + rules, keep in mind that unless the quick + keyword appears in a rule, every rule is read in order, with + the last matching rule being the one + that is applied. This means that even if the first rule to + match a packet is a pass, if there is a + later matching rule that is a block, the + packet will be dropped. Sample rulesets can be found in + /usr/share/examples/ipfilter. + + When creating rules, a # character is + used to mark the start of a comment and may appear at the end + of a rule, to explain that rule's function, or on its own + line. Any blank lines are ignored. + + The keywords which are used in rules must be written in a + specific order, from left to right. Some keywords are + mandatory while others are optional. Some keywords have + sub-options which may be keywords themselves and also include + more sub-options. The keyword order is as follows, where the + words shown in uppercase represent a variable and the words + shown in lowercase must precede the variable that follows + it: ACTION DIRECTION OPTIONS proto PROTO_TYPE - from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT TCP_FLAG|ICMP_TYPE - keep state STATE + from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT + TCP_FLAG|ICMP_TYPE keep state STATE - This section describes each of these keywords and their options. It - is not an exhaustive list of every possible option. Refer to - &man.ipf.5; for a complete description of the rule - syntax that can be used when creating + This section describes each of these keywords and their + options. It is not an exhaustive list of every possible + option. Refer to &man.ipf.5; for a complete description of + the rule syntax that can be used when creating IPF rules and examples for using each keyword. @@ -1755,15 +1755,16 @@ ipnat_rules="/etc/ipnat.rules" # rule ACTION The action keyword indicates what to do with the - packet if it matches that rule. Every - rule must have an action. The + packet if it matches that rule. Every rule + must have an action. The following actions are recognized: block: drops the packet. pass: allows the packet. - log: generates a log record. + log: generates a log + record. count: counts the number of packets and bytes which can provide an indication of @@ -1777,62 +1778,60 @@ ipnat_rules="/etc/ipnat.rules" # rule allow more complex actions. decapsulate: removes any headers - in order to process the contents of the packet. + in order to process the contents of the packet. DIRECTION - Next, each rule must - explicitly state the direction of traffic using one of - these keywords: + Next, each rule must explicitly state the direction + of traffic using one of these keywords: - in: the rule is - applied against an inbound packet. + in: the rule is applied against + an inbound packet. - out: the rule is - applied against an outbound packet. + out: the rule is applied against + an outbound packet. all: the rule applies to either direction. - + If the system has multiple interfaces, the interface - can be specified along with the direction. An example would - be in on fxp0. + can be specified along with the direction. An example + would be in on fxp0. OPTIONS - Options are optional. However, if multiple options - are specified, they must be used in the order shown - here. + Options are optional. However, if multiple options + are specified, they must be used in the order shown + here. log: when performing the - specified ACTION, the contents of the packet's - headers will be written to the &man.ipl.4; packet log + specified ACTION, the contents of the packet's headers + will be written to the &man.ipl.4; packet log pseudo-device. - quick: if - a packet matches this rule, the ACTION specified by the - rule occurs and no further processing of any - following rules will occur for this packet. - - on: must be followed by the interface name - as displayed by &man.ifconfig.8;. - The rule will only match if the - packet is going through the specified interface in the specified - direction. + quick: if a packet matches this + rule, the ACTION specified by the rule occurs and no + further processing of any following rules will occur for + this packet. + + on: must be followed by the + interface name as displayed by &man.ifconfig.8;. The + rule will only match if the packet is going through the + specified interface in the specified direction. When using 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. + 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 @@ -1841,8 +1840,9 @@ ipnat_rules="/etc/ipnat.rules" # rule packet is logged and not every packet which matches the stateful connection. - Additional options are available to specify - error return messages. Refer to &man.ipf.5; for more details. + Additional options are available to specify error + return messages. Refer to &man.ipf.5; for more + details. @@ -1850,7 +1850,7 @@ ipnat_rules="/etc/ipnat.rules" # rule PROTO_TYPE - The protocol type is optional. However, it is + The protocol type is optional. However, it is mandatory if the rule needs to specify a a SRC_PORT or a DST_PORT as it defines the type of protocol. When specifying the type of protocol, use the @@ -1858,10 +1858,10 @@ ipnat_rules="/etc/ipnat.rules" # rule protocol number or name from /etc/protocols. Example protocol names include tcp, - udp, or - icmp. If PROTO_TYPE is specified but - no SRC_PORT or DST_PORT is specified, all port numbers - for that protocol will match that rule. + udp, or icmp. If + PROTO_TYPE is specified but no SRC_PORT or DST_PORT is + specified, all port numbers for that protocol will match + that rule. @@ -1870,17 +1870,19 @@ ipnat_rules="/etc/ipnat.rules" # rule The from keyword is mandatory and is followed by a keyword which represents the source of - the packet. The source can be a hostname, an + the packet. The source can be a hostname, an IP address followed by the CIDR mask, an address pool, or the keyword all. Refer to &man.ipf.5; for examples. - 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 package or port may be used to - ease the calculation of the CIDR mask. Additional information is + 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 package or port may + be used to ease the calculation of the + CIDR mask. Additional information is available at the utility's web page: http://jodies.de/ipcalc. @@ -1890,24 +1892,24 @@ ipnat_rules="/etc/ipnat.rules" # rule SRC_PORT The port number of the source is optional. However, - if it is used, it requires PROTO_TYPE to be first defined in - the rule. The port number must also be preceded by the - proto keyword. - - A number of different comparison operators are supported: - = (equal to), - != (not equal to), + if it is used, it requires PROTO_TYPE to be first + defined in the rule. The port number must also be + preceded by the proto keyword. + + A number of different comparison operators are + supported: = (equal to), + != (not equal to), < (less than), - > (greater than), + > (greater than), <= (less than or equal to), and - >= (greater than or equal to). - + >= (greater than or equal + to). To specify port ranges, place the two port numbers - between <> (less than and greater than ), - >< (greater than and less than ), or - : (greater than or equal to and - less than or equal to). + between <> (less than and + greater than ), >< (greater + than and less than ), or : (greater + than or equal to and less than or equal to). @@ -1915,20 +1917,21 @@ ipnat_rules="/etc/ipnat.rules" # rule DST_ADDR The to keyword is mandatory and - is followed by a keyword which represents the destination of - the packet. Similar to SRC_ADDR, it can be a hostname, an - IP address followed by the - CIDR mask, an address pool, or the - keyword all. + is followed by a keyword which represents the + destination of the packet. Similar to SRC_ADDR, it can + be a hostname, an IP address + followed by the CIDR mask, an address + pool, or the keyword all. DST_PORT - Similar to SRC_PORT, the port number of the destination is optional. However, - if it is used, it requires PROTO_TYPE to be first defined in - the rule. The port number must also be preceded by the + Similar to SRC_PORT, the port number of the + destination is optional. However, if it is used, it + requires PROTO_TYPE to be first defined in the rule. + The port number must also be preceded by the proto keyword. @@ -1936,11 +1939,12 @@ ipnat_rules="/etc/ipnat.rules" # rule TCP_FLAG|ICMP_TYPE - If tcp is specifed as the PROTO_TYPE, flags - can be specified as letters, where each letter represents one of the possible - TCP flags used to determine - the state of a connection. Possible values - are: S (SYN), + If tcp is specifed as the + PROTO_TYPE, flags can be specified as letters, where + each letter represents one of the possible + TCP flags used to determine the state + of a connection. Possible values are: + S (SYN), A (ACK), P (PSH), F (FIN), @@ -1949,9 +1953,10 @@ ipnat_rules="/etc/ipnat.rules" # rule C (CWN), and E (ECN). - If icmp is specifed as the PROTO_TYPE, - the ICMP type to match can be - specified. Refer to &man.ipf.5; for the allowable types. + If icmp is specifed as the + PROTO_TYPE, the ICMP type to match + can be specified. Refer to &man.ipf.5; for the + allowable types. @@ -1959,39 +1964,42 @@ ipnat_rules="/etc/ipnat.rules" # rule STATE If a pass rule contains - keep state, - IPF will add an entry to its - dynamic state table and allow subsequent packets that - match the connection. - IPF can track state for - TCP, UDP, and - ICMP sessions. Any packet that IPF can be certain - is part of an active session, even if it is a different - protocol, will be allowed. - - In IPF, packets destined to go out through the interface connected - to the public Internet are first checked against the dynamic - state table. If the packet matches the next expected packet - comprising an active session conversation, it exits the - firewall and the state of the session conversation flow is - updated in the dynamic state table. Packets that do not - belong to an already active session are checked against the - outbound ruleset. Packets coming in from the interface connected to the - public Internet are first checked against the dynamic state - table. If the packet matches the next expected packet - comprising an active session, it exits the firewall and the - state of the session conversation flow is updated in the - dynamic state table. Packets that do not belong to an already - active session are checked against the inbound - ruleset. - - Several keywords can be added after - keep state. If used, these keywords set - various options that control stateful filtering, such as - setting connection limits or connection age. Refer to - &man.ipf.5; for the list of available options and their - descriptions. - + keep state, + IPF will add an entry to its + dynamic state table and allow subsequent packets that + match the connection. + IPF can track state for + TCP, UDP, and + ICMP sessions. Any packet that + IPF can be certain is part of + an active session, even if it is a different protocol, + will be allowed. + + In IPF, packets destined + to go out through the interface connected to the public + Internet are first checked against the dynamic state + table. If the packet matches the next expected packet + comprising an active session conversation, it exits the + firewall and the state of the session conversation flow + is updated in the dynamic state table. Packets that do + not belong to an already active session are checked + against the outbound ruleset. Packets coming in from + the interface connected to the public Internet are first + checked against the dynamic state table. If the packet + matches the next expected packet comprising an active + session, it exits the firewall and the state of the + session conversation flow is updated in the dynamic + state table. Packets that do not belong to an already + active session are checked against the inbound + ruleset. + + Several keywords can be added after + keep state. If used, these keywords + set various options that control stateful filtering, + such as setting connection limits or connection age. + Refer to &man.ipf.5; for the list of available options + and their descriptions. + @@ -2003,47 +2011,51 @@ ipnat_rules="/etc/ipnat.rules" # rule which only allows services matching pass rules and blocks all others. - &os; uses the loopback interface (lo0) and the IP + &os; uses the loopback interface + (lo0) and the IP address 127.0.0.1 - for internal communication. The - firewall ruleset must contain rules to allow free movement of - these internally used packets: + for internal communication. The firewall ruleset must contain + rules to allow free movement of these internally used + packets: # no restrictions on loopback interface pass in quick on lo0 all pass out quick on lo0 all The public interface connected to the Internet is used to - authorize and control access of - all outbound and inbound connections. If one or more interfaces are cabled to private + authorize and control access of all outbound and inbound + connections. If one or more interfaces are cabled to private networks, those internal interfaces may require rules to allow - packets originating from the LAN to flow between the internal networks - or to the interface attached to the Internet. The ruleset should be organized into three major - sections: any trusted internal interfaces, outbound connections through the public - interface, and inbound connections through the public interface. - - These two rules allow all traffic to pass through a trusted - LAN interface named xl0: + packets originating from the LAN to flow + between the internal networks or to the interface attached to + the Internet. The ruleset should be organized into three + major sections: any trusted internal interfaces, outbound + connections through the public interface, and inbound + connections through the public interface. + + These two rules allow all traffic to pass through a + trusted LAN interface named + xl0: # no restrictions on inside LAN interface for private network pass out quick on xl0 all pass in quick on xl0 all - - The rules for the public interface's outbound and inbound sections should - have the most frequently matched rules placed before less - commonly matched rules, with the last rule in the section - blocking and logging all packets for that interface and - direction. + + The rules for the public interface's outbound and inbound + sections should have the most frequently matched rules placed + before less commonly matched rules, with the last rule in the + section blocking and logging all packets for that interface + and direction. This set of rules defines the outbound section of the - public interface named dc0. - These rules keep state and identify - the specific services that internal systems are authorized for public Internet access. - All the rules use quick and specify the + public interface named dc0. These rules + keep state and identify the specific services that internal + systems are authorized for public Internet access. All the + rules use quick and specify the appropriate port numbers and, where applicable, destination addresses. - # interface facing Internet (outbound) + # interface facing Internet (outbound) # Matches session start requests originating from or behind the # firewall, destined for the Internet. @@ -2082,11 +2094,11 @@ pass out quick on dc0 proto icmp from an # Block and log everything else block out log first quick on dc0 all - + This example of the rules in the inbound section of the - public interface blocks all undesirable packets first. - This reduces the number of packets that are - logged by the last rule. + public interface blocks all undesirable packets first. This + reduces the number of packets that are logged by the last + rule. # interface facing Internet (inbound) # Block all inbound traffic from non-routable or reserved address spaces @@ -2126,18 +2138,16 @@ block in log first quick on dc0 proto tc Any time there are logged messages on a rule with the log first option, run - ipfstat -hio - to evaluate how many times the rule has been matched. A - large number of matches may indicate that the system is - under attack. + ipfstat -hio to evaluate how many times the + rule has been matched. A large number of matches may indicate + that the system is under attack. The rest of the rules in the inbound section define which connections are allowed to be initiated from the Internet. The last rule denies all connections which were not explicitly allowed by previous rules in this section. - -# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with + # Allow traffic in from ISP's DHCP server. Replace z.z.z.z with # the same IP address used in the outbound section. pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state