<p>Attempt to resolve given addresses and service names.</p></dd><dt>-S</dt><dd><p>Show the set each rule belongs to. If this flag is not specified, disabled rules willnot be listed.</p></dd></dl></div></div><div class="SECT3"><h3 class="SECT3"><a id="AEN20428" name="AEN20428">14.8.4.3. Flushing the IPFWRules</a></h3><p>The syntax for flushing the chain is:</p><p><tt class="COMMAND">ipfw</tt> flush</p><br /><br /><p>This causes all entries in the firewall chain to be removed except the fixed defaultpolicy enforced by the kernel (index 65535). Use caution when flushing rules; the defaultdeny policy will leave your system cut off from the network until allow entries are addedto the chain.</p></div><div class="SECT3"><h3 class="SECT3"><a id="AEN20435" name="AEN20435">14.8.4.4. Clearing the IPFW PacketCounters</a></h3><p>The syntax for clearing one or more packet counters is:</p><p><tt class="COMMAND">ipfw</tt> zero [<var class="REPLACEABLE">index</var>]</p><br /><br /><p>When used without an <var class="REPLACEABLE">index</var> argument, all packetcounters are cleared. If an <var class="REPLACEABLE">index</var> is supplied, theclearing operation only affects a specific chain entry.</p></div></div><div class="SECT2"><h2 class="SECT2"><a id="AEN20446" name="AEN20446">14.8.5. Example Commands for <bclass="APPLICATION">ipfw</b></a></h2><p>This command will deny all packets from the host <ttclass="HOSTID">evil.crackers.org</tt> to the telnet port of the host <ttclass="HOSTID">nice.people.org</tt>:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbdclass="USERINPUT">ipfw add deny tcp from evil.crackers.org to nice.people.org 23</kbd></pre><p>The next example denies and logs any TCP traffic from the entire <ttclass="HOSTID">crackers.org</tt> network (a class C) to the <ttclass="HOSTID">nice.people.org</tt> machine (any port).</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbdclass="USERINPUT">ipfw add deny log tcp from evil.crackers.org/24 to nice.people.org</kbd></pre><p>If you do not want people sending X sessions to your internal network (a subnet of aclass C), the following command will do the necessary filtering:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbdclass="USERINPUT">ipfw add deny tcp from any to my.org/28 6000 setup</kbd></pre><p>To see the accounting records:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbd class="USERINPUT">ipfw -a list</kbd></pre>or in the short form <pre class="SCREEN"><samp class="PROMPT">#</samp> <kbd class="USERINPUT">ipfw -a l</kbd></pre><br /><br /><p>You can also see the last time a chain entry was matched with:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbd class="USERINPUT">ipfw -at l</kbd></pre></div><div class="SECT2"><h2 class="SECT2"><a id="AEN20476" name="AEN20476">14.8.6. Building a Packet FilteringFirewall</a></h2><div class="NOTE"><blockquote class="NOTE"><p><b>注:</b> The following suggestions are just that: suggestions. The requirements ofeach firewall are different and we cannot tell you how to build a firewall to meet yourparticular requirements.</p></blockquote></div><p>When initially setting up your firewall, unless you have a test bench setup where youcan configure your firewall host in a controlled environment, it is strongly recommendyou use the logging version of the commands and enable logging in the kernel. This willallow 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 possible attacks and also modification of the firewall rules ifyour requirements alter.</p><div class="NOTE"><blockquote class="NOTE"><p><b>注:</b> If you use the logging versions of the <tt class="COMMAND">accept</tt>command, be aware that it can generate <span class="emphasis"><iclass="EMPHASIS">large</i></span> amounts of log data. One log entry will be generatedfor every packet that passes through the firewall, so large FTP/http transfers, etc, willreally slow the system down. It also increases the latencies on those packets as itrequires more work to be done by the kernel before the packet can be passed on. <bclass="APPLICATION">syslogd</b> will also start using up a lot more processor time as itlogs all the extra data to disk, and it could quite easily fill the partition <ttclass="FILENAME">/var/log</tt> is located on.</p></blockquote></div><p>You should enable your firewall from <tt class="FILENAME">/etc/rc.conf.local</tt> or<tt class="FILENAME">/etc/rc.conf</tt>. The associated manual page explains which knobsto fiddle and lists some preset firewall configurations. If you do not use a presetconfiguration, <tt class="COMMAND">ipfw list</tt> will output the current ruleset into afile that you can pass to <tt class="FILENAME">rc.conf</tt>. If you do not use <ttclass="FILENAME">/etc/rc.conf.local</tt> or <tt class="FILENAME">/etc/rc.conf</tt> toenable your firewall, it is important to make sure your firewall is enabled before any IPinterfaces are configured.</p><p>The next problem is what your firewall should actually <span class="emphasis"><iclass="EMPHASIS">do</i></span>! This is largely dependent on what access to your networkyou want to allow from the outside, and how much access to the outside world you want toallow from the inside. Some general rules are:</p><ul><li><p>Block all incoming access to ports below 1024 for TCP. This is where most of thesecurity sensitive services are, like finger, SMTP (mail) and telnet.</p></li><li><p>Block <span class="emphasis"><i class="EMPHASIS">all</i></span> incoming UDP traffic.There are very few useful services that travel over UDP, and what useful traffic thereis, is normally a security threat (e.g. Suns RPC and NFS protocols). This has itsdisadvantages also, since UDP is a connectionless protocol, denying incoming UDP trafficalso blocks the replies to outgoing UDP traffic. This can cause a problem for people (onthe inside) using external archie (prospero) servers. If you want to allow access toarchie, you will have to allow packets coming from ports 191 and 1525 to any internal UDPport through the firewall. <b class="APPLICATION">ntp</b> is another service you mayconsider allowing through, which comes from port 123.</p></li><li><p>Block traffic to port 6000 from the outside. Port 6000 is the port used for access toX11 servers, and can be a security threat (especially if people are in the habit of doing<tt class="COMMAND">xhost +</tt> on their workstations). X11 can actually use a range ofports starting at 6000, the upper limit being how many X displays you can run on themachine. The upper limit as defined by RFC 1700 (Assigned Numbers) is 6063.</p></li><li><p>Check what ports any internal servers use (e.g. SQL servers, etc). It is probably agood idea to block those as well, as they normally fall outside the 1-1024 rangespecified above.</p></li></ul><p>Another checklist for firewall configuration is available from CERT at <ahref="http://www.cert.org/tech_tips/packet_filtering.html"target="_top">http://www.cert.org/tech_tips/packet_filtering.html</a></p><p>As stated above, these are only <span class="emphasis"><iclass="EMPHASIS">guidelines</i></span>. You will have to decide what filter rules youwant to use on your firewall yourself. We cannot accept ANY responsibility if someonebreaks into your network, even if you follow the advice given above.</p></div><div class="SECT2"><h2 class="SECT2"><a id="IPFW-OVERHEAD" name="IPFW-OVERHEAD">14.8.7. IPFW Overhead andOptimization</a></h2><p>Many people want to know how much overhead IPFW adds to a system. The answer to thisdepends mostly on your rule set and processor speed. For most applications dealing withEthernet and small rule sets, the answer is ``negligible''. For those of you that needactual measurements to satisfy your curiosity, read on.</p><p>The following measurements were made using 2.2.5-STABLE on a 486-66. (While IPFW haschanged slightly in later releases of FreeBSD, it still performs with similar speed.)IPFW was modified to measure the time spent within the <varclass="LITERAL">ip_fw_chk</var> routine, displaying the results to the console every 1000packets.</p><p>Two rule sets, each with 1000 rules, were tested. The first set was designed todemonstrate a worst case scenario by repeating the rule:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbdclass="USERINPUT">ipfw add deny tcp from any to any 55555</kbd></pre><p>This demonstrates a worst case scenario by causing most of IPFW's packet check routineto be executed before finally deciding that the packet does not match the rule (by virtueof the port number). Following the 999th iteration of this rule was an <varclass="LITERAL">allow ip from any to any</var>.</p><p>The second set of rules were designed to abort the rule check quickly:</p><pre class="SCREEN"><samp class="PROMPT">#</samp> <kbdclass="USERINPUT">ipfw add deny ip from 1.2.3.4 to 1.2.3.4</kbd></pre><p>The non-matching source IP address for the above rule causes these rules to be skippedvery quickly. As before, the 1000th rule was an <var class="LITERAL">allow ip from any toany</var>.</p><p>The per-packet processing overhead in the former case was approximately2.703&nbsp;ms/packet, or roughly 2.7&nbsp;microseconds per rule. Thus the theoreticalpacket processing limit with these rules is around 370&nbsp;packets per second. Assuming10&nbsp;Mbps Ethernet and a ~1500&nbsp;byte packet size, we would only be able to achieve55.5% bandwidth utilization.</p><p>For the latter case each packet was processed in approximately 1.172&nbsp;ms, orroughly 1.2&nbsp;microseconds per rule. The theoretical packet processing limit herewould be about 853&nbsp;packets per second, which could consume 10&nbsp;Mbps Ethernetbandwidth.</p><p>The excessive number of rules tested and the nature of those rules do not provide areal-world scenario -- they were used only to generate the timing information presentedhere. Here are a few things to keep in mind when building an efficient rule set:</p><ul><li><p>Place an <var class="LITERAL">established</var> rule early on to handle the majorityof TCP traffic. Do not put any <var class="LITERAL">allow tcp</var> statements beforethis rule.</p></li><li><p>Place heavily triggered rules earlier in the rule set than those rarely used (<spanclass="emphasis"><i class="EMPHASIS">without changing the permissiveness of thefirewall</i></span>, of course). You can see which rules are used most often by examiningthe packet counting statistics with <tt class="COMMAND">ipfw -a l</tt>.</p></li></ul></div></div><div class="NAVFOOTER"><hr align="LEFT" width="100%" /><table summary="Footer navigation table" width="100%" border="0" cellpadding="0"cellspacing="0"><tr><td width="33%" align="left" valign="top"><a href="kerberos5.html"accesskey="P">后退</a></td><td width="34%" align="center" valign="top"><a href="index.html"accesskey="H">起點</a></td><td width="33%" align="right" valign="top"><a href="openssl.html"accesskey="N">前進</a></td></tr><tr><td width="33%" align="left" valign="top"><b class="APPLICATION">Kerberos5</b></td><td width="34%" align="center" valign="top"><a href="security.html"accesskey="U">上一級</a></td><td width="33%" align="right" valign="top">OpenSSL</td></tr></table></div></body></html>