From owner-svn-doc-all@FreeBSD.ORG Tue Feb 25 17:38:33 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81464F2D; Tue, 25 Feb 2014 17:38:33 +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 687BF130F; Tue, 25 Feb 2014 17:38:33 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s1PHcXIJ026970; Tue, 25 Feb 2014 17:38:33 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s1PHcXZR026969; Tue, 25 Feb 2014 17:38:33 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201402251738.s1PHcXZR026969@svn.freebsd.org> From: Dru Lavigne Date: Tue, 25 Feb 2014 17:38:33 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44053 - 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: Tue, 25 Feb 2014 17:38:33 -0000 Author: dru Date: Tue Feb 25 17:38:33 2014 New Revision: 44053 URL: http://svnweb.freebsd.org/changeset/doc/44053 Log: Move the IPF chapter after the IPFW chapter. 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 Tue Feb 25 17:30:26 2014 (r44052) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Tue Feb 25 17:38:33 2014 (r44053) @@ -79,9 +79,8 @@ &os; has three firewalls built into the base system: PF, - IPFILTER, also known as - IPF, and - IPFW. + IPFW, and IPFILTER, also known as + IPF. &os; also provides two traffic shapers for controlling bandwidth usage: &man.altq.4; and &man.dummynet.4;. ALTQ has @@ -117,12 +116,12 @@ How to use and configure the - IPFILTER firewall. + IPFW firewall. How to use and configure the - IPFW firewall. + IPFILTER firewall. @@ -1585,2294 +1584,2294 @@ block drop out quick on $ext_if from any - - IPFILTER (IPF) + + IPFW firewall - IPFILTER + IPFW - 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 - 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. - - For a detailed explanation of the legacy rules processing - method, refer to http://coombs.anu.edu.au/~avalon/ip-filter.html. + IPFW is a stateful firewall written for + &os; which also provides a traffic shaper, packet scheduler, + and in-kernel NAT. - 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. + &os; provides a sample ruleset in + /etc/rc.firewall. The sample ruleset + define several firewall types for common scenarios to assist + novice users in generating an appropriate ruleset. + &man.ipfw.8; provides a powerful syntax which advanced users can + use to craft customized rulesets that meet the security + requirements of a given environment. - This section of the Handbook focuses on - IPF as it pertains to FreeBSD. It - provides examples of rules that contain the - quick and keep state - options. + IPFW is composed of several components: the kernel firewall + filter rule processor and its integrated packet accounting + facility, the logging facility, the + divert rule which triggers + NAT, the dummynet traffic shaper facilities, + the fwd rule forward facility, the bridge + facility, and the ipstealth facility. IPFW supports both IPv4 + and IPv6. - - Enabling <application>IPF</application> + + Enabling IPFW - IPFILTER + IPFW 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. + IPFW is included in the basic &os; install as a run time + loadable module. The system will dynamically load the kernel + module when rc.conf contains the + statement firewall_enable="YES". After + rebooting the system, the following white highlighted message + is displayed on the screen as part of the boot process: + + ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled + + The loadable module includes logging ability. To enable + logging and set the verbose logging limit, add these + statements to + /etc/sysctl.conf before rebooting: + + net.inet.ip.fw.verbose=1 +net.inet.ip.fw.verbose_limit=5 + + + + Kernel Options kernel options - IPFILTER + IPFIREWALL kernel options - IPFILTER_LOG + IPFIREWALL_VERBOSE kernel options - IPFILTER_DEFAULT_BLOCK + IPFIREWALL_VERBOSE_LIMIT - IPFILTER + IPFW 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: - - 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. - - ipfilter_enable="YES" # Start ipf firewall -ipfilter_rules="/etc/ipf.rules" # loads rules definition text file -ipmon_enable="YES" # Start IP monitor log -ipmon_flags="-Ds" # D = start as daemon - # s = log to syslog - # v = log tcp window, ack, seq - # n = map IP & port to names + For those users who wish to statically compile kernel + IPFW support, the following options are available for the + custom kernel configuration file: - If NAT functionality is needed, also - add these lines: + options IPFIREWALL - gateway_enable="YES" # Enable as LAN gateway -ipnat_enable="YES" # Start ipnat function -ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat + This option enables IPFW as part of the kernel. - Then, to start IPF now: + options IPFIREWALL_VERBOSE - &prompt.root; service ipfilter start + This option enables logging of packets that pass through + IPFW and have the log keyword specified in + the ruleset. - 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: + options IPFIREWALL_VERBOSE_LIMIT=5 - &prompt.root; ipf -Fa -f /etc/ipf.rules + This option limits the number of packets logged through + &man.syslogd.8;, on a per-entry basis. This option may be + used in hostile environments, when firewall activity logging + is desired. This will close a possible denial of service + attack via syslog flooding. - where flushes all the internal rules - tables and specifies the file containing - the rules to load. + + kernel options - 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. + IPFIREWALL_DEFAULT_TO_ACCEPT + - Refer to &man.ipf.8; for details on the other flags - available with this command. - + options IPFIREWALL_DEFAULT_TO_ACCEPT - - <application>IPF</application> Rule Syntax + This option allows everything to pass through the firewall + by default, which is a good idea when the firewall is being + set up for the first time. - IPFILTER + kernel options - rule syntax + IPDIVERT - 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. + options IPDIVERT - 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. + This option enables the use of NAT + functionality. - 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: + + The firewall will block all incoming and outgoing + packets if either the + IPFIREWALL_DEFAULT_TO_ACCEPT kernel + option or a rule to explicitly allow these connections is + missing. + + - ACTION DIRECTION OPTIONS proto PROTO_TYPE - from SRC_ADDR SRC_PORT to DST_ADDR DST_PORT - TCP_FLAG|ICMP_TYPE keep state STATE + + <filename>/etc/rc.conf</filename> Options - 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. + Enables the firewall: - - - ACTION - - The action keyword indicates what to do with the - packet if it matches that rule. Every rule - must have an action. The - following actions are recognized: + firewall_enable="YES" - block: drops the packet. + To select one of the default firewall types provided by + &os;, select one by reading + /etc/rc.firewall and specify it in + the following: - pass: allows the packet. + firewall_type="open" - log: generates a log - record. + Available values for this setting are: - count: counts the number of - packets and bytes which can provide an indication of - how often a rule is used. + + + open: passes all traffic. + + + client: protects only this + machine. + + + simple: protects the whole + network. + + + closed: entirely disables IP + traffic except for the loopback interface. + + + UNKNOWN: disables the loading of + firewall rules. + + + filename: + absolute path of the file containing the firewall + rules. + + - auth: queues the packet for - further processing by another program. + Two methods are available for loading custom + ipfw rules. One is to set the + firewall_type variable to the absolute + path of the file which contains the firewall rules. - call: provides access to - functions built into IPF that - allow more complex actions. + The other method is to set the + firewall_script variable to the absolute + path of an executable script that includes + ipfw commands. A ruleset script that + blocks all incoming and outgoing traffic would look like + this: - decapsulate: removes any headers - in order to process the contents of the packet. - - + #!/bin/sh - - DIRECTION - - Next, each rule must explicitly state the direction - of traffic using one of these keywords: +ipfw -q flush - in: the rule is applied against - an inbound packet. +ipfw add deny in +ipfw add deny out - out: the rule is applied against - an outbound packet. + + If firewall_type is set to either + client or simple, + modify the default rules found in + /etc/rc.firewall to fit the + configuration of the system. The examples used in this + section assume that the firewall_script + is set to /etc/ipfw.rules. + - all: the rule applies to either - direction. + Enable logging: - If the system has multiple interfaces, the interface - can be specified along with the direction. An example - would be in on fxp0. - - + firewall_logging="YES" - - OPTIONS - - Options are optional. However, if multiple options - are specified, they must be used in the order shown - here. + + firewall_logging sets the + net.inet.ip.fw.verbose sysctl + variable to the value of 1. There is no + rc.conf variable to set log + limitations, but the desired value can be set using + sysctl or by adding the following + variable and desired value to + /etc/sysctl.conf: - log: when performing the - specified ACTION, the contents of the packet's headers - will be written to the &man.ipl.4; packet log - pseudo-device. + net.inet.ip.fw.verbose_limit=5 + - 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. + If the machine is acting as a gateway providing + NAT using &man.natd.8;, + refer to for information + regarding the required /etc/rc.conf + options. + - 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. + + The IPFW Command - When using the - log keyword, the following qualifiers - may be used in this order: + ipfw - body: indicates that the first - 128 bytes of the packet contents will be logged after - the headers. + ipfw can be used to make manual, + single rule additions or deletions to the active firewall + while it is running. The problem with using this method is + that all the changes are lost when the system reboots. It is + recommended to instead write all the rules in a file and to + use that file to load the rules at boot time and to replace + the currently running firewall rules whenever that file + changes. - 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. + ipfw is a useful way to display the + running firewall rules to the console screen. The IPFW + accounting facility dynamically creates a counter for each + rule that counts each packet that matches the rule. During + the process of testing a rule, listing the rule with its + counter is one way to determine if the rule is + functioning as expected. - Additional options are available to specify error - return messages. Refer to &man.ipf.5; for more - details. + To list all the running rules in sequence: - - + &prompt.root; ipfw list - - PROTO_TYPE - - The protocol type is optional. However, it is - mandatory if the rule needs to specify a SRC_PORT or - a DST_PORT as it defines the type of protocol. When - specifying the type of protocol, use the - proto keyword followed by either a - 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. - - + To list all the running rules with a time stamp of when + the last time the rule was matched: - - SRC_ADDR - - 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 - IP address followed by the - CIDR mask, an address pool, or the - keyword all. Refer to &man.ipf.5; - for examples. + &prompt.root; ipfw -t list - 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. - - + The next example lists accounting information and the + packet count for matched rules along with the rules + themselves. The first column is the rule number, followed by + the number of matched packets and bytes, followed by the rule + itself. - - 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. + &prompt.root; ipfw -a list - A number of different comparison operators are - supported: = (equal to), - != (not equal to), - < (less than), - > (greater than), - <= (less than or equal to), and - >= (greater than or equal - to). + To list dynamic rules in addition to static rules: - 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). - - + &prompt.root; ipfw -d list - - 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. - - + To also show the expired dynamic rules: - - 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 - proto keyword. - - + &prompt.root; ipfw -d -e list - - 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), - A (ACK), - P (PSH), - F (FIN), - U (URG), - R (RST), - 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. - - + To zero the counters: - - 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. + &prompt.root; ipfw zero - 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. + To zero the counters for just the rule with number + NUM: - 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. - - - + &prompt.root; ipfw zero NUM - - Example Ruleset + + IPFW Rulesets - This section demonstrates how to create an example ruleset - which only allows services matching - pass rules and blocks all others. + + IPFW - &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: + rule processing order + - # no restrictions on loopback interface -pass in quick on lo0 all -pass out quick on lo0 all + When a packet enters the IPFW firewall, + it is compared against the first rule in the ruleset and + progresses one rule at a time, moving from top to bottom of + the set in ascending rule number sequence order. When the + packet matches the selection parameters of a rule, the rule's + action field value is executed and the search of the ruleset + terminates for that packet. This is referred to as + first match wins. If the packet does not match + any of the rules, it gets caught by the mandatory IPFW default + rule, number 65535, which denies all packets and silently + discards them. However, if the packet matches a rule that + contains the count, + skipto, or tee keywords, + the search continues. Refer to &man.ipfw.8; for details on + how these keywords affect rule processing. - 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 - 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. + The examples in this section create an inclusive type + firewall ruleset containing the stateful keep + state, limit, + in, out and + via options. For a complete rule syntax + description, refer to &man.ipfw.8;. - These two rules allow all traffic to pass through a - trusted LAN interface named - xl0: + + Be careful when working with firewall rules, as it is + easy to lock out even the administrator. + - # no restrictions on inside LAN interface for private network -pass out quick on xl0 all -pass in quick on xl0 all + + Rule Syntax - 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. + + IPFW - 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 - appropriate port numbers and, where applicable, destination - addresses. + rule syntax + - # interface facing Internet (outbound) -# Matches session start requests originating from or behind the -# firewall, destined for the Internet. + This section describes the keywords which comprise an + IPFW rule. Keywords must be written in + the following order. # is used to mark + the start of a comment and may appear at the end of a rule + line or on its own line. Blank lines are ignored. -# Allow outbound access to public DNS servers. -# Replace x.x.x. with address listed in /etc/resolv.conf. -# Repeat for each DNS server. -pass out quick on dc0 proto tcp from any to x.x.x. port = 53 flags S keep state -pass out quick on dc0 proto udp from any to xxx port = 53 keep state + CMD RULE_NUMBER ACTION LOGGING SELECTION + STATEFUL -# Allow access to ISP's specified DHCP server for cable or DSL networks. -# Use the first rule, then check log for the IP address of DHCP server. -# Then, uncomment the second rule, replace z.z.z.z with the IP address, -# and comment out the first rule -pass out log quick on dc0 proto udp from any to any port = 67 keep state -#pass out quick on dc0 proto udp from any to z.z.z.z port = 67 keep state + + CMD -# Allow HTTP and HTTPS -pass out quick on dc0 proto tcp from any to any port = 80 flags S keep state -pass out quick on dc0 proto tcp from any to any port = 443 flags S keep state + Each new rule has to be prefixed with + add to add the rule to the internal + table. + -# Allow email -pass out quick on dc0 proto tcp from any to any port = 110 flags S keep state -pass out quick on dc0 proto tcp from any to any port = 25 flags S keep state + + RULE_NUMBER -# Allow NTP -pass out quick on dc0 proto tcp from any to any port = 37 flags S keep state + Each rule is associated with a rule_number in the + range of 1 to + 65535. + -# Allow FTP -pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state + + ACTION -# Allow SSH -pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state + A rule can be associated with one of the following + actions. The specified action will be executed when the + packet matches the selection criterion of the rule. -# Allow ping -pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state + allow | accept | pass | + permit -# Block and log everything else -block out log first quick on dc0 all + These keywords are equivalent as they allow packets + that match the rule to exit the firewall rule processing. + The search terminates at this rule. - 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. + check-state - # interface facing Internet (inbound) -# Block all inbound traffic from non-routable or reserved address spaces -block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP -block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP -block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP -block in quick on dc0 from 127.0.0.0/8 to any #loopback -block in quick on dc0 from 0.0.0.0/8 to any #loopback -block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config -block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs -block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect -block in quick on dc0 from 224.0.0.0/3 to any #Class D & E multicast + Checks the packet against the dynamic rules table. + If a match is found, execute the action associated with + the rule which generated this dynamic rule, otherwise + move to the next rule. A check-state + rule does not have selection criterion. If no + check-state rule is present in the + ruleset, the dynamic rules table is checked at the first + keep-state or limit + rule. -# Block fragments and too short tcp packets -block in quick on dc0 all with frags -block in quick on dc0 proto tcp all with short + deny | drop -# block source routed packets -block in quick on dc0 all with opt lsrr -block in quick on dc0 all with opt ssrr + Both words mean the same thing, which is to discard + packets that match this rule. The search + terminates. + -# Block OS fingerprint attempts and log first occurrence -block in log first quick on dc0 proto tcp from any to any flags FUP + + Logging -# Block anything with special options -block in quick on dc0 all with ipopts + When a packet matches a rule with the + log keyword, a message will be logged + to &man.syslogd.8; with a facility name of + SECURITY. Logging only occurs if the + number of packets logged for that particular rule does not + exceed the logamount parameter. If no + logamount is specified, the limit is + taken from the sysctl value of + net.inet.ip.fw.verbose_limit. In both + cases, a value of zero removes the logging limit. Once + the limit is reached, logging can be re-enabled by + clearing the logging counter or the packet counter for + that rule, using ipfw reset log. -# Block public pings and ident -block in quick on dc0 proto icmp all icmp-type 8 -block in quick on dc0 proto tcp from any to any port = 113 + + Logging is done after all other packet matching + conditions have been met, and before performing the + final action on the packet. The administrator decides + which rules to enable logging on. + + -# Block incoming Netbios services -block in log first quick on dc0 proto tcp/udp from any to any port = 137 -block in log first quick on dc0 proto tcp/udp from any to any port = 138 -block in log first quick on dc0 proto tcp/udp from any to any port = 139 -block in log first quick on dc0 proto tcp/udp from any to any port = 81 + + Selection - 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. + The keywords described in this section are used to + describe attributes of the packet to be checked when + determining whether rules match the packet or not. + The following general-purpose attributes are provided for + matching, and must be used in this order: - 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. + udp | tcp | icmp - # 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 + Any other protocol names found in + /etc/protocols can be used. The + value specified is the protocol to be matched against. + This is a mandatory keyword. -# Allow public connections to specified internal web server -pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state + from src to dst -# Block and log only first occurrence of all remaining traffic. -block in log first quick on dc0 all - + The from and to + keywords are used to match against IP addresses. Rules + must specify both source and + destination parameters. any is a + special keyword that matches any IP address. + me is a special keyword that matches + any IP address configured on an interface in the &os; + system to represent the PC the firewall is running on. + Example usage includes from me to any, + from any to me, + from 0.0.0.0/0 to any, + from any to 0.0.0.0/0, + from 0.0.0.0 to any, + from any to 0.0.0.0, + and from me to 0.0.0.0. IP addresses + are specified in dotted IP address format followed by the + mask in CIDR notation, or as a single host in dotted IP + address format. This keyword is a mandatory requirement. + The net-mgmt/ipcalc port may be used to + assist the mask calculation. - - Configuring <acronym>NAT</acronym> + port number - NAT + For protocols which support port numbers, such as + TCP and UDP, it + is mandatory to include the port number of the service + that will be matched. Service names from + /etc/services may be used instead + of numeric port values. - - IP masquerading + in | out - NAT - *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***