From owner-svn-doc-head@FreeBSD.ORG Mon Feb 11 15:01:38 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 498B6659; Mon, 11 Feb 2013 15:01:38 +0000 (UTC) (envelope-from dru@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 2526E7A9; Mon, 11 Feb 2013 15:01:38 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.5/8.14.5) with ESMTP id r1BF1cFZ036956; Mon, 11 Feb 2013 15:01:38 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.5/8.14.5/Submit) id r1BF1cpO036953; Mon, 11 Feb 2013 15:01:38 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201302111501.r1BF1cpO036953@svn.freebsd.org> From: Dru Lavigne Date: Mon, 11 Feb 2013 15:01:38 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r40948 - 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: Mon, 11 Feb 2013 15:01:38 -0000 Author: dru Date: Mon Feb 11 15:01:37 2013 New Revision: 40948 URL: http://svnweb.freebsd.org/changeset/doc/40948 Log: This patch addresses the following: - rewording to remove you, etc., i.e., and references to PPP - fixes xref - general tightening, removal of redundant paragraphs, and many fixes to grammos/typos - a reference to a non-existing logging section was removed - several comments were addressed and removed Approved by gjb (mentor) 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 Mon Feb 11 14:58:34 2013 (r40947) +++ head/en_US.ISO8859-1/books/handbook/firewalls/chapter.xml Mon Feb 11 15:01:37 2013 (r40948) @@ -36,39 +36,37 @@ 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 can greatly enhance the security of a host or a - network. They can be used to do one or more of - the following things: + Firewalls make it possible to filter the incoming and + outgoing traffic that flows through a system. A firewall can + use one or more sets of rules to inspect network + packets as they come in or go out of 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 such as the protocol type, source or destination host + address, and source or destination port. + + Firewalls can enhance the security of a host or a network. + They can be used to do one or more of the following: - To protect and insulate the applications, services and - machines of your internal network from unwanted traffic - coming in from the public Internet. + Protect and insulate the applications, services, and + machines of an internal network from unwanted traffic from + the public Internet. - To limit or disable access from hosts of the internal + Limit or disable access from hosts of the internal network to services of the public Internet. - To support network address translation - (NAT), which allows your internal network + Support network address translation + (NAT), which allows an internal network to use private IP addresses and share a - single connection to the public Internet (either with a - single IP address or by a shared pool of - automatically assigned public addresses). + single connection to the public Internet using either a + single IP address or a shared pool of + automatically assigned public addresses. @@ -76,27 +74,27 @@ - How to properly define packet filtering rules. + How to define packet filtering rules. - The differences between the firewalls - built into &os;. + The differences between the firewalls built into + &os;. - How to use and configure the OpenBSD + How to use and configure the PF firewall. - How to use and configure - IPFILTER. + How to use and configure the + IPFILTER firewall. - How to use and configure - IPFW. + How to use and configure the + IPFW firewall. @@ -118,81 +116,68 @@ rulesets - There are two basic ways to create firewall rulesets: - inclusive or exclusive. An + A firewall ruleset can be either + exclusive or inclusive. An exclusive firewall allows all traffic through except for the traffic matching the ruleset. An inclusive firewall does the - reverse. It only allows traffic matching the rules through and + reverse as 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 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 a private network. All traffic that does not match + the rules is blocked and logged. Inclusive firewalls are + generally safer than exclusive firewalls because they + significantly reduce the risk of allowing unwanted + traffic. Unless noted otherwise, all configuration and example - rulesets in this chapter, create inclusive type - firewalls. + rulesets in this chapter create inclusive firewall + rulesets. Security can be tightened further using a stateful - firewall. This type of firewall keeps - track of which connections are opened through the firewall and - will only allow traffic through which either matches an existing - connection or opens a new one. The disadvantage of a stateful - firewall is that it can be vulnerable to Denial of Service - (DoS) attacks if a lot of new connections are - opened very fast. With most firewalls it is possible to use a - combination of stateful and non-stateful behavior to make an - optimal firewall for the site. + firewall. This type of firewall keeps track of open + connections and only allows traffic which either matches an + existing connection or opens a new, allowed connection. The + disadvantage of a stateful firewall is that it can be vulnerable + to Denial of Service (DoS) attacks if a lot + of new connections are opened very fast. Most firewalls use a + combination of stateful and non-stateful behavior. Firewall Packages - &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 - ALTQ with - 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. - - The reason that &os; has multiple built in firewall packages - is that different people have different requirements and - preferences. No single firewall package is the best. - - The author prefers IPFILTER because its stateful rules are - much less complicated to use in a NAT - environment and it has a built in ftp proxy that simplifies the - rules to allow secure outbound FTP usage. + &os; has three firewalls built into the base system: + IPFILTER, also known as + IPF, IPFIREWALL, also + known as IPFW, and PF). + &os; also provides two traffic shapers for controlling bandwidth + usage: &man.altq.4; and &man.dummynet.4;. Dummynet has + traditionally been closely tied with IPFW, + and ALTQ with PF. Each + firewall uses rules to control the access of packets to and from + a &os; system, although they go about it in different ways and + each has a different rule syntax. + + &os; provides multiple firewalls in order to meet the + different requirements and preferences for a wide variety of + users. Each user should evaluate which firewall best meets + their needs. Since all firewalls are based on inspecting the values of selected packet control fields, the creator of the firewall - rulesets must have an understanding of how + ruleset must have an understanding of how TCP/IP works, what the different values in - the packet control fields are and how these values are used in a - normal session conversation. For a good explanation go to: - . + the packet control fields are, and how these values are used in + a normal session conversation. For a good introduction, refer + to Daryl's TCP/IP + Primer. @@ -207,8 +192,7 @@ - The OpenBSD Packet Filter (PF) and - <acronym>ALTQ</acronym> + PF and <acronym>ALTQ</acronym> firewall @@ -216,72 +200,65 @@ PF - As of July 2003 the OpenBSD firewall software application - known as PF was ported to &os; and - made available in the &os; Ports Collection. Released in 2004, - &os; 5.3 was the first release that contained - PF as an integrated part of the base system. - PF is a complete, full-featured firewall - that has optional support for ALTQ (Alternate - Queuing). ALTQ provides Quality of Service - (QoS) functionality. - - The OpenBSD Project does an outstanding job of - maintaining the PF FAQ. - As such, this section of the Handbook will focus on - PF as it pertains to &os; while providing - some general information regarding usage. For detailed usage - information please refer to the PF FAQ. + Since &os; 5.3, a ported version of OpenBSD's + PF firewall has been included as an + integrated part of the base system. PF is a + complete, full-featured firewall that has optional support for + ALTQ (Alternate Queuing), which provides + Quality of Service (QoS). + + Since the OpenBSD Project maintains the definitive + reference for PF in thePF FAQ, this + section of the Handbook focuses on PF as it + pertains to &os;, while providing some general usage + information. - More information about PF for &os; + More information about porting PF to &os; can be found at . Using the PF Loadable Kernel Modules - To load the PF Kernel Module add the following line to + In order to use PF, the PF kernel module must be first + loaded. 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; service pf start - Note that the PF Module will not load if it cannot find - the ruleset config file. The default location is + The PF module will not load if it cannot find the + ruleset configuration 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 - /etc/rc.conf: + located somewhere else, add a line to + /etc/rc.conf which specifies the full + path to the file: 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: &prompt.root; kldload pf.ko - Logging support for PF is provided by the - pflog.ko and can be loaded by adding the + Logging support for PF is provided by + pflog.ko which can be loaded by adding the following line to /etc/rc.conf: pflog_enable="YES" - Then run the startup script to load the module: + Then, run the startup script to load the module: &prompt.root; service pflog start - If you need other PF features you will - need to compile PF support into the - kernel. @@ -305,37 +282,32 @@ device pfsync - 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 - 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: + While it is not necessary to compile + PF support into the &os; kernel, some of + PF's advanced features are 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 following PF kernel options can be + found in /usr/src/sys/conf/NOTES: 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. + device pf enables PF support. + + device pflog 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 then be used to store the logging information to + disk. - The device pfsync option enables the - optional + device pfsync enables the optional &man.pfsync.4; pseudo-network device that is used to monitor state changes. @@ -343,8 +315,9 @@ device pfsync Available <filename>rc.conf</filename> Options - The following &man.rc.conf.5; statements configure - PF and &man.pflog.4; at boot: + The following &man.rc.conf.5; statements can be used to + configure PF and &man.pflog.4; at + boot: pf_enable="YES" # Enable PF (load module if required) pf_rules="/etc/pf.conf" # rules definition file for pf @@ -353,9 +326,9 @@ pflog_enable="YES" # start pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_flags="" # additional flags for pflogd startup - If you have a LAN behind this firewall and have to forward - packets for the computers on the LAN or want to do NAT, you - will need the following option as well: + If there is a LAN behind the firewall and packets need to + be forwarded for the computers on the LAN, or NAT is required, + add the following option: gateway_enable="YES" # Enable as LAN gateway @@ -363,40 +336,40 @@ pflog_flags="" # additi Creating Filtering Rules - 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; - installation includes several sample files located in - /usr/share/examples/pf/. Please refer - to the PF - FAQ for complete coverage of PF - rulesets. + By default, PF reads its configuration + rules from /etc/pf.conf and modifies, + drops, or passes packets according to the rules or definitions + specified in this file. The &os; installation includes + several sample files located in + /usr/share/examples/pf/. Refer to the + PF FAQ for + complete coverage of PF rulesets. - When browsing the PF FAQ, - please keep in mind that different versions of &os; can - contain different versions of PF. Currently, - &os; 8.X and prior is - using the same version of PF as + When reading the PF FAQ, + keep in mind that different versions of &os; contain + different versions of PF. Currently, + &os; 8.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. The &a.pf; is a good place to ask questions about - configuring and running the PF - firewall. Do not forget to check the mailing list archives - before asking questions! + configuring and running the PF firewall. + Do not forget to check the mailing list archives before asking + questions. Working with PF - Use &man.pfctl.8; to control PF. Below - are some useful commands (be sure to review the &man.pfctl.8; - man page for all available options): + To control PF, use &man.pfctl.8;. + Below are some useful options to this command. Review + &man.pfctl.8; for a description of all available + options: @@ -411,35 +384,35 @@ pflog_flags="" # additi pfctl - Enable PF + Enable PF. pfctl - Disable PF + Disable PF. pfctl all /etc/pf.conf - Flush all rules (nat, filter, state, table, etc.) - and reload from the file - /etc/pf.conf + Flush all NAT, filter, state, and table + rules and reload + /etc/pf.conf. pfctl [ rules | nat state ] - Report on the filter rules, nat rules, or state - table + 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 + errors, but do not load ruleset. @@ -449,11 +422,11 @@ 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. - Please see the &man.altq.4; manual page for a list of drivers - that are supported in your release of &os;. + ALTQ is only available by compiling its + support into the &os; kernel. ALTQ is not + supported by all network card drivers. Refer to &man.altq.4; + for a list of drivers that are supported by the release of + &os;. The following kernel options will enable ALTQ and add additional @@ -473,28 +446,27 @@ options ALTQ_NOPCC # Requir options ALTQ_CBQ enables Class Based Queuing (CBQ). CBQ - allows you to divide a connection's bandwidth into different + can be used 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. - True to its name, RED drops packets from - different connections randomly. + used to avoid network congestion 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. RED drops + packets from different connections randomly. 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: . + Scheduler HFSC. For more + information, refer to . options ALTQ_PRIQ enables Priority Queuing @@ -517,51 +489,46 @@ options ALTQ_NOPCC # Requir IPFILTER - The author of IPFILTER is Darren Reed. IPFILTER is not - operating system dependent: it is an open source application and + IPFILTER is a cross-platform, open source firewall which has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and - &solaris; operating systems. IPFILTER is actively being - supported and maintained, with updated versions being released - regularly. + &solaris; operating systems. 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 - 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. + can be set or deleted using &man.ipf.8;. The + NAT rules can be set or deleted using + &man.ipnat.8;. Run-time statistics for the kernel parts of + IPFILTER can be printed using &man.ipfstat.8;. To log IPFILTER + actions to the system log files, use &man.ipmon.8;. 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 - logic. The modernized functions are only included as additional - options, completely understating their benefits in producing - a far superior and more secure firewall. + of the last matching rule wins and only used + stateless rules. Over time, IPF has been enhanced to include a + quick option and a stateful + keep state option which modernized the rules + processing logic. IPF's official documentation covers only the + legacy rule coding parameters and rule file processing logic and + the modernized functions are only included as additional + options. The instructions contained in this section are based on - using rules that contain the quick option and the - stateful keep state option. This is the basic - framework for coding an inclusive firewall ruleset. - - For detailed explanation of the legacy rules processing - method see: + using rules that contain quick and + keep state as these provide the basic framework + for configuring an inclusive firewall ruleset. + + For a detailed explanation of the legacy rules processing + method, refer to 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 IPFilter mailing list is + available at . Enabling IPF @@ -572,17 +539,15 @@ 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 kernel + loadable module. The system will dynamically load + this module at boot time when + ipfilter_enable="YES" is added to + rc.conf. The module enables logging and + default pass all. To change the + default to block all, add a + block all rule at the end of the + ruleset. @@ -612,15 +577,10 @@ options ALTQ_NOPCC # Requir kernel options - It is not a mandatory requirement to enable IPF by - compiling the following options into the &os; kernel. It is - only presented here as background information. Compiling IPF - into the kernel causes the loadable module to never be - used. - - Sample kernel config IPF option statements are in the - /usr/src/sys/conf/NOTES kernel source - and are reproduced here: + For users who prefer to statically compile IPF support + into a custom kernel, the following IPF option statements, + listed in /usr/src/sys/conf/NOTES, are + available: options IPFILTER options IPFILTER_LOG @@ -629,15 +589,14 @@ options IPFILTER_DEFAULT_BLOCKoptions 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 + options IPFILTER_LOG enables IPF + logging using the 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. + the default behavior so that 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. @@ -657,9 +616,9 @@ ipmon_flags="-Ds" # D = # v = log tcp window, ack, seq # 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 + If there is a LAN behind the firewall that uses the + reserved private IP address ranges, the following lines have + to be added to enable NAT functionality: gateway_enable="YES" # Enable as LAN gateway @@ -672,36 +631,36 @@ ipnat_rules="/etc/ipnat.rules" # rule ipf - The &man.ipf.8; command is used to load your ruleset file. - Your custom rules would normally be placed in a file, and the - following command could then be used to replace in mass the - currently running firewall rules: + To load the ruleset file, use &man.ipf.8;. Custom rules + are normally placed in a file, and the following command can + be used to replace the currently running firewall + rules: &prompt.root; ipf -Fa -f /etc/ipf.rules - means flush all internal rules + flushes all the internal rules tables. - means this is the file to read for - the rules to load. + specifies the file containing the + rules to load. - This gives you the ability to make changes to your custom + This provides the ability to make changes to a custom rules file, run the above IPF command, and thus update the - running firewall with a fresh copy of all the rules without - having to reboot the system. This method is very convenient - for testing new rules as the procedure can be executed as many - times as needed. - - See the &man.ipf.8; manual page for details on the other - 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. + 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. + + &man.ipf.8; expects the rules file to be a 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 + There is a way to build IPF rules that utilize the power of script symbolic substitution. For more information, see - . + . @@ -717,15 +676,15 @@ ipnat_rules="/etc/ipnat.rules" # rule 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 - using ipf -Z. + by applying the 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 using ipf + -Z. - See the &man.ipfstat.8; manual page for details. + Refer to &man.ipfstat.8; for details. - The default &man.ipfstat.8; command output will look - something like this: + The default &man.ipfstat.8; output will look something + like this: input packets: blocked 99286 passed 1255609 nomatch 14686 counted 0 output packets: blocked 4200 passed 1284345 nomatch 14687 counted 0 @@ -751,10 +710,10 @@ ipnat_rules="/etc/ipnat.rules" # rule installed and in use by the kernel. ipfstat -in displays the inbound - internal rules table with rule number. + internal rules table with rule numbers. ipfstat -on displays the outbound - internal rules table with the rule number. + internal rules table with rule numbers. The output will look something like this: @@ -776,16 +735,15 @@ ipnat_rules="/etc/ipnat.rules" # rule 354727 block out on dc0 from any to any 430918 pass out quick on dc0 proto tcp/udp from any to any keep state - One of the most important functions of - ipfstat 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. + One of the most important options of + ipfstat is which + displays the state table in a way similar to how &man.top.1; + shows the &os; running process table. When a firewall is + under attack, this function provides the ability to identify + and see the attacking packets. The optional sub-flags give + the ability to select the destination or source IP, port, or + protocol to be monitored in real time. Refer to + &man.ipfstat.8; for details. @@ -801,55 +759,51 @@ ipnat_rules="/etc/ipnat.rules" # rule 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, the - ipmon_flags statement uses the - flags: + turned on. This command has two different modes. Native mode + is the default mode when the command is used without + . + + Daemon mode provides a continuous system log file so that + logging of past events may be reviewed. &os; has a built in + facility to automatically rotate system logs. This is why + outputting the log information to &man.syslogd.8; is better + than the default of outputting to a regular file. The default + rc.conf + ipmon_flags statement uses + : ipmon_flags="-Ds" # D = start as daemon # s = log to syslog # v = log tcp window, ack, seq # n = map IP & port to names - 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. + Logging provides the ability to review, after the fact, + information such as which packets were dropped, what addresses + they came from and 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 - administrator decides what rules in the ruleset he wants to - log and adds the log keyword to those rules. Normally only - deny rules are logged. - - 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. + generate any rule logging by default. The firewall + administrator decides which rules in the ruleset should be + logged and adds the log keyword to those rules. Normally, + only deny rules are logged. + + It is customary to include a default deny + everything rule with the log keyword included as the + 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. IPMON Logging - 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: + &man.syslogd.8; uses its own method for segregation of log + data. It uses groupings called facility and + level. By default, IPMON in + mode uses local0 as + the facility name. The following levels can be + used to further segregate the logged data: LOG_INFO - packets logged using the "log" keyword as the action rather than pass or block. LOG_NOTICE - packets logged which are also passed @@ -858,37 +812,31 @@ 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: + In order to setup IPFILTER to log all data to + /var/log/ipfilter.log, first + create the empty file: &prompt.root; touch /var/log/ipfilter.log - The &man.syslogd.8; function is controlled by definition - statements in /etc/syslog.conf. - This file offers considerable - flexibility in how syslog will - deal with system messages issued by software applications - like IPF. + &man.syslogd.8; is controlled by definition statements in + /etc/syslog.conf. This file offers + considerable flexibility in how + syslog will deal with system + messages issued by software applications like IPF. - Add the following statement to + To write all logged messages to the specified file, + add the following statement to /etc/syslog.conf: local0.* /var/log/ipfilter.log - The local0.* - means to write all the logged messages to the coded - 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 service syslogd reload + To activate the changes and instruct &man.syslogd.8; + to read the modified /etc/syslog.conf, + run service syslogd reload. Do not forget to change /etc/newsyslog.conf to rotate the new - log created above. + log file. @@ -906,16 +854,16 @@ 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). *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***