NetBSD Problem Report #18947

Received: (qmail 25449 invoked by uid 605); 5 Nov 2002 23:22:18 -0000
Message-Id: <200211052321.gA5NLNN03529@uberhost.home>
Date: Wed, 6 Nov 2002 00:21:23 +0100 (CET)
From: tecneeq@gmx.net
Sender: gnats-bugs-owner@netbsd.org
Reply-To: tecneeq@gmx.net
To: gnats-bugs@gnats.netbsd.org
Subject: ftpd lacks a per host limit
X-Send-Pr-Version: 3.95

>Number:         18947
>Category:       misc
>Synopsis:       ftpd lacks a per host limit of simultaneous connections
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 05 23:23:00 +0000 2002
>Closed-Date:    
>Last-Modified:  Mon Mar 15 04:50:02 +0000 2010
>Originator:     Karsten Kruse
>Release:        NetBSD 1.6_STABLE
>Organization:

>Environment:


System: NetBSD uberhost 1.6_STABLE NetBSD 1.6_STABLE (uberhost) #3: Sun Nov 3 12:08:57 CET 2002 karsten@uberhost:/usr/src/sys/arch/i386/compile/uberhost i386
Architecture: i386
Machine: i386
>Description:

  NetBSD's ftpd lacks a per limit of simultneuous connections. For example
  something like this in /etc/ftpd.conf:

    # limitperhost   class   simultaneous-connections
    limitperhost     anons   1

  For class anons allow only one connections per host. This would also
  be a small protection against simple DoS.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
From: matthew sporleder <msporleder@gmail.com>
To: gnats-bugs@netbsd.org, gnats-admin@netbsd.org
Cc: 
Subject: Re: misc/18947
Date: Mon, 22 Feb 2010 08:50:54 -0500

 ftpd does have the limit directive.  Does that do what you're asking?

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 28 Feb 2010 22:11:03 +0000
State-Changed-Why:
A question was asked.


From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
 connections)
Date: Sun, 28 Feb 2010 21:16:08 -0500

 On Sun, 28 Feb 2010 22:11:04 +0000 (UTC)
 dholland@NetBSD.org wrote:

 > Synopsis: ftpd lacks a per host limit of simultaneous connections
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: dholland@NetBSD.org
 > State-Changed-When: Sun, 28 Feb 2010 22:11:03 +0000
 > State-Changed-Why:
 > A question was asked.

 Further question:

 I assume that this PR is about the lack of per-address limits?  The
 current LIMIT option allows to limit the number of total connections
 allowed for a particular user class, but does not limit the amount of
 concurrent connections per user or per address.
 -- 
 Matt

From: Karsten Kruse <tecneeq@tecneeq.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous connections)
Date: Sun, 14 Mar 2010 17:43:49 +0100

 Am 01.03.2010 03:20, schrieb Matthew Mondor:

 >   I assume that this PR is about the lack of per-address limits?

 Yes, that's what i meant. A single ip could use all possible connections 
 for a userclass. Wich in fact is what happens with some of the more 
 aggressive ftp-clients. They often open 4, 6, 8 or even more connections 
 to get a file (or rather parts of it). This isn't meant to harm, but it 
 does.

 Imagine Joe Greedy would open 30 anon connections to get a single file, 
 and you have 30 connections as a limit in the anon userclass. Nobody 
 else in his class could get files. A per host limit should solve that.

 Something like ,,Allow only 5 anon class connections from a single ip''.

 Karsten

 -- 

    ()    Impassivity is a state of indifference or apathy demonstrated
   <\/>   by the absence or suppression of emotional reactions such as
   _/\_   concern, excitement, motivation and passion.

State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 14 Mar 2010 19:53:49 +0000
State-Changed-Why:
feedback received.


From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
 connections)
