Answer

Contents of the technote:

The information in this document pertains to NIM at levels of AIX 5.x through AIX 7.1.

What this document does and does not cover:

Does cover:
- Introduction to NIM service handler or 'nimsh'
- The install process
- The clean-up process
- Protocols and the ports used by these protocols during a network install
- Breakdown of ports that need to be opened in a firewall for use with NIM
- Other firewall considerations

Does not cover:
- In-depth description of NIM service handler or 'nimsh'
- How-to steps for performing network installs
- Problem determination or debugging steps for failed network installs


Introduction to NIM service handler or 'nimsh':

At AIX 5.2 Technology Level 7, AIX 5.3, AIX 6.1, and AIX 7.1 an additional optional service called 'nimsh', or the NIM service handler was added. For environments where the standard rsh protocols are not secure enough, nimsh may be implemented. The client daemon has two ports registered with the Internet Assigned Numbers Authority (IANA) for use during network communication. With nimsh, the primary port used by the client is 3901, and it listens for service requests. The primary port on the client is used for stdin and stdout while stderr is redirected to secondary, which is port 3902.

**For more information on nimsh, see the AIX 5.3 documentation at http://publib.boulder.ibm.com/infocenter/pseries/index.jsp and search on nimsh.

---

Install Process

The Install Overview gives a short summary of the install process. In this section, we will briefly describe the client/server communication during a NIM install. Both the 'push' and 'pull' installs will be briefly described.

Master Initiated Install - also known as a 'push' install
When a network install is initiated from the master's end, the NIM master prepares resources for install. When the master prepares its resources, it creates script files, NFS export resources (lpp_source, mksysb, etc), populates the /etc/bootptab file, populates the /tftpboot directory, and then executes an 'rsh' command on the client to set the bootlist for install over the network interface. The client resets and attempts to boot over the network using bootp and tftp services.

Client initiated Install - also known as a 'pull' install
When a network install is initiated from the client's end, the NIM master still prepares its resources for the install as it would for a 'push' install. The difference is the fact that during a 'pull' install, the NIM master does not execute an 'rsh' command to set the bootlist of the client and then reset it to boot from the network. The /etc/bootptab file and /tftpboot directory are still populated, along with the script files created, and NFS resources exported.

Clean-up Process after install

Upon completion of install, the client sends state information to the master via 'nimclient' calls to the master's nimesis daemon. The NIM master then deallocates all install resources from the client object which has completed installing. The deallocation process consists of:

1. Removing files from designated tftp directory
- Remove client.info file
- Remove link to boot image
- Remove file entry in /etc/bootptab

2. Unexporting nfs resources from client
- Remove entries from /etc/exports
- Export remaining entries from /etc/exports

3. Updating client object information in the NIM database
- Machine state -- running -or- not running
- Command result -- success -or- failure
- Client state -- ready for an operation -or- not running

---

Protocols used during a network install

When a network install is performed, there are several protocols involved. The following outline should provide adequate steps for determining firewall administration tasks:
Install Overview

NIM performs network installs by using a client/server model based on the bootp/tftp protocols for receiving a network boot image. Once the boot image is obtained, the client requests (using tftp) a configuration file (client.info) to determine which server contains the install image and other necessary install resources. The install image and resources are nfs mounted using nfsd/mountd services. Once all mounts succeed, the install begins and subsequent information is sent to the NIM master via nimclient calls to the nimesis daemon (nim).

RSH
stdin/stdout:
'rsh' requires clients to connect using source ports. There is a reserved port range for 'rsh' communication, and the port range for 'rsh' communication is 1023-513. Since NIM clients do not have a client service, the clients communicate by calling 'rcmd()'. This command then calls the 'rreservport()', which will create a TCP socket. When the TCP socket is created, it binds a port from the privileged port range of 1023-513. The port is determined by initializing the starting port (1023), and attempting to bind to it. If the attempt to bind to port 1023 fails, an attempt to bind to the next port, in a descending order (1022, then 1021, etc) will be made until a successful connection to an unused port copy is secured. If no attempts are successful after finally reaching port 513, the process will result in an overall failure.
stderr:
The 'rcmd()' command allows the option of binding a secondary, or auxiliary port for any stderr. When set, rreservport() is called again, but this time the starting port is based on the source port we obtained in the previous step. The same method is used to find the next open port. Source - 1, in a decending order until a successful connection to an unused port copy is secured. The secondary port will listen for any stderr received from the destination service.

NIMSH
The client daemon has two ports registered with the Internet Assigned Numbers Authority (IANA) for use during network communication. These ports are referred to as the primary and secondary ports.

The nimsh client daemon listens on these ports for requests initiated by the master using the TCP protocol. The primary port listens for service requests on reserved port 3901. When a request is accepted, the primary port is used for stdin and stdout requests. The stderr requests are redirected to secondary port 3902. This behavior is similar to auxiliary connections in rcmd(). This implementation allows the NIM master connection to stay consistent with current support of client connections through the rsh command. Using a reserved secondary port in NIMSH allows firewall administrators to write firewall rules for accepting incoming connections on privileged ports from the secondary port. These rules can have the requirement that the originating socket address (hostname : secondary port) comes from a trusted source.

