Date: Sun, 7 Jul 2002 16:15:13 -0400 (EDT) From: Chris Pepper <pepper@rockefeller.edu> To: FreeBSD-gnats-submit@FreeBSD.org Subject: docs/40313: Grammar, wording, and clarifications for handbook/security/chapter.sgml Message-ID: <20020707201513.63209A944@guest.reppep.com>
next in thread | raw e-mail | index | archive | help
>Number: 40313 >Category: docs >Synopsis: Grammar, wording, and clarifications for handbook/security/chapter.sgml >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: Sun Jul 07 13:20:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Chris Pepper >Release: FreeBSD 4.6-STABLE i386 >Organization: >Environment: System: FreeBSD guest.reppep.com 4.6-STABLE FreeBSD 4.6-STABLE #3: Sun Jul 7 02:08:43 EDT 2002 root@guest.reppep.com:/usr/obj/usr/src/sys/GENERIC i386 >Description: The IPFW chapter assumes all firewalling occurs in the kernel; it might not on a non-FreeBSD system. There are some awkward word choices. >How-To-Repeat: Visit <http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kerberos.html>. >Fix: The patch below removes assumptions that firewall occurs in the kernel from the text. It improves some wording. There are some outstanding issues I lacked sufficient information to address: This page should mention NAT, which is the firewalling term most likely to be recognized by new users. <para>As the main part of the IPFW system lives in the kernel, you will need to add one or more options to your kernel configuration file, depending on what facilities you want, and recompile your kernel. See "Reconfiguring your Kernel" (<xref linkend="kernelconfig">) for more details on how to recompile your kernel.</para> This is no longer correct -- ipfw can be kldloaded. It would be good to mention that IPFW can be activated through /etc/rc.conf, along with any additional requirements and warnings that accompany this procedure (IPFIREWALL_FORWARD broken per kern/39814; DIVERT broken for ipfw.kld per <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2998668+0+archive/2002/freebsd-questions/20020707.freebsd-questions>). <para>There are currently three kernel configuration options relevant to IPFW:</para> Per LINT, it's 4 (or 9 with IPv6). 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. Previous versions of IPFW used separate firewall and accounting entries. The present version provides packet accounting with each firewall entry. These paras (in different sections) disagree. If both filtering and accounting now use a unified ruleset, the first should be updated. --- chapter.sgml.diff begins here --- Index: chapter.sgml =================================================================== RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/security/chapter.sgml,v retrieving revision 1.111 diff -u -u -r1.111 chapter.sgml --- chapter.sgml 2002/06/18 09:58:50 1.111 +++ chapter.sgml 2002/07/07 19:47:27 @@ -919,8 +919,8 @@ respect except that it forwards encryption keys by default. What this means is that if you have a secure workstation holding keys that give you access to the rest of the system, and you - ssh to an insecure machine, your keys - becomes exposed. The actual keys themselves are not exposed, but + ssh to an insecure machine, your keys are usable by the + insecure system. The actual keys themselves are not exposed, but ssh installs a forwarding port for the duration of your login, and if an attacker has broken <username>root</username> on the @@ -1921,7 +1921,7 @@ <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 + <emphasis>packet filtering router</emphasis>, where 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 server</emphasis>, relies on daemons to provide authentication and to @@ -1946,29 +1946,29 @@ <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 has extra code 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 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 + set of rules for the filtering code so it can decide if any given packet should be allowed to pass or not.</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. + Only the first match counts, and 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 support ports), or even the packet type (UDP, TCP, ICMP, - etc).</para> + etc.).</para> </sect3> <sect3 id="firewalls-proxy-servers"> @@ -1976,29 +1976,29 @@ <para>Proxy servers are machines which have had the normal system daemons (<application>telnetd</application>, - <application>ftpd</application>, etc) replaced with special servers. + <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, + so 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> <para>Proxy servers are normally more secure than normal servers, and often have a wider variety of authentication mechanisms available, - 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 + including <quote>one-shot</quote> password systems, so that even if + someone manages to record a password being used, they will not be + able to use it, as the password + instantly expires on first use. As they do not actually give users direct 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 + they can be set up to limit which users can talk to + which destination machines. Again, what facilities are available depends largely on what proxy software you choose.</para> </sect3> </sect2> @@ -2011,12 +2011,12 @@ 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 for 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 + The firewall section performs packet filtering. There is + also an IP accounting section which tracks usage of your + router, based on similar rules. 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> @@ -2078,13 +2078,13 @@ firewall activity, but do not want to be open to a denial of service attack via syslog flooding.</para> - <para>When a chain entry reaches the packet limit specified, + <para>When a chain entry (rule) reaches the packet limit specified, logging is turned off for that particular entry. To resume logging, you will need to reset the associated counter using the &man.ipfw.8; utility:</para> <screen>&prompt.root; <userinput>ipfw zero 4500</userinput></screen> - <para>Where 4500 is the chain entry you wish to continue + <para>Where 4500 is the chain entry you wish to resume logging.</para> </listitem> </varlistentry> @@ -2200,9 +2200,9 @@ <term>allow</term> <listitem> - <para>Pass the packet on as normal. (aliases: - <literal>pass</literal> and - <literal>accept</literal>)</para> + <para>Pass the packet on as normal (aliases: + <literal>pass</literal>, <literal>permit</literal>, and + <literal>accept</literal>).</para> </listitem> </varlistentry> @@ -2212,7 +2212,7 @@ <listitem> <para>Drop the packet. The source is not notified via an ICMP message (thus it appears that the packet never - arrived at the destination).</para> + arrived at the destination). Alias: <literal>drop</literal>.</para> </listitem> </varlistentry> @@ -2362,11 +2362,11 @@ <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 list of IP options is: <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> @@ -2434,10 +2434,10 @@ <arg>-a</arg> <arg>-t</arg> <arg>-N</arg> - <arg choice="plain">l</arg> + <arg choice="plain">list</arg> </cmdsynopsis></para> - <para>There are three valid flags when using this form of the + <para>The list command may be abbreviated. There are three valid flags when using this form of the command:</para> <variablelist> @@ -2482,7 +2482,7 @@ <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> @@ -2499,7 +2499,7 @@ <para>When used without an <replaceable>index</replaceable> argument, all packet counters are cleared. If an - <replaceable>index</replaceable> is supplied, the clearing operation + <replaceable>index</replaceable> is supplied, the clear operation only affects a specific chain entry.</para> </sect3> </sect2> @@ -2546,25 +2546,25 @@ <note> <para>The following suggestions are just that: suggestions. The - requirements of each firewall are different and we cannot tell you + requirements for each firewall are different and we cannot tell you how to build a firewall to meet your particular requirements.</para> </note> <para>When initially setting up your firewall, unless you have a test bench setup where you can configure your firewall host in a controlled - environment, it is strongly recommend you use the logging version of the + environment, it is strongly recommend you use the logging versions of the commands and enable logging in the kernel. This will allow you to quickly identify problem areas and cure them without too much disruption. Even after the initial setup phase is complete, I - recommend using the logging for `deny' as it allows tracing of + recommend using the logging for `deny' rule, as it allows tracing of possible attacks and also modification of the firewall rules if your - requirements alter.</para> + requirements change.</para> <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 + data, as one log line will be generated for every packet that passes + through the firewall; this means 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 @@ -2576,7 +2576,7 @@ <para>You should enable your firewall from <filename>/etc/rc.conf.local</filename> or - <filename>/etc/rc.conf</filename>. The associated manual page explains + <filename>/etc/rc.conf</filename>. The <filename>/etc/rc.conf</filename> manual page explains which knobs to fiddle and lists some preset firewall configurations. If you do not use a preset configuration, <command>ipfw list</command> will output the current ruleset into a file that you can @@ -2590,7 +2590,7 @@ <emphasis>do</emphasis>! This is largely dependent on what access to your network you want to allow from the outside, and how much access to the outside world you want to allow from the inside. Some general - rules are:</para> + rules to start with are:</para> <itemizedlist> <listitem> @@ -2603,7 +2603,7 @@ <para>Block <emphasis>all</emphasis> incoming UDP traffic. There are very few useful services that travel over UDP, and what useful traffic there is, is normally a security threat (e.g. Suns RPC and - NFS protocols). This has its disadvantages also, since UDP is a + NFS protocols). This has its disadvantages also; since UDP is a connectionless protocol, denying incoming UDP traffic also blocks the replies to outgoing UDP traffic. This can cause a problem for people (on the inside) using external archie (prospero) servers. @@ -2626,7 +2626,7 @@ <listitem> <para>Check what ports any internal servers use (e.g. SQL servers, - etc). It is probably a good idea to block those as well, as they + etc.). It is probably a good idea to block those as well, as they normally fall outside the 1-1024 range specified above.</para> </listitem> </itemizedlist> @@ -2659,13 +2659,13 @@ <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 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 @@ -2686,7 +2686,7 @@ rule. Thus the theoretical packet processing limit with these rules is around 370 packets per second. Assuming 10Mbps Ethernet and a ~1500 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.172ms, or roughly 1.2 microseconds per rule. --- chapter.sgml.diff ends here --- >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020707201513.63209A944>