Chapter 3: Administering TCP/IP

Table of contents

Chapter 3

Administering TCP/IP

To properly administer TCP/IP, you must have a basic understanding of the various protocols that make up the TCP/IP suite, as well as TCP/IP daemons and database files. These topics are covered in ``TCP/IP''. After you configure the TCP/IP protocol stack, you are ready to administer TCP/IP. Administration consists of:

For information on tuning your system for increased TCP/IP performance, refer to ``Tuning TCP/IP performance'' in the Performance Guide.

Configuring TCP/IP client services

The Client Manager allows you to set up a host as a client of several TCP/IP networking services. With the Client Manager, you can:

The Client Manager also provides a graphical interface to the following networking tools: finger, nslookup, ping, traceroute, and whois.

See also:

The Client Manager interface

Start the Network Configuration Manager in any of these ways: 

For more information on using SCOadmin managers, see ``Administering your system with SCOadmin'' in the SCO OpenServer Handbook.

For convenience, the Client Manager displays the hostname and Internet domain name for the host being configured.

Configuring a DNS client

To configure a DNS client using the Client Manager:

  1. If the host is not already configured as a DNS client, select Services → Add → DNS.

    If the host is already configured as a DNS client, click on DNS Client in the services listed, and then select Services → Modify.

  2. Enter the following details for the host:

    Local domain
    The fully qualified name for the domain that the host is in, for example, mynet.COM. If you do not specify a domain search order, the domain name will be appended when looking up a name which does not contain a dot.

    Domain search order
    Enter a list of up to six domains that you want DNS to search if you specify a hostname without appending a domain name. For each domain you enter, click on Add to add it to the list. You should normally include the local domain in this list. DNS will search the domains for a hostname in the order that you specify them in the list.

    To change the position of a selected item in the list, click on Promote or Demote.

    Name server search order
    Enter a list of up to three DNS name servers, specified by their IP addresses, that the client can query. For each name server you enter, click on Add to add it to the list. If the host you are configuring is itself already configured as a DNS name server, place it at the top of the list by specifying it first using the loopback IP address (127.0.0.1). The resolver will query each name server in the order that you specify them in the list until it gets an answer.

    To change the position of a selected item in the list, click on Promote or Demote.

  3. Click on OK to exit.

NOTE: This procedure modifies the file /etc/resolv.conf. If the file does not exist, the Client Manager creates it upon exit when DNS client configuration values are entered. See resolv.conf(SFF) for a description of the format of this file.

Configuring the /etc/hosts file

To configure name service on a client using the /etc/hosts file:

  1. If the /etc/hosts file does not already exist, select Services → Add → Hosts database in the Client Manager.

    If the /etc/hosts file does already exist, click on /etc/hosts file in the services listed in the Client Manager, and then select Services → Modify.

  2. To add an entry to the /etc/hosts file, click on Add, enter the IP address, hostname, and any alias names, then click on OK.

    To modify an entry in the /etc/hosts file, click on it in the list to select it, and then click on Modify. Click on OK to save your changes.

    To delete an entry in the /etc/hosts file, click on it in the list to select it, and then click on Delete.

  3. Click on OK to exit.

NOTE: This procedure modifies the file /etc/hosts. See hosts(SFF) for a description of the format of this file.

Entries for the host, including the loopback address, cannot be modified to prevent accidental deletion.

Configuring a default route

To configure a default route using the Client Manager:

  1. If a default route is not already configured, select Services → Add → Default route.

    If a default route is already configured, click on Default route in the services listed, and then select Services → Modify.

    To delete a default route, click on Default route in the services listed, and then select Services → Delete.

  2. Enter the IP address of the gateway system (that is, the system to which network traffic is sent if your host does not have an explicit route for that traffic) providing the default route in the Gateway Address field.

    Enter any desired initial values for route metrics in the Default Route Options field. Available metrics are listed in the routed(ADMN) manual page, and must be entered as keyword and value inside double-quotes. For example:

    "-hopcount 1 -mtu 1500"

    Default route options can only be entered if a gateway address exists. It is not required to set default route options; if none are specified, no metrics are applied to the default route.

  3. If the new default route configuration differs from the current runtime environment (that is, from values specified in /etc/default/tcp or set with the route command), you will be prompted to sychronize the new default values.

    In the Sync Route Info? screen, click on OK for the new default route to take effect when the Client Manager exits; click on Cancel for changes to take effect at the next TCP/IP restart.

    NOTE: Selecting the Add, Modify or Delete operations can result in the tcp(SFF) default configuration file (/etc/default/tcp) being out of synch with the current runtime environment.

    The runtime default route is not sychronized until the Client Manager exits.

  4. Click on OK to exit default route configuration.

See also:

Configuring name service resolution order

To configure the order of the name services that a client will use for resolving domain names and IP addresses:

  1. Select Services → Name resolution order in the Client Manager.

  2. Select a service from the Available services list, and click on Add to add it to the Configured services list.

    To remove a configured service, select it from the Configured services list, and click on Remove.

  3. The list of configured services is in the order in which they will be tried when a client tries to resolve a hostname or IP address. If necessary, use Promote and Demote to change the order of the services. The default order is NIS, /etc/hosts, and DNS.

  4. Click on OK to exit.

NOTE: This procedure modifies the file /etc/resolv.conf. If the file does not exist, the Client Manager creates it upon exit when name service resolution order values are entered. See resolv.conf(SFF) for a description of the format of this file.

