Because of the proliferation of available software on Linux distributions, the potential for vulnerabilities big and small has also increased. There are thousands of bits of software floating around on your system, produced by developers who might work for you or your upstream vendor, or who might be open-source volunteers.
Linux has a long history as a flexible platform for all sorts of applications, which is both awesome and scary. Your baseline Linux install might include any number of things you don't necessarily want or need, and software that isn't as secure by default as it could be.
Your team likely has someone who's responsible for watching for updates and making recommendations on them. You could probably use a flexible tool for specifying your security and compliance requirements and verifying your systems on a regular basis.
Chef InSpec is an open-source testing framework that can help document and organize your infrastructure security requirements. InSpec has various methods for connecting to hosts and can be used in your software development lifecycle to ensure that changes and additions to your applications don't violate your security policies.
How InSpec can help
InSpec gives you a tool set for capturing security requirements in sophisticated profiles and applying those profiles across your systems. Below are four examples of testable items: packages, services, users, and system files. InSpec includes dozens of resources for Linux and Windows systems to give you what you need for system security.
InSpec can help your team manage security and compliance requirements more effectively by incorporating the management into your workflow. Application engineers can use InSpec along with development Docker containers. Infrastructure engineers, DevOps professionals, and site reliability engineers (SREs) can plug InSpec into a tool such as Test Kitchen to test their infrastructure code.
You can also run InSpec regularly on any of your production hosts to ensure that no configurations have drifted out of compliance. No more twice-yearly massive audits full of surprises.
To get you started, here are four of the most commonly used InSpec resources for verifying your infrastructure components.
[ Special Coverage: DevSecCon Seattle 2019 ]
Packages: Get versions and compliance in check
Package management has long been a key part of building and maintaining Linux hosts. A single Linux system may have thousands of installed or potentially installable packages, ranging from basic libraries to utilities to games, depending on the intended use of the system. Different Linux distributions have various tools and methods for publishing, installing, and maintaining these packages.
You can use InSpec tests to check for packages and versions, and use InSpec's tooling to continuously audit your systems for compliance. For example, you might have a vulnerable package—foo-1.2.3-i686.rpm—and the non-vulnerable versions are those that were released after this version.
You could test this package in the following way:
describe package(‘foo’) do
it { should be_installed }
its(‘version’) { should cmp >= ‘1.2.3’ }
end
The package resource in InSpec is quite powerful. If you wanted to ensure that a package bar wasn’t installed at all, you could also test for that state:
describe package(‘bar’) do
it { should_not be_installed }
end
Additionally, on dpkg systems, you can test whether or not a package baz is held—that it will not be upgraded if an update is available.
describe package(‘baz’) do
it { should be_held }
end
For more information on the package resource, you can check out the InSpec documentation.
Tell your services to behave
The InSpec service resource is similar to the package resource in the previous section. It gives you sophisticated control over the necessary behaviors of the services running on your systems. For example, we can disable telnetd:
describe service(‘telnetd’) do
it { should_not be_running }
it { should_not be_enabled }
end
Or require that another service, bazd,is enabled and running:
describe service(‘bazd’) do
it { should be_enabled }
it { should be_running }
end
InSpec's libraries will take care of determining how to find the services on your system and check them for your requirements. You can also examine services for appropriate versions and for correct run levels. For more details on the service resource, see the InSpec documentation.
Get your users under control
If you're managing user accounts locally, there are a few things you can do to enforce things such as password rotation policy based on the account entries in /etc/passwd. InSpec's user resource gives you access to interrogate the local accounts on your system, including those used by services.
Maybe you have a service account that shouldn't be able to log in, and your preferred method to do that is to set the account's shell to something like /sbin/nologin. Ensure that setting is always in place:
describe user(‘service1’) do
its(‘shell’) { should eq ‘/sbin/nologin’ }
end
Check out what else you can do with the user resource in the InSpec documentation.
Critical files get priority treatment
InSpec has a number of built-in resources for critical files on the system. InSpec's libraries read and test files such as /etc/passwd based on your requirements. For example, the following test will ensure that no one has accidentally created a user account with a duplicate user ID:
describe passwd do
its('uids') { should_not contain_duplicates }
end
These more complex resources include tests for common system files such as /etc/fstab, /etc/security/limits.conf, and /etc/login.defs. Common applications are also supported, such as Postgresql, MySQL, nginx, and Apache HTTPD. For a full list of supported resources, see the InSpec documentation.
Keep on top of all the moving parts
These are a few of the key components of your infrastructure that InSpec can interrogate. Open-source infrastructure has a lot of moving parts, whether you are using virtual machines, containers, the cloud, or on-premises resources, and InSpec can help you ensure it's as secure as possible.
For more about resources and other features of InSpec, see Chef's learning site and come to my session at DevSecCon Seattle, which runs from September 16 to 17, 2019.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
