Unlike most TCP/IP servers, the INETD server does not provide one
single service to clients.
The INETD server provides a variety of miscellaneous services that administrators
can customize. For that reason, the INETD server is sometimes called ″the
super server″. The INETD server has the following built-in services:
- Time
- Daytime
- Echo
- Discard
- Changed
These services are supported for both TCP and UDP. For UDP, the echo,
time, daytime, and changed services receive UDP packets, then send the packets
back to the originator. The echo server echoes back packets that it receives,
the time and daytime servers generate the time in a specific format and sends
it back, and the changed server generates a packet of printable ASCII characters
and sends it back.
The nature of these UDP services makes a system vulnerable to a denial
of service attack. For example, assume that you have two iSeries™ servers:
SYSTEMA and SYSTEMB. A malicious programmer could forge the IP header and
the UDP header with a source address of SYSTEMA and a UDP port number of the
time server. He can then send that packet to the time server on SYSTEMB, which
will send the time to SYSTEMA, which will respond back to SYSTEMB, and so
on, generating a continuous loop and consuming CPU resources on both systems,
as well as network bandwidth.
Therefore, you should consider the risk of such an attack on your iSeries system,
and only run these services on a secure network. The INETD server is shipped
to not be auto started when you start TCP/IP. You can configure whether or
not to start the services when INETD is started. By default, the TCP and UDP
time servers and daytime servers are both started when you start the INETD
server.
There are two configuration files for the INETD server: /QIBM/UserData/OS400/inetd/inetd.conf /QIBM/ProdData/OS400/inetd/inetd.conf
These files determine what programs start when the INETD server starts.
They also determine what user profile these programs are running under when
INETD starts them.
Note: The configuration file in proddata should never be
modified. It is replaced each time the system is reloaded. Customer configuration
changes should only be placed in the file, in the UserData directory tree,
as this file in not updated during release upgrades.
If a malicious
programmer got access to these files, she could configure them to start any
program when INETD started. Therefore it is very important to protect these
files. By default they require QSECOFR authority to make changes. You should
not reduce the authority required to access them.
Note: Do not modify the configuration
file in the ProdData directory. That file is replaced each time that the system
is reloaded. Customer configuration changes should only be placed in the file
in the UserData directory tree, as that file is not updated during release
upgrades.