Date: Wed, 13 May 2009 18:55:28 GMT From: Rene Ladan <rene@FreeBSD.org> To: Perforce Change Reviews <perforce@FreeBSD.org> Subject: PERFORCE change 162030 for review Message-ID: <200905131855.n4DItSV7054285@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=162030 Change 162030 by rene@rene_self on 2009/05/13 18:55:13 IFC Affected files ... .. //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributing/article.sgml#3 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml#6 integrate .. //depot/projects/docproj_nl/en_US.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml#5 integrate .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/multimedia/chapter.sgml#8 integrate .. //depot/projects/docproj_nl/www/en/news/status/report-2009-01-2009-03.xml#2 integrate .. //depot/projects/docproj_nl/www/share/sgml/news.xml#40 integrate Differences ... ==== //depot/projects/docproj_nl/en_US.ISO8859-1/articles/contributing/article.sgml#3 (text+ko) ==== @@ -8,7 +8,7 @@ <articleinfo> <title>Contributing to FreeBSD</title> - <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/contributing/article.sgml,v 1.510 2009/04/30 18:26:32 keramida Exp $</pubdate> + <pubdate>$FreeBSD: doc/en_US.ISO8859-1/articles/contributing/article.sgml,v 1.511 2009/05/13 02:05:11 keramida Exp $</pubdate> <abstract> <para>This article describes the different ways in which an @@ -172,7 +172,8 @@ </listitem> <listitem> - <para>If you have contributed any ports, send your patches + <para>If you have contributed any ports and you had to make + &os;-specific changes, send your patches back to the original authors (this will make your life easier when they bring out the next version).</para> </listitem> @@ -341,22 +342,24 @@ <para>For example:</para> - <para> - <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen> + <screen>&prompt.user; <userinput>diff -c oldfile newfile</userinput></screen> - or + <para>or</para> - <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen> + <screen>&prompt.user; <userinput>diff -c -r olddir newdir</userinput></screen> - would generate such a set of context diffs for the given + <para>would generate such a set of context diffs for the given source file or directory hierarchy.</para> - <para>Likewise, - <screen>&prompt.user; <userinput>diff -u oldfile newfile</userinput></screen> - or - <screen>&prompt.user; <userinput>diff -u -r olddir newdir</userinput></screen> + <para>Likewise,</para> + + <screen>&prompt.user; <userinput>diff -u oldfile newfile</userinput></screen> + + <para>or</para> + + <screen>&prompt.user; <userinput>diff -u -r olddir newdir</userinput></screen> - would do the same, except in the unified diff format.</para> + <para>would do the same, except in the unified diff format.</para> <para>See the manual page for &man.diff.1; for more details.</para> ==== //depot/projects/docproj_nl/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml#6 (text+ko) ==== @@ -1,7 +1,7 @@ <!-- The FreeBSD Documentation Project - $FreeBSD: doc/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml,v 1.86 2008/12/24 01:33:40 danger Exp $ + $FreeBSD: doc/en_US.ISO8859-1/books/handbook/firewalls/chapter.sgml,v 1.87 2009/05/13 17:20:58 manolis Exp $ --> <chapter id="firewalls"> @@ -124,12 +124,22 @@ reverse. It only allows traffic matching the rules through and blocks everything else.</para> - <para>Inclusive firewalls are generally safer than exclusive + <para>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 the firewall.</para> + unwanted traffic to pass through them.</para> + + <note> + <para>Unless noted otherwise, all configuration and example + rulesets in this chapter, create inclusive type firewalls.</para> + </note> <para>Security can be tightened further using a <quote>stateful - firewall</quote>. With a stateful firewall the firewall keeps + firewall</quote>. 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 @@ -153,14 +163,14 @@ &man.altq.4; and &man.dummynet.4;. Dummynet has traditionally been closely tied with <acronym>IPFW</acronym>, and <acronym>ALTQ</acronym> with - <acronym>PF</acronym>. Traffic shaping for <acronym>IPFILTER</acronym> can currently - be done with <acronym>IPFILTER</acronym> for NAT and filtering and + <acronym>PF</acronym>. Traffic shaping for IPFILTER can currently + be done with IPFILTER for NAT and filtering and <acronym>IPFW</acronym> with &man.dummynet.4; <emphasis>or</emphasis> by using <acronym>PF</acronym> with <acronym>ALTQ</acronym>. 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 different rule syntaxes.</para> + have a different rule syntax.</para> <para>The reason that &os; has multiple built in firewall packages is that different people have different requirements and @@ -174,7 +184,7 @@ <para>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 - <acronym>TCP</acronym>/IP works, what the different values in + <acronym>TCP/IP</acronym> 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: <ulink @@ -233,7 +243,7 @@ system will dynamically load the PF kernel module when the &man.rc.conf.5; statement <literal>pf_enable="YES"</literal> is present. However, the <acronym>PF</acronym> module will - not load if the system cannot find a <acronym>PF</acronym> + not be loaded if the system cannot find a <acronym>PF</acronym> ruleset configuration file. The default location is <filename>/etc/pf.conf</filename>. If your <acronym>PF</acronym> ruleset is located somewhere else put @@ -291,7 +301,7 @@ paired with &man.carp.4; to create failover firewalls using <acronym>PF</acronym>. More information on <acronym>CARP</acronym> can be found in - <link linkend="carp">chapter 29</link> of the handbook.</para> + <xref linkend="carp"> of the Handbook.</para> <para>The <acronym>PF</acronym> kernel options can be found in <filename>/usr/src/sys/conf/NOTES</filename> and are reproduced @@ -448,14 +458,14 @@ <para><literal>options ALTQ</literal> enables the <acronym>ALTQ</acronym> framework.</para> - <para><literal>options ALTQ_CBQ</literal> enables Class Based - Queuing (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> + <para><literal>options ALTQ_CBQ</literal> enables <emphasis>Class Based + Queuing</emphasis> (<acronym>CBQ</acronym>). <acronym>CBQ</acronym> allows you to divide a connection's bandwidth into different classes or queues to prioritize traffic based on filter rules.</para> - <para><literal>options ALTQ_RED</literal> enables Random Early - Detection (<acronym>RED</acronym>). <acronym>RED</acronym> is + <para><literal>options ALTQ_RED</literal> enables <emphasis>Random Early + Detection</emphasis> (<acronym>RED</acronym>). <acronym>RED</acronym> is used to avoid network congestion. <acronym>RED</acronym> does this by measuring the length of the queue and comparing it to the minimum and maximum thresholds for the queue. If the @@ -463,16 +473,16 @@ True to its name, <acronym>RED</acronym> drops packets from different connections randomly.</para> - <para><literal>options ALTQ_RIO</literal> enables Random Early - Detection In and Out.</para> + <para><literal>options ALTQ_RIO</literal> enables <emphasis>Random Early + Detection In and Out</emphasis>.</para> <para><literal>options ALTQ_HFSC</literal> enables the - Hierarchical Fair Service Curve Packet Scheduler. For more + <emphasis>Hierarchical Fair Service Curve Packet Scheduler</emphasis>. For more information about <acronym>HFSC</acronym> see: <ulink url="http://www-2.cs.cmu.edu/~hzhang/HFSC/main.html"></ulink>.</para>; - <para><literal>options ALTQ_PRIQ</literal> enables Priority - Queuing (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> + <para><literal>options ALTQ_PRIQ</literal> enables <emphasis>Priority + Queuing</emphasis> (<acronym>PRIQ</acronym>). <acronym>PRIQ</acronym> will always pass traffic that is in a higher queue first.</para> @@ -492,11 +502,6 @@ <secondary>IPFILTER</secondary> </indexterm> - <note> - <para>This section is work in progress. The contents might - not be accurate at all times.</para> - </note> - <para>The author of IPFILTER is Darren Reed. IPFILTER is not operating system dependent: it is an open source application and has been ported to &os;, NetBSD, OpenBSD, &sunos;, HP/UX, and @@ -519,29 +524,16 @@ stateless type of rules. Over time IPF has been enhanced to include a <quote>quick</quote> option and a stateful <quote>keep state</quote> option which drastically modernized the rules - processing logic. IPF's official documentation covers the legacy - rule coding parameters and the legacy rule file processing + 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 secure firewall.</para> + far superior and more secure firewall.</para> <para>The instructions contained in this section are based on using rules that contain the <quote>quick</quote> option and the stateful <quote>keep state</quote> option. This is the basic - framework for coding an inclusive firewall rule set.</para> - - <!-- XXX: something like this already in - <xref linkend="firewalls-concepts"> - AND: the para below is repeated 3 times in this chapter--> - - <para>An inclusive firewall only allows packets matching the rules - to pass through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything else - is blocked and logged by default design. Inclusive firewalls are - much, much more secure than exclusive firewall rule sets and is - the only rule set type covered herein.</para> + framework for coding an inclusive firewall ruleset.</para> <para>For detailed explanation of the legacy rules processing method see: <ulink @@ -567,13 +559,13 @@ <para>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 + kernel loadable module when the <filename>rc.conf</filename> statement <literal>ipfilter_enable="YES"</literal> is used. The loadable module was created with logging enabled and the - <literal>default pass all</literal> options. You do not need + <literal>default pass all</literal> options. There is no need to compile IPF into the &os; kernel just to change the default - to <literal>block all</literal>, you can do that by just coding - a block all rule at the end of your rule set.</para> + to <literal>block all</literal>. This can be done just by adding + a <literal>block all</literal> rule at the end of your ruleset.</para> </sect2> <sect2> @@ -603,7 +595,7 @@ <secondary>kernel options</secondary> </indexterm> - <para>It is not a mandatory requirement that you enable IPF by + <para>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 @@ -630,16 +622,15 @@ the default behavior so any packet not matching a firewall <literal>pass</literal> rule gets blocked.</para> - <para>These settings will take effect only after you have built - and installed a kernel with them set.</para> + <para>These settings will take effect only after installing a kernel + that has been built with the above options set.</para> </sect2> <sect2> <title>Available rc.conf Options</title> - <para>You need the following statements in - <filename>/etc/rc.conf</filename> to activate IPF at boot - time:</para> + <para>To activate IPF at boot time, the following statements need to + be added to <filename>/etc/rc.conf</filename>:</para> <programlisting>ipfilter_enable="YES" # Start ipf firewall ipfilter_rules="/etc/ipf.rules" # loads rules definition text file @@ -649,9 +640,9 @@ # v = log tcp window, ack, seq # n = map IP & port to names</programlisting> - <para>If you have a LAN behind this firewall that uses the - reserved private IP address ranges, then you need to add the - following to enable <acronym>NAT</acronym> + <para>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 <acronym>NAT</acronym> functionality:</para> <programlisting>gateway_enable="YES" # Enable as LAN gateway @@ -664,10 +655,10 @@ <indexterm><primary><command>ipf</command></primary></indexterm> - <para>The ipf command is used to load your rules file. Normally - you create a file containing your custom rules and use this - command to replace in mass the currently running firewall - internal rules:</para> + <para>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:</para> <screen>&prompt.root; <userinput>ipf -Fa -f /etc/ipf.rules</userinput></screen> @@ -738,7 +729,7 @@ Packet log flags set: (0)</screen> <para>When supplied with either <option>-i</option> for inbound - or <option>-o</option> for outbound, it will retrieve and + or <option>-o</option> for outbound, the command will retrieve and display the appropriate list of filter rules currently installed and in use by the kernel.</para> @@ -772,7 +763,7 @@ <command>ipfstat</command> command is the <option>-t</option> 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 + 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 @@ -792,19 +783,19 @@ </indexterm> <para>In order for <command>ipmon</command> to work properly, the - kernel option IPFILTER_LOG must be turned on. This command has + kernel option <literal>IPFILTER_LOG</literal> must be turned on. This command has two different modes that it can be used in. Native mode is the - default mode when you type the command on the command line + default mode when the command is typed on the command line without the <option>-D</option> flag.</para> - <para>Daemon mode is for when you want to have a continuous - system log file available so that you can review logging of - past events. This is how &os; and IPFILTER are configured to + <para>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 syslogd is better than the default of outputting to a - regular file. In the default <filename>rc.conf</filename> file - you see the ipmon_flags statement uses the <option>-Ds</option> + to &man.syslogd.8; is better than the default of outputting to a + regular file. In the default <filename>rc.conf</filename> file, + the <literal>ipmon_flags</literal> statement uses the <option>-Ds</option> flags:</para> <programlisting>ipmon_flags="-Ds" # D = start as daemon @@ -815,19 +806,19 @@ <para>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 all give you a significant edge + where they were going. These can all provide a significant edge in tracking down attackers.</para> <para>Even with the logging facility enabled, IPF will not generate any rule logging on its own. The firewall - administrator decides what rules in the rule set he wants to + 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.</para> <para>It is very customary to include a default deny everything rule with the log keyword included as your last rule in the - rule set. This way you get to see all the packets that did not - match any of the rules in the rule set.</para> + ruleset. This makes it possible to see all the packets that did not + match any of the rules in the ruleset.</para> </sect2> <sect2> @@ -850,15 +841,15 @@ <!-- XXX: "can be considered short" == "with incomplete header" --> <para>To setup IPFILTER to log all data to - <filename>/var/log/ipfilter.log</filename>, you will need to - create the file. The following command will do that:</para> + <filename>/var/log/ipfilter.log</filename>, the file will need to be + created beforehand. The following command will do that:</para> <screen>&prompt.root; <userinput>touch /var/log/ipfilter.log</userinput></screen> - <para>The syslog function is controlled by definition statements + <para>The &man.syslogd.8; function is controlled by definition statements in the <filename>/etc/syslog.conf</filename> file. The <filename>syslog.conf</filename> file offers considerable - flexibility in how syslog will deal with system messages issued + flexibility in how <application>syslog</application> will deal with system messages issued by software applications like IPF.</para> <para>Add the following statement to @@ -871,13 +862,13 @@ file location.</para> <para>To activate the changes to <filename>/etc/syslog.conf - </filename> you can reboot or bump the syslog task into + </filename> you can reboot or bump the &man.syslogd.8; daemon into re-reading <filename>/etc/syslog.conf</filename> by running <command>/etc/rc.d/syslogd reload</command></para> <para>Do not forget to change <filename>/etc/newsyslog.conf</filename> to rotate the new log - you just created above.</para> + created above.</para> </sect2> <sect2> @@ -924,18 +915,18 @@ <listitem> <para>The addresses. This is actually three fields: the source address and port (separated by a comma), the -> - symbol, and the destination address and port. - 209.53.17.22,80 -> 198.73.220.17,1722.</para> + symbol, and the destination address and port, e.g.: + <literal>209.53.17.22,80 -> 198.73.220.17,1722</literal>.</para> </listitem> <listitem> <para><literal>PR</literal> followed by the protocol name or - number, e.g. PR tcp.</para> + number, e.g.: <literal>PR tcp</literal>.</para> </listitem> <listitem> <para><literal>len</literal> followed by the header length - and total length of the packet, e.g. len 20 40.</para> + and total length of the packet, e.g.: <literal>len 20 40</literal>.</para> </listitem> </orderedlist> @@ -958,15 +949,15 @@ <para>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 you only have to change the value associated - with the symbolic name and when the script is run all the rules + 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, you can use symbolic substitution + the rules. Being a script, symbolic substitution can be used to code frequently used values and substitute them in multiple - rules. You will see this in the following example.</para> + rules. This can be seen in the following example.</para> - <para>The script syntax used here is compatible with the sh, csh, - and tcsh shells.</para> + <para>The script syntax used here is compatible with the &man.sh.1;, &man.csh.1;, + and &man.tcsh.1; shells.</para> <para>Symbolic substitution fields are prefixed with a dollar sign: <literal>$</literal>.</para> @@ -1012,8 +1003,8 @@ <para>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 <filename>/etc/ipf.rules.script</filename>, you could - reload these rules by entering the following command:</para> + named <filename>/etc/ipf.rules.script</filename>, these rules could be + reloaded by entering the following command:</para> <screen>&prompt.root; <userinput>sh /etc/ipf.rules.script</userinput></screen> @@ -1040,7 +1031,7 @@ value) into <filename>/etc/rc.conf</filename> file.</para> <para>Add a script like the following to your - <filename>/usr/local/etc/rc.d/</filename> startup + <filename class="directory">/usr/local/etc/rc.d/</filename> startup directory. The script should have an obvious name like <filename>ipf.loadrules.sh</filename>. The <filename>.sh</filename> extension is mandatory.</para> @@ -1060,27 +1051,21 @@ </sect2> <sect2> - <title>IPF Rule Sets</title> + <title>IPF Rulesets</title> - <!-- XXX: looks incorrect (and duplicated 2 times in this chapter): - 1. Packet can be processed two times depend of firewall - firewall configuration, but "return trip back" is - another packet. - 2. "Each TCP/IP service ... is predefined by its protocol ..." - - this shold be about packet and it's parameters - (source/destination address and port). --> - - <para>A rule set is a group of ipf rules coded to pass or block + <para>A 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 rule set processes the - packet two times, once on its arrival from the public Internet - host and again as it leaves for its return trip back to the - public Internet host. Each TCP/IP service (i.e. telnet, www, - mail, etc.) is predefined by its protocol, source and - destination IP address, or the source and destination port - number. This is the basic selection criteria used to create - rules which will pass or block services.</para> + 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 <acronym>TCP/IP</acronym> 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.</para> <indexterm> <primary>IPFILTER</primary> @@ -1101,19 +1086,6 @@ basic framework for coding an inclusive firewall rule set.</para> - <!-- XXX: something like this already in - <xref linkend="firewalls-concepts"> - AND: the para below is repeated 3 times in this chapter--> - - <para>An inclusive firewall only allows services matching the - rules through. This way you can control what services can - originate behind the firewall destined for the public Internet - and also control the services which can originate from the - public Internet accessing your private network. Everything - else is blocked and logged by default design. Inclusive - firewalls are much, much securer than exclusive firewall rule - sets and is the only rule set type covered herein.</para> - <warning> <para>When working with the firewall rules, be <emphasis>very careful</emphasis>. Some configurations <emphasis>will @@ -1187,7 +1159,7 @@ <para>The action indicates what to do with the packet if it matches the rest of the filter rule. Each rule - <emphasis>must</emphasis> have a action. The following + <emphasis>must</emphasis> have an action. The following actions are recognized:</para> <para><literal>block</literal> indicates that the packet should @@ -1204,7 +1176,7 @@ <para>A mandatory requirement is that each filter rule explicitly state which side of the I/O it is to be used on. - The next keyword must be either in or out and one or the + The next keyword must be either <literal>in</literal> or <literal>out</literal> and one or the other has to be coded or the rule will not pass syntax checks.</para> @@ -1250,8 +1222,8 @@ processing logic.</para> <para>When a packet is logged, the headers of the packet are - written to the IPL packet logging pseudo-device. - Immediately following the log keyword, the following + written to the <acronym>IPL</acronym> packet logging pseudo-device. + Immediately following the <literal>log</literal> keyword, the following qualifiers may be used (in this order):</para> <para><literal>body</literal> indicates that the first 128 @@ -1259,8 +1231,8 @@ headers.</para> <para><literal>first</literal> If the <literal>log</literal> - keyword is being used in conjunction with a <quote>keep - state</quote> option, it is recommended that this option is + keyword is being used in conjunction with a <literal>keep + state</literal> option, it is recommended that this option is also applied so that only the triggering packet is logged and not every packet which thereafter matches the <quote>keep state</quote> information.</para> @@ -1270,7 +1242,7 @@ <title>SELECTION</title> <para>The keywords described in this section are used to - describe attributes of the packet to be interrogated when + describe attributes of the packet to be checked when determining whether rules match or not. There is a keyword subject, and it has sub-option keywords, one of which has to be selected. The following general-purpose @@ -1291,7 +1263,7 @@ protocol names found in <filename>/etc/protocols</filename> are recognized and may be used. The special protocol keyword <literal>tcp/udp</literal> may be used to match either a - <acronym>TCP</acronym> or a UDP packet, and has been added as + <acronym>TCP</acronym> or a <acronym>UDP</acronym> packet, and has been added as a convenience to save duplication of otherwise identical rules.</para> </sect3> @@ -1303,24 +1275,22 @@ synonym for <quote>from any to any</quote> with no other match parameters.</para> - <para><literal>from src to dst</literal>: the from and to + <para><literal>from src to dst</literal>: the <literal>from</literal> and <literal>to</literal> keywords are used to match against IP addresses. Rules must - specify BOTH source and destination parameters. + specify <emphasis>both</emphasis> source and destination parameters. <literal>any</literal> is a special keyword that matches any - IP address. Examples of use: <quote>from any to any</quote> - or <quote>from 0.0.0.0/0 to any</quote> or <quote>from any to - 0.0.0.0/0</quote> or <quote>from 0.0.0.0 to any</quote> or - <quote>from any to 0.0.0.0</quote>.</para> + IP address. Examples of use: <literal>from any to any</literal> + or <literal>from 0.0.0.0/0 to any</literal> or <literal>from any to + 0.0.0.0/0</literal> or <literal>from 0.0.0.0 to any</literal> or + <literal>from any to 0.0.0.0</literal>.</para> - <!-- XXX: Needs rewording --> - <para>IP addresses may be specified as a dotted IP address - numeric form/mask-length, or as single dotted IP address - numeric form.</para> - <para>There is no way to match ranges of IP addresses which - do not express themselves easily as mask-length. See this - web page for help on writing mask-length: <ulink + do not express themselves easily using the dotted numeric + form / mask-length notation. The <filename + role="package">net-mgmt/ipcalc</filename> port may be used to + ease up the calculations. Additional information is available in + the utility's web page: <ulink url="http://jodies.de/ipcalc"></ulink>.</para>; </sect3> @@ -1329,21 +1299,21 @@ <para>If a port match is included, for either or both of source and destination, then it is only applied to - <acronym>TCP</acronym> and UDP packets. When composing port + <acronym>TCP</acronym> and <acronym>UDP</acronym> packets. When composing port comparisons, either the service name from <filename>/etc/services</filename> or an integer port number - may be used. When the port appears as part of the from + may be used. When the port appears as part of the <literal>from</literal> object, it matches the source port number; when it appears - as part of the to object, it matches the destination port + as part of the <literal>to</literal> object, it matches the destination port number. The use of the port option with the <literal>to</literal> object is a mandatory requirement for the modernized rules processing logic. Example of use: - <quote>from any to any port = 80</quote></para> + <literal>from any to any port = 80</literal></para> - <!-- XXX: Needs rewriting --> + <!-- XXX: Rewritten, but probably needs more changes --> - <para>Port comparisons may be done in a number of forms, with - a number of comparison operators, or port ranges may be + <para>Single port comparisons may be done in a number of ways, using + a number of different comparison operators. Port ranges may also be specified.</para> <para>port "=" | "!=" | "<" | ">" | "<=" | ">=" | @@ -1364,8 +1334,8 @@ <title><acronym>TCP</acronym>_FLAG</title> <para>Flags are only effective for <acronym>TCP</acronym> - filtering. The letters represents one of the possible flags - that can be interrogated in the <acronym>TCP</acronym> packet + filtering. The letters represent one of the possible flags + that can be matched against the <acronym>TCP</acronym> packet header.</para> <para>The modernized rules processing logic uses the @@ -1402,16 +1372,16 @@ exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the - bi-directional session conversation. It has the interrogation - abilities to determine if the session conversation between the + bi-directional session conversation. It has sufficient matching + capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors.</para> - <para>Keep state will also allow ICMP packets related to a - <acronym>TCP</acronym> or UDP session through. So if you get - ICMP type 3 code 4 in response to some web surfing allowed out + <para>Keep state will also allow <acronym>ICMP</acronym> packets related to a + <acronym>TCP</acronym> or <acronym>UDP</acronym> session through. So if you get + <acronym>ICMP</acronym> type 3 code 4 in response to some web surfing allowed out by a keep state rule, they will be automatically allowed in. Any packet that IPF can be certain is part of an active session, even if it is a different protocol, will be let @@ -1419,21 +1389,22 @@ <para>What happens is:</para> - <para>Packets destined to go out the interface connected to the + <para>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 in a active session conversation, then it exits the + table. If the packet matches the next expected packet + comprising an active session conversation, then it exits the firewall and the state of the session conversation flow is - updated in the dynamic state table, the remaining packets get - checked against the outbound rule set.</para> + updated in the dynamic state table. Packets that do not belong to + an already active session, are simply checked against the outbound + ruleset.</para> - <para>Packets coming in to the interface connected to the public - Internet are first checked against the dynamic state table, if - the packet matches the next expected packet comprising a + <para>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 conversation, then it exits the firewall and the state of the session conversation flow is updated in the - dynamic state table, the remaining packets get checked against - the inbound rule set.</para> + dynamic state table. Packets that do not belong to an already active + session, are simply checked against the inbound ruleset.</para> <para>When the conversation completes it is removed from the dynamic state table.</para> @@ -1443,7 +1414,7 @@ packets will be allowed through automatically and any impostors automatically rejected. If a new session is blocked, none of its subsequent packets will be allowed through. Stateful - filtering has technically advanced interrogation abilities + filtering has technically advanced matching abilities capable of defending against the flood of different attack methods currently employed by attackers.</para> </sect2> @@ -1451,14 +1422,19 @@ <sect2> <!-- XXX: This section needs a rewrite --> - <title>Inclusive Rule Set Example</title> + <title>Inclusive Ruleset Example</title> - <para>The following rule set is an example of how to code a very + <para>The following ruleset is an example of how to code a very secure inclusive type of firewall. An inclusive firewall only - allows services matching pass rules through and blocks all - other by default. All firewalls have at the minimum two - interfaces which have to have rules to allow the firewall to - function.</para> + allows services matching <literal>pass</literal> rules through, and blocks all + others by default. Firewalls intended to protect other machines, + also called <quote>network firewalls</quote>, should have at least + two interfaces, which are generally configured to trust one side + (the <acronym>LAN</acronym>) and not the other (the public Internet). Alternatively, + a firewall might be configured to protect only the system it is + running on—this is called a + <quote>host based firewall</quote>, and is particularly appropriate + for servers on an untrusted network.</para> <para>All &unix; flavored systems including &os; are designed to use interface <devicename>lo0</devicename> and IP address @@ -1468,20 +1444,19 @@ special internally used packets.</para> <para>The interface which faces the public Internet is the one - where you place your rules to authorize and control access out - to the public Internet and access requests arriving from the - public Internet. This can be your user PPP + to place the rules that authorize and control access of the outbound + and inbound connections. This can be your user PPP <devicename>tun0</devicename> interface or your NIC that is connected to your DSL or cable modem.</para> - <para>In cases where one or more NICs are cabled to private LANs - behind the firewall, those interfaces must have a rule coded to - allow free unmolested movement of packets originating from - those LAN interfaces.</para> + <para>In cases where one or more NICs are cabled to private network + segments, those interfaces may require rules to allow packets + originating from those LAN interfaces transit to each other and/or + to the outside (Internet).</para> - <para>The rules should be first organized into three major - sections: all the free unmolested interfaces, the public - interface outbound, and the public interface inbound.</para> + <para>The rules should be organized into three major + sections: first trusted interfaces, then the public + interface outbound, and last the public untrusted interface inbound.</para> <para>The rules in each of the public interface sections should have the most frequently matched rules placed before less @@ -1489,67 +1464,66 @@ blocking and logging all packets on that interface and direction.</para> - <para>The Outbound section in the following rule set only - contains 'pass' rules which contain selection values that + <para>The Outbound section in the following ruleset only + contains <literal>pass</literal> rules which contain selection values that uniquely identify the service that is authorized for public - Internet access. All the rules have the 'quick', 'on', - 'proto', 'port', and 'keep state' option coded. The 'proto - tcp' rules have the 'flag' option included to identify the + Internet access. All the rules have the <literal>quick</literal>, <literal>on</literal>, + <literal>proto</literal>, <literal>port</literal>, and <literal>keep state</literal> options set. The <literal>proto + tcp</literal> rules have the <literal>flag</literal> option included to identify the session start request as the triggering packet to activate the stateful facility.</para> <para>The Inbound section has all the blocking of undesirable packets first, for two different reasons. The first is that - these things being blocked may be part of an otherwise valid - packet which may be allowed in by the later authorized service - rules. The second reason is that by having a rule that - explicitly blocks selected packets that I receive on an - infrequent basis and that I do not want to see in the log, they - will not be caught by the last rule in the section which blocks - and logs all packets which have fallen through the rules. The - last rule in the section which blocks and logs all packets is - how you create the legal evidence needed to prosecute the - people who are attacking your system.</para> + malicious packets may be partial matches for legitimate traffic. + These packets have to be discarded rather than allowed in, based on + their partial matches against <literal>allow</literal> rules. + The second reason is that known and uninteresting rejects may be + blocked silently, rather than being caught and logged by the last + rules in the section. The final rule in each section, blocks and + logs all packets and can be used to create the legal evidence needed + to prosecute the people who are attacking your system.</para> - <para>Another thing you should take note of, is there is no - response returned for any of the undesirable stuff, their - packets just get dropped and vanish. This way the attacker + <para>Another thing that should be taken care of, is to insure there is no + response returned for any of the undesirable traffic. Invalid + packets should just get dropped and vanish. This way the attacker has no knowledge if his packets have reached your system. The less the attackers can learn about your system, the more time they must invest before actually doing something bad. - The inbound 'nmap OS fingerprint' attempts rule I log + Rules that include a <literal>log first</literal> option, will only + log the event the first time they are triggered. This option is + included in the sample <literal>nmap OS fingerprint</literal> rule. + The <filename role="package">security/nmap</filename> utility is + commonly used by attackers who attempt to identify the operating + system of your server.</para> - <!-- XXX: what? --> + <para>Any time there are logged messages on a rule with + the <literal>log first</literal> option, an <command>ipfstat -hio</command> + command should be executed to evaluate how many times the rule has + actually matched. Large number of matches usually indicate that the + system is being flooded (i.e.: under attack).</para> - the first occurrence because this is something a attacker - would do.</para> - - <para>Any time you see log messages on a rule with 'log first'. - You should do an <command>ipfstat -hio</command> command to see - the number of times the rule has been matched so you know if - you are being flooded, i.e. under attack.</para> - - <para>When you log packets with port numbers you do not - recognize, look it up in <filename>/etc/services</filename> or - go to <ulink + <para>The <filename>/etc/services</filename> file may be used to + lookup unknown port numbers. Alternatively, + visit <ulink url="http://www.securitystats.com/tools/portsearch.php"></ulink>; - and do a port number lookup to find what the purpose of that - port number is.</para> + and do a port number lookup to find the purpose of a particular + port number.</para> <para>Check out this link for port numbers used by Trojans <ulink url="http://www.simovits.com/trojans/trojans.html"></ulink>.</para>; - <para>The following rule set is a complete very secure - 'inclusive' type of firewall rule set that I have used on my - system. You can not go wrong using this rule set for your own. - Just comment out any pass rules for services that you do not - want to authorize.</para> + <para>The following ruleset creates a complete and very secure + <literal>inclusive</literal> type of firewall ruleset that has been + tested on production systems. It can be easily modified for your + own system. Just comment out any <literal>pass</literal> rules for + services that should not be authorized.</para> - <para>If you see messages in your log that you want to stop - seeing just add a block rule in the inbound section.</para> + <para>To avoid logging unwanted messages, + just add a <literal>block</literal> rule in the inbound section.</para> - <para>You have to change the <devicename>dc0</devicename> - interface name in every rule to the interface name of the Nic + <para>The <devicename>dc0</devicename> interface name has to be changed + in every rule to the real interface name of the NIC card that connects your system to the public Internet. For user PPP it would be <devicename>tun0</devicename>.</para> @@ -1572,9 +1546,9 @@ ################################################################# # Interface facing Public Internet (Outbound Section) -# Interrogate session start requests originating from behind the +# Match session start requests originating from behind the # firewall on the private network -# or from this gateway server destine for the public Internet. +# or from this gateway server destined for the public Internet. ################################################################# # Allow out access to my ISP's Domain name server. @@ -1609,38 +1583,38 @@ # Allow out nntp news pass out quick on dc0 proto tcp from any to any port = 119 flags S keep state -# Allow out gateway & LAN users non-secure FTP ( both passive & active modes) +# Allow out gateway & LAN users' non-secure FTP ( both passive & active modes) # This function uses the IP<acronym>NAT</acronym> built in FTP proxy function coded in # the nat rules file to make this single rule function correctly. # If you want to use the pkg_add command to install application packages # on your gateway system you need this rule. pass out quick on dc0 proto tcp from any to any port = 21 flags S keep state -# Allow out secure FTP, Telnet, and SCP +# Allow out ssh/sftp/scp (telnet/rlogin/FTP replacements) # This function is using SSH (secure shell) pass out quick on dc0 proto tcp from any to any port = 22 flags S keep state -# Allow out non-secure Telnet +# Allow out insecure Telnet pass out quick on dc0 proto tcp from any to any port = 23 flags S keep state -# Allow out FBSD CVSUP function +# Allow out FreeBSD CVSup pass out quick on dc0 proto tcp from any to any port = 5999 flags S keep state # Allow out ping to public Internet pass out quick on dc0 proto icmp from any to any icmp-type 8 keep state -# Allow out whois for LAN PC to public Internet +# Allow out whois from LAN to public Internet pass out quick on dc0 proto tcp from any to any port = 43 flags S keep state # Block and log only the first occurrence of everything # else that's trying to get out. -# This rule enforces the block all by default logic. +# This rule implements the default block block out log first quick on dc0 all ################################################################# # Interface facing Public Internet (Inbound Section) -# Interrogate packets originating from the public Internet -# destine for this gateway server or the private network. +# Match packets originating from the public Internet +# destined for this gateway server or the private network. ################################################################# # Block all inbound traffic from non-routable or reserved address spaces @@ -1711,9 +1685,8 @@ # Block and log only first occurrence of all remaining traffic # coming into the firewall. The logging of only the first -# occurrence stops a .denial of service. attack targeted -# at filling up your log file space. -# This rule enforces the block all by default logic. +# occurrence avoids filling up disk with Denial of Service logs. +# This rule implements the default block. block in log first quick on dc0 all ################### End of rules file #####################################</programlisting> </sect2> @@ -1735,8 +1708,8 @@ <see>NAT</see> </indexterm> - <para><acronym>NAT</acronym> stands for Network Address - Translation. To those familiar with &linux;, this concept is + <para><acronym>NAT</acronym> stands for <emphasis>Network Address + Translation</emphasis>. To those familiar with &linux;, this concept is called IP Masquerading; <acronym>NAT</acronym> and IP Masquerading are the same thing. One of the many things the IPF <acronym>NAT</acronym> function enables is the ability to @@ -1748,17 +1721,16 @@ normally assign a dynamic IP address to their non-commercial users. Dynamic means that the IP address can be different each time you dial in and log on to your ISP, or for cable and DSL - modem users when you power off and then power on your modems - you can get assigned a different IP address. This IP address - is how you are known to the public Internet.</para> >>> TRUNCATED FOR MAIL (1000 lines) <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905131855.n4DItSV7054285>