Some client applications may choose to ignore the specified order, and use their preferred method for name resolution instead.

Configuring an NTP client

To configure an NTP client using the Client Manager:

  1. If the host is not already configured as an NTP client, select Services → Add → NTP.

    If the host is already configured as an NTP client, click on NTP client in the services listed, and then select Services → Modify.

  2. Select how you want the client to behave:

    Listen for time broadcasts
    The client will listen passively for, and attempt to synchronize with, NTP packets being broadcast by time servers on the local network.

    Poll time servers for time
    The client will actively poll the listed time servers for the time, and attempt to synchronize with them.

    Enter the IP addresses or hostnames of each time server, and click on Add to add it to the list.

    Set clock at boot time
    If set to Yes, the client will attempt to synchronize its clock at boot time with the listed time servers. This is a ``step'' change rather than a gradual ``slewed'' change. If set to No, the client will not attempt to synchronize its clock at boot time.

  3. Click on OK to exit.

NOTE: This procedure modifies the /etc/ntp.conf file. See ntpd(ADMN) for a description of the format of this file.

Deleting a client service

To remove the configuration for a service using the Client Manager:

  1. Click on the service to be removed from those listed, and then select Services → Delete.

  2. Click on OK to confirm.

NOTE: It is not possible to remove the /etc/hosts file using the Client Manager. This is to prevent accidental deletion of the host's loopback address.

Using network tools

The Client Manager provides a graphical interface to the following commands:



Finding information about a user

To find out more information about a user:

  1. Select Tools → Finger in the Client Manager.

  2. Enter the name of the user and click on Finger. To interrupt the query, click on Stop.

  3. Click on Close to exit.

See also:



Looking up a hostname or an IP address

To look up the IP address corresponding to a hostname, or the hostname corresponding to an IP address:

  1. Select Tools → Host lookup in the Client Manager.

  2. Enter the hostname or IP address of the host and click on Query. To interrupt the query, click on Stop.

  3. Click on Close to exit.

See also:



Pinging other network hosts

To see if another network host is alive:

  1. Select Tools → Ping in the Client Manager.

  2. Enter the hostname or IP address of the host.

  3. To change the interval in seconds between packets or the number of packets that will be sent, click on Options, change the default values and click on OK.

  4. Click on Ping to start sending packets. To interrupt the sending of packets, click on Stop.

  5. Click on Close to exit.

See also:



Tracing the route taken by network packets

To trace the route that network packets take to reach a host:

  1. Select Tools → Trace route in the Client Manager.

  2. Enter the hostname or IP address of the host.

  3. To set various trace options, click on Options. To change the maximum time in seconds that your host will wait for a response, or to set the maximum number of hops before the trace will be terminated, click on Options, change the default values, and click on OK.

  4. Click on Trace to start the trace. To interrupt the trace, click on Stop.

  5. Click on Close to exit.

See also:



Looking up a name in the Internet domain name directory service

To find out more information about a domain, nameserver, or registrar that has an entry in the Internet domain name directory service:

  1. Select Tools → Whois in the Client Manager.

  2. Enter the name you wish to search.

  3. To change the whois server (default is rs.internic.net), click on Options, enter the new server name, and click on OK.

  4. Click on Query to start the query. To interrupt the query, click on Stop.

  5. Click on Close to exit.

See also:

Setting interface parameters

All network interface drivers, including the loopback interface, require that their host addresses be defined at boot time. This is done with ifconfig(ADMN) commands included in the /etc/tcp shell script. These commands are initially set up based on information you supply during the installation, or during configuration with the Network Configuration Manager.

ifconfig(ADMN) also sets the netmask, broadcast address, and IP address at boot time. You can change any of this information: 

Using the Network Configuration Manager, while intuitive, can take longer than editing the file, especially when you are:

To edit /etc/tcp:

  1. Log onto the system as root.

  2. Make a backup of /etc/tcp: 

    cp /etc/tcp /etc/tcp.00

  3. Edit /etc/tcp to include the desired information on lines beginning with ifconfig.

  4. Shut the system down and reboot it by using the System Shutdown Manager as described in the SCO OpenServer Handbook. Remember to select Reboot after shutdown when using the manager.

  5. After the system reboots and returns to multiuser mode, test TCP/IP by using ping(ADMN) to contact another host.

Creating subnets

In TCP/IP, the DARPA Internet support includes the concept of the subnet, sometimes called a subnetwork. This is a mechanism that enables several local networks to appear as a single Internet network to off-site hosts. You should consider using subnets in the following instances: 

Setting up a subnet consists of:

To set up subnet addresses, you must use a segment of the host portion of the IP address to use as the subnet address. For example, consider the following IP addresses and netmasks:


For class A and B networks, you can create subnets by converting the second and third octets, respectively, from host addresses to subnet addresses. Notice how the netmask changes accordingly:

The class A network 16 can now have up to 254 subnets (16.1 - 16.254). The class B network 10.0 can also have up to 254 subnets (10.0.1 - 10.0.254). While the netmask masks the network portion of the address, the broadcast address exposes the network address and hides the host portion. For example, the broadcast address for the subnet 10.0.246, with a netmask of 255.255.255.0, is 10.0.246.255.

NOTE: The subnet portion of the network address cannot consist of all binary zeros (0) or ones (255). See RFC 950 for more information.

For more information on setting netmask and broadcast addresses, see Appendix A, ``Configuration parameters'' in Configuring Network Connections.

