Most IBM i shops have not secured their DDM implementation. Carol discusses why that’s putting those shops at risk.

Distributed Data Management (DDM) comes in two flavors: an ancient implementation that runs over SNA and one that runs over TCP/IP. The version I’m going to discuss is the implementation over TCP/IP. While the default setting for DDM over TCP/IP is to require a valid user ID and password to make a connection to a target server, most IBM i shops have changed this setting and require only a valid user ID. In other words, when a DDM connection is established, the user making the DDM connection must have the same user profile name on the target server. When that’s the case, the connection is established.  

Why Is This a Problem? 

On the surface, this may not seem like an issue. If you’re SUE on one partition, it’s likely that the profile SUE represents the same person on a different partition. The problem comes with this thing called a “server authentication entry.” Its purpose is to tell the DDM server what profile to connect with when establishing a DDM connection to another partition.

If the server is configured to require a password, the server authentication entry also contains the password to be used to authenticate the user on the target partition. However, when the DDM server is configured to require only a user ID, the server authentication entry doesn’t contain a password but still contains the name of the profile to be used on the connection—and the profile names do not have to be the same. In other words, a server authentication entry could be added for CAROL that says that the profile to be used on the target partition is CAROLTEST. Worse, if Carol has access to a command line, she could run the Add Server Authentication Entry (ADDSVRAUTE) command (because it ships as *PUBLIC *USE) and specify that she wants to make DDM connections as any other profile that exists on the target partition...such as QSECOFR!

That may seem like a bug, but that decision was made while I was still at IBM, and I remember the discussion to this day. No authority checking can be done to see if the user specified is authorized to use the target profile because the entry is generic. That is, there’s one entry for all DDM connections made for the user. Since there’s no way to know at the time the entry is created what partition(s) the user will be connecting to, there can be no authority checking done to determine if the user on the originating partition has authority to the profile on the partition to which the DDM is being made.

So What?

OK, so what if I do have access to a command line and run the following command?

ADDSVRAUTE USRPRF(carol) SERVER(QDDMSERVER) USRID(qsecofr) 

What could I do? Here’s where the remote command aspect of DDM comes into play. First, I would need to create a DDM file that references the partition I want to connect to.

CRTDDMF FILE(QGPL/USERS) RMTFILE(QGPL/USERS) RMTLOCNAME(TargetSystemName *IP)

The next step is to run a remote command. In this example, I’m displaying the list of users on the target system. First, I run the remote command to generate the file containing the list of profiles.

SBMRMTCMD CMD('DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE)              OUTFILE(QGPL/users)') DDMFILE(QGPL/users)

Next, I display the DDMF, which points back to the file on the target system and displays the list of users on the target system:

DSPPFM QGPL/USERS

I’m going to leave it up to your imagination what you, or someone with extra curiosity (think developers or someone in your “shadow IT” group), or someone intent on doing harm could do with this functionality. I’ll focus the rest of this article on preventing—or at least limiting—this access.

Securing DDM

First, and foremost, if you are not using DDM or Distributed Relational Database Access (DRDA, which uses the DDM server), don’t start the DDM server! If the server isn’t running, it can’t be used. These commands end the server and change the auto-start value so it won’t automatically be started when TCP/IP starts:

ENDTCPSVR SERVER(*DDM) 

CHGDDMTCPA AUTOSTART(*NO)

However, DDM is a very powerful feature and is used by many IBM i shops. In fact, Backup, Recovery and Media Services (BRMS) uses DDM, as do several vendors. If your organization uses DDM, you can make its use more secure by heeding the following advice.

Require a password when DDM connections are made. You have several options when configuring the DDM server to require a password. The most secure is to specify *ENCUSRPWD. Remember that these configuration options take effect when a DDM connection is received. This configuration has no effect on the partition where the DDM connection originates. If you specify on partition PROD that the DDM server requires *ENCUSRPWD, then any partition making a DDM connection to PROD must pass an encrypted user ID and an encrypted password to establish the DDM connection. If the user ID and password match a user ID and its password on PROD, the DDM connection will be established and will run as the user specified. If you’re using Kerberos for authentication (rather than passwords) throughout your organization, you can also specify to require a Kerberos ticket to establish a connection.

What are the implications when requiring a password to establish a DDM connection? When the DDM server requires a password, it means that, for every profile making a DDM connection, a server authentication entry will have to be created on each partition where a DDM connection originates. While that’s not an issue if you have only one or two profiles making DDM connections, this can be a real maintenance headache if most or all users make DDM connections to other partitions. First, you must remember or somehow automate adding an entry every time a profile is created on each of those partitions. Then, the entry much be updated each time users change their passwords. Fortunately, two rather recent enhancements have been provided that help reduce the maintenance overhead.

The first enhancement, added in V7R2 and PTFed to V6R1 and V7R1, allows you to specify a group profile along with its password for the server authentication entry on the originating partitions. Any user who is a member of that group profile can establish a DDM connection based on the user ID and password of that group profile, eliminating the need to add an entry for each user. The downside is that, when a DDM connection is established, the connection on the target server is made as the group profile rather than the individual. That means that all audit journal entries will be logged as the group profile rather than the individual, so some accountability is lost using this method. For more information, go here and search for “Simplified DDM and DRDM.”

The second enhancement, added to V7R2, allows you to create an environment variable that indicates to the operating system that the user’s current user ID and password should be used on the DDM connection. While each user making a DDM connection still requires an entry, you won’t update their entry when they change their password.

Note: If your DDM use is limited to only BRMS and vendor profiles, it’s possible that the server authentication entry already exists for those profiles. Run the Display Server Authentication Entry (DSPSVRAUTE) command for each of those profiles to determine if an entry already exists.

Reducing the Risk When a Password Is Not Required

If you need some time to investigate using passwords on your DDM connections, I encourage you to block access for users not using DDM. One way to do that is to use the function QIBM_DB_DDMDRDA. Think of it as an on/off switch for using DDM. You can configure the use of this function by launching Application Administration and going to the Host Applications tab. Open Database and modify the DDM & DRDA Application Server Access function. Or run WRKFCNCUSG QIBM_DB_DDMDRDA from a command line. However, if you need more detailed logging of DDM use or more granular access controls, such as allowing some users to establish a DDM connection from just an IP address, you will need to use an exit point solution, such as the Network Security product from HelpSystems. Exit point solutions provide significantly more detailed logging and access controls than the simple on/off capability provided by Application Administration.

If you haven’t already, consider setting QSECOFR to STATUS(*DISABLED). This will prevent anyone from signing on with the profile as well as using it to establish any remote connections, including DDM. Note: You can always sign on to the console with QSECOFR, even when it’s disabled.

Last but certainly not least, secure the ADDSVRAUTE command! You don’t want all command line users to be able to add their own DDM/DRDA server authentication entry. Also, determine the processes that legitimately need to use the CRTDDMF and SBMRMTCMD commands. Use the Change Object Auditing (CHGOBJAUD) command and examine the ZR entries that are generated when the commands are used. Once you’ve determined what profiles need to use these commands, consider securing them (setting them to *PUBLIC *EXCLUDE) as well.

Summary

Let me reiterate that, as shipped, DDM requires a password to make a connection. However, the vast majority of systems that my team and I examine have changed the configuration of the DDM server to not require a password. This leaves systems and data open to unintended access. Whether you change the DDM server or not, my hope is that you’ll take action to reduce the risk posed by a DDM server that doesn’t require a password.