Anatomy of IBM i IFS and Windows network shares

Today we’re exploring the IBM i File Server exit point QIBM_QPWFS_FILE_SERV - specifically the PWFS0200 format.  This exit point (like many others) is provided by IBM as a “hook” into the operating system.  User-written programs (or commercial products) can be registered at these exit points to provide enhanced functionality, such as security.  

For the purposes of this article, the most important detail from IBM’s exit point documentation is the “requested function”.  These are the possible operations that can be requested by the client (Windows) system:

X’0000’ - Change file attributes request
X’0001’ - Create stream file or directory request
X’0002’ - Delete file or delete directory request
X’0003’ - List file attributes request
X’0004’ - Move request
X’0005’ - Open stream file request
X’0006’ - Rename request
X’0007’ - Allocate conversation request
X’0008’ - Copy request

In the case of function X’0005’ a file can be opened with different access levels (read, write, read/write, delete allowed).

When one of these functions or “transactions” occur, IBM i provides these details to the exit program.  From there, the program logic can log the details, or even take action such as denying the request.

You can view this exit point on your own system using the WRKREGINF command. There you’ll find two exit point formats.

As shown below, Kisco’s SafeNet/i exit point security product is installed in this LPAR, and the SAFENET exit program is registered at this exit point for the PWFS0200 format.

SafeNet can monitor and log the traffic (transactions) that come across this exit point. This includes “Netserver” mapped network drives, as well as the ACS IFS plugin tool. We will explore the anatomy of mapped Windows network drive traffic here. A future article will cover the ACS IFS plugin. Let’s begin!

---

Mapping the network drive:

For the purposes of this article, we have connected the “Z:” drive in a Windows workstation to a NetServer file share called “tmp” on the IBM i. On the IBM i server the “tmp” share is (intuitively) mapped to the /tmp IFS directory. The work that we perform in the Z:\ drive on Windows will actually happen in the /tmp directory on the IBM i.

When the drive mapping was performed, SafeNet captured an X’0007’ transaction which is the initial connection or “conversation allocation” with the file server.

Create a new directory using Windows command prompt:

We’ll start our testing using the Windows command prompt, as it provides a simple interface for performing basic operations like creating directories/files and navigating between directories.

First we switch to the Z: drive and create a new directory called “newfolder”. From an exit point perspective, SafeNet captured an X’0001’ operation, which is the creation of a new stream file or directory. No other transactions occur across the exit point in this scenario.

Listing directory contents using Windows command prompt:

Next we used “cd” to navigate into the “newfolder” directory and then used the “dir” command to list the contents. At the *FILESRV exit point we see an X’0003’ or “List Directory” operation.

Create a new file using Windows command prompt:

From the command line we created file called “filename.txt”. This resulted in two different transactions at the *FILESRV exit point. First, we see an X’0001’ or “Create Stream File or Directory” operation, followed by an X’0005’ or “Open Stream File for UPDATE”. This is intuitive, as the file was created and then “This is the file content” was written into it.

Read from an existing text file:

We can verify the contents of the new file and also review what this looks like from the exit point perspective. Here we used “type” to display the contents of “filename.txt”. SafeNet captured an X’0005’ “Open stream file for READ”.

Appending data to a file:

Here we simply added another line of data into our text file. Predictably, this is an X’0005’ operation where the file is opened for UPDATE. We saw the same thing in the earlier step where we originally created this file.

Renaming a file from Windows command prompt:

Next we renamed our test file. From the exit point perspective, the behavior is predictable. The rename resulted in an X’0006’ Rename operation. SafeNet captured the file that was renamed, and the new name of the file.

Moving a file from Windows command prompt:

Here we moved the test file from “newfolder” into the parent directory Z:\. Once again the transaction recorded at the exit point is intuitive. This resulted in an X’0004’ Move request. We can see the file that was moved, and the IFS location to which it was moved.

Deleting a file from Windows command prompt:

Lastly, we navigated to the parent directory and deleted our test file. This resulted in an X’0002’ Delete file or Directory transaction. SafeNet captured all of the important details, including the timestamp, user, client IP address, and file name that was deleted.

Using Windows Explorer:

Performing these operations in a command window was useful, but we also want to see what these transactions look like when they’re performed using Windows Explorer.

Since Windows Explorer is a GUI, it retrieves directory/folder contents whenever you open a folder. Therefore, when we simply open the Z: drive using Explorer we immediately see an X’0003’ or “List Directory” operation. In fact, Explorer seems to be unnecessarily “chatty” and performed this operation four times, as shown in the SafeNet transaction review screenshot. Each of these transactions was identical.

