inetd default behavior (was: FreeBSD 5.3-BETA6 available)
ma at dt.e-technik.uni-dortmund.de
Mon Sep 27 16:07:20 PDT 2004
Scott Long <scottl at FreeBSD.org> writes:
> I understand and appreciate that. That's why I asked how other OS's
> handle inetd.
Ideally, the default configuration would limit the number of clients to
some fixed figure, rather than limiting the number of connections.
The latter is ineffective to control resource in the general case
because it places no fixed upper limit and an attacker can run the
machine out of file descriptors or memory.
This is no news, Dan J. Bernstein, like him or not, has published this
problem in 2000 at http://cr.yp.to/docs/inetd.html already.
I'm not sure if this is a documentation issue or a configuration
issue. I originally filed this in the "conf" category but it has one
foot on the "docs" camp, too.
On one hand, I'd say that setting inetd_enable=YES shouldn't cause DoS
surprises, on the other hand I'm aware that there are so many options
that have an impact on the choice which service should allow how many
clients that it's impossible for the OS to offer a sensible
default. DJB's tcpserver (not open source) uses a client limit of 40
unless otherwise configured, xinetd does not impose client limits by
default but requires "instances=40" or similar configuration.
The inetd shipping with SuSE Linux is outright crap of the old kind,
allowing for 40 spawns per service per minute.
In a previous discussion it was mentioned that changing the default
might surprise users who run loaded services with many clients - so the
last chance to make incompatible changes before 6 becomes "stable" is
FreeBSD's inetd is among the better of its kind for its libwrap
integration and absolute client limiting capabilities but the latter is
not used in the default configuration but the unhelpful rate limiting.
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
More information about the freebsd-current