From owner-freebsd-hackers Thu Jun 20 20:26:11 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 3513537B40F; Thu, 20 Jun 2002 20:26:09 -0700 (PDT) Received: from pool0544.cvx21-bradley.dialup.earthlink.net ([209.179.194.34] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LF3m-00067x-00; Thu, 20 Jun 2002 20:26:07 -0700 Message-ID: <3D129CA8.EFADA4FF@mindspring.com> Date: Thu, 20 Jun 2002 20:25:28 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Giorgos Keramidas Cc: hackers@FreeBSD.org Subject: Re: Limiting clients per source IP address (ftpd, inetd, etc.) References: <20020621000924.GA2178@hades.hell.gr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Giorgos Keramidas wrote: > I've been thinking for quite some time to add per-client-IP limiting > to ftpd, and I had almost decided upon something like the following, > where each child of ftpd has two numbers associated with it. The > client IP address, and the PID of the ftpd child that serves it. The > hash at the beginning of the lists serves as a minor assistance in > splitting the 2^32 address space in smaller chunks so that we don't > end up with a singly linked list of a few thousand entries. Someone just did something similar for inetd (per IP per port). The more I think about this, and the fact that there is code growing to do basically the same thing in every program, the more I think that the code to do this needs to be centralized. I would prefer a divert to an administrative daemon approach, using ipfw rules and exisitng code. You could also do it in the kernel, or you could do it by adding a wrapper library for "accept" and "close", where the accounting on connections can be enforced. Putting this code into a seperate daemon, or even natd, makes a lot more sense to me than hacking up the kernel, or every network application ever written. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message