Date: Wed, 5 Apr 2000 16:58:41 -0400 (EDT) From: Omachonu Ogali <oogali@intranova.net> To: Doug Barton <Doug@gorean.org> Cc: Pete Fritchman <petef@binary.databits.net>, freebsd-questions@freebsd.org Subject: Re: icmp-response bandwidth limit question Message-ID: <Pine.BSF.4.10.10004051643410.31933-100000@hydrant.intranova.net> In-Reply-To: <Pine.BSF.4.21.0004051155540.24259-100000@dt051n0b.san.rr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10004051643410.31933-100000>