Partitioning a class C address is slightly more complex, as you must take a portion of the fourth octet as the subnetwork. For example, you might partition the first three (high order) bits of the fourth octet to represent the subnetwork, with the last five bits representing the host:

This scheme allows for up to 6 subnets of 30 hosts each, for a total of 180 hosts. The netmask for the hosts on these subnets is 255.255.255.224; 224 is a decimal representation of the binary octet 11100000, which masks the subnet portion of the IP address.

Possible subnets for the class C network 221.138.62.0, with associated broadcast addresses, are: 

 ----------------------------------------------------
 Subnet           Hosts       Broadcast address
 ----------------------------------------------------
 221.138.62.32    .33-.62     221.138.62.63
 221.138.62.64    .65-.94     221.138.62.95
 221.138.62.96    .97-.126    221.138.62.127
 221.138.62.128   .129-.158   221.138.62.159
 221.138.62.160   .161-.190   221.138.62.191
 221.138.62.192   .193-.222   221.138.62.223
After you determine the new addresses for your hosts, you must configure them with the Network Configuration Manager or by editing /etc/tcp. In addition, you must configure gateways between your subnets: these are hosts with multiple networking cards that serve more than one network.

Establishing user equivalence

User equivalence allows a user to use rlogin to log in to an equivalent account on another host without entering a password. SCOadmin managers require this equivalence to allow you to manage other systems over the network. You can establish user equivalence between:

NOTE: Entries in /etc/hosts.equiv can create large holes in system security. Be sparing in their use. In most circumstances, it is unwise to create entries that allow all users on remote hosts to access all accounts on your local host.

If there are entries in both .rhosts and /etc/hosts.equiv for the same host or host/account combination, then the entry from /etc/hosts.equiv determines the extent of user equivalence. For more information, see the manual page for rhosts(SFF).

The User Equivalence Manager interface

You can start the User Equivalence Manager in any of these ways:

For more information on using SCOadmin managers, see ``Administering your system with SCOadmin'' in the SCO OpenServer Handbook.

The User Equivalence Manager's top level and menus are illustrated here:

With the User Equivalence Manager, you can:


When you run the User Equivalence Manager as root, you by default edit root's user equivalence. To edit the equivalence of another user, select Open from the File menu and choose another user to edit.

You can also perform each of these tasks manually. See the manual page for rhosts(SFF) for more information.

Opening another user's equivalence file

Only root can open another user's equivalence file. To do so in the User Equivalence Manager:

  1. Choose Open from the File menu. A list of user names appears.

  2. Select a user in one of two ways:

    To limit the list to those users matching a certain pattern, enter the pattern (including wildcard characters) in the ``Filter'' field, then click on Filter. You can then make your selection from the list and click on OK.

After opening another user's equivalence file, you can add or delete equivalences for that user.

Adding user equivalence

In the User Equivalence Manager:

  1. Select Add Equivalence from the User menu, or click on the add a new equivalence entry toolbar button.

  2. Enter the host name of the remote host. To select a host from a list of networked hosts, click on the Select button. This may take up to a minute on a network with many hosts.

  3. Enter a user name.

  4. Click on the OK button.

  5. Continue adding equivalences by repeating steps 1 through 4.

  6. When you are finished, select Save from the File menu. If you do not save the file, either now or when leaving the User Equivalence Manager, the additions you make are not saved.

Selecting another host while adding equivalence

You specify a remote host when adding user equivalence. To select a host name from a list of available networked hosts:

  1. Click on the Select button On the Add a user window.

  2. Select a host name by one of the following means:

    To limit the list to those hosts matching a certain pattern, enter the pattern (including wildcard characters) in the ``Filter'' field, then click on Filter. You can then make your selection from the list and click on OK.

You can sort the list by name or address. To do so, click on the appropriate radio button.

Deleting user equivalence

In the User Equivalence Manager:

  1. Select the equivalence you want to delete from the list.

  2. Select Delete equivalence from the User menu, or click on the delete the selected equivalence entry toolbar button.

  3. When prompted, click on Yes to confirm the deletion.

  4. Repeat steps 1 through 3 for each equivalence you want to delete.

  5. When done deleting equivalences, select Save from the File menu. If you do not save the file, either now or when prompted by the User Equivalence Manager, the deletions you make are not saved.

Using the Secure TCP (Kerberized) utilities

This release includes Secure TCP versions (providing Kerberos Version 5 authentication) of the following client utilities and server daemons: 

 ---------------------------------------------------------------
 Client utilities           Server daemon
 ---------------------------------------------------------------
 ftp(TC)                    ftpd(ADMN)
 rcmd(TC) and rcp(TC)       rshd(ADMN)
 rlogin(TC)                 rlogind(ADMN)
 telnet(TC)                 telnetd(ADMN)
You can use these utilities and daemons in a Kerberos Version 5 realm or DCE cell to provide authenticated TCP/IP services as described below.

NOTE: You cannot use the Kerberos authentication features of these utilities unless you have a Kerberos Version 5 Security Server such as the SCO Security Services (supplied with the SCO Distributed Services Release 1.0.3). The utilities will function without providing Kerberos authentication if you do not have such a server.

Configuring the Secure TCP utilities

