File Transfer Protocols


FTP is widely used for exchanging files between different platforms. For example, Guardian files are transferred between an HP NonStop server and PC-based workstation. Bi-directional binary and text transfers are done by copying exact images of a file.

FTP supports transfer of the following types of files:

ASCII

Unstructured

Structured (key-sequenced, relative, and entry- sequenced )

FTP does not support the transfer of SQL files.

RISK FTP server has no built in security, it relies entirely on the security native to the resident operating system. If the system hosting the FTP server is not properly secured, users can explore the system at will, copy any files that they have read access to, and place unauthorized files anywhere on the system. It is possible for FTP users to damage applications and databases and steal business data.

RISK The HP FTP server does not produce audits of its activity.

Safeguard software will audit file accesses by FTP users if configured to do so. Some third party FTP products provide comprehensive auditing of FTP activity on the NonStop server.

RISK FTP is a method that sensitive data can be move from an HP NonStop server to a remote system.

AP-ADVICE-FTP-01 FTP activity must be controlled at a maximum level.

The components are:

FTP

FTPEXTH

FTPSERV

FTPCSTM (FTP Custom Files)

FTP

FTP is the HP NonStop server FTP client. It is used to interactively transfer or manage files on a remote system. The remote system need not be another NonStop server.

FTPSERV

FTP servers respond to file transfer requests from the client FTP. The FTPSERV server is initiated from the LISTNER on the FTP port. The typical port for FTP is 21.

FTP CUSTOM Files

FTP reads the FTPCSTM file before it issues its first prompt. This allows the creation of a customized FTP environment before entering any commands. Please refer to the Gazette section on *CSTM Configuration Files.

FTP Systems

Both local and remote systems can place restrictions on which files can be transferred and where the files can be placed.

FTP Userids

AP-FTP-USERIDS-01 NonStop server users should login to FTP with their own userids to ensure that they only have access to the appropriate files.

Securing the Anonymous FTP Userid and Environment

Anonymous FTP is primarily intended for and supported in the OSS environment, but can be used in the Guardian environment.

The anonymous FTP userid, by convention is named NULL.FTP.

RISK Only implement Anonymous FTP if it is absolutely necessary. Anonymous FTP opens the system for general access. To mitigate the risks, implement the following precautions :

AP-FTP-USERIDS-02 Create an alias to the NULL.FTP userid, called "anonymous" or "ftp." This alias will be used to log into the FTP subsystem.

AP-FTP-USERIDS-03 Expire NULL.FTP's password. No password is necessary within the FTP subsystem.

AP-FTP-USERIDS-04 Freeze NULL.FTP to prevent users from logging onto the Anonymous userid outside of the FTP subsystem.

RISK If Safeguard software is down for any reason, the frozen userids (though still frozen) behave as if they are thawed.

Assign NULL.FTP and any of its aliases an appropriate 'home' where any users logging into FTP as anonymous will begin their session:

In the OSS environment, assign an initial directory, for example: /guest/FTP.

In a Guardian environment, assign a default subvolume, for example FTPGUEST.

AP-ADVICE-FTP-02 In the OSS Environment, the NULL.FTP user should not own any directories, especially the initial root directory. Directory owners can alter the security of the directory. Directories should be owned by SUPER.SUPER or another appropriate userid.

RISK Any references (symbolic links) to directories or files that are outside of the anonymous FTP subtree should be avoided.

Caution

A SYMBOLIC LINK is a file that contains the name of another file. If a system operates on symbolic links, a user can be directed to the file that the symbolic link points to. When the user displays a file that has a symbolic link, the user can see the original file as well as its link, which, depending on the contents of the file, could pose a security risk.

RISK Any absolute symbolic links (the ones that start with "/") should be avoided within a subtree. Absolute symbolic links will be understood by the system as referring to the Initial-Directory, rather than to the root directory of the OSS fileset.

RISK Do not grant NULL.FTP write access to any files.

