docs/74668: [patch] Handbook: update firewall chapter
Joel Dahl
joel at automatvapen.se
Sat Dec 4 13:10:27 UTC 2004
>Number: 74668
>Category: docs
>Synopsis: [patch] Handbook: update firewall chapter
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: doc-bug
>Submitter-Id: current-users
>Arrival-Date: Sat Dec 04 13:10:27 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator: Joel Dahl
>Release: FreeBSD 5.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #1: Sat Nov 13 19:50:36 CET 2004 joel at dude.automatvapen.se:/usr/obj/usr/src/sys/WRK i386
>Description:
- Remove contractions.
- Correct spelling and grammar.
>How-To-Repeat:
>Fix:
--- firewall1.diff begins here ---
Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v
retrieving revision 1.247
diff -u -r1.247 chapter.sgml
--- chapter.sgml 2 Dec 2004 14:27:28 -0000 1.247
+++ chapter.sgml 4 Dec 2004 12:44:52 -0000
@@ -4492,7 +4492,7 @@
<sect3>
<title>Port Redirection</title>
<para>An very common practice is to have a web server, email
- server, database server and DNS sever each segregated to a
+ server, database server and DNS server each segregated to a
different PC on the LAN. In this case the traffic from these
servers still have to be <acronym>NAT</acronym>ed, but there has to be some way
to direct the inbound traffic to the correct LAN PC's. IP<acronym>NAT</acronym>
@@ -4518,7 +4518,7 @@
<sect3>
<title>FTP and <acronym>NAT</acronym></title>
<para>FTP is a dinosaur left over from the time before the
- Internet as it is know today, when research universities were
+ Internet as it is known today, when research universities were
leased lined together and FTP was used to share files among
research Scientists. This was a time when data security was
not even an idea yet. Over the years the FTP protocol became
@@ -4720,7 +4720,7 @@
<sect3>
<title><filename>/etc/rc.conf</filename> Options</title>
- <para>If you don't have IPFW compliled into your kernel you will
+ <para>If you don't have IPFW compiled into your kernel you will
need to load it with the following statement in your
<filename>/etc/rc.conf</filename>:</para>
@@ -5045,7 +5045,7 @@
administrator decides what rules in the rule set he wants to
log and adds the log verb to those rules. Normally only deny
rules are logged. Like the deny rule for incoming <acronym>ICMP</acronym>
- pings. It's very customary to duplicate the ipfw default
+ pings. It is very customary to duplicate the ipfw default
deny everything rule with the log verb 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>
@@ -5221,8 +5221,8 @@
<title>An Example Inclusive Ruleset</title>
<para>The following non-<acronym>NAT</acronym>ed rule set is a complete inclusive
type ruleset. You can not go wrong using this rule set for
- you own. Just comment out any pass rules for services to
- don't want. If you see messages in your log that you want to
+ you own. Just comment out any pass rules for services you
+ do not want. If you see messages in your log that you want to
stop seeing just add a deny rule in the inbound section. You
have to change the 'dc0' interface name in every rule to the
interface name of the NIC that connects your system to the
@@ -5442,7 +5442,7 @@
top of the rule file and progress one rule at a time deeper
into the file until the end is reach or the packet being
tested to the selection criteria matches and the packet is
- released out of the firewall. It's important to take notice
+ released out of the firewall. It is important to take notice
of the location of rule numbers 100 101, 450, 500, and 510.
These rules control the translation of the outbound and
inbound packets so their entries in the keep-state dynamic
@@ -5459,13 +5459,13 @@
it is headed out not in. It passes rule 101 because this is
the first packet so it has not been posted to the keep-state
dynamic table yet. The packet finally comes to rule 125 a
- matches. It's outbound through the NIC facing the public
+ matches. It is outbound through the NIC facing the public
Internet. The packet still has it's source IP address as a
private Lan IP address. On the match to this rule, two
- action take place. The keep-state option will post this rule
+ actions take place. The keep-state option will post this rule
into the keep-state dynamic rules table and the specified
action is executed. The action is part of the info posted to
- the dynamic table. In this case it's "skipto rule 500". Rule
+ the dynamic table. In this case it is "skipto rule 500". Rule
500 <acronym>NAT</acronym>s the packet IP address and out it goes. Remember
this, this is very important. This packet makes it's way to
the destination and returns and enters the top of the rule
@@ -5477,7 +5477,7 @@
packet is sent requesting another segment of the data from
the remote server. This time it gets checked by the
check-state rule and it's outbound entry is found, the
- associated action, 'skipto 500', is executed. the packet
+ associated action, 'skipto 500', is executed. The packet
jumps to rule 500 gets <acronym>NAT</acronym>ed and released on it's way out.
</para>
@@ -5552,7 +5552,7 @@
######################## end of rules ##################
</programlisting>
- <para>The following is pretty much the same as above but, uses
+ <para>The following is pretty much the same as above, but uses
a self documenting coding style full of description comments
to help the inexperienced IPFW rule writer to better
understand what the rules are doing.</para>
--- firewall1.diff ends here ---
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-doc
mailing list