HP Integrity NonStop H-Series - Manual (Page 154)

NOTE: If Safeguard is brought down for any reason, although the frozen users remain
frozen, they behave as if they were unfrozen (or thawed) thus losing the added security
provided.
To enable the Guardian anonymous user support, the NULL.FTP user needs to be thawed.
However, once this is done, the NULL.FTP logon with the password “guest” becomes
accessible outside of FTP. Sites using Safeguard ACLs to secure their system, must take this
into consideration and secure not only volumes, subvolumes and files, but also processes,
terminals and devices.
•
For a secure OSS environment, the system administrator should freeze the alias “anonymous”
and “ftp” user (for the purpose of disabling the anonymous access outside of FTP) as shown:
SAFECOM
=freeze alias anonymous
=freeze alias ftp
•
In the OSS environment, the initial root directory (that is, /guest/ftp) and other subdirectories
specifically set up by the system administrator for the anonymous user should be owned by
the super user ID or some special user ID. By not allowing these directories to be owned or
reside in the same group as the anonymous user prevents the anonymous user from altering
the security access. The OSS initial directory should not be a /E or any directory on a remote
system because this is invalid and the anonymous logon will be denied. The /G (Guardian
initial directory) is also invalid and will cause the anonymous logon to be denied.
CAUTION: Users who wish to support the anonymous FTP writes must be aware of the
inherent security risks. In order to provide this capability in a secure manner, one currently
known safe practice is to put all the files generated by anonymous FTP writes into a write-only
area (that is, not readable by the anonymous FTP user). After careful inspections and approvals
have been made according to site policies, these files are later manually moved into a read-only
area (for the anonymous FTP user) by the FTP system administrator.
•
Access to the OSS files and directories is controlled by the POSIX.1 file permission bits. No
additional level of security is provided. Using the CHMOD command, the nine permission bits
should be setup to restrict the anonymous user’s files and directories access. The nine permission
bits can be shown with the list long directory contents command as follows:
/guest/ftp: ls -l
total 987
drwxr-xr-x 1 super super 1024 Nov 22 15:58 tprog
-rw-r--r-- 1 super super 36001 Mar 7 10:47 tcp1_rfc
-rw-r--r-- 1 super super 34000 Mar 8 11:00 tcp2_rfc
-rw-r--r-- 1 super super 27500 Aug 20 13:00 tcp3_rfc
-rw-r----- 1 super super 10370 Jun 27 11:00 xfile
The directory (d) or file (-) field precedes the three types of user (Owner, Group, Other) with
three types of permissions (read, write, execute).
The anonymous user would be categorized as an “Other” user. Therefore, the last three
permission bits determine the anonymous user access. The r (read) and x (execute) permission
bits on a directory must be set to allow “Other” users (that is, FTP anonymous users) to access
the directory.
•
In the OSS environment, care should be taken that no OSS files under the anonymous user
root directory are linked to Guardian files. In other words, symbolic links connecting OSS files
to /G Guardian files must not be configured for the OSS anonymous user. Users should not
have any symbolic links referring to directories or files outside the subtree, since such directories
and/or files will be inaccessible to the anonymous user. It is best to avoid all absolute symbolic
links (those whose contents begin with “/”) within the subtree, since these links will be
154 Anonymous FTP