Secure communication over a computer network is one of the most important requirements for a system, and yet it can be difficult to set up correctly. This example shows how to set up Red Hat AMQ 7 end-to-end TLS encryption using a custom X.509 certificate on the Red Hat OpenShift platform.
You need to have the following in place before you can proceed with this example:
- An OpenShift cluster up and running.
- A custom X.509 certificate in PEM format (along with its chain).
- An active Red Hat Customer Portal account.
Continue reading “Set up Red Hat AMQ 7 custom certificates on OpenShift”
Security-conscious organizations are accustomed to using digital signatures to validate application content from the Internet. A common example is RPM package signing. Red Hat Enterprise Linux (RHEL) validates signatures of RPM packages by default.
In the container world, a similar paradigm should be adhered to. In fact, all container images from Red Hat have been digitally signed and have been for several years. Many users are not aware of this because early container tooling was not designed to support digital signatures.
In this article, I’ll demonstrate how to configure a container engine to validate signatures of container images from the Red Hat registries for increased security of your containerized applications.
Continue reading “Verifying signatures of Red Hat container images”
Getting an SSL certificate for your web server has traditionally been a something of an effort. You need to correctly generate a weird thing called a certificate signing request (CSR), submit it to the web page of your chosen Certificate Authority (CA), wait for them to sign and generate a certificate, work out where to put the certificate to configure it for your web server—making sure you also configure any required intermediate CA certificates—and then restart the web server. If you got all that right, you then need to enter a calendar entry so you’ll remember to go through the process again in (say) a year’s time. Even some of the biggest names in IT can mess up this process.
With new CAs like Let’s Encrypt, along with some supporting software, the rigmarole around SSL certificates becomes a thing of the past. The technology behind this revolution is Automatic Certificate Management Environment (ACME), a new IETF standard (RFC 8555) client/server protocol which allows TLS certificates to be automatically obtained, deployed, and renewed. In this protocol, an “agent” running on the server that needs an SSL certificate will talk to to the CA’s ACME server over HTTP.
A popular method for using ACME on your Red Hat Enterprise Linux 7 server is certbot. Certbot is a standalone ACME agent that is configured out-of-the-box to work with Let’s Encrypt and can work with Apache httpd, Nginx, and a wide variety of other web (and non-web!) servers. The certbot authors have an excellent guide describing how to set up certbot with httpd on RHEL7.
In this tutorial, I’ll show an alternative method—the mod_md module—which is an ACME agent implemented as a module for Apache httpd, tightly integrated with mod_ssl, and is supported today in Red Hat Enterprise Linux 7. The mod_md module was implemented by Stefan Eissing—a prolific developer who also added HTTP/2 support to httpd—and contributed to the Apache Software Foundation, becoming a standard part of any new installation since httpd version 2.4.30.
Continue reading “Using Let’s Encrypt with Apache httpd on Red Hat Enterprise Linux 7”
More and more CPUs implement new features with instructions that are executed as NOPs (no-operation instructions) on previous CPU generations. This results in some challenges for operating system builders, particularly in the area of legacy software support.
Continue reading “Guidelines for instruction encoding in the NOP space”
You’ve created a container image that has all the packages that you and your team need to do something useful, or maybe you’ve built a public image that anybody can use. But, what if that image contains packages with known security vulnerabilities? Regardless of the severity of those vulnerabilities, you’ll want to learn more and take steps to mitigate them as soon as possible.
Fortunately, your team uses Quay.io* as your registry. When you push an image to Quay.io, it automatically runs a security scan against that image.
Continue reading “Using Quay.io to find vulnerabilities in your container images”
Red Hat provides the Go programming language to Red Hat Enterprise Linux customers via the
go-toolset package. If this package is new to you, and you want to learn more, check out some of the previous articles that have been written for some background.
go-toolset package is currently shipping Go version 1.11.x, with Red Hat planning to ship 1.12.x in Fall 2019. Currently, the
go-toolset package only provides the Go toolchain (e.g., the compiler and associated tools like
gofmt); however, we are looking into adding other tools to provide a more complete and full-featured Go development environment.
In this article, I will talk about some of the improvements, changes, and exciting new features for go-toolset that we have been working on. These changes bring many upstream improvements and CVE fixes, as well as new features that we have been developing internally alongside upstream.
Continue reading “Go and FIPS 140-2 on Red Hat Enterprise Linux”
In our previous article about Stack Clash, we covered the basics of the Stack Clash vulnerability. To summarize, an attacker first uses various means to bring the heap and stack close together. A large stack allocation is then used to “jump the stack guard.” Subsequent stores into the stack may modify objects in the heap or vice versa. This, in turn, can be used by attackers to gain control over applications.
GCC has a capability (
-fstack-check), which looked promising for mitigating Stack Clash attacks. This article will cover how
-fstack-check works and why it is insufficient for mitigating Stack Clash attacks.
Continue reading “Stack Clash mitigation in GCC: Why -fstack-check is not the answer”
Red Hat Data Grid is an in-memory, distributed, NoSQL datastore solution. With it, your applications can access, process, and analyze data at in-memory speed to deliver a superior user experience. In-memory Data Grid has a variety of use cases in today’s environment, such as fast data access for low-latency apps, storing objects (NoSQL) in a datastore, achieving linear scalability with data distribution/partitioning, and data high-availability across geographies, among many others. With containers getting more attention, the need to have Data Grid running on a container platform like OpenShift is clear, and we are seeing more and more customers aligning their architecture with a datastore running natively on a container platform.
In this article, I will talk about multiple layers of security available while deploying Data Grid on OpenShift. The layers of security offer a combination of security measures provided by Data Grid as well as by OpenShift/Kubernetes.
Continue reading “Five layers of security for Red Hat Data Grid on OpenShift”
In a software world where each day is more hostile than the previous one, security matters and developers are coping with more and more non-functional requirements about security. The most common ones are the “OWASP Top 10”: the ten security risks that every developer should know. There are many more security risks you should care about, but those ten risks are the ones having the most impact on the security of your software. Among them are authentication and access control.
The good news is that authentication and access control are now commodities in the open source world, thanks to Red Hat Single Sign-On Red Hat Single Sign-On is an access management tool that takes care of the details of most authentication protocols such as SAML, OAuth, and OpenID Connect; user consent with UMA; and even access control. It is easy to use, is very well-documented, and has a very active community: Keycloak.
This article describes how to download and install Red Hat Single Sign-On for no cost.
Continue reading “Red Hat Single Sign-On: Give it a try for no cost!”
The Annobin plugin for GCC stores extra information inside binary files as they are compiled. Examining this information used to be performed by a set of shell scripts, but that has now changed and a new program—annocheck—has been written to do the job. The advantage of the program is that it is faster and more flexible than the scripts, and it does not rely upon other utilities to actually peer inside the binaries.
This article is about the annocheck program: how to use it, how it works, and how to extend it. The program’s main purpose is to examine how a binary was built and to check that it has all of the appropriate security hardening features enabled. But that is not its only use. It also has several other modes that perform different kinds of examination of binary files.
Another feature of annocheck is that it was designed to be easily extensible. It provides a framework for dissecting binary files and a set of utilities to help with this examination. It also knows how to handle archives, RPMs, and directories, presenting the contents of these to each tool as a series of ordinary files. Thus, tools need only worry about the specific tasks they want to carry out.
Continue reading “Annocheck: Examining the contents of binary files”