Date: Sun, 14 Mar 2010 17:24:59 -0400

 Since I implemented such a limit system on a few daemons in the past, I
 took a brief look at the ftpd code.

 In the code I previously adapted to support such limits, only daemon
 mode was supported and as such it was easy to use a global shared hash
 table in a MAP_ANON region along with flock(2).  Other cases were
 multithreaded so it was even easier.

 Allowing inetd introduces performance penalties and complexity for this
 scenario, I think.  From what I see, the current per-class connections
 limits is calculated via count_users() which actually uses a file of
 PIDs.

 Following a similar route, I guess that it'd be possible (and
 simplest), to implement per-address limits using a file as well, using
 dbopen(3)/hash(3) to store per-address information such as a
 connection/refcount.  Alternatively, instead of only storing the pid_t
 in the pids file, it'd be possible to store pid_t+address but running
 through the set testing for every match would be suboptimal.

 Other alternatives would be using a second mmap(2)d shared file
 implementing a hash table, or sysvipc, but I doubt that this would
 really be better than bdb for real use, and it would be more complex to
 implement, some code actually duplicating what bdb might be doing.

 Apart from chosing the way this hash table should be stored and
 accessed, since ftpd supports several address families, I think that
 some address-family specific code will have to be used, because the
 address size is different for each family, and this is what we should
 be hashing.  It'd also be possible to serialize the address to string
 before hashing using inet_ntop(3) or equivalent, costing a few more
 cycles...

 In a better world, it'd probably be possible to adapt all local daemons
 to support such policies by sharing a lightweight database daemon
 replacing or supplementing utmp and allowing sophisticated and
 efficient user WHO queries, internally using a library with a decent C
 API to also do queries from C... :)  But we don't currenty have this.
 -- 
 Matt

From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous connections)
Date: Sun, 14 Mar 2010 18:07:46 -0400

 Matthew Mondor wrote:

 >  In a better world, it'd probably be possible to adapt all local daemons
 >  to support such policies by sharing a lightweight database daemon
 >  replacing or supplementing utmp and allowing sophisticated and
 >  efficient user WHO queries, internally using a library with a decent C
 >  API to also do queries from C... :)  But we don't currenty have this.

 Right, you want each program to have the ability to export events along
 with some data so that everything that happens on a system/network/etc.
 can be correlated and acted upon in a centralized way. It's an easy way
 to construct a big picture of what exactly is going on.

 Lacking such a mechanism, however, here's the cleanest way to "fix" such
 problems:

 	http://www.openbsd.org/faq/pf/filter.html

 (See, e.g., "Stateful Tracking Options.")

 This PR should be closed.

 -e.

From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
 connections)
Date: Sun, 14 Mar 2010 18:39:21 -0400

 On Sun, 14 Mar 2010 22:10:09 +0000 (UTC)
 Elad Efrat <elad@NetBSD.org> wrote:

 >  Right, you want each program to have the ability to export events along
 >  with some data so that everything that happens on a system/network/etc.
 >  can be correlated and acted upon in a centralized way. It's an easy way
 >  to construct a big picture of what exactly is going on.
 >  
 >  Lacking such a mechanism, however, here's the cleanest way to "fix" such
 >  problems:
 >  
 >  	http://www.openbsd.org/faq/pf/filter.html
 >  
 >  (See, e.g., "Stateful Tracking Options.")
 >  
 >  This PR should be closed.

 I know that pf can do this, but I don't personally think that because a
 firewall supports this option a daemon shouldn't be able to...  Of
 course, if the original poster doesn't mind and wants the PR closed, I
 won't argue however, as I'm not personally using the in-base ftpd (my
 ftpd supports such limits).
 -- 
 Matt

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
	connections)
Date: Mon, 15 Mar 2010 04:05:19 +0000

 On Sun, Mar 14, 2010 at 10:10:09PM +0000, Elad Efrat wrote:
  >  Lacking such a mechanism, however, here's the cleanest way to "fix" such
  >  problems:
  >  
  >  	http://www.openbsd.org/faq/pf/filter.html
  >  
  >  (See, e.g., "Stateful Tracking Options.")
  >  
  >  This PR should be closed.

 I don't think that's the right long-term answer.

 inetd already has connection rate limiting; why shouldn't it get a bit
 smarter?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous connections)
Date: Mon, 15 Mar 2010 00:44:55 -0400

 David Holland wrote:
 > The following reply was made to PR misc/18947; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: misc/18947 (ftpd lacks a per host limit of simultaneous
 > 	connections)
 > Date: Mon, 15 Mar 2010 04:05:19 +0000
 > 
 >  On Sun, Mar 14, 2010 at 10:10:09PM +0000, Elad Efrat wrote:
 >   >  Lacking such a mechanism, however, here's the cleanest way to "fix" such
 >   >  problems:
 >   >  
 >   >  	http://www.openbsd.org/faq/pf/filter.html
 >   >  
 >   >  (See, e.g., "Stateful Tracking Options.")
 >   >  
 >   >  This PR should be closed.
 >  
 >  I don't think that's the right long-term answer.
 >  
 >  inetd already has connection rate limiting; why shouldn't it get a bit
 >  smarter?

 Using inetd to do it falls in the same category as using pf to do it (as
 both lack application context, e.g. username), only that it's much
 worse, of course, as it requires someone -- whom I suspect isn't going
 to be you -- to write code that already exists and is actively
 maintained elsewhere.

 -e.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.