To use these utilities with Kerberos Version 5 authentication, you must first define the users (interactive principals) and host systems (machine principals) on the Security Server(s) for the Kerberos realm or DCE cell where they are to operate:

  1. If you are using SCO Security Services, the cell administrator (authentication principal) must use the SCO Distributed Administration Service Security Manager or rgy_edit to add a registry object for each interactive and machine principal to /.:/sec/principal in the local cell. See the secadmin(ADMD) and rgy_edit(8sec) manual pages for more information. Machine principals must be added to the host subhierarchy. For example, the machine principal corresponding to the host foo in the domain bar.com would be:

    /.:/sec/principal/host/foo.bar.com

    Interactive principals may be added directly to the /.:/sec/principal hierarchy. Create passwords in the account properties of all new principals.

  2. On each host where Secure TCP utilities or daemons are to be run, log in as root and run the auth.config(ADMN) command.

  3. Use auth.config to define the DCE cell (or Kerberos realm) and fully qualified domain name of the Security Server that will be used to authenticate service requests. When asked for a host password for Secure TCP services, you can select a machine-generated password as you do not need to remember this password.

  4. Use auth.config to choose the level of authentication required for access to the ftpd, rshd, rlogind and telnetd daemons. You can select to make authentication optional if some users require traditional unauthenticated access.

  5. If users are required to use authenticated access, the access control file, .k5login (see k5login(SFF)), must exist in their home directories on the machine where the server daemon is running. This file contains the names and cells of principals that can access an account. For example, the entry ``chuck@local_cell'' specifies that the principal chuck in the cell (or realm) local_cell has access. Only the owner must have write permission on .k5login, and the owner must either be root or the user associated with the home directory.

Obtaining Kerberos session credentials

Before a user can use the Secure TCP utilities, they must obtain Kerberos session credentials. Because the current versions of login(M) and scologin(XC) do not support Kerberos authenticated login, there are two alternative methods by which a user may obtain these credentials:



Obtaining session credentials using kinit

Log in locally using unauthenticated login and then obtain session credentials using kinit(TC). The kinit command will authenticate the user's session with the Security Server and obtain a Ticket Granting Ticket for the user's session provided the user can supply the correct password for their interactive principal name. To monitor their credentials, the user must run the ksession(TC) command which will warn when the credentials are about to expire. The user can also use the klist(TC) command to view their credentials and their expiry date.

WARNING: If a user performs an authenticated connection to another host (gamma) from a host (beta) to which they already connected remotely from a machine (alpha), their password will be transmitted in clear text across the network from alpha to beta.



Obtaining session credentials using ktadd and kinit

To avoid the possibility that passwords can be transmitted in clear text, root can use the ktadd(ADMN) command to create user keys on the various machines that different users are allowed to access. Alternatively a user can use ktadd to create a user key on each of the machines that they need to use.

WARNING: You should only invoke ktadd(ADMN) on the system to which you are directly logged in. This is to prevent passwords being passed in clear text across the network.

For example, to obtain a user key for the interactive principal chuck with password ``clydenw'' for the cell local_cell, enter the following commands:

ktadd -p chuck@local_cell -pw clydenw -f ~chuck/.v5srvtab
chmod 600 ~chuck/.v5srvtab

This creates a private key table .v5srvtab for chuck in their home directory and changes its permissions so only chuck and root can read from or write to this file. (Note that this example assumes that the shell being used is either ksh or csh.)

To use their private key table when obtaining session credentials, the user calls kinit from their .profile or .login file. This example also shows ksession being run to monitor chuck's credentials:

kinit -k -t ~chuck/.v5srvtab
ksession

For more information about using the SCO Security Services, see the SCO Security Services Release and Installation Notes. For more information about using the SCO DCE Executive, see the SCO DCE Executive Release and Installation Notes.

Protecting against IP address spoofing attacks

A random element has been introduced into how TCP chooses the initial send sequence number and its increment. This feature helps protect system from IP address attacks (also known as ``IP spoofing''). You can use inconfig(ADMN) to seed the random number sequence by setting the value of the TCP/IP parameter, tcp_secret. The value of tcp_secret can be set to any integer from 0 through 2147483647.

Another parameter, tcp_seqbits, selects the number of bits of tcp_secret that are used to seed the sequence number increment value. The default value of tcp_seqbits is 21; its minimum and maximum values are 16 and 26. The default value represents a compromise between security and the uniqueness of the sequence number. If the value of tcp_seqbits is small, this increases the possibility that an attacker can guess the random number. A large value for tcp_seqbits decreases the time before a given sequence number occurs again. See Appendix C, ``Configuring TCP/IP tunable parameters'' in the Performance Guide for more information.

Protecting against SYN flood attacks

A ``SYN flood'' is a Denial of Service attack that takes advantage of the TCP ``three way handshake'' protocol. A SYN is a type of TCP packet sent to initiate a connection with a listening TCP port. The port responds with a SYN/ACK to the initiating port, and places the SYN packet in a partial connections queue. When a corresponding ACK packet is received on the listening port, the validated SYN packet is removed from the partial connections queue and an entry is placed in the established connection queue awaiting a socket connection.

A SYN flood occurs when one or more listening TCP ports are sent large numbers of SYN packets. Such attacks could take various forms, most of which do not adversely affect the attacked system. However, the most potentially harmful attack sends SYN packets in which the client address refers to a system which does not exist. In this case, SYN packets remain in the TCP partial connection queue for each listening port that is attacked, unable to complete because the SYN/ACK cannot be routed to a bogus address. If the queues are too small and packets awaiting response remain on the queues, the TCP stack refuses to accept any connections until the bogus packets have timed out.

You can control the size of the TCP queues by setting the tcp_q0limit parameter with the inconfig(ADMN) command. When tcp_q0limit is set to a value greater than 0:

