Attachment 12254 Details for Bug 23787 – file.diff

[patch] file.diff

file.diff (text/plain), 2.91 KB, created by dima on 2000-12-23 03:30:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: dima

Created: 2000-12-23 03:30:01 UTC

Size: 2.91 KB

patch

obsolete

>Index: book.sgml
>===================================================================
>RCS file: /st/src/FreeBSD/doc/en_US.ISO_8859-1/books/faq/book.sgml,v
>retrieving revision 1.129
>diff -u -r1.129 book.sgml
>--- book.sgml	2000/12/05 13:18:16	1.129
>+++ book.sgml	2000/12/23 00:28:10
>@@ -8023,6 +8023,63 @@
> 
>         </answer>
>       </qandaentry>
>+
>+      <qandaentry>
>+        <question id="icmp-response-bw-limit">
>+          <para>What are these messages about <quote>icmp-response
>+            bandwidth limit 300/200 pps</quote> in my log
>+            files?</para>
>+        </question>
>+
>+        <answer>
>+          <para>This is the kernel telling you that some activity is
>+            provoking it to send more ICMP or TCP reset (RST)
>+            responses than it thinks it should.  ICMP responses are
>+            often generated as a result of attempted connections to
>+            unused UDP ports.  TCP resets are generated as a result of
>+            attempted connections to unopened TCP ports.  Among
>+            others, these are the kinds of activities which may cause
>+            these messages:</para>
>+
>+          <itemizedlist>
>+            <listitem>
>+              <para>Brute-force denial of service (DoS) attacks (as
>+              opposed to single-packet attacks which exploit a
>+              specific vulnerability).</para>
>+            </listitem>
>+
>+            <listitem>
>+              <para>Port scans which attempt to connect to every port
>+                possible (as opposed to only trying some well-known
>+                ports).</para>
>+            </listitem>
>+          </itemizedlist>
>+
>+          <para>The first number in the message tells you how many
>+            packets the kernel would've sent if the limit wasn't in
>+            place, and the second number tells you the limit.  You can
>+            control the limit using the
>+            <varname>net.inet.icmp.icmplim</varname> sysctl variable
>+            like this, where <literal>300</literal> is the limit in
>+            packets per second:</para>
>+
>+          <screen>&prompt.root; <userinput>sysctl -w net.inet.icmp.icmplim=300</userinput></screen>
>+
>+          <para>If you don't want to see messages about this in your
>+            log files, but you still want the kernel to do response
>+            limiting, you can use the
>+            <varname>net.inet.icmp.icmplim_output</varname> sysctl
>+            variable to disable the output like this:</para>
>+
>+          <screen>&prompt.root; <userinput>sysctl -w net.inet.icmp.icmplim_output=0</userinput></screen>
>+
>+          <para>Finally, if you want to disable response limiting, you
>+            can set the <varname>net.inet.icmp.icmplim</varname>
>+            sysctl variable (see above for an example) to
>+            <literal>0</literal>.  Disabling response limiting is
>+            discouraged for the reasons listed above.</para>
>+        </answer>
>+      </qandaentry>
>     </qandaset>
>   </chapter>

Actions: View | Diff

Attachments on bug 23787: 12254