xinetd

[Kurt Wall]

Scribbling feverishly on May 05, M.W.Chang managed to emit:
> 
> with iptables, should we need to worry about the problems listed? should
> one replace inetd with xinetd?

IMNSHO, xinetd is a solution in search of a problem. The "expanded syntax"
opens up additional opportunities for bugs.
> 
> quoted from from linuxjournal (Mar 2001:
> 
> "... xinetd replaces the common inetd lines with bracketed, expanded
> syntax. In addition, new possibilities are given for logging and access
> control. While inetd allows control for TCP connections using Venema's
> tcp_wrappers software (tcpd), you cannot control UDP connections. Also,

The inetd on my box is capable of controlling UDP connections and, in
fact, IPv6 connections in both TCP and UDP flavors. That said, xinetd's
reputedly better logging capability is nice, although I'm of the opinion
that syslogd and klogd are the appropriate tools for enhancing logging,
since they were designed for that purpose.

> it doesn't do well with RPC (portmapper) type services. Additionally,

Inetd *does* have problems with RPC services, but RPC is one huge
playground of potential exploits, quite apart from anything that inetd or
xinetd can do.

> while you can control the rate of connections using inetd (by appending
> a number to the wait or no wait argument, for example, nowait.1 for one
> instance per second), you cannot control the maximum number of
> instances. This could lead to process table attacks, for example, an
> effective denial of service. By using xinetd, we can thwart this."

I'm not sure inetd or xinetd is the place to address this, although having
it as a backup to something more rigorous, like iptables, doesn't hurt.

Kurt
-- 
We really don't have any enemies.  It's just that some of our best
friends are trying to kill us.