os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Remove contractions.

Browse source 
- Correct spelling and grammar.

PR:		docs/74668
Submitted by:	Joel Dahl <joel@automatvapen.se>
This commit is contained in:
Simon L. B. Nielsen 2004-12-04 20:23:16 +00:00
parent bf1daf1f72
commit 9ed12089ab
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=23120
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
en_US.ISO8859-1/books/handbook/security/chapter.sgml
View file

@ -4492,7 +4492,7 @@ block in log first quick on dc0 all
<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 @@ block in log first quick on dc0 all
<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 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
<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 do not 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 @@ options IPV6FIREWALL_DEFAULT_TO_ACCEPT</programlisting>
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 @@ ipfw -q add 00611 allow udp from any to 192.0.2.11 53 out via tun0 keep-state</p
<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 @@ natd_flags="-dynamic -m" # -m = preserve port numbers if possible</pr
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 @@ natd_flags="-dynamic -m" # -m = preserve port numbers if possible</pr
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 @@ natd_flags="-dynamic -m" # -m = preserve port numbers if possible</pr
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 @@ ipfw -q -f flush
######################## 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>