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 several 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 send
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 IBM i platforms:
SYSTEMA and SYSTEMB. A malicious programmer might 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 IBM i platform, 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 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 and
/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, they can 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.