BOOTP
The BOOTP protocol uses two reserved port numbers. 'BOOTP client' uses reserved port 68 (UDP/TCP), and 'BOOTP server' uses reserved port 67 (TCP/UDP). The client sends requests using 'BOOTP server' as the destination port. This request is usually a broadcast request. The bootp server (or NIM master in this case) sends replies using 'BOOTP client' as the destination port. Depending on the kernel or driver facilities in the server, this may or may not be a broadcast. The reason two reserved ports are used, is to avoid 'waking up' and scheduling the BOOTP server daemons when a boot reply must be broadcast to a client.

TFTP
The NIM client contacts the master on port 69 (UDP). Then TFTP protocol uses 'transfer identifiers' (TID's) as ports for communication. This means that the ports used for TFTP must be between 32,768 and 65,535. In order to create a connection, the master and the client both choose a TID for theirselves to be used for the duration of that connection. The TID's chosen for a connection should be randomly chosen, so that the probability that the same number is chosen twice in immediate succession is very low. Every packet has associated with it the two TID's of the ends of the connection, the source TID and the destination TID.
These TID's are handed to the supporting UDP (User Datagram Protocol) as the source and destination ports. A requesting host (NIM client) chooses its source TID randomly as described above, and sends its initial request to the known TID on the serving host (NIM Master, port 69). The master's response to the request uses a TID chosen by the NIM master as its source TID, and the TID chosen previously by the client as its destination TID. The two chosen TID's are then used for the remainder of the transfer.

ICMP
When initializing the client (running the 'niminit' command), the client will first attempt to contact the master using the ICMP protocol. Essentially pinging the master to make sure there is a clear path for sending the client information to the master.

NFS
The NFS version 2 and version 3 protocol currently uses the UDP port number 2049. This is not an officially assigned port, so later versions of the protocol use the "Portmapping" facility of RPC.
The port mapper program maps RPC (Remote Procedure Call) programs and version numbers to transport-specific port numbers. This program makes dynamic binding of remote programs possible. This is desirable because the range of reserved port numbers is very small and the number of potential remote programs is very large. By running only the port mapper on a reserved port (111), the port numbers of other remote programs can be ascertained by querying the port mapper.
The port mapper also aids in broadcast RPC. A given RPC program will usually have different port number bindings on different machines, so there is no way to directly broadcast to all of these programs. The port mapper, however, does have a fixed port number. So, to broadcast to a given program, the client actually sends its message to the port mapper located at the broadcast address. Each port mapper that picks up the broadcast then calls the local service specified by the client. When the port mapper gets the reply from the local service, it sends the reply back to the client.
In the case of NFS mounts, the client will connect to the port mapper service for the master (port 111), which will provide the port numbers that the client should use to communicate with the mountd, nfsd. lockd, and statd daemons on the master. The nfsd daemon will use port 2049, but mountd, lockd, and statd use an arbitrary port number between 32,768 and 65,535 by default. This behavior can be changed for all of these services, except for statd, by adding the desired port number you wish the service to use in the /etc/services file. For example, to use port 9999 for mountd, you would add the lines:

mountd 9999/tcp
mountd 9999/udp

Then stop and restart the mountd daemon:

# stopsrc -s rpc.mountd
# startsrc -s rpc.mountd

You can check that the port you specified is being used by running:

# rpcinfo -p | grep mountd
100005 1 tcp 9999 mountd
100005 2 tcp 9999 mountd
100005 3 tcp 9999 mountd
100005 1 udp 9999 mountd
100005 2 udp 9999 mountd
100005 3 udp 9999 mountd

*Note that statd cannot be bound to a specfic port, and will always choose an arbitrary port in the 32768 - 65535 range.

NFSv4 is more complicated to set up but it is more firewall friendly. If you are using NFSv4, you only need to open your firewall for portmap (111 udp/tcp) and nfsd (2049 tcp).

NIM
Clients communicate to the NIM master using well-known service port 1058 (nim) and 1059 (nimreg) to send the client's status information during a NIM install. The information contains details specific to the install progress. This information is updated in the NIM database and actions on the master's end are handled accordingly. This means that when necessary, resources are deallocated (unexported) and boot images are removed.
The clients do not have a registered port for client services, so they use rcmd() to obtain sockets based on the rules mentioned above in the RSH section of this document. The API (Application Programming Interface) is passed through the service port 1058 for establishing a connection to the NIM master. The nimesis daemon runs on the NIM master and listens on the nim service port (1058). When a request for service is received the nimesis daemon accepts the connection, verifies the originator, and sends an ACK signal in a similar fashion as expected by rcmd. Upon a successful connection, state information is passed and commands are placed on the client using the secondary port which has a file descriptor associated with the socket. ACK is a tool like grep, used by programmers with large trees of source code. Because NIM clients do not have access to the NIM database, all NIM commands are interpreted on the NIM master's end. Subsequent operations are then placed on the client for shell execution. This detail is important to understand because clients are allowed the option of requesting NIM operations. Since clients have no knowledge of which commands must execute per NIM operation, the requests are always sent to the NIM master (1058) and the master responds by pushing (rsh) the necessary commands on the client machines.
The registration port (1059) is used when clients attempt to add themselves to a current NIM environment. The clients use rcmd() to obtain sockets and pass the service port 1059 for establishing a connection to the NIM master. When connected, clients pass machine configuration information to the NIM master. The NIM database is updated with the newly defined client object and rsh permissions are given to the NIM master.

---

Breakdown of ports that need to be opened in a firewall for use with NIM:

Protocol	Port(s)
nimsh	3901 - 3902
icmp	5813
rsh*	513 - 1023**
rlogin*	513
shell*	514
bootp	67 - 68
tftp	69 and 32,768 - 65,535
nfs	2049
mountd	32,768 - 65,535 or user's choice
portmapper	111
NIM	1058 - 1059

*Required for rsh operation

**For every NIM communication using, leave five (5) ports open starting at 1023 for the NIM master, and decreasing from there.
See additional information in 'Firewall Considerations,' rule 3.

***When using the 'nimsh' communication protocol, ports 1023 - 513 must still be opened in the firewall for the client to communicate with the NIM master, when a client is adding themselves to the NIM masters database (when running the 'niminit' command on the client). Although these ports must be opened for communication, 'rsh' does not need to be enabled on either the NIM master or client. After the client has been initialized (after running the 'niminit' command on the client), the client will start to use ports 3901 and 3902 to communicate with the NIM master, but because the the 'nimsh' daemon only runs on the client the NIM master will still use ports 1023 - 513 to communicate with the client's ports 3901 and 3902.

Directions for communications over ports to be opened for NIM use, if you do not want to open all necessary ports bi-directionally:

BOOTP:
Client UDP 68 --> Master UDP 67
Master UDP 67 --> Client UDP 68

So the client communicates from UDP port 68 to master's UDP port 67.
Then the master's UDP port 67 responds to the client's UDP port 68.

TFTP:
Client UDP <--> Master UDP 69
Client UDP <--> Master UDP (random port between 32768 and 65535)

Here the client communicates via UDP to the master's port 69. The port that the client uses cannot be predicted.
Then, the master responds from port 69 back to the same port that made the request.
I used the bidirectional arrow to represent this.
Then random UDP ports are chosen on both the master and the client to affect the transfer of data. Again bidirectional.

NFS:
Client UDP <--> Master UDP 111
Client TCP <--> Master TCP (random port between 32768 and 65535, or the port specified in /etc/services for 'mountd' and 'lockd', as 'statd' must use the port range between 32768 and 65535)
Client TCP <--> Master TCP 2049

Similar "statements" for NFS's portmapper, mountd, and nfsd processes.

ICMP:
Client UDP 5813 <--> Master UDP 5813
Client TCP 5813 <--> Master TCP 5813

NIM:
Client TCP <--> Master TCP 1058/1059 + 513-1023

For rsh operations, which do not occur during install:
Master TCP <--> Client TCP 513, 514 + 513-1023

Firewall Considerations

NIMSH: Client TCP 1023 - 513 < --> Master TCP 1023 - 513 (For 'niminit' from the client only) Client TCP 3901 <--> Master TCP 1023 - 513 Client TCP 3902 <--> Master TCP 1023 - 513

NIM makes use of several protocols which are generally considered "risky" services on firewall machines. It is recommended that users who desire firewall protection within their NIM environment follow a few rules:

1. The NFS program usually runs at port 2049 which is outside of the privileged port space. Normally, access to portmapper (port 111) is needed to find which port this service runs on, but since most installations run NFS on this port, hackers can bypass NFS and try this port directly. NFS was designed as a LAN service and contains numerous security vulnerabilities when used over the Internet. NFS services should not be run on firewall machines. If a NIM master resides on a firewall machine, then resources should reside on another client - clients may also be used as resource servers in a NIM environment.
2. If possible, TFTP servers should not be placed on firewall machines since no authentication is needed when requesting service. The TFTP protocol does allow for denying access based on entries contained in /etc/tftpaccess.ctl. NIM manages access to files in /tftpboot only; so all other directory locations should be off limits. When managed properly, TFTP access can be viewed as acceptable in the NIM environment.
3. Since rsh is the standard method of client control, clients participating in the NIM environment must allow shell service (514) or enable Kerberos in the NIM environment per client. In order to reduce the amount of open ports in the NIM environment, the following rules may be applied:
* For every NIM communication, leave five (5) ports open starting at 1023 and descending from there. So when using 'rsh' as the communication protocol and a client is communicating with the NIM master ports (1023-1019) should be left open for both the master and client. This is an estimate and may not work in all environments since other services may call rreservport() prior to, or during, NIM operations.
* Users may also add secondary interfaces for each client participating in the NIM environment. The additional interfaces should be packet filtered.
* When NIM clients no longer participate in the NIM environment, or are temporarily removed from the NIM environment, users should disable rsh services on client machines by removing /.rhosts and/or removing rshd service.


For information regarding NIM please visit our Document Control Facility at
http://www.ibm.com/support/us/en
In the “Search all of support” box type in the following search string :
NIM Setup Guide