Date: Thu, 14 Dec 2000 04:15:53 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: "Richard A. Steenbergen" <ras@e-gerbil.net>, Alfred Perlstein <bright@wintelcom.net> Cc: Bosko Milekic <bmilekic@technokratis.com>, freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <200012141215.EAA25399@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.BSF.4.21.0012131432530.816-100000@overlord.e-gerbil.net> References: <Pine.BSF.4.21.0012131432530.816-100000@overlord.e-gerbil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 13, 2:42pm, "Richard A. Steenbergen" wrote: } Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) } On Wed, 13 Dec 2000, Alfred Perlstein wrote: } > Suppressing outgoing RST due to high rate of connections on an unopen } > port (possible portscan): 202/200 pps } } It could just as easily be a SYN flood against a single port... or a large } number of clients trying to connected to your crashed web server... :P Or } it could just as easily be an ack flood against a port without a listener } and be showing up in the "not the ack flood" counter. } } Attaching motives and trying to play intrusion detection pattern analysis } games without complete information is dangerous, and none of these } routines qualify as advanced enough to make any such determination. IMHO } break it down by "RST from ports with or without a listener" (or open } port, whatever floats the boat) and be done with it. The major goal of } this code would seem to be to provide simple but fairly useful protection } against common attacks out of the box, not to provide analysis of the } attacks (since no useful analysis can be performed without looking further } anyways). I think there are three interesting cases: RSTs resulting from SYN packets sent to non-listening ports. This could be a SYN flood, SYN scan, crashed web server with a lot of clients banging on it, etc. RSTs generated by other packets because there is no matching PCB This is probably an ACK flood or ACK scan. RSTs generated by the LAND DoS fixes. I think this really deserves it's now quota in order to prevent a LAND DoS attack from being sucessful just because we hit the RST limit. and maybe an "other" category. Since SYN and ACK floods tend to occur simultaneously, I would be inclined to combine these on one line to decrease the verbosity in the logs. The out of sequence and LAND fix RSTs are also related, the main difference being the socket state. Suppressing TCP RST: SYN to bad port 19999/200 pps, no PCB 19999/200 pps Suppressing TCP RST: SYN_RECEIVED sequence 19999/200 pps, other 19999/200 pps To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012141215.EAA25399>