Re: How secure is inetd nowadays?

Some years ago (late '90s) I stopped using inetd, because there were
some
serious security issues. I think mainly around the portmapper, IIRC.
Anyway,

The main 'security issue' is the possibility of a user opening and holding open a large number of connections to a service, and the way
inetd and xinetd work.
Either
(a) There is no predefined limit to the number of instances, in this case, an attacker can open thousands of connections resulting in thousands of processes (possibly consuming excessive resources).

Or...
(b) There is a predefined limit of number connections per service, in
this case, an attacker can open that many connections, hold them open,
and no-one else can use that service (since all connection slots are consumed)


There are many ways of dealing with these types of problems.
Ideally there would be a physical firewall protecting against connection spam.

And no, xinetd won't necessarily save you, although it may provide you with some configuration options you can set that will help.

A standalone daemon (such as apache) is preferable in many ways;
forking a new process for each connection is not very scalable, except
for serving a fairly small number of connections.

Uh, inetd has been replaced by xinetd.

Not universally.

In certain ways, inetd is superior to xinetd, and preferable.

Configuration of a service running inetd is much simpler, and requires editing just one file, not digging to find a file, and (for most administrtors) checking the manual for the extensive syntax xinetd
requires to setup a new service.

inetd.conf syntax is more well known (been around for almost 20 years and is still used almost exclusively by Unix OSes) and easy to memorize; inetd.conf offers administrative convenience, which is a HUGE advantage over xinetd.

Xinetd seems like overkill in many cases.
It has a great number of features that provide _zero_ benefit for most installations, wereas inetd is simpler.

(Probably Xinetd's increased complexity makes it more likely to have
security issues crop up)


It is easy to create an inetd.conf service by hand.

It is also easier for hand-made scripts to parse and manipulate inetd.conf.



OTOH... It is easy to have a xinetd service created for you while installing a software package (Provided the installer takes care of it for you).

It is very much a pain to define a xinetd service by hand, compared to
the ease of a single inetd.conf line; you have many more options you need to consider to fully configure a service using xinetd.



Well this is a fine discussion, but could somebody please explain *why*
xinetd is so much safer than inetd?

Because editing a single configuration file of inconsistent, limited
and post-parsed format is prone to massive errors that will break
*all* the services. Under xinetd, each service has its own

If you do it correctly it won't. There's nothing really inconsistent about inetd.conf configuration...

In practice very few important services run from inetd (the rest are standalone servers), so inetd dying when you reload it, until you
can fix the config, isn't much of a concern.

configuration files and gets edited or managed separately. So
conflicts don't occur when two applications being installed try to
edit the same file at once.

/etc/inetd.conf should never be edited or created by any application, except initial installation by the inetd package that owns the file;
inetd.conf should only be edited by the system administrator.


Mere installation of an application does not mean the administrator is
ready to enable it yet.



The same argument about making packages play nice with each other
could be made to say /etc/passwd is bogus and should
be thrown out in favor of /etc/passwd.d and /etc/shadow.d
since sometimes applications might in theory want to have their own user...

shall we have...

/etc/passwd.d/123
user 123
{
disable = no
login username = myusername
login group id = 123
login shell = /bin/bash
login home directory = /home/myusername
login real name = blah blah
password = *
}


......
If it makes sense for inetd, then _every single_ config file should be done this way, otherwise it's definitely not consistent.

This is really just the argument that configuration in a registry-type structure is safer.

Then individual packages can own configuration objects...
Kind of like how it works in Windows.

When all is said and done, why not utilize a SINGLE database as the backend for all system configuration to recover performance lost (due to CPU time spent parsing the extended config files every time something needs to be done like say, auth'ing a user...)


Performing a query against a well-designed database beats ad-hoc
parsing of tons of extended specialized flatfiles...


--
-J
.

Relevant Pages

  • Re: allow and deny ih fedora 7
    ... network connections to the Internet. ... But in Fedora 7 by default there is neither inetd nor xinetd. ... The relevant software is called "tcp_wrappers". ...
    (comp.os.linux.security)
  • Re: 11 years of inetd default insecurity?
    ... we all blame Microsoft in insecure default configuration... ... With closer look we have good old inetd ... or allow an *infinite* number of connections to the port. ... If connection is closed by attacker before ...
    (Bugtraq)
  • Re: Secure Servers (SMTP, POP3, FTP)
    ... >> You can also run ftpd with xinetd. ... >> connections. ... >> secure than inetd. ... with "unsubscribe freebsd-security" in the body of the message ...
    (FreeBSD-Security)
  • Re: How to troubleshoot Telnet on Red Hat 8.0?
    ... > Connecting To 192.168.2.71...Could not open connection to the host ... inetd (or xinetd) configuration. ...
    (comp.os.linux.misc)
  • [UNIX] Xinetd Memory Leaks
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... A vulnerability in Xinetd allows remote attackers to cause the program to ... leak memory, by causing enough memory leakage a computer running Xinetd ... It created> 5000 connections in 1 second. ...
    (Securiteam)