The FTP (File Transfer Protocol) server provides file access between remote systems. Information about using this utility is in the MultiNet User's Guide.
FTP is configured automatically during the MultiNet installation procedure. This chapter explains how to administer the FTP client and server.
Configuring the FTP client consists of creating a MULTINET:FTP.INIT file for site-specific purposes. When the FTP client is started, the commands in the MULTINET:FTP.INIT file are executed before the commands in the SYS$LOGIN:FTP.INIT file of the user running FTP. See the MultiNet User's Guide for more information about creating FTP.INIT files.
The FTP client censors the output of the NLST/LIST commands. A period (.) replaces unprintable characters.
If the logical name MULTINET_FTP_DELAY_TRANSFER_NEGOTIATION is defined, then the FTP client does not attempt to negotiate STRU O VMS transfer mode until after you have logged into the remote system successfully. You can define this logical at the user or system level.
$ DEFINE MULTINET_FTP_DELAY_TRANSFER_NEGOTIATION anything
If the logical MULTINET_FTP_SIZE_BEFORE_GET is defined to FALSE, NO, or 0 (zero) the SIZE command will not be sent before the GET command for a file. When the logical is not defined, or is defined to a value other than FALSE, NO, or 0, the SIZE command is sent. Any returned value is used to preallocate the file size and to report progress of a file transfer. Some FTP servers leave the file open accidentally after the SIZE command.
If the logical name MULTINET_FTP_NONPASV is defined, then the FTP client will start up in PASSIVE OFF mode. The default client behavior is PASSIVE ON.
Managing an FTP server may include the following tasks:
· Creating an anonymous FTP login (see the Configuring Anonymous FTP section).
· Creating an FTP server login command procedure (see the Creating an FTP Server Login Command Procedure section).
· Using log files (see the Using FTP Log Files section).
· Managing FTP security (see the Managing FTP Security section).
· Specifying a message at connect time (see the Specifying a Message at Connect Time section).
· Specifying UNIX-style listings (see the Specifying UNIX-Style Listings section).
· Specifying the maximum idle time before a connection times out (see the Specifying the Maximum Idle Time section).
· Using FTP server site commands (see the Using FTP Site Commands section).
· Using Network Service Monitoring (see the Network Service Monitoring section).
· Using Session Accounting (see the Session Accounting section).
To set up anonymous FTP access on your system:
1. Create an account named ANONYMOUS with the password GUEST. Any password works from the remote host but the account is validated with the password GUEST. Use the OpenVMS AUTHORIZE utility to create the account:
$ RUN SYS$SYSTEM:AUTHORIZE
UAF>ADD ANONYMOUS /PASSWORD=GUEST /OWNER="Anonymous FTP" -
/DEVICE=device/UIC=[uic]
UAF> Ctrl/Z
$
uic is the UIC to use for ANONYMOUS.
device is the device on which the directory [ANONYMOUS] is located.
2. Use the NOLOCAL, NOBATCH, NOREMOTE, and NODIALUP access restrictions to the ANONYMOUS login to prevent other forms of access. You set these restrictions by running AUTHORIZE and issuing the command:
UAF>MODIFY ANONYMOUS /NOLOCAL /NOBATCH /NOREMOTE /NODIALUP
3. To prevent access to the account through DECnet, do not grant the NETMBX privilege to ANONYMOUS. To make sure that ANONYMOUS does not have the NETMBX privilege, issue the following AUTHORIZE command:
UAF>MODIFY ANONYMOUS /PRIV=NONETMBX /DEFPRIV=NONETMBX
4. To restrict anonymous FTP access to the [ANONYMOUS] directory tree, use the NET-CONFIG utility SET ANONYMOUS-FTP-DIRECTORY and SET ANONYMOUS-FTP-ACCESS to set this access restriction. See the MultiNet Administrator's Reference for additional information about NET-CONFIG commands.
Anonymous FTP server processes are created with the process name *FTP_pwd,
pwd is the password the user specifies.
By convention, many people specify GUEST, their personal name, or their local user name for the password, because anything is accepted.
If you do not want to create FTP_SERVER.LOG files in the anonymous directory, assign a new default directory for the login with a directory restriction to make sure the log files appear in the correct directory. In this example, an alternate FTP directory is created for the log files:
$ SET DEFAULT SYS$SYSTEM
$ RUN SYS$SYSTEM:AUTHORIZE
UAF>MODIFY ANONYMOUS/DEVICE=SYS$COMMON:/DIR=[SYSMGR.ANONYMOUS]
UAF>EXIT
$ CREATE/DIRECTORY/OWNER=ANONYMOUS SYS$COMMON:[SYSMGR.ANONYMOUS]
$ MULTINET CONFIGURE
NET-CONFIG>SET ANONYMOUS-FTP-DIRECTORY USERS:[ANONYMOUS]
NET-CONFIG>EXIT
$
You can now control the setting of the MULTINET_ANONYMOUS_FTP_CONTROL logical name using either the network configuration utility (MULTINET CONFIGURE):
$ MULTINET CONFIGURE
NET-CONFIG>SET ANONYMOUS-FTP-ACCESS NOWRITE,NOSPAWN
NET-CONFIG>EXIT
[Changes take effect after the next MultiNet reload]
$
This is a new method for controlling the definition of that logical name. Other methods required you to define the logical name yourself during system startup. You can make the change take effect before the next system reboot by defining the associated logical name DEFINE /SYSTEM /EXECUTIVE_MODE MULTINET_ANONYMOUS_FTP_CONTROL "...". For example:
$ DEFINE /SYSTEM /EXECUTIVE_MODE
MULTINET_ANONYMOUS_FTP_CONTROL -
_$ “NOSPAWN,NODELETE”
The default setting is NOWRITE, NOSPAWN. See the table below for other options.
If you do not want to use the “anonymous” name, there is a logical that will allow users to use names which are not anonymous, but have the same anonymous account behavior. The MULTINET_ANONYMOUS_USERNAMES logical usage is shown in the following example:
$ DEFINE /SYSTEM /EXEC MULTINET_ANONYMOUS_USERNAMES _$“anonymous,user1,user2,..."
If you define this logical as shown in the preceding example and set the “user1,user2,...” accounts using the same password as the anonymous account, then the FTP server will treat “user1,user2,...” as an anonymous type of user.
The logical MULTINET_FTP_SERVER_DATA_PORT_RANGE specifies the range of port numbers to use for passive connections. The format is:
$ DEFINE /SYSTEM /EXEC MULTINET_FTP_SERVER_DATA_PORT_RANGE “<starting port number><end port number>”
When this logical is defined, the FTP server will use port numbers between the specified values for the data channel when operating in passive mode.
To limit user activities during an FTP session, edit the FTP_SERVER.COM file using this command:
$ MULTINET FTP/SERVER [qualifier]
The table below lists the FTP server qualifiers.
|
Qualifier |
Purpose |
|
/ACCESS=([NOLIST], [NOWRITE], [NOSPAWN], [NOREAD], [NODELETE]) |
Denies write or search access for this session; NOSPAWN disables the site SPAWN command; NOREAD prohibits read access. By default, /ACCESS=NOSPAWN is used for anonymous FTP sessions to prevent users from spawning commands. NOWRITE disables the storing of files. NODELETE disables the deletion/renaming of files. |
|
/DIRECTORY=(directory1,...) |
Restricts access to these directory trees (note plural). |
|
/GET_REMOTE_INFO |
Gets information about the remote system. This qualifier works by
defining the logical names MULTINET_FTP_ADDRESS,
Note! MULTINET_FTP_ANONYMOUS_PASSWORD is only set if the user name is "anonymous."
When MULTINET_FTP_DONT_REPORT_FILESIZE is defined, the estimate of the number of bytes to be transmitted is not included in the 150 reply line to a GET operation. |
|
/MESSAGE=message |
Displays a banner message when the user logs in. This message precedes the "User xxx logged in..." line. |
|
/REJECT |
Instead of accepting the connection, rejects the login with the error specified in the /MESSAGE qualifier. |
The MultiNet FTP server keeps a log of all FTP transactions that occur after login between the client and server in an FTP_SERVER.LOG file in the user's login directory on the server system. A log file is created for each FTP client session. The previous log is overwritten when a new session starts, but you can specify a number of log files to retain.
Note! If the MultiNet FTP server process does not start or mysteriously disappears, examine the beginning of FTP_SERVER.LOG for error messages. Because the system-wide login command procedure (SYS$MANAGER:SYLOGIN.COM) and the user's LOGIN.COM are executed as part of the server process creation, errors in these procedures can cause the server process to terminate. In most instances, however, the reason for the process terminating appears at the beginning of the FTP_SERVER.LOG file.
The following sample log file contains the FTP transactions involved when the user logs in under the user name HOLMES, issues a DIRECTORY command, and then retrieves the file FOO.BAR.
-------------------------------------------------------
FTP Login request received at Wed Jun 14 19:05:10 2015
from remote IP address 127.0.0.1
-------------------------------------------------------
>>> 230 User HOLMES logged into U1:[HOLMES] at Wed 07-Jun-2015 19:05,
job 3a.
<<< TYPE A
>>> 200 Type A ok.
<<< STRU F
>>> 200 Stru F ok.
<<< MODE S
>>> 200 Mode S ok.
<<< PORT 127,0,0,1,4,14
>>> 200 Port 4.14 at Host 127.0.0.1 accepted.
<<< LIST
>>> 150 List started.
>>> 226 Transfer completed.
<<< PORT 127,0,0,1,4,15
>>> 200 Port 4.15 at Host 127.0.0.1 accepted.
<<< RETR foo.bar
>>> 150 ASCII retrieve of USERS:[HOLMES]FOO.BAR;1 started.
>>> 226 Transfer completed. 210 (8) bytes transferred.
<<< QUIT
>>> 221 QUIT command received. Goodbye.
HOLMES job terminated at 11-JUN-2015 19:05:23.08
By setting the logical name MULTINET_FTP_SERVER_LOG_LIMIT in the LOGIN.COM file, you can specify that log files be retained. Set the logical name to a dash (-) to retain all log files, or specify a number in the range of 1 to 32000.
Directory size restrictions limit the number of potential files that can actually be created. If you do not specify a number or value, one log file is created or overwritten for each FTP session. Use the DCL PURGE command to delete unneeded log files. The following example specifies that 42 log files be retained:
$ DEFINE MULTINET_FTP_SERVER_LOG_LIMIT 42
Because the FTP server process is started by running SYS$SYSTEM:LOGINOUT.EXE, both the system-wide login command procedure (SYS$MANAGER:SYLOGIN.COM) and the specific user's LOGIN.COM are executed. As a result, any customization (default file protection, process/job logical name definitions, and so on) done in these command procedures is available under the FTP server process.
All standard OpenVMS security-checking mechanisms also validate the FTP server process creation. If a login command procedure contains any commands specific to interactive jobs (for example, SET TERMINAL commands), the FTP server process may crash. To avoid this problem without altering the functionality of command procedures, use the DCL lexical function F$MODE with interactive commands. For example:
$ IF F$MODE() .EQS. "INTERACTIVE" THEN SET TERMINAL /INQUIRE
You can use the following logicals in the FTP_SERVER.COM command procedure to restrict specific users from some types of access:
· The following logical restricts username to accessing only the specified directories when connecting to the host using FTP:
MULTINET_'username'_FTP_DIRECTORY "directory-spec,..."
This logical is used in the FTP_SERVER/DIRECTORY-directory_spec,... qualifier.
· The following logical restricts username to only the type of access specified when accessing the host via FTP:
MULTINET 'username'_FTP_CONTROL "access-spec,..."
This logical is used in the FTP_SERVER/ACCESS=access-spec,... qualifier.
access-spec=[NO]LIST, [NO]WRITE, [NO]SPAWN, or [NO]READ
· The following logical limits the information given out on connection or when using the STAT command:
MULTINET_FTP_CONNECT_BANNER “FTP server name”
If this logical is defined as whitespace, operating system and TCP stack information is removed from the FTP server connection banner. If this logical is defined with a specific FTP server name, the information banner does not appear in response to the STAT command.
You can apply the logical MULTINET_FTP_DISALLOW_WILDCARD_DELETES to anything to disallow the new functionality of accepting wildcards on delete. This may be done at the process, group, or system level.
The MULTINET_FTP_ANNOUNCE logical provides a SYS$ANNOUNCE-style message along with the "220" banner at connect time. Define the logical in a fashion similar to SYS$ANNOUNCE, using one of the following commands:
$ DEFINE/SYSTEM MULTINET_FTP_ANNOUNCE "message text"
In the following version, the announcement is in the specified file:
$ DEFINE/SYSTEM MULTINET_FTP_ANNOUNCE "@file specification"
If you define the logical name MULTINET_FTP_UNIX_STYLE_BY_DEFAULT, the FTP Server starts in UNIX emulation mode.
The control of version number displays has been reworked in response to LIST and NLST commands. The default is VMS-mode output.
The logical name MULTINET_FTP_UNIX_STRIP_VERSION no longer has any effect. In UNIX mode, the FTP Server always removes version numbers from directory listings.
The logical name MULTINET_FTP_STRIP_VERSION causes VMS mode output to have no versions.
Note! It is recommended that you NOT use the MULTINET_FTP_STRIP_VERSION logical. Stripping version numbers from the VMS mode LIST output can cause problems for some FTP clients (notably WS_FTP).
The logical name MULTINET_FTP_ALL_VERSIONS requests the NLST and LIST commands to display all version numbers. If MULTINET_FTP_ALL_VERSIONS is defined, the logical name MULTINET_FTP_STRIP_VERSION has no effect.
Note! MULTINET_FTP_ALL_VERSIONS is ignored if the FTP Server is in UNIX emulation mode.
The FTP Server updates UNIX emulation improving MultiNet interoperability with various FTP clients. Features of the UNIX emulation mode are
· The syntax you use for a directory determines the mode you want. For example, CWD / uses UNIX mode; CWD [] uses VMS mode.
· The LIST command returns output similar to that produced by ls -al.
· The logical name MULTINET_FTP_UNIX_STYLE_CASE_INSENSITIVE allows UNIX style filename handling to be case insensitive.
· Mixed case file names and those with special characters are translated into legal OpenVMS file names using the NFS mappings.
· The directories listing uses UNIX syntax. For example, USERS:[MRUHL] becomes /users/mruhl.
· When changing directories or referencing files using an absolute UNIX pathname, directory lookups treat SYS$LOGIN as if they were the root directory (/). So, if SYS$LOGIN is USERS:[MRUHL],
/login.com refers to USERS:[MRUHL]LOGIN.COM and /multinet_common_root/multinet refers to USERS:[MRUHL.MULTINET_COMMON_ROOT.MULTINET] if that directory exists. If it does not exist, the first segment of the pathname is used as the device specification in a second lookup attempt, and /multinet_common_root/multinet refers to MULTINET_COMMON_ROOT:[MULTINET].
· If the FTP server is in UNIX mode, the SYST command displays the banner “UNIX MultiNet Unix Emulation.” If the FTP server is in VMS mode, the SYST command displays the equivalence string associated with the MULTINET_FTP_SYST_BANNER logical name (if defined). Otherwise, the SYST command displays “VMS MultiNet Vx.y(rev)”:
o Vx.y is the MultiNet version number.
o (rev) is the revision number of the FTP server.
Note! The logical name MULTINET_FTP_SYST_BANNER is ignored if the FTP Server is already in UNIX mode.
The FTP Server does not drop spaces in filenames. It converts them to the character sequence $7A.
The FTP Server protects privileged ports by not opening data connections to privileged ports.
The file open routines allow all modes to fetch data from a file open for write but marked for shared access.
The FTP service corrects synchronization problems resulting in messages repeatedly sent to the FTP client.
There is no PASV command interference with data link window sizing.
If you want the device name, the file name, and the directory name included in the results of all NLST commands, define the logical MULTINET_FTP_INCLUDE_DEVICE_IN_NLST. This logical may be declared system wide or in the user’s LOGIN.COM file.
The FTP Service corrects a problem with RENAME operations with UNIX-style file specifications. The RENAME operation overrides the current protection of the file to do the operation and then restores it afterwards. This is necessary because directories are created such that they cannot be deleted without changing the protection. To cause RENAME to observe the file protection, define the logical MULTINET_FTP_OBSERVE_VMS_PROTECTION to true.
An FTP default is to rename files by changing the final dot (.) to $5N. The logical MULTINET_FTP_DODROP1DOT lets you override this FTP default by dropping the final dot and NOT adding $5N.
VMS always implies that a dot is present in file names regardless of whether it is followed by an extension. VMS also does not support multiple dots in a file name. The rule FTP follows is that when there is only one dot, and that dot is the final character, the dot is converted to $5N. The resultant local file is then distinguishable from a similarly named file that did not have a dot. For example, “FILE.” becomes “FILE$5N” when using the FTP default; however, “FILE.” becomes “FILE” with the logical defined.
The FTP server displays the creation month, day, and year of a file for a UNIX mode directory if the file is older than 1 year (365 days). If the logical MULTINET_FTP_UNIX_YEAR_OLD_FILES is defined False, No, or 0 (zero), the old behavior is restored, displaying all files with Month, Day, and Time.
The logical MULTINET_FTP_DISALLOW_UNIX_STYLE controls whether UNIX-style filename parsing is done. The default value for MULTINET_FTP_DISALLOW_UNIX_STYLE is true (T), UNIX-style filename parsing is not handled. If you want UNIX-style filename parsing, you must define this logical as FALSE. When UNIX-style parsing is enabled, it is not normally done until a CD command has been done with a directory specification that contains a “/” in it. For example:
FTP> cd ../my_directory
Note! For some FTP clients (MultiNet is one of them) you will have to enclose the directory specification in quotes (“ ”) when it contains the “/” to prevent the client from attempting to parse it.
To exit UNIX-type filename parsing, use a CD command with either the “[” or “<” character in the directory specification. For example:
FTP> cd [-.my_directory]
$ DEFINE/SYSTEM/NOLOG/EXEC MULTINET_FTP_DISALLOW_UNIX_STYLE FALSE
Some graphical display FTP clients expect the output of directory commands to be in a UNIX system format. To enable this UNIX format, use the following either at the system level or in the user's LOGIN.COM:
$ DEFINE MULTINET_FTP_DISALLOW_UNIX_STYLE FALSE
and
$ DEFINE MULTINET_FTP_UNIX_STYLE_BY_DEFAULT ANYTHING
The MULTINET_FTP_MAXIMUM_IDLE_TIME logical specifies the length of time before an idle FTP server connection times out. The value is set in seconds, with a default of 300 seconds. If this logical is set to 0, timeouts are disabled.
The logical name MULTINET_FTP_FAST_TIMEOUT is equivalent to the settings in the logicals MULTINET_NAMESERVER_RETRANS and MULTINET_NAMESERVER_RETRY for the FTP server process to 5 and 2 respectively. This helps the FTP server start up faster when DNS PTR records for the client are improperly defined or nonexistent.
The table below lists the commands for controlling and configuring the FTP server from the FTP prompt.
|
Command |
Description |
|
SITE SHOW TIME |
Shows the time on the system the FTP server is running on. |
|
SITE NONE |
This is a NO OPERATION. |
|
SITE PRIV [privileges] |
Turns ON or OFF VMS privileges. If no privileges are specified, displays the current privileges. |
|
SITE RMS BLOCK [ON|OFF] |
Turns Block Image mode transfers ON or OFF, or if there is no argument, displays the current state.
When image (binary) transfers are done with Block Image mode OFF (the default), the FTP server opens VMS record files such that the record control information is not included in the data and a linefeed separates each record. With Block Image mode ON the record control information and the data are transferred. |
|
SITE RMS RECSIZE [value] |
With no argument, displays the current record size. With an argument, sets the record size for Image PUT transfers to the size specified. The default is 512. |
|
SITE SPAWN command |
Spawns a subprocess and uses the rest of the line as a VMS DCL command. Not valid for CAPTIVE processes. |
|
SITE RMS STREAM [ON|OFF] |
With no argument, displays the current state. When ON, writes text files in Stream-LF format. When OFF (default), writes text files as VMS carriage-control record files. |
|
SITE +VMS+ |
Enables VMS + mode transfers. |
|
SITE VMS |
Disables VMS + mode transfers. |
|
SITE WINDOW-SIZE |
With no argument, displays the TCP window size. With an argument, sets the window size for the data channel. Default value is 32768 bytes |
The MULTINET_FTP_221_REPLY logical lets you define the message users see when they end the FTP session. If you do not define this logical, MultiNet uses the default message instead “221 QUIT command received. Goodbye.” You can define a text string or file. If the string starts with the “at” sign @, it specifies the name of a file containing text to be displayed. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_221_REPLY -
_$ "Connection to FTP server has been closed"
Now, when the user closes the FTP connection, the following message appears:
221 Connection to FTP server has been closed
The MULTINET_FTP_230_REPLY logical defines a message to appear when a user successfully logs in. If you do not define this logical, MultiNet uses the default message instead. As with MULTINET_FTP_221_REPLY, you can define a text string or file. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_230_REPLY-
_$ "Login successful"
Now, when the user logs in using FTP, the following message appears:
230 Login successful
The MULTINET_FTP_ANONYMOUS_230_REPLY logical defines a message to appear when an ANONYMOUS user successfully logs in. If you do not define this logical, MultiNet uses the default message instead. As with MULTINET_FTP_230_REPLY, you can define a text string or file. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_ANONYMOUS_230_REPLY-
_$ "ANONYMOUS login successful"
Now, when a user logs in using the ANONYMOUS account, the following message appears:
230 ANONYMOUS login successful
The MULTINET_FTP_421_REPLY logical lets you defines the message users see when they connect to the server but should not log in. After sending the message, the connection closes. For example, you can define this logical to prevent FTP access for a short time period. Be sure to deassign the logical after this period to allow FTP access again. If the string starts with the “at” sign @, it specifies the name of a file containing text to be displayed. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_421_REPLY-
_$ "System maintenance in progress until 17:30"
Now, when the user connects to the host using FTP, the following message appears and then the connection closes:
421 System maintenance in progress until 17:30
The MULTINET_FTP_LOGFILE (system level, executive mode) logical can be defined to specify the name of a log file. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_LOGFILE-
_$ SYS$COMMON:[SYSMGR]FTPLOGIN.LOG
If this logical exists, the FTP server writes a record to the specified file each time a user attempts to log in. Each record includes the date and time, the remote host's internet address, and whether the login succeeded. This is especially useful to use if you suspect someone has tried to break into the FTP server.
This logical specifies the name of the file to which all commands and responses to ANONYMOUS FTP services are logged. If MULTINET_FTP_LOG_ALL_USERS is also defined, then commands and responses for all users are logged. If MultiNet is already running, the Master Server must be restarted (@MULTINET:START_SERVER) for these definitions to take effect.
The logical MULTINET_FTP_LOG_ALL_USERS causes all commands and responses to be logged to the file defined by MULTINET_FTP_LOGFILE. The default (when this logical is not defined) is to just log the commands and responses for anonymous users.
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_LOG_ALL_USERS TRUE
The FTP client and the FTP server normally check the record size of an ASCII transfer and disallow more than 8192 byte records (as a sanity check). However, you can define the MULTINET_FTP_MAXREC logical to override the default of 8192. The definition of the MULTINET_FTP_MAXREC logical is commented out but defined in the FTP_CONTROL.COM file as follows:
$ DEFINE/SYSTEM/NOLOG/EXEC MULTINET_FTP_MAXREC 8192
Note that the maximum record size supported by OpenVMS is 65535.
The MULTINET_DIRECTORY_MESSAGE_FILENAME logical can be defined to name the file you want to appear when a session enters a directory. For example:
$ DEFINE/SYSTEM/EXEC MULTINET_DIRECTORY_MESSAGE_FILENAME example.txt
This section describes how to define password messages in MultiNet.
The MULTINET_FTP_PASSWORD_WARNING_MESSAGE logical lets you define the message users see when their password is going to expire. If you want the amount of time before the password expires to be included, add %s to the logical.
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_PASSWORD_WARNING_MESSAGE %s
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_PASSWORD_WARNING_MESSAGE message
text string
The MULTINET_FTP_PASSWORD_WARNING_TIME logical uses the VMS delta time to specify the minimum remaining lifetime for the user's password. If the remaining lifetime is greater than the VMS delta time then no message appears. It is necessary to define this value to enable checking for the remaining lifetime of a password.
$ DEFINE/SYSTEM/EXEC MULTINET_FTP_PASSWORD_WARNING_TIME dddd hh:mm:ss.hh
The MULTINET_FTP_RECEIVE_THRESHOLD logical specifies the amount of buffer space that can be used to buffer transmitted data on the data socket. The default value if 6144. If this logical is defined and it begins with a /, then it specifies the fraction of the window size; if only a fraction is specified, then it indicates the number of bytes to be used. The ? in the logical represents where defined values go.
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_FTP_RECEIVE_THRESHOLD ?
The MULTINET_FTP_NOLOGIN_EXPIRED_PASSWORD
logical lets you prevent accounts with expired passwords from logging in.
$ DEFINE/SYSTEM/EXEC
MULTINET_FTP_NOLOGIN_EXPIRED_PASSWORD TRUE
will prevent a user with an expired password from logging in and displays the following message:
<Your password has expired; contact your system manager>
By default the MultiNet FTP server checks the IP address given in the port command and does not make the connection if the IP address does not match that of the control connection. This can be disabled by defining the logical MULTINET_FTP_SERVER_RELAXED_PORT_COMMAND.
$ DEFINE MULTINET_FTP_SERVER_RELAXED_PORT_COMMAND 197.0.0.1
Follow these steps to configure the MultiNet FTP server to allow TLS authentication:
· Generate or obtain certificate and key files. On OpenVMS V8.3 and higher SSL$COM:SSL$CERT_TOOL can be used to do this.
· Place the certificate and key file where you want them and verify that the protection is set such that world has no access.
· Using MULTINET CONFIGURE/SERVER select FTP and set the RFC-4217-CERTIFICATE and RFC-4217-KEY parameters to the location of the appropriate files. Optionally set the REQUIRE_TLS parameter to YES.
· Restart the MultiNet master server - @multinet:start_server restart
RFC4217-CERTIFICATE Specifies the certificate file to be used with RFC 4217 negotiation. The certificate and key files must be created by an external means such as the SSL certificate tool and be in PEM format. Both a certificate and key file must be specified set up to allow TLS negotiation. On OpenVMS V8.3 and higher you can use @SSL$COM:SSL$CERT_TOOL.
RFC4217-KEY Specifies the private key file to be used with RFC 4217 negotiation. The certificate and key files must be created by an external means such as the SSL certificate tool and be in PEM format. Both a certificate and key file must be specified set up to allow TLS negotiation. On OpenVMS V8.3 and higher you can use @SSL$COM:SSL$CERT_TOOL.
REQUIRE-TLS YES Specifies that user authentications other than anonymous and users that have no password must use TLS authentication. The FTP USER command will get a 530 response if it is issued before TLS authentication has been done. This prevents passwords from being exchanged in clear text mode with the users.
FTP’s network service monitoring is based on RFC 2788 (Network Services Monitoring MIB). Information is maintained only while the service is active. The following items from the Network Services Monitoring MIB (RFC 2788) are available in the enterprises.105.2.25 MIB:
|
ApplAccumulatedInboundAssociations |
(Counter) the total number of connections that the FTP Listener program has serviced since it was started. enterprises.105.2.21.10 |
|
ApplDescription |
(String) Description of the program/application. This is the banner that gets printed when the client connects to the FTP Listener program. enterprises.105.2.21.16 |
|
ApplInboundAssociations |
(Counter) The number of connections currently active. enterprises.105.2.21.8 |
|
ApplIndex |
(Integer) unique application index. The port FTP is offered on (21). enterprises.105.2.21.1 |
|
ApplLastChange |
(TimeTicks) the value of sysUpTime when the FTP Listener program entered the current state. enterprises.105.2.21.7 |
|
ApplLastInboundActivity |
(TimeTicks) the value of sysUpTime at the time the most recent connection was established. enterprises.105.2.21.12 |
|
ApplName |
(String) FTP. enterprises.105.2.21.2 |
|
ApplOperStatus |
(Integer) the operational status of the FTP Listener program; the values are: up(1), down(2), halted(3), congested(4), restarting(5), quiescing(6). Some of these values may not be used. enterprises.105.2.21.6 |
|
ApplRejectedInboundAssociations |
(Counter) the number of connections that have been rejected (due to not being allowed from the access list values). enterprises.105.2.21.14 |
|
ApplUptime |
(TimeTicks) the value of the SNMP variable sysUpTime when the FTP
Listener program was started. This time has a resolution of 5 minutes. |
|
ApplVersion |
(String) the version of the FTP Listener program. enterprises.105.2.21.4 |
This feature requires the SNMP Agent X functionality. To use this SNMP must be configured to have Agent X service enabled, and to allow the system's IP and the local host addresses (127.0.0.1) to each be an AGENTX_PEER. See Chapter 23 for more information on SNMP and Agent X. This information can be displayed with the MULTINET SHOW/SNMP command and can be displayed with a MIB browser.
To enable network service monitoring, do the following:
$ MULTINET CONFIGURE /SERVER
SELECT FTP
SET FLAGS SNMP_MONITORED | PASS_FOREIGN_SOCKET
WRITE
EXIT
$ @MULTINET:START_SERVER
Any service using TCP_INIT, TCP_LISTEN, and TCP_CONNECTED routines may use SET FLAGS SNMP_MONITORED. The level of functionality may vary with the service.
MultiNet can record accounting information from services that have been enabled. Currently this includes FTP and SMTP. The accounting information includes information about when a network session took place and how much data was transferred. The accounting facility is enabled by setting the accounting port and the accounting host and reading MULTINET:ACCOUNTING.CONF for additional configuration information. The format of the accounting records is described in MULTINET_ROOT:[MULTINET.EXAMPLES]ACCOUNTING.H
A sample program using this is in MULTINET_ROOT:[MULTINET.EXAMPLES]ACC_DUMP.C
You must configure FTP and session accounting in order to activate the accounting function. FTP-ACCOUNTING-HOST is the name of the system running the accounting program. FTP-ACCOUNTING-PORT is the port number that the program was set up to listen on. FTP accounting can be configured with the following:
MULTINET CONFIGURE /NETWORK
SET FTP-ACCOUNTING-HOST name
SET FTP-ACCOUNTING-PORT number
WRITE
EXIT
In order for accounting to be activated before your next reboot, you can define the logicals as follows:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_FTP_ACCOUNTING_HOST lillies
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_FTP_ACCOUNTING_PORT 1234
Note! The accounting port must be set to an unused port, not the port for the service on which accounting is being enabled.
The next section explains how to configure the file.
The collected accounting information can be displayed with the MULTINET ACCOUNTING command. See Chapter 1 of the MultiNet Administrator’s Reference for more information about the MULTINET ACCOUNTING command.
The Accounting configuration file is MULTINET:ACCOUNTING.CONF. The accounting configuration file defines:
· The port the accounting program listens on. This should be an unused port, not the port for the service on which logging is being enabled, and the same port specified to FTP or SMTP.
· The name of the file used for accounting records. This file is opened shareable and new records are always appended to it. To start a new file stop the accounting program, delete (or rename) the existing file, and restart the accounting program.
· The IP addresses of systems that are allowed to write accounting records to this host.
Note! After editing the configuration, stop and restart the Accounting program so that the changes can take effect.
Follow these guidelines when entering data in the accounting configuration file:
· Allow one line for each item.
· Enter information in any order; in upper- or lowercase.
· Use a pound sign (#) or exclamation point (!) to denote comments. The accounting facility ignores all information following these characters.
The commands that can be in MULTINET:ACCOUNTING.CONF are:
|
PORT port_number |
The TCP port that the accounting program should listen on. |
|
PEER ip-address |
The IP address of a host that is allowed to log records with the accounting software. |
|
FILENAME filename |
The name of the file that the accounting records will be written to. The MULTINET: device is assumed if a device is not specified as part of the file specification. |
To enable the FTP accounting logger, do the following:
$ MULTINET CONFIGURE/SERVER
ENABLE ACCOUNTING
WRITE
$ @MULTINET:START_SERVER
To view accounting information, do the following:
$ MULTINET ACCOUNTING/INPUT=accounting_data_file [/output=output_filename]
-
_$ [/since=start_date] [/before=end_date]
[/protocol={SMTP, FTP, MAIL}] [/CSV]
· accounting_data_file is the name of the logging file you want to see.
· output filename is the name of the file you want to call this information. If this field is omitted, the information displays to the terminal screen.
·
start_date is the beginning date you want
the command to start with. The date format is
[DD-MMM-YYYY
[:]] [hh:mm:ss]cc] If not specified, all records display
up to the end of the data found.
· The time is always in local time.
·
end_date is the ending date you want the
command to end with. The date format is
[DD-MMM-YYYY
[:]] [hh:mm:ss]cc] If not specified, all records display
until the end of the file.
· protocol is any combination of SMTP, FTP, or MAIL.
· CSV is the Comma Separated Values, for input to products like Excel.
The accounting file is written using OpenVMS RMS records. The format of these records is defined in MULTINET_ROOT:[MULTINET.EXAMPLES]ACCOUNTING.H, and listed below:
/*
* PDU format
*/
struct accountingPDU {
char version;
char type; /* type of record */
/*
* FTP:
* C - Client
* S - Server
*
* SMTP:
* N - Network delivery (send)
* L - Local delivery (received)
* F - Forwarded
* R - Returned
* D - Delivery Receipt
* Q - ReQueued
*
*/
char flags; /* not currently used */
char reserved; /* for future use */
int payload_length; /* length (in bytes) of data after header */
int port; /* IP port of reporting service - 25 SMTP, 21 - FTP */
int reporterIP; /* IP address of reporter */
};
struct FTPaccounting_data {
struct accountingPDU header;
int start_time[2]; /* VMS time that session started */
int end_time[2]; /* VMS time that session ended */
int datasent; /* KBytes of file data sent */
int datarecv; /* KBytes of file data received */
int filessent; /* Number of files sent */
int filesrecv; /* Number of files received */
int partnerIP; /* IP address of partner */
char user[12]; /* username that operations were done under */
};
struct SMTPaccounting_data {
struct accountingPDU header;
int date[2]; /* Time of activity */
int msg_size; /* size of message in bytes */
int from_str_size; /* size of From: string */
int to_str_size; /* size of To: string */
char from_to_str[1]; /* text of From & To string */
};
#define accounting_Close 1
typedef struct accounting_peer_info {
struct accounting_peer_info *next;
ulong ia;
} accounting_peer_info;
#define MAX_STRING_LEN 255
The Network Service Monitoring and Session Accounting have not yet been updated for IPv6. The same logicals and command files are used for both FTP over IPv4 and FTP over IPv6. When IPv6 is in use FTP uses the EPSV and EPRT commands. Other than the differences noted, FTP over IPv6 should be the same as FTP over IPv4.