From owner-svn-doc-head@FreeBSD.ORG Sat Jan 19 21:09:12 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3A529559; Sat, 19 Jan 2013 21:09:12 +0000 (UTC) (envelope-from bcr@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id 2B96D67; Sat, 19 Jan 2013 21:09:12 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.5/8.14.5) with ESMTP id r0JL9CCa088802; Sat, 19 Jan 2013 21:09:12 GMT (envelope-from bcr@svn.freebsd.org) Received: (from bcr@localhost) by svn.freebsd.org (8.14.5/8.14.5/Submit) id r0JL9Ce8088801; Sat, 19 Jan 2013 21:09:12 GMT (envelope-from bcr@svn.freebsd.org) Message-Id: <201301192109.r0JL9Ce8088801@svn.freebsd.org> From: Benedict Reuschling Date: Sat, 19 Jan 2013 21:09:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40685 - 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-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2013 21:09:12 -0000 Author: bcr Date: Sat Jan 19 21:09:11 2013 New Revision: 40685 URL: http://svnweb.freebsd.org/changeset/doc/40685 Log: Whitespace fixes for the entire firewalls chapter. Translators can ignore this. Submitted by: Dru Lavigne 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 Jan 19 17:40:46 2013 (r40684) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Sat Jan 19 21:09:11 2013 (r40685) @@ -36,15 +36,15 @@ Introduction - Firewalls make it possible to filter - incoming and outgoing traffic that flows through your system. - A firewall can use one or more sets of rules to - inspect the network packets as they come in or go out of your - network connections and either allows the traffic through or - blocks it. The rules of a firewall can inspect one or more - characteristics of the packets, including but not limited to the - protocol type, the source or destination host address, and the - source or destination port. + Firewalls make it possible to filter incoming and outgoing + traffic that flows through your system. A firewall can use one + or more sets of rules to inspect the network + packets as they come in or go out of your network connections + and either allows the traffic through or blocks it. The rules + of a firewall can inspect one or more characteristics of the + packets, including but not limited to the protocol type, the + source or destination host address, and the source or + destination port. Firewalls can greatly enhance the security of a host or a network. They can be used to do one or more of @@ -125,18 +125,20 @@ reverse. It only allows traffic matching the rules through and blocks everything else. - An inclusive firewall offers much better control of the outgoing - traffic, making it a better choice for systems that offer services to - the public Internet. It also controls the type of traffic originating - from the public Internet that can gain access to your private network. - All traffic that does not match the rules, is blocked and logged by - design. Inclusive firewalls are generally safer than exclusive - firewalls because they significantly reduce the risk of allowing - unwanted traffic to pass through them. + An inclusive firewall offers much better control of the + outgoing traffic, making it a better choice for systems that + offer services to the public Internet. It also controls the + type of traffic originating from the public Internet that can + gain access to your private network. All traffic that does + not match the rules, is blocked and logged by design. Inclusive + firewalls are generally safer than exclusive firewalls because + they significantly reduce the risk of allowing unwanted traffic + to pass through them. Unless noted otherwise, all configuration and example - rulesets in this chapter, create inclusive type firewalls. + rulesets in this chapter, create inclusive type + firewalls. Security can be tightened further using a stateful @@ -157,21 +159,22 @@ &os; has three different firewall packages built into the base system. They are: IPFILTER (also known as IPF), - IPFIREWALL (also known as IPFW), - and OpenBSD's PacketFilter (also known as - PF). &os; also has two built in packages for - traffic shaping (basically controlling bandwidth usage): - &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been - closely tied with IPFW, and + IPFIREWALL (also known as + IPFW), and OpenBSD's + PacketFilter (also known as PF). + &os; also has two built in packages for traffic shaping + (basically controlling bandwidth usage): &man.altq.4; and + &man.dummynet.4;. Dummynet has traditionally been closely + tied with IPFW, and ALTQ with - PF. Traffic shaping for IPFILTER can currently - be done with IPFILTER for NAT and filtering and + PF. Traffic shaping for IPFILTER can + currently be done with IPFILTER for NAT and filtering and IPFW with &man.dummynet.4; or by using PF with ALTQ. - IPFW, and PF all use rules to control the access of packets to and - from your system, although they go about it different ways and - have a different rule syntax. + IPFW, and PF all use rules to control the access of packets + to and from your system, although they go about it different + ways and have a different rule syntax. The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -193,16 +196,16 @@ - - - - John - Ferrell - Revised and updated by - - - - + + + + John + Ferrell + Revised and updated by + + + + The OpenBSD Packet Filter (PF) and <acronym>ALTQ</acronym> @@ -239,36 +242,35 @@ Using the PF Loadable Kernel Modules - To load the PF Kernel Module add the following line to - /etc/rc.conf: + To load the PF Kernel Module add the following line to + /etc/rc.conf: pf_enable="YES" - Then run the startup script to load the module: + Then run the startup script to load the module: &prompt.root; /etc/rc.d/pf start Note that the PF Module will not load if it cannot find the ruleset config file. The default location is /etc/pf.conf. If the PF ruleset is - located somewhere else, PF can be instructed to look there by - adding a line like the following to + located somewhere else, PF can be instructed to look there + by adding a line like the following to /etc/rc.conf: pf_rules="/path/to/pf.conf" The sample pf.conf can be found in /usr/share/examples/pf/. - + class="directory">/usr/share/examples/pf/. - The PF module can also be loaded manually - from the command line: + The PF module can also be loaded + manually from the command line: &prompt.root; kldload pf.ko Logging support for PF is provided by the - pflog.ko and can be loaded by adding the + pflog.ko and can be loaded by adding the following line to /etc/rc.conf: pflog_enable="YES" @@ -278,7 +280,8 @@ &prompt.root; /etc/rc.d/pflog start If you need other PF features you will - need to compile PF support into the kernel. + need to compile PF support into the + kernel. @@ -303,33 +306,36 @@ While it is not necessary that you compile - PF support into the &os; kernel, you may want - to do so to take advantage of one of PF's advanced features that - is not included in the loadable module, namely &man.pfsync.4;, which - is a pseudo-device that exposes certain changes to - the state table used by PF. It can be - paired with &man.carp.4; to create failover firewalls using - PF. More information on + PF support into the &os; kernel, you may + want to do so to take advantage of one of PF's advanced + features that is not included in the loadable module, namely + &man.pfsync.4;, which is a pseudo-device that exposes certain + changes to the state table used by PF. + It can be paired with &man.carp.4; to create failover + firewalls using PF. More information on CARP can be found in of the Handbook. The PF kernel options can be found in - /usr/src/sys/conf/NOTES and are reproduced - below: + /usr/src/sys/conf/NOTES and are + reproduced below: device pf device pflog device pfsync - The device pf option enables support for the - Packet Filter firewall (&man.pf.4;). - - The device pflog option enables the optional - &man.pflog.4; pseudo network device which can be used to log - traffic to a &man.bpf.4; descriptor. The &man.pflogd.8; daemon - can be used to store the logging information to disk. + The device pf option enables support + for the Packet Filter firewall + (&man.pf.4;). + + The device pflog option enables the + optional &man.pflog.4; pseudo network device which can be + used to log traffic to a &man.bpf.4; descriptor. The + &man.pflogd.8; daemon can be used to store the logging + information to disk. - The device pfsync option enables the optional + The device pfsync option enables the + optional &man.pfsync.4; pseudo-network device that is used to monitor state changes. @@ -359,12 +365,13 @@ pflog_flags="" # additi PF reads its configuration rules from &man.pf.conf.5; (/etc/pf.conf by - default) and it modifies, drops, or passes packets according to - the rules or definitions specified there. The &os; + default) and it modifies, drops, or passes packets according + to the rules or definitions specified there. The &os; installation includes several sample files located in - /usr/share/examples/pf/. Please refer to - the PF FAQ - for complete coverage of PF rulesets. + /usr/share/examples/pf/. Please refer + to the PF + FAQ for complete coverage of PF + rulesets. When browsing the X and prior is using the same version of PF as - OpenBSD 4.1. &os; 9.X and - later is using the same version of PF as - OpenBSD 4.5. + OpenBSD 4.1. &os; 9.X + and later is using the same version of PF + as OpenBSD 4.5. The &a.pf; is a good place to ask questions about @@ -402,31 +409,37 @@ pflog_flags="" # additi - pfctl + pfctl + Enable PF - pfctl + pfctl + Disable PF - pfctl all /etc/pf.conf - Flush all rules (nat, filter, state, table, etc.) and - reload from the file /etc/pf.conf + pfctl all + /etc/pf.conf + Flush all rules (nat, filter, state, table, etc.) + and reload from the file + /etc/pf.conf - pfctl [ rules | nat | state ] + pfctl [ rules | nat + state ] Report on the filter rules, nat rules, or state table - pfctl /etc/pf.conf - Check /etc/pf.conf for errors, - but do not load ruleset + pfctl + /etc/pf.conf + Check /etc/pf.conf for + errors, but do not load ruleset @@ -437,13 +450,14 @@ pflog_flags="" # additi Enabling <acronym>ALTQ</acronym> ALTQ is only available by compiling - support for it into the &os; kernel. ALTQ is - not supported by all of the available network card drivers. + support for it into the &os; kernel. ALTQ + is not supported by all of the available network card drivers. Please see the &man.altq.4; manual page for a list of drivers that are supported in your release of &os;. The following kernel options will enable - ALTQ and add additional functionality: + ALTQ and add additional + functionality: options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) @@ -456,33 +470,36 @@ options ALTQ_NOPCC # Requir options ALTQ enables the ALTQ framework. - options ALTQ_CBQ enables Class Based - Queuing (CBQ). CBQ + options ALTQ_CBQ enables + Class Based Queuing + (CBQ). CBQ allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules. - options ALTQ_RED enables Random Early - Detection (RED). RED is - used to avoid network congestion. RED does - this by measuring the length of the queue and comparing it to - the minimum and maximum thresholds for the queue. If the - queue is over the maximum all new packets will be dropped. + options ALTQ_RED enables + Random Early Detection + (RED). RED is + used to avoid network congestion. RED + does this by measuring the length of the queue and comparing + it to the minimum and maximum thresholds for the queue. If + the queue is over the maximum all new packets will be dropped. True to its name, RED drops packets from different connections randomly. - options ALTQ_RIO enables Random Early - Detection In and Out. + options ALTQ_RIO enables + Random Early Detection In and Out. options ALTQ_HFSC enables the - Hierarchical Fair Service Curve Packet Scheduler. For more - information about HFSC see: . - - options ALTQ_PRIQ enables Priority - Queuing (PRIQ). PRIQ - will always pass traffic that is in a higher queue - first. + Hierarchical Fair Service Curve Packet + Scheduler. For more information about + HFSC see: . + + options ALTQ_PRIQ enables + Priority Queuing + (PRIQ). PRIQ will + always pass traffic that is in a higher queue first. options ALTQ_NOPCC enables SMP support for ALTQ. @@ -509,24 +526,24 @@ options ALTQ_NOPCC # Requir IPFILTER is based on a kernel-side firewall and NAT mechanism that can be controlled and - monitored by userland interface programs. The firewall rules can - be set or deleted with the &man.ipf.8; utility. The + monitored by userland interface programs. The firewall rules + can be set or deleted with the &man.ipf.8; utility. The NAT rules can be set or deleted with the &man.ipnat.8; utility. The &man.ipfstat.8; utility can print run-time statistics for the kernel parts of IPFILTER. The - &man.ipmon.8; program can log IPFILTER actions to the system log - files. + &man.ipmon.8; program can log IPFILTER actions to the system + log files. - IPF was originally written using a rule processing logic of - the last matching rule wins and used only + IPF was originally written using a rule processing logic + of the last matching rule wins and used only stateless type of rules. Over time IPF has been enhanced to - include a quick option and a stateful keep - state option which drastically modernized the rules - processing logic. IPF's official documentation covers only the legacy - rule coding parameters and rule file processing + include a quick option and a stateful + keep state option which drastically modernized + the rules processing logic. IPF's official documentation covers + only the legacy rule coding parameters and rule file processing logic. The modernized functions are only included as additional - options, completely understating their benefits in producing a - far superior and more secure firewall. + options, completely understating their benefits in producing + a far superior and more secure firewall. The instructions contained in this section are based on using rules that contain the quick option and the @@ -535,16 +552,16 @@ options ALTQ_NOPCC # Requir For detailed explanation of the legacy rules processing method see: + url="http://www.munk.me.uk/ipf/ipf-howto.html"> and . + url="http://coombs.anu.edu.au/~avalon/ip-filter.html">. The IPF FAQ is at . + url="http://www.phildev.net/ipf/index.html">. - A searchable archive of the open-source IPFilter mailing list is - available at . + A searchable archive of the open-source IPFilter mailing + list is available at . Enabling IPF @@ -555,15 +572,17 @@ options ALTQ_NOPCC # Requir enabling - IPF is included in the basic &os; install as a separate run - time loadable module. The system will dynamically load the IPF - kernel loadable module when the rc.conf statement - ipfilter_enable="YES" is used. The loadable - module was created with logging enabled and the - default pass all options. There is no need - to compile IPF into the &os; kernel just to change the default - to block all. This can be done just by adding - a block all rule at the end of your ruleset. + IPF is included in the basic &os; install as a separate + run time loadable module. The system will dynamically load + the IPF kernel loadable module when the + rc.conf statement + ipfilter_enable="YES" is used. The + loadable module was created with logging enabled and the + default pass all options. There is no + need to compile IPF into the &os; kernel just to change the + default to block all. This can be done + just by adding a block all rule at the + end of your ruleset. @@ -607,28 +626,28 @@ options ALTQ_NOPCC # Requir options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK - options IPFILTER enables support for the - IPFILTER firewall. + options IPFILTER enables support for + the IPFILTER firewall. options IPFILTER_LOG enables the option to have IPF log traffic by writing to the - ipl packet logging pseudo—device - for every rule that has the log - keyword. + ipl packet logging + pseudo—device for every rule that has the + log keyword. options IPFILTER_DEFAULT_BLOCK changes the default behavior so any packet not matching a firewall pass rule gets blocked. - These settings will take effect only after installing a kernel - that has been built with the above options set. + These settings will take effect only after installing a + kernel that has been built with the above options set. Available <filename>rc.conf</filename> Options - To activate IPF at boot time, the following statements need to - be added to /etc/rc.conf: + To activate IPF at boot time, the following statements + need to be added to /etc/rc.conf: ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -639,8 +658,8 @@ ipmon_flags="-Ds" # D = # n = map IP & port to names If there is a LAN behind this firewall that uses the - reserved private IP address ranges, the following lines will have to - be added to enable NAT + reserved private IP address ranges, the following lines will + have to be added to enable NAT functionality: gateway_enable="YES" # Enable as LAN gateway @@ -663,8 +682,8 @@ ipnat_rules="/etc/ipnat.rules" # rule means flush all internal rules tables. - means this is the file to read for the - rules to load. + means this is the file to read for + the rules to load. This gives you the ability to make changes to your custom rules file, run the above IPF command, and thus update the @@ -677,8 +696,8 @@ ipnat_rules="/etc/ipnat.rules" # rule flags available with this command. The &man.ipf.8; command expects the rules file to be a - standard text file. It will not accept a rules file written as - a script with symbolic substitution. + standard text file. It will not accept a rules file written + as a script with symbolic substitution. There is a way to build IPF rules that utilizes the power of script symbolic substitution. For more information, see @@ -696,12 +715,12 @@ ipnat_rules="/etc/ipnat.rules" # rule statistics - The default behavior of &man.ipfstat.8; is to retrieve and - display the totals of the accumulated statistics gathered as a - result of applying the user coded rules against packets going - in and out of the firewall since it was last started, or since - the last time the accumulators were reset to zero by the - ipf -Z command. + The default behavior of &man.ipfstat.8; is to retrieve + and display the totals of the accumulated statistics gathered + as a result of applying the user coded rules against packets + going in and out of the firewall since it was last started, + or since the last time the accumulators were reset to zero + by the ipf -Z command. See the &man.ipfstat.8; manual page for details. @@ -727,8 +746,8 @@ ipnat_rules="/etc/ipnat.rules" # rule Packet log flags set: (0) When supplied with either for inbound - or for outbound, the command will retrieve and - display the appropriate list of filter rules currently + or for outbound, the command will retrieve + and display the appropriate list of filter rules currently installed and in use by the kernel. ipfstat -in displays the inbound @@ -759,14 +778,14 @@ ipnat_rules="/etc/ipnat.rules" # rule One of the most important functions of the ipfstat command is the - flag which displays the state table in a way similar to the way - &man.top.1; shows the &os; running process table. When your - firewall is under attack, this function gives you the ability to - identify, drill down to, and see the attacking packets. The - optional sub-flags give the ability to select the destination - or source IP, port, or protocol that you want to monitor in - real time. See the &man.ipfstat.8; manual page for - details. + flag which displays the state table in a way similar to the + way &man.top.1; shows the &os; running process table. When + your firewall is under attack, this function gives you the + ability to identify, drill down to, and see the attacking + packets. The optional sub-flags give the ability to select + the destination or source IP, port, or protocol that you want + to monitor in real time. See the &man.ipfstat.8; manual page + for details. @@ -780,21 +799,23 @@ ipnat_rules="/etc/ipnat.rules" # rule logging - In order for ipmon to work properly, the - kernel option IPFILTER_LOG must be turned on. This command has - two different modes that it can be used in. Native mode is the - default mode when the command is typed on the command line - without the flag. + In order for ipmon to work properly, + the kernel option IPFILTER_LOG must be + turned on. This command has two different modes that it can + be used in. Native mode is the default mode when the command + is typed on the command line without the + flag. Daemon mode is for when a continuous - system log file is desired, so that logging of past events may be - reviewed. This is how &os; and IPFILTER are configured to - work together. &os; has a built in facility to automatically - rotate system logs. That is why outputting the log information - to &man.syslogd.8; is better than the default of outputting to a - regular file. In the default rc.conf file, - the ipmon_flags statement uses the - flags: + system log file is desired, so that logging of past events + may be reviewed. This is how &os; and IPFILTER are configured + to work together. &os; has a built in facility to + automatically rotate system logs. That is why outputting the + log information to &man.syslogd.8; is better than the default + of outputting to a regular file. In the default + rc.conf file, the + ipmon_flags statement uses the + flags: ipmon_flags="-Ds" # D = start as daemon # s = log to syslog @@ -804,8 +825,8 @@ ipnat_rules="/etc/ipnat.rules" # rule The benefits of logging are obvious. It provides the ability to review, after the fact, information such as which packets had been dropped, what addresses they came from and - where they were going. These can all provide a significant edge - in tracking down attackers. + where they were going. These can all provide a significant + edge in tracking down attackers. Even with the logging facility enabled, IPF will not generate any rule logging on its own. The firewall @@ -815,8 +836,8 @@ ipnat_rules="/etc/ipnat.rules" # rule It is very customary to include a default deny everything rule with the log keyword included as your last rule in the - ruleset. This makes it possible to see all the packets that did not - match any of the rules in the ruleset. + ruleset. This makes it possible to see all the packets that + did not match any of the rules in the ruleset. @@ -824,12 +845,11 @@ ipnat_rules="/etc/ipnat.rules" # rule Syslogd uses its own special method for segregation of log data. It uses special groupings - called facility and level. IPMON - in mode uses local0 - as the facility - name by default. - The following levels can be - used to further segregate the logged data if desired: + called facility and level. + IPMON in mode uses + local0 as the facility + name by default. The following levels can be used to further + segregate the logged data if desired: LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed @@ -839,16 +859,18 @@ LOG_ERR - packets which have been logged To setup IPFILTER to log all data to - /var/log/ipfilter.log, the file will need to be - created beforehand. The following command will do that: + /var/log/ipfilter.log, the file will + need to be created beforehand. The following command will + do that: &prompt.root; touch /var/log/ipfilter.log - The &man.syslogd.8; function is controlled by definition statements - in the /etc/syslog.conf file. The - syslog.conf file offers considerable - flexibility in how syslog will deal with system messages issued - by software applications like IPF. + The &man.syslogd.8; function is controlled by definition + statements in the /etc/syslog.conf file. + The syslog.conf file offers considerable + flexibility in how syslog will + deal with system messages issued by software applications + like IPF. Add the following statement to /etc/syslog.conf: @@ -860,21 +882,21 @@ LOG_ERR - packets which have been logged file location. To activate the changes to /etc/syslog.conf - you can reboot or bump the &man.syslogd.8; daemon into - re-reading /etc/syslog.conf by running - /etc/rc.d/syslogd reload + you can reboot or bump the &man.syslogd.8; + daemon into re-reading /etc/syslog.conf + by running /etc/rc.d/syslogd reload Do not forget to change - /etc/newsyslog.conf to rotate the new log - created above. + /etc/newsyslog.conf to rotate the new + log created above. The Format of Logged Messages - Messages generated by ipmon consist of - data fields separated by white space. Fields common to all - messages are: + Messages generated by ipmon consist + of data fields separated by white space. Fields common to + all messages are: @@ -883,13 +905,13 @@ LOG_ERR - packets which have been logged The time of packet receipt. This is in the form - HH:MM:SS.F, for hours, minutes, seconds, and fractions of a - second (which can be several digits long). + HH:MM:SS.F, for hours, minutes, seconds, and fractions + of a second (which can be several digits long). - The name of the interface the packet was processed on, - e.g., dc0. + The name of the interface the packet was processed + on, e.g., dc0. @@ -898,33 +920,36 @@ LOG_ERR - packets which have been logged - These can be viewed with ipfstat - -in. + These can be viewed with + ipfstat -in. The action: p for passed, b for blocked, S for a short - packet, n did not match any rules, L for a log rule. The - order of precedence in showing flags is: S, p, b, n, L. A - capital P or B means that the packet has been logged due to - a global logging setting, not a particular rule. + packet, n did not match any rules, L for a log rule. + The order of precedence in showing flags is: S, p, b, n, + L. A capital P or B means that the packet has been logged + due to a global logging setting, not a particular + rule. The addresses. This is actually three fields: the source address and port (separated by a comma), the -> symbol, and the destination address and port, e.g.: - 209.53.17.22,80 -> 198.73.220.17,1722. + 209.53.17.22,80 -> + 198.73.220.17,1722. - PR followed by the protocol name or - number, e.g.: PR tcp. + PR followed by the protocol name + or number, e.g.: PR tcp. len followed by the header length - and total length of the packet, e.g.: len 20 40. + and total length of the packet, e.g.: + len 20 40. @@ -935,9 +960,10 @@ LOG_ERR - packets which have been logged flags. If the packet is an ICMP packet, there will be two fields - at the end, the first always being ICMP, and the - next being the ICMP message and sub-message type, separated by - a slash, e.g., ICMP 3/3 for a port unreachable message. + at the end, the first always being ICMP, and + the next being the ICMP message and sub-message type, + separated by a slash, e.g., ICMP 3/3 for a port unreachable + message. @@ -945,17 +971,18 @@ LOG_ERR - packets which have been logged Substitution Some experienced IPF users create a file containing the - rules and code them in a manner compatible with running them as - a script with symbolic substitution. The major benefit of - doing this is that only the value associated - with the symbolic name needs to be changed, and when the script is run all the rules - containing the symbolic name will have the value substituted in - the rules. Being a script, symbolic substitution can be used - to code frequently used values and substitute them in multiple - rules. This can be seen in the following example. + rules and code them in a manner compatible with running them + as a script with symbolic substitution. The major benefit + of doing this is that only the value associated with the + symbolic name needs to be changed, and when the script is + run all the rules containing the symbolic name will have the + value substituted in the rules. Being a script, symbolic + substitution can be used to code frequently used values and + substitute them in multiple rules. This can be seen in the + following example. - The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, - and &man.tcsh.1; shells. + The script syntax used here is compatible with the + &man.sh.1;, &man.csh.1;, and &man.tcsh.1; shells. Symbolic substitution fields are prefixed with a dollar sign: $. @@ -998,11 +1025,11 @@ pass out quick on $oif proto tcp EOF ################## End of IPF rules script ######################## - That is all there is to it. The rules are not important in - this example; how the symbolic substitution fields are + That is all there is to it. The rules are not important + in this example; how the symbolic substitution fields are populated and used are. If the above example was in a file - named /etc/ipf.rules.script, these rules could be - reloaded by entering the following command: + named /etc/ipf.rules.script, these rules + could be reloaded by entering the following command: &prompt.root; sh /etc/ipf.rules.script @@ -1029,9 +1056,10 @@ EOF value) into /etc/rc.conf file. Add a script like the following to your - /usr/local/etc/rc.d/ startup - directory. The script should have an obvious name like - ipf.loadrules.sh. The + /usr/local/etc/rc.d/ + startup directory. The script should have an obvious + name like ipf.loadrules.sh. The .sh extension is mandatory. #!/bin/sh @@ -1053,30 +1081,31 @@ sh /etc/ipf.rules.scriptA ruleset is a group of IPF rules coded to 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. + 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 (i.e.: telnet, www, - mail, etc.) is predefined by its protocol and privileged (listening) - port. Packets destined for a specific service, originate from the - source address using an unprivileged (high order) port and target the - specific service port on the destination address. All the above - parameters (i.e.: ports and addresses) can be used as selection - criteria to create rules which will pass or block services. + mail, etc.) is predefined by its protocol and privileged + (listening) port. Packets destined for a specific service, + originate from the source address using an unprivileged (high + order) port and target the specific service port on the + destination address. All the above parameters (i.e.: ports + and addresses) can be used as selection criteria to create + rules which will pass or block services. IPFILTER rule processing order - + - IPF was originally written using a rules processing logic - of the last matching rule wins and used only - stateless rules. Over time IPF has been enhanced to include a - quick option and a stateful keep - state option which drastically modernized the rule - processing logic. + IPF was originally written using a rules processing + logic of the last matching rule wins and used + only stateless rules. Over time IPF has been enhanced to + include a quick option and a stateful + keep state option which drastically modernized + the rule processing logic. The instructions contained in this section are based on using rules that contain the quick option and @@ -1086,8 +1115,8 @@ sh /etc/ipf.rules.script When working with the firewall rules, be very - careful. Some configurations will - lock you out of the server. To be on the safe + careful. Some configurations will + lock you out of the server. To be on the safe side, you may wish to consider performing the initial firewall configuration from the local console rather than doing it remotely e.g., via @@ -1104,27 +1133,28 @@ sh /etc/ipf.rules.scriptrule syntax - The rule syntax presented here has been simplified to only - address the modern stateful rule context and first - matching rule wins logic. For the complete legacy rule - syntax description see the &man.ipf.8; manual page. - - A # character 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. - - Rules contain keywords. These keywords have to be coded in - a specific order from left to right on the line. Keywords are - identified in bold type. Some keywords have sub-options which - may be keywords themselves and also include more sub-options. - Each of the headings in the below syntax has a bold section - header which expands on the content. + The rule syntax presented here has been simplified to + only address the modern stateful rule context and first + matching rule wins logic. For the complete legacy + rule syntax description see the &man.ipf.8; manual + page. + + A # character 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. + + Rules contain keywords. These keywords have to be coded + in a specific order from left to right on the line. Keywords + are identified in bold type. Some keywords have sub-options + which may be keywords themselves and also include more + sub-options. Each of the headings in the below syntax has + a bold section header which expands on the content. - ACTION IN-OUT OPTIONS SELECTION STATEFUL PROTO - SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG + ACTION IN-OUT OPTIONS SELECTION STATEFUL + PROTO SRC_ADDR,DST_ADDR OBJECT PORT_NUM TCP_FLAG STATEFUL ACTION = block | pass @@ -1132,19 +1162,20 @@ sh /etc/ipf.rules.scriptIN-OUT = in | out OPTIONS = log | quick | on - interface-name + interface-name SELECTION = proto value | - source/destination IP | port = number | flags - flag-value + source/destination IP | port = number | flags + flag-value PROTO = tcp/udp | udp | tcp | - icmp + icmp SRC_ADD,DST_ADDR = all | from - object to object + object to object - OBJECT = IP address | any + OBJECT = IP address | + any PORT_NUM = port number @@ -1160,8 +1191,8 @@ sh /etc/ipf.rules.scriptmust have an action. The following actions are recognized: - block indicates that the packet should *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***