Windows Explorer also retrieves the folder contents periodically, completely unprompted. If you simply have the directory open with Explorer, it will occasionally retrieve a new directory listing to check whether anything has changed (files deleted, new files created, file attribute changes, etc).

Create a new directory using Windows Explorer:

In this test we right-clicked inside the Z:\ directory and clicked New>Folder.

Windows immediately creates a new folder called “New folder”, then prompts us to type the desired folder name. We gave it the name “anotherfolder”. Within SafeNet we can see that this action resulted in multiple transactions:

1. X’0001’ – This function indicates the creation of a stream file or directory. In this case a new directory called “New folder” was created
2. X’0003’ – This is a directory listing, which Windows actually performs twice
3. X’0004’ – This is a “move request” which occurred after we gave the folder the name “anotherfolder”. SafeNet captures the directory that was “moved” and the new name of the directory.
4. X’0003’ – Windows again performs two more directory listings

This is what we mean when we say that Windows Explorer is “chatty”. It’s also interesting that the directory “New folder” is MOVED to become “anotherfolder”. It is a MOVE operation rather than RENAME.

Create a new file with Windows Explorer:

Next we navigated into our “anotherfolder” directory by double-clicking on it, then right-clicked and chose New>Text Document. Windows created a file called “New Text Document.txt” and prompted us to give the file a new name. We chose “anotherfile.txt”.

From the exit point perspective, this simple operation created a number of transactions.

1. X’0003’ – First, Windows requested a new directory listing of the /tmp parent directory (twice!)
2. X’0003’ – Next Windows requested a directory listing of /tmp/anotherfolder
3. X’0001’ – Finally Windows has gotten around to our request and created “New Text Document.txt”
4. X’0005’ – Windows then opened the new file for UPDATE
5. X’0003’ – Again a directory listing was performed on /tmp/anotherfolder, presumably to update the display to show the existence of the new file
6. X’0003’ – And again Windows retrieved the contents of the parent directory “/tmp” for an unknown reason (TWICE!)
7. X’0006’ – This is a RENAME request. The file “New Text Document.txt” was renamed to “anotherfile.txt”
8. X’0003’ – Lastly, Windows listed the contents of /tmp/anotherfolder to reflect the new file name

As you can see, this is a lot of transactions for the simple creation of a file!

Read from a file:

So now we’ve created a text file. Let’s double-click on it to see the contents. (Spoiler alert: it is empty!) In SafeNet we see 3 transactions occur (the second one occurs twice):

1. X’0005’ – open stream file for READ
2. X’0003’ – list the directory contents of the parent directory /tmp (TWICE!)

Write data into a file with Notepad:

What if we update the file? We can type some text into it and then Ctrl-S to save it! In this case we see one simple X’0005’ operation – Open Stream File for UPDATE.

Rename a file:

Now we can rename the file using Windows Explorer. We changed it to “newfilename.txt” and four transactions occurred:

1. X’0003’ – List the contents of the /tmp directory (TWICE AGAIN!)
2. X’0006’ – This is the rename request
3. X’0003’ – List the contents of /tmp/anotherfolder to reflect the new file name

Move a file:

We can also move the file by drag-and-drop or cut/paste. Here we will “cut” the file from its current location (Z:\anotherfolder\newfilename.txt) and paste it into the Z:\ drive. This process generated 10 exit point transactions, as we had to navigate up into the Z:\ drive before performing the “paste” which resulted in even more X’0003’ directory listing transactions.

1. X’0003’ - /tmp (twice)
2. X’0003’ - /tmp/anotherfolder
3. X’0003’ - /tmp (twice more!)
4. X’0004’ – this is the Move operation, moving the file from /tmp/anotherfolder to /tmp
5. X’0003’ – and FOUR MORE TIMES for good measure, a listing of the contents of /tmp

Delete a file:

Lastly, we will delete the file “newfilename.txt” using Windows Explorer with a right-click and “Delete”. After confirming deletion at the prompt, three exit point transactions were recorded:

1. X’0003’ – By now its no surprise, Windows Explorer performed a directory listing on /tmp twice
2. X’0002’ – Then it deleted the file /tmp/newfilename.txt

Conclusion

It should be clear by now that the Windows Explorer GUI executes a lot of transactions as a user navigates around the IFS performing operations. SafeNet can monitor, capture, and even BLOCK these transactions on the file server. Access can be controlled based on user profile (or group membership), IFS path, time of day, client IP address, and other metrics. SafeNet can do this for the other IBM i exit points as well. This is an added layer of protection above-and-beyond your existing object-level authorities/permissions. Security in layers (also known as “defense in depth”) is critical to your system security, and the well-being of your entire enterprise!

---

Contributed by:
Steve Riedmueller
IBM i Security Services Director
Kisco Systems