June, 2021 - Built on Power

2021-06-292021-06-30

AIX Certification Preparation

There is a new certification in place for AIX admins and we would like with this post try to help you get a better grip of what you need to know and how to acquire the right skills to become certified.

There are different ways of learning stuff as always. Courses are one way but reading Redbooks and other documents could be a good alternative and/or complement. Most links are taken from the original landing page for the certification, but we’ve added a bunch of other good links that hopefully helps in your journey to become certified.

(IBM Champion Dmitry Mironow has written about the certification process and gives some tips in THIS ARTICLE)

IBM AIX v7 Administrator Specialty

You can get a sample test HERE

By IBM recommended courses:

AIX Basics (Course code AN10DG)

Power Systems for AIX II AIX Implementation and Administration (Course code AN12G)

Pre-reqs for AN12G:

AN10G: AIX Basics

AN11G:Power Systems for AIX I: LPAR Configuration and Planning

Power Systems for AIX III: Advanced Administration and Problem Determination (Course code AN15G)

Pre-reqs for AN15G
AN11G: Power Systems for AIX I: LPAR Configuration and Planning
AN12G: Power Systems for AIX II AIX Implementation and Administration

AIX Network Installation Management Concepts and Configuration (Course code AN22G)

Pre-reqs for AN22G
https://www.ibm.com/training/course/AN11G
https://www.ibm.com/training/course/AN12G

Areas and objectives in the exam

System Management

Related Link

Set user’s environment
Create and troubleshoot a shell script
Connect to AIX system console
Create and verify a system backup using mksysb, volume group backups with savevg,
Manage file backups and file archives
Define AIX management tools including SMIT
Manage devices and attributes
Document the systems configuration
Identify the LPAR configuration
Manage system time
Manage services using System Resource Controller (SRC)
Start and stop programs / scripts in /etc/rc.local etc
Manage the AIX boot and shutdown sequence
Manage root email
Define the process lifecycle and priorities
Scheduling execution of commands using cron, at, batch

Software Management

Related Link

Install AIX fixes and updates
Manage open source packages with rpm
Use NIM

Storage Management

Related Link

Explain the LVM terminology
Manage volume groups
Manage root volume group specific tasks
Manage logical volumes
Manage file systems
Manage raw physical volumes

System & Network Security

Network Management

Related Link

Manage basic IP configuration
Manage hosts and name resolution order
Manage network services with inetd
Mount and export NFS

Performance Management & Tuning

Related Link

Define performance bottlenecks
Explain the difference between logical, physical and virtual CPU
Define basic VMM concepts
Monitor usage of memory
Expand and monitor usage of the paging space
Define basic IO performance concepts
Display system tunables

Problem Determination & Management

MITTR: “GitHub: Lessons from global developers to bolster the remote workforce”

2021-06-29

Configuring IBM i Password Security & Composition Rules for Regulatory Compliance –

IBM i April 2, 2021

While most regulatory standards specify that you should use appropriate password security, they often don’t specify password composition standards. This makes it difficult to know whether your password security and composition rules will create more secure passwords and meet regulatory standards.

Let’s look at what IBM i password security and composition rules you might put in place to meet a regulatory standard, using the Payment Card Industry (PCI) Data Security Standard (DSS) as an example. We’ll look at PCI DSS requirements, how you develop an IBM i standard to meet those requirements, and what changes you can make in your IBM i system to meet that standard. Even though we’re looking at PCI DSS, the methods used here can be applied to creating password composition rules for other standards, such as Sarbanes-Oxley (SOX) and the EU General Data Protection Regulation (GDPR).

Step #1: Look at what the standard says about password security and password composition

The first step is to determine what your obligations are for password security. Here’s what PCI DSS says about user names and authentication.

Always change ALL vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. This includes wireless devices that are connected to the cardholder data environment or are used to transmit cardholder data. (Requirement 2.1)—This includes IBM i-supplied and third party-supplied user names.
Assign all users a unique user name before allowing them to access system components or cardholder data (Requirement 8.1)—Everyone has their own user profile. No shared sign ons.
Employ at least one of these to authenticate all users: something you know, such as a password or passphrase; something you have, such as a token device or smart card; or something you are, such as a biometric (Requirement 8.2)—You have a choice of which authentication technique to use, even if you just stay with passwords.
Use strong authentication methods and render all passwords/passphrases unreadable during transmission and storage using strong cryptography. (Requirement 8.2) —Passwords must not be retrievable, which has never been a problem with IBM i.
Secure all individual non-console administrative access and all remote access to the cardholder data environment using multi-factor authentication. (Requirement 8.3)— There are several third-party IBM i programs such as SEA’s iSecurity Password Reset that provide two-factor authentication for password changes and sign ons.
Do not use group, shared, or generic IDs, or other authentication methods. Service providers with access to customer environments must use a unique authentication credential (such as a password/passphrase) for each customer environment. (Requirement 8.5)—Administrators, system developers, database admins, and other users who work on the system but don’t consume data, must also have separate user names and authentication. Everyone must be authenticated.

