Years ago when we all started using FTP as a method of delivering data from one machine to another a need was created to log transactions and add security.
On the IBM i, the native FTP server did not have many (if any) logging or security features. Because of our needs, as well as many customer requests, we created FTPTOOL.
FTP Server Logging
The first feature FTPTOOL adds is logging FTP activity from the FTP Server on your IBM i. This logging can be turned on or off at a global level, and also turned on or off at a User ID level. This means that if you're only curious about a couple different user's FTP activity you can log only them. Or, you can choose to log all activity (and then turn off logging for your own or any other User ID).
The layout of the FTP Log file is as following (compliments of the free List File Field Description (LSTFFD) utility):
As you can see, there is pretty much all the information available that you would need.
Even attempts to log on are recorded. So, if you want to see if people are finding your IBM i and trying to log in through FTP, just make sure logging is turned on and start your detective work.
Initial connections will be logged under the user ID QTCP with an operation of Connect. The User ID will be QTCP because when someone first connects to the FTP server, they haven't attempted to log on and there is no associated User ID. But, you'll also have the IP address of the attempt which can be useful in tracking down malicious behavior.
If someone does attempt to log on just randomly trying User IDs and passwords, those will also be logged.
Initial FTP Library or Directory at a User Level
One issue with the FTP Server on the IBM i is that the initial location (ie, the library system or the IFS) can only be set at a global level.
With FTPTOOL you have the option to override this at a user level. This means that the default setting for the FTP server's initial name format (found using the Change FTP Attributes (CHGFTPA) command) is the default for all users. But, using the FTPTOOL User Maintenance you can override this setting at a User ID level.
First, use the FTPTOOL command to enter the User Maintenance Screen:
Select option 2 (Default Directory) next to the user you want to set up a default FTP directory for and you're presented with the following screen:
We can now enter the IFS path that we want to be the default directory for this user.
No stopping and starting of the FTP server is required for this change to take affect. The next time the user logs on to your IBM i using FTP they will automatically start in the directory provided:
Locking Down FTP Commands at a Global or User and Library/Directory Level
If your IBM i is used in production as an FTP server where you allow users to connect and either retrieve and/or drop off files, you most likely will want to contain the users that log on to specific libraries or directories.
FTPTOOL allows this feature and it all starts at the global level using the FTPTOOLDFT command. This is where we set up the default security settings that will apply to users that are not set up in the FTPTOOL User Maintenance application.
Once these defaults are set, we can go into the FTP application and at a user level (or even deeper, a user/IP address level) allow, disallow, or conditionally allow (depending on the library or directory) each specific FTP command, one by one.
First is to issue the FTPTOOL command so we are in the FTPTOOL User Maintenance screen:
Next, use option 9 next to the user that you want to limit the FTPTOOL commands for. This will bring you into the FTPTOOL Operation Maintenance Screen.
We decided to limit user BVSTONE (hey, that's me!) so that they can only use GET in /home/bvstone. We are also going to turn off the ability for them to use the CMD command which is used to run remote commands through the FTP interface.
So, we set up the GET FTP command as type "R" for Restricted, and then set up the restricted path of /home/bvstone. We also set up the CMD FTP command as type N for Not Allowed. Any commands not listed here will default to the values in the FTPTOOLDFT command.
Now, when we FTP to our system we can see what's allowed, and what is not:
First we retrieve test.txt from the /home/bvstone directory and all is well. Next, we try to retrieve the same file from the /tmp directory. But, because the GET command is limited for user BVSTONE to only the directory /home/bvstone, the request is rejected. Finally, we attempt to run a command and it is not allowed because we have chosen to not allow user BVSTONE to run a command by blocking the FTP CMD command.
Another very popular feature of FTPTOOL is the option to call a command or program when a specific user runs a specific FTP command. This is again done from the FTPTOOL operation maintenance.
Let's assume that every time user BVSTONE performed a PUT on our system we wanted to alert QSYSOPR. We simply go into the operation maintenance for user BVSTONE, add the FTP command we want to set the trigger up for (in this case, PUT) and set it's use (allowed, or restricted to certain library(ies) or directory(ies). Then, use option 10 to work with the commands to trigger:
Selecting option 10 next to an operation will take use to the FTPTOOL Command Maintenance screen.
The command that we entered is as follows:
SNDMSG MSG('User &U performed action &O for file &F from IP address &I.') TOUSR(*SYSOPR)
You'll notice that we have some replacement variables in the command.
So, if we issue a PUT for a file to our IBM i, we now see that QSYSOPR has the following message:
So, as you can see, FTPTOOL will not only help lock down your IBM i FTP server, but it can also add some neat automation possibilities which are customizable down to the user id level!
The official FTPTOOL documentation can be found at http://docs.bvstools.com/home/ftptool/docs.
FTPTOOL can be downloaded from http://www.bvstools.com/ftptool.html and with all of our software, free demos are available.