Anne Carasik <[EMAIL PROTECTED]> writes:

>> The question of what to do with these ports comes up every once in a
>> while on this list. Some people prefer to leave them on, others turn
>> them off. I don't think there's ever been an exploit that involves these
>> ports, as the code is quite simple (i.e. easy to implement securely).
>
> Occasionally, there may be a DOS attack, but nothing invasive.

Depends. I thought it was an old trick to persuade echo ports to talk to
each other and run away giggling...

>> Yes, this is good advice, and something that never occurs to most
>> people. Most common services these days run quite happily in standalone
>> mode, so there's often no reason to use inetd at all.
>
> Given most everything can run through SSH or SSL (at least TCP-based) :)

The short reasons in favour of inetd are that

a) you save memory space by not having the daemon running all the time (at
the slight cost of latency on start-up - choose according to your
situation!);

b) (if using xinetd instead of boring old inetd) you can apply the same
syntax for per-host rate- and resource-limiting to many services that would
otherwise either require much research to implement (try exim and apache
for size), or not even implement it at all; 

c) if you're writing a network listener of your own you can implement it in
(x)inetd without having to worry about writing the regular listen-accept-
process loop *again*.

Not that it's *always* a good idea to use inetd, but it still has its plus-
points by a long way, especially xinetd instead.

~Tim
-- 
<http://spodzone.org.uk/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to