View | Details | Raw Unified | Return to bug 29086
Collapse All | Expand All

(-)article.sgml (-11 / +16 lines)
Lines 103-119 Link Here
103
103
104
    <variablelist>
104
    <variablelist>
105
      <varlistentry>
105
      <varlistentry>
106
	<term><literal>options TCP_RESTRICT_RST</literal></term>
107
108
	<listitem>
109
	  <para>This option blocks all TCP RST packets.  This is
110
	    best used for systems that might be exposed to SYN 
111
	    flooding (IRC Servers are a good example) or for those who 
112
     	    do not want to be easily portscannable.</para>
113
	</listitem>
114
      </varlistentry>
115
116
      <varlistentry>
117
	<term><literal>options TCP_DROP_SYNFIN</literal></term>
106
	<term><literal>options TCP_DROP_SYNFIN</literal></term>
118
107
119
	<listitem>
108
	<listitem>
Lines 272-277 Link Here
272
	    because I prefer firewalling to be done at a kernel level rather
261
	    because I prefer firewalling to be done at a kernel level rather
273
	    than by a userland program.</para>
262
	    than by a userland program.</para>
274
	</answer>
263
	</answer>
264
      </qandaentry>
265
266
      <qandaentry>
267
        <question>
268
	  <para>I get messages like "limit 100 reached on entry 2800"
269
  	    and after that I never see more denies in my logs.  Is my 
270
	    firewall still working?</para>
271
        </question>
272
273
	<answer>
274
	  <para>This merely means that the maximum logging count for the
275
	    rule has been reached.  The rule itself is still working,
276
	    but it will no longer log until such time as you reset the
277
	    logging counters.  This can be done by simply prefixing the
278
	    ipfw command with the "resetlog" option.</para>
279
        </answer>
275
      </qandaentry>
280
      </qandaentry>
276
281
277
      <qandaentry>
282
      <qandaentry>

Return to bug 29086