Re: network installation manager

On Mar 14, 5:38 am, dnnet...@xxxxxxxxxxxx (vinicio) wrote:
hello, i have to setup a nim environment, define resources and test the
correct operation of the service

there is a firewall between master and client machines, is it correct to
open ports 1058/9 and 3901 enough ?

--

questo articolo e` stato inviato via web dal servizio gratuitohttp://www.newsland.it/newssegnala gli abusi ad a...@xxxxxxxxxxx

IBM's FAQ
http://www-1.ibm.com/support/docview.wss?rs=111&context=SWG10&context=HW130&dc=DB520&q1=NIM+firewall+AIX&uid=isg3T1000508&loc=en_US&cs=utf-8&lang=en

Problem
NIM Communication within a Firewall Environment

Solution
NIM Communication within a Firewall Environment
The information in this document pertains to NIM at all levels of AIX
from AIX 4.x through AIX 5.3.

NOTE: At AIX 5.3 and 5200-07, there is an additional optional service
called the NIM service handler (nimsh). For environments where the
standard rsh protocols are not secure enough, nimsh may be
implemented.

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. The default reserved network ports for nimsh are 3901 and
3902.

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 install 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 (tftp) a configuration
file (niminfo) to determine which server(s) contain 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).

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


Removing files from designated tftp directory
Remove niminfo file
Remove link to boot image
Remove file entry in /etc/bootptab
Unexporting nfs resources from client
Remove entries from /etc/exports
Export remaining entries from /etc/exports
Updating client object information in the NIM database
Machine state (running / not running)
Command result (success / failure)* client state (ready for an
operation)
Install Process
The Install Overview gives a short summary of the install process. In
this section, we will describe the client / server communication
during a NIM install. A NIM master push will be presented with
specifics into the Install Process.

Master Initiated Install
When a network install is initiated from the master's end, the NIM
master prepares resources for install (create script files, NFS export
resources, create file entry in /etc/bootptab) 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. The diagram below lists the
steps taken to perform the network install.


rcmd()
rsh

-----
-----
| M | src port: <---------- stdin & stdout ---------- > dest port:
| C |
----- 1023-513
514 -----
aux port: <-------------- stderr ---------------- aux port:
1023-513 1023-513


bootps
bootpc

-----
-----
| | dest port: <------------------------------------ > src port:
| |
----- 67
68 -----

tftp
server
tftp
client

-----
-----
| | dest port: <------------------------------------ > src port:
| |
----- 68
0-65534 -----
nfs
server
nfs
client

-----
-----
| | dest port: <------------------------------------ > src port:
| |
----- 2049
0-65534 -----

nim
nimclient

-----
-----
| | dest port: <---------- stdin & stdout ---------- > src port:
| |
----- 1058
1023-513 -----
aux port: --------------- stderr --------------- > aux port:
1023-513 1023-513
The Protocols
RSH
RSH requires clients to connect using source ports obtained from the
reserved port range of 1023-513. Since NIM clients do not have a
client service, the clients communicate by calling rcmd(), which in
turn, calls rreservport() to create a TCP socket and binds a port from
the privileged port range of 1023-513. The port is determined by
initializing the starting port at 1023 and attempting to bind it; if
this fail, we decrement the port number and reattempt to bind a port.
This process continues until we succeed in finding an unused port or
we fail after reaching port 513.
Upon successful binding of the source port, rcmd() allows the option
of binding a secondary (auxiliary) port for any stderr. When set,
rreservport() is called, but this time the starting port is based on
the source port we obtained in the previous step (source - 1). Once
initialized, we repeat the binding process from above and upon
success, we listen on this secondary port for any stderr received from
the destination service.
NIM makes use of this option and passes return code status (in
addition to error messages) over the secondary port.
BOOTP
The BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
and 'BOOTP server' (67). The client sends requests using 'BOOTP
server' as the destination port; this is usually a broadcast. The
server 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 TFTP protocol uses transfer identifiers (TID's) as ports for
communication; therefore they must be between 0 and 65,535. In order
to create a connection, each end of the connection chooses a TID for
itself, 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 (or other datagram
protocol) as the source and destination ports. A requesting host
chooses its source TID as described above, and sends its initial
request to the known TID 69 decimal (105 octal) on the serving host.
The response to the request, under normal operation, uses a TID chosen
by the server as its source TID and the TID chosen for the previous
message by the requestor as its destination TID. The two chosen TID's
are then used for the remainder of the transfer.
NFS
The NFS 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
program 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 on back to the client.
NIM
Clients communicate to the NIM master using well-known service port
1058 (nim) and 1059 (nimreg). During the install process, the NIM
clients send status information. 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;
when necessary, resources are deallocated (unexported) and boot images
are removed.
The clients do not have a registered client service, so they use
rcmd() to obtain sockets based on the rules mentioned above in the RSH
section of this document. The API is passed the service port of 1058
for establishing a connection to the NIM master. The nimesis daemon
runs on the NIM master and listens on the nim service port. 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.
Since NIM clients do not have access to the NIM database, all NIM
commands are interpreted on the NIM master's end and subsequent
operations are placed on the client for shell execution. This detail
is important to understand since 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.
Firewall Considerations
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:

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.
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.
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 using rsh, leave five (5) ports open
starting at 1023 and decrementing from there. So if a client is
communicating in the NIM environment, the client should leave open
ports (1023-1019) and the master should leave open ports (1023-1019).
This is an estimate and may not work in all environments since other
services may call rreservport() prior to, or during, NIM operations.
When monitored, this approach should work fine in small environments
since access to ports in the privileged space are restricted to super-
user access only.
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.





.

Relevant Pages

  • Re: thin client com ports
    ... I'm glad that you got at least one more client working! ... MCSE, CCEA, Microsoft MVP - Terminal Server ... the COM port settings? ... I am testing several thin clients. ...
    (microsoft.public.windows.terminal_services)
  • help: using smtp.gmail.com as SMART_HOST
    ... with my Google gmail address. ... is pop.gmail.com, using port 995. ... Retrieving mail is not the problem since my Google searches ... client, I believe the term is) to send my mail to Google's ...
    (comp.mail.sendmail)
  • Re: Unable to print to networked printer - get access denied messa
    ... Check the permissions on the server assuming the client has a true RPC ... How is the Standard TCP/IP port configured for the device? ...
    (microsoft.public.windowsxp.print_fax)
  • Re: Why encapsulate state pattern......
    ... >>>without changing the interface nor the object's identity. ... >> closing an already closed port. ... is that the client has to track a rule that says old states need to be ... is open, in order to send data, so it needs to know that open, opens ...
    (comp.object)
  • problem with nim upgrade
    ... My nim master is 5.2.0.0 with no patches. ... My nim client is 4.3.3. ... I found a reference to a similiar problem and the fix was to make sure ...
    (comp.unix.aix)