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:
(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.