You can safely raise the tcp_q0limit value during an attack.

In the event of an attack, you should ensure that legitimate requests remain in a queue long enough to receive responses and get passed to the established connections queue. The higher the tcp_q0limit value, the less likely legitimate packets will be dropped. However, low-speed or high-latency links increase the time a packet must wait in a queue for response, and slower connections will be at greater risk during an attack.

WARNING: Although the upper limit of tcp_q0limit is 65535, do not set an arbitrarily high value that would exceed system memory during an attack.

To estimate a prudent value for tcp_q0limit, you can calculate ``attacks per turnaround''; that is, a function of the rate of attack (bogus SYN packets received per second) and the time required for a legitimate SYN packet to receive a response. You can measure the rate of attack with a packet sniffer. You can estimate the response time by collecting a representative sample of legitimate addresses and sending ping packets to each (SYN/ACK turnaround is probably quicker than ping turnaround given their higher priority of transmission). This will tell you the ``survival rate'' of a client's connection at a given tcp_q0limit value.

If S is the attack rate in packets/millisecond, T is the turnaround time of a particular client in milliseconds, and Q is the value of tcp_q0limit, the survival rate of the client's connection can be calculated as:

R1, survival rate during a single attack = ((Q - 1) / Q)
A, attacks during turnaround = T * S
R, survival rate = R1 ^ A = ((Q - 1) / Q) ^ (T * S)

For example, if bogus SYN packets arrive at a rate of 2000/second or S = 2/millisecond, and a particular client's turnaround T is 300ms, 600 attacks (A = S * T) arrive while that client's connection is partially open. If tcp_q0limit is set to Q = 450, the survival rate would be:

R1 = ((450 - 1) / 450) = 0.9978
R = ((450 - 1) / 450) ^ 600 = 0.2632

or about 26.3%. Increasing tcp_q0limit to 900 would yield:

R1 = ((900 - 1) / 900) = 0.9989
R = ((900 - 1) / 900) ^ 600 = 0.5132

or about 51.3%.

The memory costs of these values depend on the number of listening ports configured. At least 800 bytes are allocated for each partial connection, so the memory consumption = tcp_q0limit value * number of ports * 800. If in this example you had 100 listening ports configured, setting tcp_q0limit to 450 would consume 36MB of memory, while increasing it to 900 would consume 72MB. Note that:

For more information, see ``Using inconfig to change global TCP/IP parameters'' and ``Transmission Control Protocol (TCP) parameters'' in the Performance Guide. RFC 793 describes the TCP protocol; see ``Obtaining RFCs from the Internet''.

Setting up anonymous ftp

The ftp server included in the system provides support for an anonymous ftp account. Because of the inherent security problems with such a facility, you should read this section carefully if you want to provide such a service.

When a client accesses the anonymous ftp account, a chroot(ADM) system call is performed by the server to restrict the client from moving outside that part of the filesystem where the ftp home directory is located. Because a chroot call is used, certain programs and files used by the server process must be placed in the ftp home directory as shown in the following procedure:

  1. If the directory (or a link) called /usr/internet/ip/0.0.0.0/sco_ftp exists on the system, remove it or rename it (such as sco_ftp-). (If the directory does not exist, create it.) 

  2. Create a user called ftp with the Account Manager. Do not set a password for the account. Most importantly, set the login shell to rsh(C) to deny access to the rest of the system.

  3. Create a symbolic link to the ftp home directory as follows:

    ln -s homedir /usr/internet/ip/0.0.0.0/sco_ftp

    where homedir is the location of the home directory you specified when creating the ftp account.

  4. Run the following to set up directories below ftp's home directory: 

    cd ~ftp
    chmod 755 .; chown root .; chgrp root .
    mkdir bin dev etc lib pub usr usr/lib
    chown root bin etc dev lib usr usr/lib
    chmod 555 bin etc dev lib usr usr/lib
    chown ftp pub
    chmod 777 pub
    cd bin
    cp /bin/ls .
    chmod 111 ls
    cd ../etc
    cp /etc/passwd .
    cp /etc/group .
    chmod 444 passwd group
    cd ../lib
    cp /lib/libprot.so.1 .

    chmod 555 lib*
    chown bin lib*
    cd ../usr/lib
    cp /usr/lib/libc.so.1 .
    cp /usr/lib/libsocket.so.1 .
    chmod 555 lib*
    chown bin lib*
    cd ../..
    find /dev/socksys -print | cpio -dumpv ~ftp
    find /dev/zero -print | cpio -dumpv ~ftp

Files put in the anonymous area by local users must be placed in a subdirectory. In the setup described here, the directory ~ftp/pub is used. 

WARNING: Another issue to consider is the /etc/passwd file placed in ~/ftp/etc/passwd. Because anonymous ftp does not actually use the password stored in the encrypted password field, you should edit the copied file to contain blanks in this field such that anonymous users cannot obtain the encrypted passwords.

For example, you could edit the following line in ~/ftp/etc/passwd: 

   root:UDOkW7PLd1/ZQ,..EI:0:3:Superuser:/:
to read: 
   root::0:3:Superuser:/:

The ftp server provides a security loophole if certain user accounts are allowed. To prevent this, the file /etc/ftpusers is checked on each connection. If the requested user name is located in the file, the request for service is denied. This file should be owned by root in the sys group, have permissions set to 444, and contain at least the following names: 

   uucp
   root