These requirements provide general rather than specific guidance for password creation and authentication. This isn’t unusual. Password requirements for other regulations can also be general.

The key to defining IBM i password compliance lies in matching the standard’s requirements to IBM i capabilities. Matching allows us to determine what changes you’ll need to make to reach compliance. Here are some steps we took to match up PCI DSS requirements to IBM i configurations.

Step #2: Review and implement existing auditor recommendations

Your password security must meet auditor recommendations. While painful, audits and audit violations are valuable tools for shoring up password security and avoiding regulatory fines. Listen to what your auditors say and implement those recommendations.

Step #3: Weed out vendor-supplied default and known passwords (Requirement 2.1)

For PCI DSS requirement 2.1, review and implement the recommendations in IBM’s document on Changing Known Passwords. This document tells you how to secure well-known password entrances into an IBM i server, including disabling default and well known passwords (passwords published on the Internet), setting IBM i supplied profile password values (Q* users) to *NONE, and changing default dedicated service tools (DST) and system service tools (SST) passwords.

Step #4: Everybody gets their own password (Requirement 8.1 and 8.5)

Some organizations use generic user names and passwords for users with the same duties. For example, there may be one Accounts Payable user called APUSER, and three people sign on as APUSER to do their work. This is a poor security practice that will generate an audit point every time. Every user on your IBM i system must have their own user profile and password. This goes double for system administrators, programmers, and security officers who have special privileges on the system. Don’t share user profile names, especially the QSECOFR profile or any other profile with security office privileges.

Step #5: Use something you know for authentication (Requirement 8.2)

The most practical IBM i user authentication technique is to use a password or passphrase (something you know). IBM i shops usually have too many users to implement a something you have technique, such as using a card reader or USB device for authentication. And while biometric techniques including fingerprint scanning or facial recognition are becoming more common (especially on smartphones), something you are techniques are not practical for widespread IBM i use yet.

Best practices in this area (as defined by the National Institute of Standards, NIST in their Digital Identity Guidelines) are to use passphrase lengths between 8 and 64 characters and the user can use all printing ASCII (RFC 20) characters in a passphrase, including upper- and lower-case passwords, spaces, and special characters.

To make sure your IBM i can support these requirements, you may need to change your IBM i password level system value (QPWDLVL) from level ‘0’ or ‘1’ to level ‘2’ or ‘3’. QPWDLVL level ‘2’ or ‘3’ allows passphrase lengths up to 128 characters and any character is allowed in a passphrase, while the ‘0’ and ‘1’ level require ten-character passwords.

Before you change your IBM i password level to ‘2’ or ‘3’, check out IBM’s Knowledge Center article on considerations for changing QPWDLVL from ‘0’ or ‘1’ to ‘2’. There are several gotchas that can occur with using existing level ‘0’ or ‘1’ passwords at QPWDLVL level ‘2’ or ‘3’.

Also plan for increasing the maximum length of your passwords, as longer passphrases may force you to change applications that display or send passwords. Changing the maximum length from 10 characters to 16 characters, for example, could break custom sign-on screens and cause issues when sending passwords between programs. Evaluate a maximum password length change in conjunction with your applications.

Step 6: Create possible password composition rules

Your password composition rules will set the minimum and maximum password and passphrase lengths, as well as rules for creating harder-to-guess, more complicated passwords. Eliminating harder-to-guess passwords may not explicitly be stated in your standard requirements, but it’s common sense to reduce hacking and your auditors will demand it.

NIST recommends comparing passwords against known lists of passwords that a) have been previously breached, b) contain dictionary words, c) contain repetitive or sequential characters, or d) contain context-specific words such as the user name. While many IBM i shops may not have the software to compare incoming passwords to known lists, it is generally accepted to use the IBM i password composition values shown in Table 1. Many of these settings are defined in the Password Rules system value (QPWDRULES), while other settings are defined in different system values.

