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.
Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online