Accounts with nonstandard shells should be listed in this file. Accounts without passwords need not be listed in this file; the ftp server does not service these users.

See also:

Adding or removing pseudo-ttys

When you install TCP/IP, the Network Configuration Manager prompts you to modify the number of pseudo-ttys configured on your system. These pseudo-ttys enable users on other hosts to use telnet or rlogin to access your host. The default, 32, is adequate for situations in which several (2-10) users access your system simultaneously. You need to add pseudo-ttys if:

To change the number of configured pseudo-ttys after installing and configuring TCP/IP, use the Hardware/Kernel Manager:

  1. Log in as root.

  2. Run the Hardware/Kernel Manager.

  3. Select Pseudo-ttys from the list and click on the Configure Driver button.

  4. Enter 1 to add pseudo-ttys, 2 to delete pseudo-ttys, or 3 to view the current number of pseudo-ttys configured.

  5. When done, enter q to quit.

  6. If you added or deleted pseudo-ttys, click on the Relink Kernel button and click on Relink to confirm. See ``Relinking the kernel'' in the SCO OpenServer Handbook for more information.

    NOTE: If you do not relink the kernel now, the changes you made do not take place, and you must then relink at a later time to effect the changes.

  7. Exit the Hardware/Kernel Manager.

  8. Shut the system down and reboot it by using the System Shutdown Manager as described in the SCO OpenServer Handbook. Remember to select Reboot after shutdown when using the manager.

Configuring UUCP over TCP/IP

There are several reasons you may wish to configure UUCP over TCP/IP. Some sites do not provide ftpd or rshd servers and/or their respective clients, ftp and rcp. Thus transferring files across a TCP/IP network is not an option with these systems. Additionally, some versions of TCP/IP do not provide the Simple Mail Transfer Protocol, SMTP, for mail transfer. In these cases, setting up UUCP to use TCP/IP may be an option to allow both file transfer and exchange of mail between such systems.

In the following paragraphs, the word ``client'' refers to a system that executes the uucp or uux command, while the term ``server'' or ``listener'' refers to a system that responds to a request from a client system.

There are two approaches to configuring UUCP over TCP/IP: the TCP socket interface and TLI/XTI (Transport Layer Interface and X/Open Transport Interface).

TCP socket interface

The server system uses the inetd superserver to listen for incoming uucp requests on TCP port 540. When receiving a request from a client uucico process, the server system forks the uucpd daemon, which logs in the client with the shell uucico. The two uucico processes can then transfer information similar to the way they would in a standard serial line configuration.

TLI/XTI

The server system uses a process called listen to wait for requests from a predefined TCP port and then when receiving a request, forks a uucico process directly, bypassing the standard UUCP login sequence.

NOTE: When connecting two SCO systems, the TCP socket interface is the preferred method. When connecting an SCO system to another vendor's TCP/IP product, consult the vendor's documentation to determine which method is supported and what procedure to use at that end. If the socket interface is supported, use it for best results.

Configuring UUCP over TCP/IP with the TCP socket interface

