An effective way to reduce the risk of suffering an outage from malware is to stop sharing directories containing critical data and/or shares that expose large portions or the entire system (such as a share to root (‘/’), /QOpenSys or /QSYS.LIB.) Great advice, but how can you determine whether the share is in use and, if it is, who’s using it?
The profiles currently attached to a share are easily viewed using Navigator for i. Simply sign in, click on the file system icon -> file shares. This view shows the number of profiles currently attached. Right click on the share and choose Properties. If you scroll down, this window displays the name and IP address of currently attached profiles. But this view is a point in time. Relying on this view means that you may be missing the service account that only attaches during nighttime processing or users that log in after you’ve displayed the properties for example. So how do you find the complete list?
The File Share category in New Nav shows the number of connected users.
If you have IBM i 7.4 or later, the easiest way to determine which profiles are using file shares is to start Authority Collection on each of the paths that are currently shared. Here’s an example of discovering who’s using the PAYROLL share.
First, configure authority collection on the path associated with the PAYROLL share:
CHGAUTCOL OBJ('/payroll_upload') AUTCOLVAL(*OBJINF)
Then start the collection if you haven’t done so previously:
STRAUTCOL TYPE(*OBJAUTCOL)
Once enough time has passed that you know the file shares should have been used, run the following from a Run SQL Scripts window:
SELECT authorization_name as User_profile,
check_timestamp,
job_name,
job_user,
job_number
FROM qsys2.authority_collection_fsobj
WHERE job_name LIKE 'QZLSFILE%'
AND upper(path_name) LIKE '/PAYROLL_UPLOAD%';
stop;
The result will be a list of profiles showing the date and time the user accessed the system via the PAYROLL file share. I encourage you to carefully scrutinize this list. Just because a profile is currently accessing a share doesn’t mean they have a business need to do so. It’s possible that when the user mapped a drive to the file share and the ‘Reconnect at signon’ box was checked. Because of this, a connection is constantly re-established even though there is no current business need to do so. Or, a user may once have needed a daily connection but they’ve changed roles and no longer need access. Reviewing the list of profiles currently accessing the share and stopping the automatic re-connection is a critical part of reducing the risk of malware infection. Fewer users mapping a drive to IBM i lowers the risk of malware infection. Note: If the list is empty, the file share wasn’t used while authority collection was active.