RISK Files that NULL.FTP or its alias must drop onto the system should be limited to a single 'WRITE only' location. NULL.FTP should not be granted READ access to the 'WRITE only' location. Requires a lot of user (administrator's) intervention.

RISK NFS file security differs from that of standard files; but the FTP subsystem doesn't have the mechanism to differentiate an NFS file from a standard file.

NULL.FTP should never be allowed to own NFS files, since it'll give the user extended access capabilities.

The following three steps provide a 'safe area' that the Anonymous FTP users can't get out of, while trusted users can easily get at the anonymous mount point's files and drag them wherever they want to without lots of security headaches . The key is containing anonymous users strictly to this OSS mount point.

AP-FTP-USERIDS-05 Set up an OSS partition on one isolated disk pair and make it a separate mount point.

AP-FTP-USERIDS-06 Secure the parent directory of this mount point very tight so the anonymous FTP users can't navigate out of the "root" of this disk.

AP-FTP-USERIDS-07 Use SCF to set up an NFS alias for guest as anonymous (if it is to be NFS mountable from other nodes).

AP-FTP-USERIDS-08 Make sure the NULL.FTP user account is configured the same as the anonymous alias's account so that neither can get at anything except the anonymous OSS file space. The Safeguard initial directory and Guardian default subvolume should both point to this file space.

With CMON

Some CMONs can restrict FTP logon access by PORT and by IP address to limit the IP addresses from which authorized users can logon to a system and access the FTP subsystem.

Please refer to the Gazette section on CMON for more information.

BP-PROCESS-CMON-01 Using a third party CMON product or a modified CMON, restrict the IP addresses that can use the FTP ports.

Without the Safeguard Subsystem

To try to minimize the risks of FTP, grant READ access only those files that FTP users are allowed to GET. This can be difficult because of the large number of files on a system. On a more restricted system, secure the FTP programs or eliminate FTP access through TCP/IP to mitigate the risks.

RISK In the Guardian environment, there is no way to restrict where FTP users PUT files.

RISK The HP FTP server does not produce audits of its activity.

With the Safeguard Subsystem

Safeguard provides some support for securing FTP. Use Safeguard VOLUME and SUBVOLUME rules to restrict where FTP users PUT files. To try to minimize the risks of FTP, grant READ access only to those files that FTP users are allowed to GET. This can be difficult because of the large number of files on a system. On a more restricted system, secure the FTP program or eliminate FTP access through TCP/IP to mitigate the risks.

Safeguard software will audit file accesses by FTP users if configured to do so.

AP-SAFE-FTP-01 Add Safeguard VOLUME and SUBVOLUME rules to restrict where FTP users PUT files.

AP-SAFE-FTP-02 Add a Safeguard Protection Record to grant appropriate access to the FTP program.

With Third Party Products

3P-FTP-USERIDS-01 Third party FTP products provide granular access to FTP commands and can provide the following:

Authenticate and authorize users as they logon to the FTP subsystem.

Limit the IP addresses from which authorized users can logon to the FTP subsystem

Limit what FTP users can explore by restricting the use of the FTP DIR and LIST commands.

Limit what files FTP users can retrieve from the system by restricting the use of the FTP GET command

Limit where FTP users write files by restricting the use of the FTP PUT command

Provide auditing of FTP activity.

The NonStop server FTP server provides no control over what users can see once logged in.

AP-FTP-USERIDS-09 They can view the files in any subvolume or directory with the LIST or DIR command.

AP-FTP-USERIDS-10 They can GET (copy) any file that isn't secured against READ access.

RISK HP's implementation of FTP has no encryption capabilities. Sensitive data, userids, and passwords are transferred between remote nodes in the clear and unprotected , vulnerable to capture with a network sniffer.

AP-FTP-USERIDS-11 Some third party products provide encryption for both the Command Channel (port) and the Data transmission Channel (port) between the client FTP software and the server FTP software on the NonStop server.

FTP-USERIDS-11 NFS mounted files [i.e. files whose format is compatible with DOS or UNIX systems. These files are used to manage files on HP Non- Stop server from PC or workstation] are special case files . Their security differs from the security of standard files; anonymous FTP, though doesn't have the mechanism to tell them apart from the 'regular' files.

Take extreme caution securing NFS files if they will be accessed by the anonymous FTP userid.

An anonymous user should never be allowed to own NFS files, since it will give the user extended access capabilities.

Securing FTP Components

BP-FILE-FTP-01 FTP should be secured "UUNU".

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

BP-OPSYS-FILELOC-01 FTP must reside in $SYSTEM.SYSnn.

BP-FILE-FTP-02 FTPSERV should be secured "UUNU".

BP-OPSYS-LICENSE-03 FTPSERV must be LICENSED.

BP-OPSYS-OWNER-03 FTPSERV should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-03 FTPSERV resides in $SYSTEM.ZTCPIP.

With certain exceptions listed above, FTP can only operate on object files that userids have been granted access to via the Guardian or Safeguard system.

AP-ADVICE-FTP-02 Users should run FTP under their own userid.

AP-ADVICE-FTP-03 The databases and other sensitive files should be secured to prevent unauthorized transfer of data via FTP.

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

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

BP-SAFE-FTP-02 Add a Safeguard Protection Record to grant appropriate access to the FTPSERV object file.

Discovery Questions

Look here:

OPSYS-OWNER-01

Who owns the FTP client object file?

Fileinfo

OPSYS-OWNER-03

Who owns the FTPSERV server object file?

Fileinfo

OPSYS-LICENSE-03

Is the FTPSERV object file licensed?

Fileinfo

FILE-POLICY

Who is allowed to execute FTP on the system?

Policy

FILE-POLICY

Is anonymous FTP used on the system?

Policy

FILE-FTP-01
SAFE-FTP-01

Is the FTP object file correctly secured with the Guardian or Safeguard system?

Fileinfo Safecom

FILE-FTP-02
SAFE-FTP-02

Is the FTPSERV object file correctly secured with the Guardian or Safeguard system?

Fileinfo Safecom

Trivial File Transfer Program (TFTP) User Program

The Trivial File Transfer Protocol (TFTP) is an Internet standard protocol for file transfer that uses minimal capability and minimal overhead. TFTP depends only on the unreliable connectionless datagram delivery service (UDP), so it can be used on machines like diskless workstations that keep such software in ROM and use it to bootstrap themselves .

Remote TFTP clients are used to transfer public files to and from an HP NonStop server host system's TFTP server (TFTPSRV).

The HP TFTP client is used to transfer public files to and from a remote system.

Files can be transferred to or from any system on a network that has a TFTP server that accepts requests from the TFTP client.

RISK TFTP does not provide any mechanism for users to log on to the remote system with a userid and password and verify which files they can access. The files remote users are allowed to retrieve from a remote system are typically secured for public access; that is, anyone on the network can read the files. The TFTP server on the remote system sets the restrictions on which files users can retrieve, as well as restrictions on storing files.

AP-ADVICE-TFTP-01 Both local and remote systems can each place restrictions on which files that can transferred and where the files can be placed.

Users can GET (retrieve) only files that grant all users remote READ access. That is, the files must be secured "Nxxx." TFTP ignores the rest of the security string.

Users can only PUT (drop) files where they have remote WRITE access.

To overwrite a file, the existing file security must grant all users remote WRITE access. That is, the files must be secured "xNxx." TFTP ignores the rest of the security string.

Remote users can only create new files in a subvolume specified when the TFTP server was started. If no subvolumes were specified, users can create new files only in $DATA.PUBLIC and only if $DATA.PUBLIC is present on the system.

RISK TFTP assigns new files PUT onto the system a security string of "NUNU," which allows network access.

TFTP Components

Starting with Release Version Update G06.12, the TFTP server consists of two distinct process types that use the following programs:

TFTP

TFTPSRV

TFTPCHLD

TFTP

TFTP is the HP NonStop server TFTP client. It is used to interactively transfer or manage files on a remote system. The remote system need not be another NonStop server.

TFTPSRV

The TFTPSRV process validates requests and starts the TFTPCHLD processes. For every sixteen TFTP requests, TFTPSRV generates a new TFTPCHLD process.

TFTPCHLD

The TFTPCHLD processes handle data transfers. The individual TFTPCHLD processes terminate when after they've handled sixteen requests and no further request is pending or when they have been idle for 10 minutes.

Securing TFTP Components

TFTP should be managed similarly to FTP. See the discussion on Securing FTP with and without the Safeguard Subsystem above.

AP-ADVICE-TFTP-02 If remote clients are allowed to use TFTP and SWANs are in use on the system, all files in the $SYSTEM.CSSnn subvolume must be secured for network READ access. HP recommends that SWAN users secure these files for network READ and EXECUTE access (NUNU).

BP-FILE-TFTP-01 TFTP should be secured "UUNU".

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

BP-OPSYS-FILELOC-01 TFTP must reside in $SYSTEM.SYSnn.

BP-FILE-TFTP-02 TFTPSRV should be secured "UUNU".

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

BP-OPSYS-FILELOC-03 TFTPSRV resides in $SYSTEM.ZTCPIP

BP-FILE-TFTP-03 TFTPCHLD should be secured "UUNU".

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

BP-OPSYS-FILELOC-03 TFTPCHLD resides in $SYSTEM.ZTCPIP

If available, use Safeguard software or a third party object security product to grant access to TFTP object files to necessary personnel, and deny access to all other users.

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

BP-SAFE-TFTP-02 Add a Safeguard Protection Record to grant appropriate access to the TFTPSRV object file.

Discovery Questions

Look here:

OPSYS-OWNER-01

Who owns the TFTP client object file?

Fileinfo

OPSYS-OWNER-03

Who owns the TFTPSRV server object file?

Fileinfo

OPSYS-OWNER-03

Who owns the TFTPCHLD object file?

Fileinfo

FILE-POLICY

Who is allowed to execute TFTP on the system?

Policy

FILE-TFTP-01

SAFE-TFTP-01

Is the TFTP object file correctly secured with the Guardian or Safeguard system?

Fileinfo Safecom

FILE-TFTP-02
SAFE-TFTP-02

Is the TFTPSRV object file correctly secured with the Guardian or Safeguard system?

Fileinfo Safecom

FILE-TFTP-03

Is the TFTPCHLD object file secured correctly?

Fileinfo

Information Exchange Facility (IXF) User Program

The Information Exchange Facility (IXF) is a standard protocol for file transfer support that uses minimal capability and minimal overhead.

Securing IXF Components

IXF should be managed similarly to FTP. See the discussion on Securing FTP with and without the Safeguard Subsystem above.

BP-FILE-IXF-01 IXF should be secured "UUNU".

BP-OPSYS-LICENSE-02 IXF must be LICENSED.

BP-OPSYS-OWNER-02 IXF should be owned by SUPER.SUPER.

BP-OPSYS-FILELOC-02 IXF must reside in $SYSTEM.SYSTEM.

If available, use Safeguard software or a third party object security product to grant access to IXF object files to necessary personnel, and deny access to all other users

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

Discovery Questions

Look here:

FILE-POLICY

Is IXF allowed to be used to transfer files on the system?

Policy

OPSYS-OWNER-02

Who owns the IXF client object file?

Fileinfo

OPSYS-LICENSE-02

Is the IXF object file licensed?

Fileinfo

FILE-IXF-01
SAFE-IXF-01

Is the IXF object file correctly secured with the Guardian or Safeguard system?

Fileinfo Safecom

Related Topics

Operating System Security

TCP/IP




HP NonStop Server Security 2004
HP NonStop Server Security 2004
ISBN: 159059035X
EAN: N/A
Year: 2004
Pages: 157

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net