IBM i Access Client Solutions (ACS) is a critical tool for essential features such as 5250 emulation, SQL, Db2 performance, and open source package management. Every update is packed with functionality improvements, bug fixes, and security updates.
Carol Woodbury
I had the privilege of hosting security expert Carol Woodbury as she led a roundtable discussion at this past summer’s OCEAN TechCon. Carol is IBM i Security SME and Senior Advisor with our friends at Kisco Systems.
Although there are many reasons—including performance—to update to newer PHP releases, the number one reason is to avoid losing security updates.
Each version of PHP (7.4, 8.0, 8.1, 8.2, 8.3, etc.) has three years of support before it is considered end of life. For two years, it gets bug fixes and all security fixes. In the third year, it gets only critical security fixes. After that, nothing!
If you have encrypted your website, API, Telnet server, or other service with TLS (SSL), good for you!
Now, do you know when those certificates will expire? If they expire without renewal, your service could become unavailable without warning.
In the past, to find expiration dates for digital certificates on IBM i, you’d either have to look in the Digital Certificate Manager (DCM), call the Retrieve Certificate Information (QYCURTVCI, QycuRetrieveCertificateInfo) API, or keep extremely good notes!
CERTIFICATE_INFO, an IBM i service recently delivered by IBM, solves all this. This SQL table function, documented here, returns a result table that contains information about server or Certificate Authority (CA) certificates, including their expiration date.
Here’s how to use CERTIFICATE_INFO to find expiring certificates.
A client asked about a vulnerability found in libwebp, which is used by PHP’s image-handling gd extension.
My first step was to find a reputable source for details. According to this trusted article about the vulnerability, the issue affected only libwebp versions 1.3.1 and earlier. I checked our own system and found we had a patched version from IBM, so we were safe. The client was, too.
Here is the procedure you can use for checking the version of this or any other open source package on IBM i. Read more →
The Apache-based IBM HTTP Server for i is a vital defense in web and API security for IBM i. As such, it requires regular attention.
IBM Support’s PCI Compliance web page is a resource we use to help our clients protect their systems.
Even if your organization does not process, store, or transmit credit card information, applying the PTFs recommended for PCI compliance constitutes a general best practice for IBM i web and API security.
A client asked for help addressing a Denial of Service (DoS) vulnerability that their security company discovered. The company found it could slow down the Apache web server by sending it incorrect headers. By sending an artificially high “Content-Length” header, they caused the web server to wait for data that would never come.
To make our IBM i servers more secure, our system administrator has configured our SSH services to require public key authentication rather than password-based logins. To comply with this security policy, we also set up our Visual Studio Code for i connections to use SSH keys.
This article explains how to set up an SSH key with Code for i.
You may have heard claims that HTTP “basic” authentication (classic user/password popup prompt or via an API call) leaves credentials unencrypted and exposed. While it’s true that basic auth itself doesn’t encrypt credentials, this doesn’t matter in practice.
Modern sites and APIs should be using HTTPS, which encrypts everything over the wire, protecting basic authentication credentials in transit. This article will explain why that’s the case.
ODBC connections between Linux and IBM i should be encrypted to keep their Db2 data safe in transit.
To encrypt ODBC data, IBM recommends the industry-standard TLS encryption protocol (the successor to SSL).