If your IBM i is running TCP/IP, you have a problem. While the availability of IP applications is a blessing in that it gives your company an easy way to access your systems based on a set of defined standards, it also gives hackers an easy way to get into your systems and data using defined standards. Utilizing secure IP connectivity for your Telnet, FTP, and HTTP connectivity can help to curb the problem, but what about all of those other IP applications?

Often, the worst part of the issue can be getting a handle on exactly what applications you have running over TCP/IP. While you can display currently active IP connections using the NETSTAT command, that command gives only a snapshot of what's currently happening. The ideal would be a way to capture that activity on a timed basis to monitor TCP/IP traffic. By stringing together a few IBM APIs, we can do exactly that. In this article, we'll explore a utility to monitor IP traffic as well as learn exactly how to control traffic on restricted ports.

Monitoring TCP/IP Traffic

The command to dump IP network status data is DMPIPSTS. The source for this command can be found here. The parameters for this command are shown below:

The first parameter on this command identifies the destination for the data using one of the following three special values:

• *OUTFILE—This value identifies that the output should be sent to the physical file identified on the OUTFILE parameter and the member identified on the OUTMBR parameter. The "Add or Replace Records" parameter is also used to identify whether or not to clear the destination file prior to adding new records.
• *STMF—This value specifies that the output should be sent to the stream file identified on the Output Stream File parameter (STMF). The Stream File Type parameter (STMFTYPE) identifies the format of the output stream file as one of the following values: *CSV (the output is sent to a comma-delimited text format) or *TXT (the output is sent as a flat text file format).
• *PRINT—This value defines that the output should be sent to a spooled file. When this option is used, multiple spooled files are created as a result of the number of columns of output.

Data Generated

The data generated by this command contains local and remote connection data along with associated job data for each IP network connection available at the time the command is executed. Below is a list of the columns generated by this command: 

The same output is generated whether you select *PRINT, *OUTFILE, or *STMF output. The main difference between the three options is that the *OUTFILE option allows you to indicate that you want to add the output to an existing physical file. This option gives you the ability to capture data over a period of time at given intervals. The command below shows how you would do this;

DMPIPSTS    OUTFMT(*OUTFILE) OUTFILE(MYLIB/IPSTATUS)

            OUTMBR(*FIRST) ADDRPL(*ADD)

This command will add current IP status data to the file IPSTATUS in library MYLIB.

When generating output to *STMF, you have the option of generating the output as a fixed-format text file or as a comma-delimited *CSV file. Figure 1 below shows a sample of the data as displayed in Microsoft Excel.

Figure 1: This is a sample of output generated to a comma delimited file.

To generate a file like the one shown above, the command below would be executed:

DMPIPSTS    OUTFMT(*STMF) STMF('/home/reports/ipstatus.csv')

            STMFTYPE(*CSV)

Knowledge Is Power

The key to securing your TCP/IP connectivity is knowing what IP traffic you're using. Because the output includes a timestamp indicating when the output was generated, you have the ability to also identify how long connectivity to a given port was connected and the IP address of the client that connected to that port. The output also identifies the user who started the job that is servicing the IP request locally. This can be a big help in ensuring that unnecessary (or even rogue) applications aren't leaving IP ports open on your system. Securing traffic for standard applications like Telnet, HTTP, or FTP is only half the battle. Identifying all of the "other" traffic is as important as, or maybe even more important than, implementing SSL on all of those standard applications. Now you have the utility to help you do that.