Table 1: Commonly used IBM i password composition system value settings

Step 7: Implement two-factor authentication for remote access or as needed (Requirement 8.3)

Research which third-party products can provide two-factor authentication (also known as multi-factor authentication), such as sending an access code to the user (via cell phone or email) that must be entered in addition to their passphrase when signing on. This will handle two-factor authentication for sign on. Also, consider using a third-party IBM i two-factor password reset program, such as SEA’s iSecurity Password Reset, which allows users to reset their passwords using two-factor authentication.

Step 8: Finding out about IBM i non-retrievable passwords (Requirement 8.4)

The IBM i has always stored its passwords in unreadable format. There is no issue with reverse encryption on an IBM i box as there could be on older Microsoft servers. IBM i passwords are never stored on the system. The system uses encryption algorithms to provide one-way encryption and verification for user sign ons. For more information, check out IBM’s tech support note on IBM i Password Encryption.

Step-by-step for password security and composition rules

This example showed the steps you can follow to configure an IBM i system for PCI DSS password compliance. Use this information as a template for evaluating other regulatory standard requirements against IBM i password capabilities. Many of the capabilities discussed here are universal and can be applied to many different auditing situations.

Allow your users to reset their own passwords!!! iSecurity Password Reset automates end-user IBM i password resets using 2-factor authentication, without contacting your Help Desk or a System Administrator. Click here to learn more.

2021-06-29

Case conversion (%LOWER & %UPPER) in RPGLE – IBM i

Case Conversion

Built-In Function %XLATE has been very useful to convert the string from lowercase to uppercase and vice versa.

With the introduction of BIFs %LOWER (Convert to Lowercase) and %UPPER (Convert to Uppercase), this has been made much easier.*

%LOWER (Convert to Lowercase)

%LOWER converts the string passed (first operand) to lowercase. Part of the string can be converted to lower case by specifying optional start position and length operands.

Syntax

%LOWER(string : start_position : length)

%UPPER (Convert to Uppercase)

%UPPER converts the string passed (first operand) to uppercase. Part of the string can be converted to upper case by specifying optional start position and length operands.

Syntax

%UPPER(string : start_position : length)

Let’s have a look at the example to understand these better.

**Free

Dcl-S MixedCaseString Char(10) Inz(‘UpPeRcaSE’) ;

Dcl-S LowerCaseString Char(10) ;

Dcl-S UpperCaseString Char(10) ;

// Converting the full string to lowercase

LowerCaseString = %Lower(‘LOWERCASE’); //lowercase

Dsply LowerCaseString ;

// Converting the portion of a string to lowercase

LowerCaseString = %Lower(‘LOWERCASE’ : 2); //Lowercase

Dsply LowerCaseString ;

// Converting the portion of a string to lowercase

LowerCaseString = %Lower(‘LOWERCASE’ : 2 : 4); //LowerCASE

Dsply LowerCaseString ;

// Converting the string to uppercase

UpperCaseString = %Upper(MixedCaseString); //UPPERCASE

Dsply UpperCaseString ;

*InLr = *On ;

In the above example,

Line – 8: We are passing the string (in uppercase) to BIF %LOWER without any optional parameters.This would convert the full string to lowercase. Line – 12: We are passing the string (in uppercase) to BIF %LOWER with an optional parameter ‘start position’.This would convert the string from start position till end of the string.Line – 16: We are passing the string (in uppercase) to BIF %LOWER with both the optional parameters ‘start position’ and ‘length’. This would convert the string from start position till the number of characters mentioned in the length parameter. Remaining string would be unchanged. Line – 20: We are passing a variable (with string in both lowercase and uppercase letters) to BIF %UPPER without any optional parameters. This would convert the full string to uppercase. Similar to the BIF %LOWER, Optional parameters can be used with %UPPER to convert part of the string to uppercase.

*These Built-in Functions are only available since IBM i 7.4 TR4 and IBM i 7.3 TR 10.

If you have any Suggestions or Feedback, Please leave a comment below or use Contact Form.

2021-06-29

IBM i – IBM Power Systems Community

As of the time of writing this document (original November 2020, updated June 2021), there are no known ransomware malware programs or viruses that run directly on the IBM i. However, the IBM i can be affected by an infected PC on the network. These PCs are most often infected by opening an infected email attachment, web browser injection, visiting a link to a site that distributes the malware program masquerading as a patch, update, or viewer, by the user being socially engineered by the attacker, or a combination of these.

