From owner-freebsd-net Wed Dec 13 11:29:51 2000 From owner-freebsd-net@FreeBSD.ORG Wed Dec 13 11:29:49 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9B09C37B400; Wed, 13 Dec 2000 11:29:49 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eBDJTZA29071; Wed, 13 Dec 2000 11:29:35 -0800 (PST) Date: Wed, 13 Dec 2000 11:29:35 -0800 From: Alfred Perlstein To: "Richard A. Steenbergen" Cc: Bosko Milekic , freebsd-net@FreeBSD.ORG, green@FreeBSD.ORG Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!) Message-ID: <20001213112935.K16205@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ras@e-gerbil.net on Wed, Dec 13, 2000 at 02:16:53PM -0500 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Richard A. Steenbergen [001213 11:17] wrote: > On Wed, 13 Dec 2000, Bosko Milekic wrote: > > > Suppressing udp flood/scan: 212/200 pps > > Suppressing outgoing RST due to port scan: 202/200 pps > > Suppressing outgoing RST due to ACK flood: 19725/200 pps > > Suppressing ping flood: 230/200 pps > > Suppressing icmp tstamp flood: 210/200 pps > > > > While the descriptions for the two RST cases can be accused > > of oversimplification, they should cut down on questions by > > users confused with the current terminology. Experienced > > users can always run a packet sniffer if they need more > > exact knowledge of what's occuring. > > I would be extremely careful with those descriptions... When you tell > people directly that something is an attack, even if its not, there are > enough who will jump to immediate conclusions and begin making false > accusations. While it may be highly likely that the reasons for those rate > limits is some kind of attack, it is not guaranteed, and I would be very > reluctant to so blatantly tell people that it is... > > Personally I'd recommend straight forward descriptions like "RST due to no > listening socket". I also see no compelling reason to put ICMP Timestamp > in a seperate queue, but what I would recommend is seperate queues for > ICMP messages which would be defined as "query/response" and those which > would be called "error" messages. If someone needs more specific > protection they can use dummynet. > > Just a thought... I think the word "possible" should be prepended to all of these messages. Now I have a weird question, I've seen the ICMP responce limit when getting pegged by a couple hundred hits per second on a port that isn't open by legimitimate connections. This would probably fall under: > > Suppressing outgoing RST due to port scan: 202/200 pps Which is untrue, it should read something like: Suppressing outgoing RST due to high rate of connections on an unopen port (possible portscan): 202/200 pps -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message