LISTNER System Utility

The LISTNER process listens to configured TCP/IP ports, waiting for incoming connection requests from remote clients . LISTNER starts a configured program when a request is made via TCP/IP to a specified port.

The TCP/IP process will notify the configured LISTNER process when a request is received to the port for which it is configured. A port is configured in a <portconf> file along with the server process that will be started when a request is received for the port and any optional startup message. When the LISTNER process receives the notification, it starts the target server process. The target server creates a socket using the hostname and source-port information, then accepts the pending connection request on the newly created socket. Every connection to a single port will generate a unique instantiation of the defined server process for use by each individual remote user .

LISTNER is responsible for starting the ECHO, FINGER, and FTP servers when a client request is received for those processes. LISTNER is used only for TCP/IP processing requests.

Once the connection has been made to the target server process, the LISTNER process is no longer involved in the communication and continues to process new incoming requests.

Multiple LISTNER processes may be running on the system. Each LISTNER has a defined <portconf> file.

Caution

These services do not apply to UDP ports; LISTNER is a TCP-oriented program and listens only to TCP ports.

RISK The LISTNER process requires privileged access to some TCP/IP ports, so it may need to be started by SUPER Group members . LISTNERs not started by a member of the SUPER Group cannot use ports less than 1024.

Programs started by the LISTNER inherit the CAID and PAID of the LISTNER. Programs started by a LISTNER should always require authentication verification by processing a logon and password sequence.

RISK Programs started by LISTNER may give SUPER access.

LISTNER is part of the TCP/IP communications subsystem. A program commonly started by LISTNER is FTP, which is used for file transfer.

The components of LISTNER are:

PORTCONF Configuration File

SERVICES Configuration File

PORTCONF

The PORTCONF file is used to designate the usage of specific ports. The PORTCONF file is normally located in the $SYSTEM.ZTCPIP subvolume, but can be located elsewhere as defined to TCP/IP.

The LISTNER process must have a static or continuously available input file, output file and home terminal. $ZHOME or $VHS is recommended.

RISK If no specific location for the PORTCONF file is specified, the process will load the default PORTCONF in the $SYSTEM.ZTCPIP subvolume, which might not be expected, if alternative locations for the PORTCONF are used.

AP-ADVICE-LISTNER-01 The command to start a LISTNER should explicitly specify the location of the PORTCONF file.

RISK Discerning which LISTNER is using which <portconf> file is not easily done. This cannot be easily monitored for unauthorized changes.

RISK Once the LISTNER has read the <portconf> file, the file is closed. If the <portconf> file is modified, the LISTNER will not accept the changes without stopping and restarting the LISTNER.

RISK If two LISTNER processes are started pointing to the same <portconf>, collisions may occur. Whenever this happens, whichever process is second won't listen at the port. It will issue EMS messages.

The following example shows the <portconf> configuration for ports 7810 and 7820. The '!' is used to designate comments.

  7810 $DATA5.SECGUI.SECGUIX !test s7400 connect only   7820 $DATA4.SECGUI.KSERVR !text s7400 connect w/ k expand  

In the example for port 7810, the program $DATA5.SECGUI.SECGUIX will be started when a request is made of this port via TCP/IP.

Preventing Port Collisions

In the OSS environment, the inetd daemon provides the equivalent function as LISTNER.

RISK Collisions between the services provided by the LISTNER and the inetd daemon can occur if both processes are assigned to the same TCP/IP process using the same port. When this happens, the second process issues an EMS message and does not listen for a specific service.

To prevent this condition, modify one or both of the configuration files (PORTCONF or inetd.conf):

In the inetd.conf file specify a TCP/IP process (Transport Provider) that doesn't have a LISTNER running on it.

In the PORTCONF file, take advantage of the fact that LISTNER supports only TCP ports. Comment out the TCP port for the service in the inetd.conf file. This will allow the LISTNER process to provide the service (on the TCP port) from the Guardian environment while the inetd daemon will provide the service (on the UDP port) from the OSS environment.

TCP/IP Services File

RISK A process's security via LISTNER is only as secure as the TCP/IP that is supporting it. Please refer to the Gazette section on TCP/IP

Securing LISTNER

BP-FILE-LISTNER-01 LISTNER should be secured "UUCU".

BP-OPSYS-OWNER-01 LISTNER should be owned by SUPER.SUPER.

BP-FILE-FILELOC-01 LISTNER must reside in $SYSTEM.SYSnn.

BP-FILE-LISTNER-02 <portconf> should be secured "NCUU".

BP-OPSYS-OWNER-03 <portconf> should be owned by SUPER.SUPER.

BP-FILE-FILELOC-03 <portconf> resides in $SYSTEM.ZTCPIP.

If available, use Safeguard or a third-party object security product to grant access to LISTNER object files only to users who require access in order to perform their jobs.

BP-SAFE-LISTNER “01 Add a Safeguard Protection Record to grant appropriate access to the LISTNER object file.

BP-SAFE-LISTNER-02 Add a Safeguard Protection Record to grant appropriate access to the PORTCONF disk file.

	Discovery Questions	Look here:
OPSYS-OWNER-01	Who owns the LISTNER object file?	Fileinfo
OPSYS-OWNER-03	Who owns the <portconf> file?	Fileinfo
FILE-POLICY	Who is allowed to start and stop LISTNERs on the system?	Policy
FILE- LISTNER-01 SAFE-LISTNER-01	Is the LISTNER object file correctly secured with the Guardian or Safeguard system?	Fileinfo Safecom
FILE-POLICY	Who can make changes to the <portconf> file?	Policy
FILE- LISTNER-02 SAFE-LISTNER-02	Is the <portconf> file correctly secured with the Guardian or Safeguard system?	Fileinfo Safecom

Related Topics

TCP/IP