The IBM i can be a file server to PCs holding any sort of binary data. This means that the IBM i could be a holder of an infected file, but the file will not run directly on or infect the IBM i. There are many ways a file could end upon the system in the first place, such as FTP, SCP, or removable media, not just from a network share. Those infected files could then be shared to a PC via those same methods or more widely if the system is also a web server. The bulk of this article will focus on the risks that come from the IBM i serving as file server, the largest attack surface for this type of malware.

There can be many purposes for these malware programs. First and most obvious, and its namesake, is to lock up systems and hold access to them until a ransom or fee is paid, usually in bitcoin due to its anonymous nature. This lock up is done by encrypting critical data, operating system files, and if possible, backups. The theory is that once the ransom is paid, a decryption program and key will be provided. Almost all IT security groups, including the FBI, recommend NOT paying the ransom. In the US, it may even be considered a crime to pay the ransom depending on the location of the attackers. Once a company is known to pay ransom, they will become a larger target to other groups. Only once the lure of money is gone, will ransomware go away.

Even if these systems can be restored from unaffected or segmented backups, there is a second and growing concern. Before encrypting systems, more strains of ransomware now will look around the network first. As part of their reconnaissance to get a better foothold and pivot to higher value computers or domain controllers, they will look for high value data or personally identifiable information (PII). Once found, it will be exfiltrated from the network to the attackers. Now, if the ransom is not paid, not only is the company on their own to recover their systems, but the attackers also threaten to publicly release the stolen information.

Keep in mind this information is about ransomware in general. Specifics on IBM i will follow. One resource for more information is the National Institute of Standards and Technology (NIST) Cybersecurity Special Publication (SP) 1800-26, Detecting and Responding to Ransomware and Other Destructive Events. And of course, from IBM’s own X-Force team The definitive guide to ransomware: Readiness, response, and remediation.

Protecting the IBM i

There are many steps a company can take to reduce the exposure of the IBM i to an attack like this. These mitigations focus on reducing the exposure of the IBM i file system to the network over NetServer, our version of SMB. First, make sure that guest access is disabled. Guest support is enabled by defining an existing user profile on the system that all unauthenticated users will be mapped to. Those network guest users will get the mapped user profile’s level of permissions. While our recommendation is to disable guest access, if it must be used, make sure the guest account as no special authorities and the lowest level of rights possible. Ideally, this would be read only to prevent any changes. To disable guest access, remove the user profile from the configuration so that it is blank. This will prevent just anyone on the network from accessing the IBM i and requires users to have an IBM i user profile and account.

Next, remove any shares that are no longer needed. Administrators can view the active number of sessions per share via IBM Navigator for i (File Systems > File Shares). This is just a snapshot in time; it is not a log nor cumulative. Each share can also be set to be read only. For example, if there is a directory that is an archive of PDF invoices generated by the system, they may only need to be viewed for reference from a PC. There is no need to expose this share as writeable to the network. While this type of change will prevent the files from becoming encrypted, it will not prevent them from being copied and sent to the attacker. This also does not override OS security (which will be discussed later) – the user would still need write and/or read authority to the objects from the OS level. As always, this should be properly set to avoid exposure even directly on the IBM i. This NetServer setting is in addition and provides further restrictions above and beyond the OS layer, mainly prevented writing from the network if it were otherwise allowed on the system.

In furtherance of reducing exposure, make sure that the mount points for the IFS are as far down the directory path as possible, limiting the number of files accessible. If only a certain sub-folder of an application needs to be accessible from the network, do not share the entire application folder. Share just the sub-folder containing the needed data. This may require creating a larger number of smaller shares under a particular folder. However, it will reduce the total files exposed and increase security. And this should go without saying, but to be explicit, NEVER SHARE THE IFS ROOT (/).

Remember that QSYS.LIB, the library or traditional portion of the IBM i file system, can also be shared, and thereby exposed, to network attacks. The system provides the QPWFSERVER authorization list which can be used to restrict which users are allowed to access QSYS.LIB from NetServer. Just like the read only attribute, this setting is in addition to the OS level security. A user would still need at least read authority to the libraries to access them over the network.