The following steps demonstrate how to configure UUCP over TCP/IP using the TCP socket interface between the systems london and thames.

  1. On both systems, verify that the file /etc/inetd.conf contains the following line (with no ``#'' character at the beginning of the line): 
       uucp    stream tcp      nowait  NOLUID  /etc/uucpd uucpd

    NOTE: If the system you are configuring is running SCO TCP/IP Release 1.1.3, replace ``NOLUID'' with ``root'' in the above line.

    Should the program /etc/uucpd not exist, execute the following commands as root:

    ln /usr/lib/uucp/uucpd /etc/uucpd
    chmod 755 /etc/uucpd

  2. Verify that the following line is in the /etc/services file on both systems: 
       uucp    540/tcp         uucpd           # uucp daemon

  3. Verify the configuration of the nuucp account on each host. Make sure that the shell of this account is /usr/lib/uucp/uucico, and that the account has a password on both hosts. You will probably have to set a password for the nuucp account. Use the Account Manager to confirm the account information and set a password.

  4. Add the following line to the file /usr/lib/uucp/Systems on london: 
       thames Any TCP,e Any - ogin: nuucp word: password
    where password is the password of the nuucp account on thames.

  5. Add the following line to the file /usr/lib/uucp/Systems on thames: 
       london Any TCP,e Any - ogin: nuucp word: password
    where password is the password of the nuucp account on london.

  6. Verify that the /usr/lib/uucp/Permissions file on london has the following entry: 
       MACHINE=thames LOGNAME=nuucp \
           COMMANDS=rmail:rnews:uucp \
           READ=/usr/spool/uucppublic:/usr/tmp \
           WRITE=/usr/spool/uucppublic:/usr/tmp \
           SENDFILES=yes REQUEST=yes

  7. Verify that the /usr/lib/uucp/Permissions file on thames has the following entry: 
       MACHINE=london LOGNAME=nuucp \
           COMMANDS=rmail:rnews:uucp \
           READ=/usr/spool/uucppublic:/usr/tmp \
           WRITE=/usr/spool/uucppublic:/usr/tmp \
           SENDFILES=yes REQUEST=yes

  8. Add the following line to /usr/lib/uucp/Devices on both hosts: 
       TCP,e TCP       -       Any     TCP     540

  9. Verify that both systems are in the other's /etc/hosts file or resolvable by a name server.

  10. If you needed to change anything in step 1, shutdown and reboot the systems on which you made the changes. UUCP should then work as expected between the two systems. Each system should be able to issue requests for the opposite system.

    Note that if you alter /etc/inetd.conf while the system is running, you should force inetd to reread the configuration file by entering the following command:

    kill -1 'cat /etc/inetd.pid'

    If you fail to make inetd restart before trying to contact it, the contacting host may give a ``Connection refused'' error.

NOTE: Note that steps 3 through 7 are similar to the steps used in configuring UUCP between systems over a serial line. Also, the user names and sample Permissions files shown here are only examples and may be changed to suit the security needs of a particular site.

Configuring UUCP over TCP/IP with TLI

The following steps demonstrate how to configure UUCP over TCP/IP using TLI between the systems london and thames. The example shown by the following procedure is a configuration where the host london initiates all UUCP requests, while the host thames listens and responds to all requests. If you want both hosts to be able to use the uucp command to initiate a UUCP transaction, repeat this procedure on each host, exchanging host names where appropriate.

  1. Pick a TCP port on which thames will listen for incoming UUCP requests. The sample following procedure uses port 698. The port chosen should not already appear in the /etc/services file and should not be port 540.

  2. Determine the address on which thames will listen for requests. This number is the representation of a sockaddr_in structure as defined in the /usr/include/sys/netinet/in.h header file. This number is a 16-byte number and needs to be constructed both in hexadecimal and in octal. Use of the bc(C) command is helpful here. To construct the number in hexadecimal, note that:

  3. Set up the Network Listening Service on thames:

    a.
    As root, enter: 

    nlsadmin -i inet/tcp

    This creates the directory /usr/net/nls/inet/tcp and allows us to add services that listen on the device /dev/inet/tcp.

    b.
    Enter on one line:

    nlsadmin -a 101 -c "/usr/lib/uucp/uucico -r0 -iTLI -unuucp"
    -w uucp -y "TLI UUCP" inet/tcp

    This adds service number 101, which executes the command /usr/lib/uucp/uucico -r0 -iTLI -unuucp as the user uucp, when a request for service number 101 is received on the device /dev/inet/tcp.

    The options and arguments to nlsadmin are:

    -a 101
    Add a service with label 101 (service code).

    -c "command"
    Fork the command in quotes.

    -w uucp
    Enter the command given in the -c option as the user uucp.

    -y "TLI UUCP"
    Add a comment.

    inet/tcp
    Specify that this service is to listen on /dev/inet/tcp. This step requires that the command in step 3a has already been executed.

    The options to the uucico command in the -c option of nlsadmin are:

    -r0
    Act in slave mode.

    -iTLI
    Use the TLI interface.

    -u nuucp
    Start up as the user nuucp. This is different from the -w option in the nlsadmin command.

    c.
    Enter the command:

    nlsadmin -l "\x020002ba849376030000000000000000" inet/tcp

    This is the hexadecimal representation of the address constructed in step 2.

  4. Add the following line to /usr/lib/uucp/Systems on thames: 
       london Never TLI,e Any
    If this line for london has already been added for TLI so that thames can initiate a connection, make no changes to the /usr/lib/uucp/Systems file.

  5. Add the following set of lines to /usr/lib/uucp/Permissions on thames: 
       MACHINE=london LOGNAME=nuucp \
           COMMANDS=rmail:rnews:uucp \
           READ=/usr/spool/uucppublic:/usr/tmp \
           WRITE=/usr/spool/uucppublic:/usr/tmp \
           SENDFILES=yes REQUEST=yes

  6. Add the following line to the /usr/lib/uucp/Systems file on london: 
       thames Any TLI,e Any address
    where address is the octal representation of the address constructed in step 2. Thus the line to add is: 
       thames Any TLI,e Any \002\000\002\272\204\223\166\003
           \000\000\000\000\000\000\000\000
    This should all be on one line. The backslashes surrounding each octal byte are required.

  7. Add the following line to the /usr/lib/uucp/Devices file on london: 
       TLI inet/tcp - Any TLI \D nls

  8. Add the following line to the /usr/lib/uucp/Dialers file on london: 
       nls "" "" NLPS:000:001:101\N\c
    Note that the ``101'' specified here matches the service code added with nlsadmin -a in step 3b.

  9. Add the following lines to the /usr/lib/uucp/Permissions file on london: 
       MACHINE=thames LOGNAME=nuucp \
           COMMANDS=rmail:rnews:uucp \
           READ=/usr/spool/uucppublic:/usr/tmp \
           WRITE=/usr/spool/uucppublic:/usr/tmp \
           SENDFILES=yes REQUEST=yes

  10. Verify that each host is listed in the other's /etc/hosts file or resolvable by the nameserver. Add the following lines to the end of the file /etc/rc2.d/P87USRDAEMON on thames, so that the listener is started when the system is booted: 
       nlsadmin -s inet/tcp 2>/dev/null
   [ $? = 0 ] && echo "Started listener"

  11. Shut down and reboot both systems. Verify that the process called ``listen'' is running on thames. You should now be able to issue uucp requests for thames from london.

Obtaining RFCs from the Internet

SCO TCP/IP and other manual pages frequently cite appropriate RFCs (Requests for Comments). RFCs can be obtained from InterNIC Information Services in the following ways:

Troubleshooting TCP/IP

From time to time, you will encounter problems using your network. The following general procedure can help solve most problems and points to additional documentation for help.

To troubleshoot the most common TCP/IP problems:

  1. Run the netstat command to verify the presence of TCP/IP interfaces.

  2. Use ping to verify stack configuration and local connectivity.

  3. Use ping to verify connectivity to remote networks.

  4. Use netstat to track down abnormal network behavior.

  5. Turn debugging on for TCP/IP server daemons.

In addition to these steps, you can troubleshoot additional TCP/IP protocols by referring to the following sections:

Verifying the presence of TCP/IP interfaces

Use the netstat -i command to see which interfaces are currently configured. You should see the loopback interface, plus one interface for each networking card or serial line interface on your system. When viewing the results of netstat -i:


Verifying local network connectivity

The ping(ADMN) command sends TCP/IP packets to the desired destination and, if successful, returns packets to the sender. With ping, you can verify that the TCP/IP stack is configured correctly on the local host and that your system can reach others via configured interfaces. To verify connectivity:


When you ping a remote host, the following results are possible:

Verifying remote network connectivity

If you can ping hosts on the local network, try to ping one remotely connected via a gateway:


Troubleshooting problems with netstat

The netstat(TC) program is helpful in tracking down network malfunctions. In particular, use the following options:


Flushing phantom connections

Use the netstat -a command to display active connections and sockets. Look for phantom connections -- those that still appear as active in the display that were terminated abnormally. If many appear, your network may run slowly, and you may need to stop and restart TCP/IP to flush the connections.

Troubleshooting packet errors

The netstat -i command displays active interfaces (network card and serial interfaces) as well as statistics on:

Ipkts
input packets per interface

Ierrs
input errors per interface

Opkts
output packets per interface

Oerrs
output errors per interface

Coll
packet collisions detected
Here is a sample output: 
   Name  Mtu    Network       Address     Ipkts  Ierrs Opkts   Oerrs Coll
   net0  1500   10.0.118      don         1348   12    1854    23    65
   lo0   8232   loopback      localhost   4058   0     4058    0     0
In using netstat -i, you should verify that the card is receiving and sending packets (that Ipkts and Opkts are nonzero), and that input and output errors as well as collisions are a small percentage of the packet total.

If both Ipkts and Ierrs are zero, the connection to the network may be bad, the network card may be bad, or there may be an interrupt vector conflict. Verify network cabling, then check for interrupt conflicts by running hwconfig or vectorsinuse. If a conflict exists, use the Network Configuration Manager to reconfigure your card. If the cable and interrupt vectors check out, run any diagnostic tools supplied by the manufacturer of the networking card.

If Ipkts is zero, but Ierrs is nonzero, the network, cabling, or card may be bad, another host on the network may be generating bad packets, or the network may be incorrectly terminated.

If Opkts is zero and Oerrs is nonzero, there may be a conflict of I/O addresses on the system. If both are zero, the conflict may be in shared memory addresses. Verify the I/O and shared memory addresses of each card on your system, and reconfigure your networking card with other supported addresses if conflicts exist.

If Coll is high (greater than 1-2 percent of the Opkts total), your network is very busy. Consider breaking the network into multiple separate networks.

Monitoring streams usage

Use the netstat -m command to monitor streams usage. The display shows each type of buffer allocated; the number free, allocated, and configured; the number of failures per type; and other streams information.

Streams are dynamically allocated in this release of TCP/IP, so streams errors should be uncommon. However, if you notice streams failures and need to reconfigure streams allocation, do so by using configure(ADM).

Verifying correct routing behavior

The netstat -r command provides information about the usage of each route configured on your system. A route consists of a destination host or network and a network interface used to exchange packets. Direct routes are created for each interface attached to the local host.

At a minimum, your routing table should display entries for the loopback mechanism (localhost), the local network, the local hostname, and the IP Multicasting route, 224. The following is a typical display: 

   Routing tables
   Destination     Gateway         Flags     Refs     Use   Interface
   localhost       localhost       UH        24       66    lo0
   10.0.118        nile            UC        1        0     net0
   nile            localhost       UGHS      3        36    lo0
   224             nile            UCS       0        0     net0
The columns display:

Destination
Network or host to which this route allows you to connect.

Gateway
Name of the gateway you configured for this route. If you are directly connected, this is a local address. Otherwise, it is the name of the host through which packets must be routed.

Flags
State of the route. For a complete list, refer to the manual page for route(ADMN). Common states are:

C
cloning -- new routes are derived from this route

G
a route to a gateway

H
a route to a host

N
a route to a network

S
static

U
up

Refs
Current number of active connections using the route. Connection-oriented protocols normally hold on to a single route for the duration of the connection, while connectionless protocols obtain a route, then discard it as needed.

Use
Current number of packets sent using this route.

Interface
Name of the physical network interface to begin the route.
If one or more of these routes are missing, you may see routing errors when you try to contact other hosts. You can add routes manually by using the route add command. See route(ADMN) for more information.

Logging troubleshooting information

Most of the server daemons started by /etc/inetd.conf accept a -d option forcing all sockets to be created with debugging turned on. With debugging on, activity is logged in /usr/adm/syslog. To enable logging:

  1. Edit /etc/inetd.conf to add the -d option to each daemon you want to log.

  2. Determine the process ID of inetd by entering the following command:

    cat /etc/inetd.pid

    The process ID of inetd appears.

  3. Send a message to inetd to force it to reread /etc/inetd.conf:

    kill -1 inetd_pid

    inetd_pid is the process ID from step 2.

If you enable logging for all server daemons, take care to monitor the size of /usr/adm/syslog, as it may grow quickly. To turn off logging, reedit inetd.conf to remove debug flags and kill -1 the inet daemon again.