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> |