While the preceding talks to NetServer, there is a second way to share files from the IBM i across your network – NFS or Network File System. With NFS, rather than creating file shares, you create NFS exports. These exports publish directories and files which can then be mounted by an NFS client, such as Linux or Windows. When these exports are created, the authorized users for each export is defined. The major concern is that the user creating the NFS export can define anonymous access to the files, requiring no user authentication to access those objects. Worse, the default when an export is defined is that anonymous access is created unless overridden to be disabled. Like NetServer guest access, anonymous NFS access maps unauthenticated NFS users to a single, real IBM i profile. The default is QNFSANON. Make sure that the profile that these anonymous users map to has no special authority and as few permissions as possible, ideally read only. To disable anonymous access, define the NFS exports with ANON=-1 or select None in IBM Navigator for i.

As with NetServer, many of the same recommendations also apply to NFS exports. First, make sure the exports are not defined to allow anonymous, unauthenticated access. Next, if logical for business need, make the exports read only to prevent encryption from a ransomware attack from an NFS client. The root file system (/) and QSYS.LIB are both exportable via NFS. There is no authorization list like with NetServer to help prevent this. Finally, make sure the NFS exports are as far down the file path as possible to expose the least amount of data and files. Administrators can use IBM Navigator for i (Network > Servers > TCP/IP Servers > NFS > Exports) to look for these NFS exports and their settings.

Further Steps

Everything covered so far is in addition to the protection the IBM i operating system already provides. However, many clients have less than ideal object level authorities and permissions defined. While all objects are important, the key items are libraries and folders as they act as a gateway to the objects and files inside them. Best practices include removing *PUBLIC, individual, and group read and write permissions to objects. Access should be granted by using adopted authority (QSYS.LIB) or swapping profiles (IFS) to get access to data objects only via the approved applications. Do not forget that users or groups with *ALLOBJ special authority have access to all objects on the system. By removing write authority, the files are protected from being altered and encrypted. By removing read authority, the files are protected from being copied and stolen. One of the best ways to find out what authority is needed, what authority a user has, and where they are getting that authority from is to run an Authority Collection. This tool serves as a trace for seeing all the authority decisions the IBM i made under the covers, there are more than one might think!

Besides changes to user libraries and folders, IBM recommends making two changes to the IFS once the system is set up, configured, and running. These are to change the authority on the IFS root (/) and QOpenSys folders from *PUBLIC *RWX to just *RX. While these paths may need to be written to as the system is being configured, once operational there is no good reason to leave these locations as publicly writable. Review user and application created root IFS folders for excessive public write and read permissions and check the authorities under the /home directory if that is used by individuals for private storage.

In case there is a ransomware attack, the best way to recover is to have a well planned and tested recovery strategy. It is important that the backups are in an isolated or segmented network. Ransomware attackers look for online backups to corrupt or encrypt to make recovery more difficult. These backups must be kept in a safe place. Consider immutable backup technologies such as IBM’s SafeGuarded Copy or Recovery Point Flash. If the system is attacked, it is possible that those corrupted files would be replicated to an HA system or backup up on media and should be reviewed.

And as with all technology, staying up to date with supported operating system releases and software patches (PTFs) is crucial. Make sure the IBM i OS level is actively supported. Apply the latest cumulative, HIPER, Db2, and Security PTF groups at least once a quarter. Don’t forget third-party and open-source applications installed on the system as well.

Get an Assessment

Most IT standards require an annual security assessment performed by an outside organization. This is a great way to get “fresh eyes” to review the environment and make sure things are set how they should be. The IBM i Security Lab Services team provides security assessments to look for risks and weaknesses in the environment. An IBM i Security Assessment is a great way get a handle on the possible exposures. For more information about these assessments, please visit our website at: http://ibm.biz/IBMiSecurity#assessments.

IBM i Ransomware Protection Checklist

Disable guest/anonymous network access

Remove as many network shares/exports as possible

Set remaining shares/exports to read only, if possible

Move the share/export mount point to reduce the number of directories and files exposed

NEVER share/export the Root of the IFS (/)

Use QPWFSERVER to block access to QSYS.LIB from NetServer

Limit access to the shared data to as few people as possible

Change Library or IFS folder permissions to remove write authority (prevents file encryption)

Change Library or IFS folder permissions to remove read authority (prevents data exfiltration)

Change the IFS Root (/) and QOpenSys to *PUBLIC *RX from *RWX after system setup is complete

Have a completely tested isolated and segmented backup methodology and documented plan

Stay current on PTFs, patches, and OS levels

Get an annual security assessment from an outside source such as IBM Lab Services