Tony Summers wrote:
>
> I have a grumble about INETD.

> It does not explain (except in passing) what the existing (internal)
> entries in the sample configuration files do.  I.e  Are these
> internal services optional or mandatory  ? and what are the
> security risks associated with these internal services ?.

The sample that ships with 5.5 is (slightly edited):

> # Internet server configuration database
> #
> echo         stream tcp nowait MANAGER.SYS internal
> echo         dgram  udp nowait MANAGER.SYS internal
> daytime      stream tcp nowait MANAGER.SYS internal
> daytime      dgram  udp nowait MANAGER.SYS internal
> time         stream tcp nowait MANAGER.SYS internal
> time         dgram  udp nowait MANAGER.SYS internal
> discard      stream tcp nowait MANAGER.SYS internal
> discard      dgram  udp nowait MANAGER.SYS internal
> chargen      stream tcp nowait MANAGER.SYS internal
> chargen      dgram  udp nowait MANAGER.SYS internal
> #telnet       stream tcp nowait MANAGER.SYS internal
> #bootps       dgram  udp wait   MANAGER.SYS /SYS/NET/BOOTPD bootpd
> #tftp         dgram  udp wait   USER.TFTP /SYS/NET/TFTPD tftpd

All that is needed for telnet is to uncomment (remove the "#") from the
telnet line.  As for the others:

echo does just that, any data sent to the echo port is sent back to the
originator.  discard likewise does just that, it accepts data from
anything the drops it in the bit bucket.  chargen generates an ASCII
stream of data until the connection is closed.  All 3 were originally
intended for debugging or checking connectivity at layer 4 (ping only
checks layer 3).

daytime gives you a human-readable timestamp, for example:
   Wed Jun 21 11:52:07 2000

time returns a binary timestamp (unix ctime() I think.

These services have been known to be abused for denial of service or
general horseplay, for example, spoofing packets to line a chargen port
to an echo port, or other weirdness.  It is generally recommended that
these services be turned OFF unless you have a designated need.

In addition to this configuration file, an often overlooked facility is
the /usr/adm/inetd.sec file, which should be symlinked to INETDSEC.NET
(or vice versa).  You can restrict access to any of your inetd services
by setting up the allowed network ranges for each service, preventing
arbitrary connections.

Jeff Kell <[log in to unmask]>




--
Jeff Kell <[log in to unmask]>