 |
» |
|
|
|
When troubleshooting problems with the Internet Services,
you need a reference point to work from. For example, does the problem
exist on the remote system or on the local system? However, the
terms "local" and "remote" are
limited in their description of complex communications, such as
when a local system logs onto a remote system and then the remote
system logs back onto the local system. At that point, which is
the local system and which is the remote system? A better solution is to use the terms "client" and "server." The
term "client" refers to a process that is requesting
a service from another process. The term "server" refers
to a process or host that performs operations requested by local
or remote hosts that are running client processes. HP has implemented a "super-server" known
as the internet daemon, inetd. This program acts like a switchboard; that is,
it listens for any request and activates the appropriate server
based on the request. A typical network service consists of two co-operating programs.
The client program runs on the requesting system. The server program
runs on the system with which you want your system to communicate.
The client program initiates requests to communicate. The server
program accepts requests for communication. For example, the network
service rlogin is the client program that requests a login to
a remote HP-UX or UNIX system. When the request to log in is received
on the remote host by inetd, inetd invokes the server program for rlogin (called rlogind) to handle the service request. Error Messages | |
The error messages generated by a service as seen on the client
can be generated by the client or the server. Error messages from
the client occur before a connection is completely established.
Error messages from the server occur after a connection is completely
established. Whenever you receive an error message, follow the corrective
action supplied in the man page for that service. The error message
is preceded by the name of the service. Table 12-2 “Reference Pages for Error Messages” shows
the appropriate man page to consult for a description of the error
messages: Table 12-2 Reference Pages for Error Messages Service | Client | Server | telnet | telnet(1) | telnetd(1M) | ftp | ftp(1) | ftpd(1M) | rlogin | rlogin(1) | rlogind(1M) | remsh | remsh(1) | remshd(1M) | rcp | rcp(1) | remshd(1M) | ruptime | ruptime(1) | rwhod(1M) | rwho | rwho(1) | rwhod(1M) | ddfa | user application | ocd(1M) |
If the server or the client is not an HP 9000 computer,
refer to the appropriate user's manual or system administration
manual for that system. There is not a standard naming convention
for servers or processes that activate the servers; however, you
should be able to find the information in the system's
documentation. Services Checklist | |
Did you answer the questions in the
troubleshooting checklist at the beginning of this chapter? Run the service to your own node. To do this, your
node name and internet address must be in the /etc/hosts file. If the server is successful, then the client
and the server halves of the service operate correctly. This provides
a starting point to determine where problems are occurring.
Flowchart 1. Checking for a Server | |
Follow this flowchart for all services and servers, and replace
the words "service" and "server" with
the appropriate service name or server name. - 1A.
Assumptions. Before you begin Flowchart 1, you should have
verified local node operations and verified connectivity with ping (see the troubleshooting section of Installing
and Administering LAN/9000 Software). - 1B.
List current servers. List the servers currently
running on your system by executing the following: Table 12-3 “Servers Required for Each Service” lists the servers required for
each service.
Table 12-3 Servers Required for Each Service Local
Address | Client/Request | TCP
State | *.ftp | ftp | LISTEN | *.telnet | telnet | LISTEN | *.login | rlogin | LISTEN | *.shell | remsh, rcp | LISTEN | *.exec | rexec library | LISTEN | *.who | rwho, ruptime | | *.smtp | sendmail SMTP | LISTEN | *.tftp | tftp | LISTEN | *.bootps | bootpd | LISTEN | *.finger | fingerd | LISTEN |
Note that UDP-based protocols are datagram driven so they
do not show a TCP LISTEN status. - 1C.
Server exists for service? If the server does not
exist for the requested service, continue with 1D to determine why.
If the server does exist for the server, continue with 1C1. - 1C1.
Go to Flowchart 2. Go to the next flowchart to begin troubleshooting
the security of the Internet Services. - 1D.
Are files correct? Is there an entry for the servers
or services in the /etc/inetd.conf or /etc/services files? Table 12-4 “Entries Required in /etc/inetd.conf” lists the entries that are required
in the /etc/inetd.conf file.
Table 12-4 Entries Required in /etc/inetd.conf Service Requested | inetd.conf Entry | ftp | ftp stream tcp nowait root /usr/lbin/ftpd ftpd | telnet | telnet stream tcp nowait root /usr/lbin/telnetd telnetd | rlogin | login stream tcp nowait root /usr/lbin/rlogind rlogind | remsh, rcp | shell stream tcp nowait root /usr/lbin/remshd remshd | rexec library | exec stream tcp nowait root /usr/lbin/rexecd rexecd | tftp | tftp dgram udp nowait root /usr/lbin/tftpd tftpd | bootpd | bootps dgram udp wait root /usr/lbin/bootpd bootpd | fingerd | finger stream tcp nowait bin /usr/lbin/fingerd fingerd |
Check the permissions on the files in the /usr/lbin and /usr/sbin directories. The files ftpd, bootpd, telnetd, rlogind, remshd, rexecd, rwhod, and inetd must be owned and executable by root only. The
file fingerd should be owned and executed by bin only. No other user should have permission to
write them, although all users can read them. Table 12-5 “Entries Required in /etc/services” lists the entries that are required
in the /etc/services file.
Table 12-5 Entries Required in /etc/services Service
Requested | /etc/services Entry | | ftp | ftp 21/tcp | | telnet | telnet 23/tcp | | sendmail/SMTP | smtp 25/tcp | | rexec library | exec 512/tcp | | rlogin | login 513/tcp | | remsh and rcp | shell 514/tcp | | rwho and ruptime | who 513/tcp | | tftp | tftp 69/udp | | bootpd | bootps 67/udp and bootpc 68/udp | | fingerd | finger 79/tcp |
If the file entries or permissions are not correct, continue
with 1E. - 1D1.
Issue ps command to check for internet daemon. To see if
the inetd daemon is active on the server node, log in to
the server node and execute the following: - 1D2.
The ps command lists only the grep process for inetd? If the grep message is the only response, inetd is not active. If this is true, continue with
1D3. - 1D3.
Start internet daemon. To start inetd, execute the following as superuser: or, if you want to start connection logging, The /sbin/init.d/inetd shell script usually starts inetd at boot time. See Chapter 2 “Installing and Configuring Internet
Services”. - 1D4.
Go to 1B. Once inetd is running, repeat this flowchart beginning with
1B. - 1E.
Correct files. If there was an incorrect entry or
no entry in the /etc/inetd.conf or /etc/services files, enter the correct information and continue
with 1D1. - 1F.
Reconfigure the internet daemon. To reconfigure inetd, execute the following as superuser: and continue with 1G. - 1G.
Go to 1B. Repeat flowchart from 1B to check if the server
exists.
Flowchart 2. Security for telnet and ftp | |
Even though a server exists for a service, the server may
not accept connections due to the security that has been implemented
for the server. | | | |  | NOTE: The corrections suggested in 2B1, 2C1, and 2F1 must
be done by the superuser. Also, except for the "anonymous" user
ID, ftp requires non-null passwords on remote user accounts. | | | | |
- 2A.
Determine number of existing connections. If inetd was started with the -l option, the system log may list the number of
connections. If these messages do not appear in the system log,
continue with 2B, or enable the connection logging with inetd -l. - 2B.
Maximum number of connections? The maximum number
of simultaneous connections is specified in the optional file /var/adm/inetd.sec. When inetd is configured, it checks this file to determine
the number of allowable incoming connections. Look at this file
to determine how many connections are allowed. The default is 1000. - 2B1.
See node manager. If the maximum number of connections
has been reached, the node manager can change this value in the /var/adm/inetd.sec file. - 2C.
Access to the server? The /var/adm/inetd.sec file also contains a list of systems that may
not access the server. If inetd was started with the -l option, the system log may list the connections
that are refused access to the server. Check this log file, if it
exists, or ask the node manager to verify whether you have access
to the server. If you find that you do not have access to the server,
continue with 2D. - 2C1.
Using telnet or ftp? There are additional security files that exist
for these services that must be checked. If you are using ftp or telnet go to 2C2; otherwise, go to 2E. - 2C2.
Using ftp? Are you attempting to use ftp? If you are, go to 2C3; otherwise, go to 2F. - 2C3.
Access to ftp? If the user you are logging in as is listed in
the /etc/ftpusers file on the server system, you may not use ftp to that system. If you do not have access to ftp, go to 2G. - 2C4.
$HOME/.netrc file incorrect or non-existent? If this file is
incorrect or non-existent, it is not used for the connection attempt.
In particular, if the file exists, check its mode bits, owner ID,
and syntax. Type man 4 netrc for more information. If it is correct, go to
2H. - 2C5.
Fix $HOME/.netrc. If the file is incorrect, make corrections to
it and go to 2C6. - 2C6.
Once the corrections are made, repeat this flowchart beginning
with 2A. - 2D.
See node manager. If your system was denied access
to the server system by the /var/adm/inetd.sec file, but you wish to use the server, contact
the node manager of the server system and request access. - 2E.
Go to Flowchart 3. If you are using the Berkeley Services
(sendmail, BIND, finger, the rexec library, or any of the "r" services), go to Flowchart 3 to begin troubleshooting
the security for those services. - 2F.
telnet should work. If you have reached this point in the
flowchart, the telnet server exists and you have access to the system.
If you are using correct syntax, if the login password you are using
exists on the server system, and if none of the error messages have
solved the problem, report the problem to your Hewlett-Packard support
contact. - 2G.
See node manager. You are not allowed to use ftp to access the server system. Check with the node manager
of the server system and request that the appropriate user name
be removed from the /etc/ftupusers file. - 2H.
ftp should work. If you have reached this point in
the flowchart, the ftp server exists and you have access to the system.
If you are using correct syntax and none of the error messages have
solved the problem, report the problem to your Hewlett-Packard support
contact.
Flowchart 3. Security for Berkeley Services | |
This flowchart is for troubleshooting security for the Berkeley
Services: sendmail, BIND, finger, the rexec library, and those services that begin with "r". The following information assumes an
account has a password. If it does not, the security checks are
not performed. - 3A.
User name exists on server host? Does the user name that
you want to log in as exist on the server host? You can specify
another user's name by using the -1 option with rlogin. If the desired user name does not exist on the
server host, continue with 3B. - 3A1.
Accessing server system as yourself? If not, go
to 3D. - 3A2.
Are you superuser? If you are, go to 3D; otherwise continue
with 3C. - 3B.
Cannot access. Since your user name or the user
name that you want to use to log in does not exist on the remote
system, you cannot log in to the remote system unless the remote
system's node manager creates an account for you. - 3C.
Entry in server's /etc/hosts.equiv file? Does the server system have your official
host name entered in its /etc/hosts.equiv file? If so, you should be logged into the remote
system without a password prompt. If you can do this, continue with
3C1; otherwise go to 3D. - 3C1.
OK. If you are using the rlogin service, you are automatically logged in. If you
are using another Berkeley service, permission is granted for the operation. - 3D.
$HOME/.rhosts file exists and has entry for you? Does the user
name that you want to become on the server system have a .rhosts file in that user's $HOME directory? If it does, does it have your local
host and user name listed properly? If the $HOME/.rhosts file does not exist on the server system, or if
it does not have an entry for you, continue with 3E; otherwise continue
with 3C1. - 3E.
Using rlogin? If you are using the rlogin service go to 3E1. If you are not using rlogin, go to 3F. - 3E1.
Password prompt. You will receive a password prompt. Enter
the password for your remote user name. - 3F.
Permission denied. You do not have permission to access
the user's account. Ask the user to add your local host
and user name to his or her .rhosts file.
| | | | | NOTE: For C2 Security, refer to A Beginner's
Guide to HP-UX and the HP-UX System Security
Manual. | | | | |
|
