Using FTP for file transfers between clients and the z/OS server offers a wide range of capabilities. Each FTP user who requests services from the z/OS FTP server requires prior authentification with a valid z/OS user ID and password – without enabling “anonymous FTP”. This user also needs a (UNIX) UID from the user’s OMVS segment if it is not provided by a default UID definition. After authentification, a wide spectrum of operations is then possible depending on the FTP server’s configuration and the authority granted to the user in the security system. You should know that z/OS FTP is not limited to simple file transfers. For example, you may also submit jobs and receive spool output within your FTP session by changing the “file type” accordingly. If enabled, you may even send SQL statements to your DB2 subsystem. Of course, the permission defined by your security system still represents the baseline for all available resources, functions, and operations.
It becomes immediately obvious that any weaknesses inside the security system’s definitions may immediately expose your z/OS system to high risk. Carefully consider a given user ID. It will make a difference, if it is used in a batch job, started in a task-related context, or used inside an FTP session coming from the outside. In a scenario based on the misuse of a highly privileged user ID via FTP-based remote access from “far away”, you probably do not want to grant all authority to this user ID, but restrict possible operations to “task-based” performance only. For example, you will not allow a JCL submission to all users, but only when it is specifically required. How can you solve this problem without disabling FTP completely?
SHER-BLOCK, the blocking component of SF-Sherlock, lets you establish smart command verification for FTP. Aside from supporting FTP, RACF, and console commands, it also monitors critical interfaces that allow hidden operations. Its highly flexible concept, which also supports whitelists referring to RACF definitions, lets you precisely control and log critical activities by setting up corresponding rules. Here are some sample blocking definitions provided in the standard plug & play rule set: a) prevent JCL submission in FTP, b) prevent disablement of RACF command logging via the “SETROPT NOSAUDIT” command, c) prevent the “Z EOD” system command from being issued in any TSO SDSF session, and much more. If your company’s IT requires SOX compliance, then SHER-BLOCK will let you finally setup fully-automated controls around FTP.