Unveiling the Truth: The Risky Business of IBMi FTP and How to Secure Your Data
FTP (File Transfer Protocol) is a popular method for transferring files between different systems, including IBMi servers.
While FTP is a convenient way to move files, it can also be used to submit IBMi commands to the system.
Unfortunately, this can create a security risk, especially for users with basic authority levels.
Here is an example of how you can submit remote commands from a windows PC using the command line.
In the above script I've created a new library, this of course I then have access to.
After that I've run a command that is available with my basic user profile to display my user profile and any other user profiles I have access to, that information is written into a file in my library.
I've then run a command that copies that data from that database file into a csv file in my default folder in the IFS. So far so good - I'm only using what I am authorized to use. Then I upload that newly created text file to my PC and open it with Open office calc.
Now I've spotted a potential mis-configuration, I can see one other profile that has far more authority than I've been given.
The reason I can see these is because the Object authority on the other user profile is set to *PUBLIC.
When companies install 3rd Party software sometimes the install procedure creates user profiles to own the objects of that application, these profiles need to be checked in case they have *PUBLIC *use authority.
This is where un-secured/un-audited ftp becomes a real risk.
Now we are in the realms of what I am not authorized to do if this was a live system - and of course I urge you to only do what you are authorized to do or what your company policies allow.
Looking at the special authorities PDOWNER still has *USER class however it has *ALLOBJ authority which gives this profile authority to all objects on the system.
If I submit the same job DSPUSRPRF as PDOWNER , I can list ALL the user profiles on the system.
Looking at the submit job you can see I've added the USER(PDOWNER) to the end. Now I can see all the user profiles on the system. My example just shows the IBM defined profiles.
Now you have a list of all the user ID's on the system you could check each one for a default password or even try and obtain the password by various other means.
You can also have access to a command that will outline all the files on your system you are actually authorized to use :-
quote rcmd SBMJOB CMD(DSPOBJD OBJ(*ALLUSR/*ALL) OBJTYPE(*FILE) OUTPUT(*OUTFILE) OUTFILE(FTPLIB/FTPTEST)) USER(PDOWNER)
Data theft can still be achieved through the use of the previous commands. This involves saving a list of objects to a data file, which can then be transferred using CPYTOIMPF with the higher authority of another profile.
A concerning issue arises when working on a system that relies solely on menus for security, and you have access to the underlying files. This is because, if the FTP server is active and unsecured or not audited, you can bypass the menu security by submitting commands through the FTP server, which could potentially leave your IBMi system vulnerable to internal or external abuse.
On to Securing your data
Without a security product installed on your IBMi system, FTP commands can operate undetected, without triggering any alerts. As a result, any attempt to use IBMi's auditing products will only record the access after the fact, without blocking it in real-time.
If you have the IBMi Audit journal active you will see the create library commands and the create file commands so watch out for those, again this will be after the fact.
Using the limited capabilities will mitigate this, however "limit some" will not.
So using ftp is a minefield if you do not have tight control of this server.
Using a product like Enforcive will give you this.
The ftp server access control gives me granular control of various ftp functions and further I can decide which libraries can be modified if so required.
the "..." button allows this
Just select/omit and tick.
On the audit side every command I've submitted is logged and either allowed or rejected.
And every command is logged
Enforcive can also be configured to alert in real time when these commands are executed.
To prevent this type of security breach, it's important to limit access to the FTP server and to ensure that users with access only have the authority necessary to perform their job duties. It's also a good idea to monitor FTP activity and to look for unusual activity, such as users submitting commands that they wouldn't normally have access to.
In summary, while FTP is a useful tool for transferring files, it can also be used to submit IBMi commands and potentially circumvent security measures in place. By limiting access, monitoring activity, and configuring the FTP server to restrict certain commands, organizations can help reduce the risk of unauthorized access and maintain the security of their IBMi systems.
Contact me if you would like to see this product in action, via my LinkedIn profile or our contact form here..