85 lines
5.3 KiB
HTML
85 lines
5.3 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
<!DOCTYPE html
|
||
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
<html lang="en-us" xml:lang="en-us">
|
||
|
<head>
|
||
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
<meta name="security" content="public" />
|
||
|
<meta name="Robots" content="index,follow" />
|
||
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
<meta name="DC.Type" content="concept" />
|
||
|
<meta name="DC.Title" content="Security considerations for INETD server" />
|
||
|
<meta name="abstract" content="Unlike most TCP/IP servers, the INETD server does not provide one single service to clients." />
|
||
|
<meta name="description" content="Unlike most TCP/IP servers, the INETD server does not provide one single service to clients." />
|
||
|
<meta name="DC.Relation" scheme="URI" content="rzamvtcpsetupsecurity.htm" />
|
||
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
||
|
<meta name="DC.Format" content="XHTML" />
|
||
|
<meta name="DC.Identifier" content="tcpinetd" />
|
||
|
<meta name="DC.Language" content="en-us" />
|
||
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
<!-- US Government Users Restricted Rights -->
|
||
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
<title>Security considerations for INETD server</title>
|
||
|
</head>
|
||
|
<body id="tcpinetd"><a name="tcpinetd"><!-- --></a>
|
||
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
<h1 class="topictitle1">Security considerations for INETD server</h1>
|
||
|
<div><p>Unlike most TCP/IP servers, the INETD server does not provide one
|
||
|
single service to clients. </p>
|
||
|
<div class="p">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:<ul><li>Time</li>
|
||
|
<li>Daytime</li>
|
||
|
<li>Echo</li>
|
||
|
<li>Discard</li>
|
||
|
<li>Changed</li>
|
||
|
</ul>
|
||
|
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. </div>
|
||
|
<p>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. </p>
|
||
|
<p>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.</p>
|
||
|
<p>There are two configuration files for the INETD server: <samp class="codeph">/QIBM/UserData/OS400/inetd/inetd.conf</samp> <samp class="codeph">/QIBM/ProdData/OS400/inetd/inetd.conf</samp></p>
|
||
|
<div class="p">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.<div class="note"><span class="notetitle">Note:</span> 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.</div>
|
||
|
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.<div class="note"><span class="notetitle">Note:</span> 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.</div>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div>
|
||
|
<div class="familylinks">
|
||
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvtcpsetupsecurity.htm" title="The following information guides you through the process of setting up TCP/IP security.">Set up TCP/IP security</a></div>
|
||
|
</div>
|
||
|
</div>
|
||
|
</body>
|
||
|
</html>
|