From owner-freebsd-questions Wed Apr 5 13:54:29 2000 Delivered-To: freebsd-questions@freebsd.org Received: from hydrant.intranova.net (hydrant.intranova.net [209.201.95.10]) by hub.freebsd.org (Postfix) with SMTP id 69BD737B897 for ; Wed, 5 Apr 2000 13:54:18 -0700 (PDT) (envelope-from oogali@intranova.net) Received: (qmail 32337 invoked from network); 5 Apr 2000 20:58:41 -0000 Received: from localhost.abuselabs.com (HELO localhost) (missnglnk@127.0.0.1) by localhost.abuselabs.com with SMTP; 5 Apr 2000 20:58:41 -0000 Date: Wed, 5 Apr 2000 16:58:41 -0400 (EDT) From: Omachonu Ogali To: Doug Barton Cc: Pete Fritchman , freebsd-questions@freebsd.org Subject: Re: icmp-response bandwidth limit question In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 5 Apr 2000, Doug Barton wrote: > On Tue, 4 Apr 2000, Omachonu Ogali wrote: > > > On Mon, 3 Apr 2000, Doug Barton wrote: > > > > > Pete Fritchman wrote: > > > > > > > > > icmp-response bandwidth limit 734/200 pps > > > > > icmp-response bandwidth limit 729/200 pps > > > > > > > > What do these indicate? > > > > > > That your kernel is dropping everything over 200 ICMP packets per > > > second. > > > > It indicates that your kernel is dropping ICMP and/or TCP responses that > > are coming out faster than 200 packets per second. It's limiting what's > > coming OUT from you. > > This option does not affect TCP responses. It's ICMP only. Sorry, once again, you are incorrect. This option affects TCP responses, if you had taken a look at /usr/src/sys/netinet/tcp_input.c you would see ICMP bandwidth limiting also limits the amount of RST's generated. (See stream.c), here is the snippet below: -- snip -- dropafterack: /* * Generate an ACK dropping incoming segment if it occupies * sequence space, where the ACK reflects our state. * * We can now skip the test for the RST flag since all * paths to this code happen after packets containing * RST have been dropped. * * In the SYN-RECEIVED state, don't send an ACK unless the * segment we received passes the SYN-RECEIVED ACK test. * If it fails send a RST. This breaks the loop in the * "LAND" DoS attack, and also prevents an ACK storm * between two listening ports that have been sent forged * SYN segments, each with the source address of the other. */ if (tp->t_state == TCPS_SYN_RECEIVED && (thflags & TH_ACK) && (SEQ_GT(tp->snd_una, th->th_ack) || SEQ_GT(th->th_ack, tp->snd_max)) ) goto maybedropwithreset; #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, &tcp_savetcp, 0); #endif m_freem(m); tp->t_flags |= TF_ACKNOW; (void) tcp_output(tp); return; /* * Conditionally drop with reset or just drop depending on whether * we think we are under attack or not. */ maybedropwithreset: -> #ifdef ICMP_BANDLIM -> if (badport_bandlim(1) < 0) -> goto drop; -> #endif /* fall through */ dropwithreset: #ifdef TCP_RESTRICT_RST if (restrict_rst) goto drop; #endif -- snip -- The parts starting with "->" show the ICMP response limiting code in TCP. > > In this case, someone may have > > been port scanning your machine and the kernel was eliciting RST's or ICMP > > unreachables in return to non-open ports, and at the rate it was being > > output it triggered ICMP response limiting. > > That's possible, true. Although if they have a semi-decent > firewall it shouldn't be allowing this type of port scanning activity. Of > course, he didn't think his firewall would let through ICMP either... I don't think you see the point, his firewall is not letting ICMP in, ICMP response limiting (this should be renamed) is kicking in as his machine is sending responses out to the offending machine. Please, re-read the kernel source/documentation before misinforming others. > Doug > -- +-------------------------------------------------------------------------+ | Omachonu Ogali oogali@intranova.net | | Intranova Networking Group http://tribune.intranova.net | | PGP Key ID: 0xBFE60839 | | PGP Fingerprint: C8 51 14 FD 2A 87 53 D1 E3 AA 12 12 01 93 BD 34 | +-------------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message