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).
Many thanks to IBM and COMMON for their recent IT Leadership Summit on Security, held August 3, 2022, at IBM’s Astor Place offices in New York City.
This free, noncommercial event for IT executives featured speakers with broad experience addressing industry security concerns. Speakers included:
Updated December 19, 2021
The Log4j Java library has been in the news recently. The details of vulnerability CVE-2021-44228 have been well documented by others, but to summarize, it allows arbitrary code execution through maliciously crafted messages. These messages cause the Java virtual machine to look up classes from an LDAP server and load them. This is obviously not good, but unless you’re familiar with Java, you might be concerned what is and isn’t vulnerable; this article aims to clarify that.
If your application deals with user accounts, it has to deal with passwords. Storing passwords in plain text would be a bad idea; a data breach could allow an attacker access to every account. The obvious answer is to encrypt the passwords. However, using cryptography without understanding could give you a false sense of security—if you make the inappropriate choice, you could make things easier for an attacker without realizing it. This article will focus on getting you up to speed with the best ways to use cryptography to secure passwords.