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

Grammar cleanups. This chapter needs a lot more work.

Browse source 
PR:		docs/40313
Submitted by:	Chris Pepper <pepper@rockefeller.edu> (partially)
This commit is contained in:
Murray Stokely 2003-04-08 02:29:37 +00:00
parent 91590a5c8a
commit ebf3f618ca
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=16494
1 changed files with 40 additions and 35 deletions

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

@ -1926,9 +1926,12 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>There are currently two distinct types of firewalls in common use
on the Internet today. The first type is more properly called a
<emphasis>packet filtering router</emphasis>, where the kernel on a
multi-homed machine chooses whether to forward or block packets based
on a set of rules. The second type, known as a <emphasis>proxy
<emphasis>packet filtering router</emphasis>. This type of
firewall utilizes a multi-homed machine and a set of rules to
determine whether to forward or block individual packets. A
multi-homed machine is simply a device with multiple network
interfaces.
The second type, known as a <emphasis>proxy
server</emphasis>, relies on daemons to provide authentication and to
forward packets, possibly on a multi-homed machine which has kernel
packet forwarding disabled.</para>
@ -1951,24 +1954,23 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<title>Packet Filtering Routers</title>
<para>A router is a machine which forwards packets between two or more
networks. A packet filtering router has an extra piece of code in
its kernel which compares each packet to a list of rules before
networks. A packet filtering router is programmed to
compare each packet to a list of rules before
deciding if it should be forwarded or not. Most modern IP routing
software has packet filtering code within it that defaults to
software includes packet filtering functionality that defaults to
forwarding all packets. To enable the filters, you need to define a
set of rules for the filtering code so it can decide if the
packet should be allowed to pass or not.</para>
set of rules.</para>
<para>To decide whether a packet should be passed on, the code looks
<para>To decide whether a packet should be passed on, the firewall looks
through its set of rules for a rule which matches the contents of
this packets headers. Once a match is found, the rule action is
the packet's headers. Once a match is found, the rule action is
obeyed. The rule action could be to drop the packet, to forward the
packet, or even to send an ICMP message back to the originator.
Only the first match counts, as the rules are searched in order.
Hence, the list of rules can be referred to as a <quote>rule
chain</quote>.</para>
<para>The packet matching criteria varies depending on the software
<para>The packet-matching criteria varies depending on the software
used, but typically you can specify rules which depend on the source
IP address of the packet, the destination IP address, the source
port number, the destination port number (for protocols which
@ -1983,10 +1985,10 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
daemons (<application>telnetd</application>,
<application>ftpd</application>, etc) replaced with special servers.
These
servers are called <emphasis>proxy servers</emphasis> as they
servers are called <emphasis>proxy servers</emphasis>, as they
normally only allow onward connections to be made. This enables you
to run (for example) a proxy telnet server on your firewall host,
and people can telnet in to your firewall from the outside, go
to run (for example) a proxy <application>telnet</application> server on your firewall host,
and people can <application>telnet</application> in to your firewall from the outside, go
through some authentication mechanism, and then gain access to the
internal network (alternatively, proxy servers can be used for
signals coming from the internal network and heading out).</para>
@ -1996,14 +1998,15 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
including <quote>one-shot</quote> password systems so that even if
someone manages to discover what password you used, they will not be
able to use it to gain access to your systems as the password
instantly expires. As they do not actually give users access to the
expires immediately after the first use. As they do not actually give users access to the
host machine, it becomes a lot more difficult for someone to install
backdoors around your security system.</para>
<para>Proxy servers often have ways of restricting access further, so
that only certain hosts can gain access to the servers, and often
they can be set up so that you can limit which users can talk to
which destination machine. Again, what facilities are available
that only certain hosts can gain access to the servers.
Most will also allow the administrator to specify which
users can talk to which destination machines.
Again, what facilities are available
depends largely on what proxy software you choose.</para>
</sect3>
</sect2>
@ -2016,15 +2019,16 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
FreeBSD, is a packet filtering and accounting system which resides in
the kernel, and has a user-land control utility,
&man.ipfw.8;. Together, they allow you to define and query the
rules currently used by the kernel in its routing decisions.</para>
rules used by the kernel in its routing decisions.</para>
<para>There are two related parts to IPFW.
The firewall section allows you to perform packet filtering. There is
also an IP accounting section which allows you to track usage of your
router, based on similar rules to the firewall section. This allows
you to see (for example) how much traffic your router is getting from
a certain machine, or how much WWW (World Wide Web) traffic it is
forwarding.</para>
The firewall section performs packet filtering. There is
also an IP accounting section which tracks usage of the
router, based on rules similar to those used in the firewall
section. This allows
the administrator to monitor how much traffic the router is
getting from a certain machine, or how much WWW traffic it is
forwarding, for example.</para>
<para>As a result of the way that IPFW is
designed, you can use IPFW on non-router
@ -2240,7 +2244,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<listitem>
<para>Pass the packet on as normal. (aliases:
<literal>pass</literal> and
<literal>pass</literal>, <literal>permit</literal>, and
<literal>accept</literal>)</para>
</listitem>
</varlistentry>
@ -2402,11 +2406,11 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<listitem>
<para>Matches if the IP header contains the comma separated list
of options specified in <replaceable>spec</replaceable>. The
supported list of IP options are: <literal>ssrr</literal>
supported IP options are: <literal>ssrr</literal>
(strict source route), <literal>lsrr</literal> (loose source
route), <literal>rr</literal> (record packet route), and
<literal>ts</literal> (time stamp). The absence of a
particular option may be denoted with a leading
particular option may be specified with a leading
<literal>!</literal>.</para>
</listitem>
</varlistentry>
@ -2560,7 +2564,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<para>This causes all entries in the firewall chain to be removed
except the fixed default policy enforced by the kernel (index
65535). Use caution when flushing rules, the default deny policy
65535). Use caution when flushing rules; the default deny policy
will leave your system cut off from the network until allow entries
are added to the chain.</para>
</sect3>
@ -2640,9 +2644,10 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<note>
<para>If you use the logging versions of the <command>accept</command>
command, it can generate <emphasis>large</emphasis> amounts of log
data as one log line will be generated for every packet that passes
through the firewall, so large FTP/http transfers, etc, will really
command, be aware that it can generate
<emphasis>large</emphasis> amounts of log data. One log
entry will be generated for every packet that passes
through the firewall, so large FTP/http transfers, etc, will really
slow the system down. It also increases the latencies on those
packets as it requires more work to be done by the kernel before the
packet can be passed on. <application>syslogd</application> will
@ -2737,13 +2742,13 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
<literal>ip_fw_chk</literal> routine, displaying the results
to the console every 1000 packets.</para>
<para>Two rule sets, each with 1000 rules were tested. The
<para>Two rule sets, each with 1000 rules, were tested. The
first set was designed to demonstrate a worst case scenario by
repeating the rule:</para>
<screen>&prompt.root; <userinput>ipfw add deny tcp from any to any 55555</userinput></screen>
<para>This demonstrates worst case by causing most of IPFW's
<para>This demonstrates a worst case scenario by causing most of IPFW's
packet check routine to be executed before finally deciding
that the packet does not match the rule (by virtue of the port
number). Following the 999th iteration of this rule was an
@ -2764,7 +2769,7 @@ FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995</screen>
rule. Thus the theoretical packet processing limit with these
rules is around 370&nbsp;packets per second. Assuming 10&nbsp;Mbps
Ethernet and a ~1500&nbsp;byte packet size, we would only be able
to achieve a 55.5% bandwidth utilization.</para>
to achieve 55.5% bandwidth utilization.</para>
<para>For the latter case each packet was processed in
approximately 1.172&nbsp;ms, or roughly 1.2&nbsp;microseconds per rule.