Auditing

After almost a year of work, we are excited to share news about the major 3.x release! It is major for multiple reasons, including the number of submissions from the community and some breaking changes. Some core functions have been rewritten and several new functions were added.

Another important area for this release is security. Being a security tool, we want Lynis to be as safe as possible, even though shell script is not specifically known for that. So this subject received additional focus on that as well.

Our digital world is full of hardware and software components. The big difference between the two is the quality. When hardware ships with defects, people will return it and talk badly about it. For software it is fine if things are not perfect from the beginning. It can be improved upon in steps, until most of its users are happy with it. Developers of this software often are some level of pressure. We already know that most of the security vulnerabilities are caused by proper training or lack of quality testing. And even then, it is hard to get everything right.

If you worked with a computer the last decade, you know the importance of keeping your software up-to-date. Those who don’t, are stacking up vulnerabilities, waiting for them to being exploited by others. Although Linux and most software are open source and can be reviewed, security flaws in software packages remain. While it isn’t easy to close every vulnerability on your system, we can at least create a stable process around it. This guide explains what is available, from vulnerability to treatment.

The standard itself is very detailed. Still, it sometimes unclear on what specifically to implement and when. This guide will help with translating the PCI standard to technical security controls on Linux systems.

This document has the goal to help you further secure your network and pass the PCI DSS audit. It is important to note that this guide is a set of generic tips. Your IT environment might require additional security measures. Always consult your auditor when it comes to interpreting the PCI DSS requirements and how it relates to your systems and network.

Recently I saw some tweets showing up from an old friend: Tiger. Surprised to see it being promoted, as I know the tool for years, but never seen any new releases in the last years. Both are actually a shame. An outdated tool is usually of lower value. Promoting old tools might actually disappoint others and harm the initial trust in the software.

History of Tiger

In its day, the tool was quite good. Seeing the tool is still being reviewed on blogs, this might be a good opportunity to check out the tool (again). At the same time, it might be a good to learn about some modern alternatives to Tiger, which are more up-to-date with current technologies. Let’s start with the history first and then dive into what we can learn from the project. Tiger is still presented as the “The Unix security audit and intrusion detection tool”.

Create a Linux security fortress; implementing security defenses using towers, bridges, and guards.

Still many companies have difficulties implementing basic security measures. Even after years of websites being defaced, and customer records stolen, the same mistakes are made over and over again. While this all might sound like an unsolvable situation, information security is getting attention from more people. If you are responsible for the system management of Linux systems, ignoring security is no longer an option.

Companies who need to comply with the PCI DSS standard need to log all actions which are executed by the root user or those accounts with similar administrative privileges.

10.2.2 Verify all actions taken by any individual with root or administrative privileges are logged.

The Linux kernel allows the monitoring of executed commands. This monitoring and logging can be done with the Linux audit framework. Using this framework, we can monitor the right system calls and create an audit trail. It is also called Linux accounting. Such accounting is similar to the call history on your mobile phone bill.

An alternative to CIS Benchmarks and hardening guides

Hardening guides, and the CIS benchmarks in particular, are a great resource to check your system for possible weaknesses and conduct system hardening. But who has the time to read it cover to cover, and apply every single step? In this article, we have a look at the alternative: open source auditing tools.

Time..

Hardening is a time-consuming task. As security specialists, we know that. It involves many small steps, followed by even more testing and troubleshooting. Unfortunately, time is something we can spend only once, making it a scarce resource.

A.1.2.a Verify the user ID of any application process is not a privileged user (root/admin).

For Unix and Linux based systems, processes should run as a non-privileged user where possible. However to be able to start, a process is usually started with root permissions (uid 0). This is required to open the required sockets (e.g. bind to port 80).

After the initial start, the process drops its privileges by switching to another user. In some cases there will maintain one master process, which is started with uid 0 as well. This process is responsible for the creation of child processes, not for handling interactions with users or processes. You can consider this as an administrative process. The child processes do handle

Logging commands on Linux with Snoopy

Our customers often want to set-up an audit trail for accounting purposes. When something happens, they want to be able to see what happened, when it did and by whom. Defining an audit trail is also becoming mandatory for compliance, like PCI. One possible solution we cover is using Snoopy, a small library to log executed commands.

How it works

Snoopy is a wrapper around the execve() function. This is a Linux kernel call which instructs it to execute a command pointed to by a filename. This filename is then logged to syslog, together with any parameters. The related syslog level is authpriv. Usually these events on this level will show up in the file /var/log/auth.log.

In this article we have a look at the privileges of Linux daemons and dropping privileges in particular. The samples provided are in C.

Why drop privileges?

Some daemons need root permissions to start. This happens for example when a daemon wants to bind to a low port (<1024). However running network based daemons with root permissions is considered to be a serious risk. In case of compromise of the process, an attacker has full access to the system. This is why software like nginx starts with a master process and forks non-privileged child processes. These child processes (or workers), run under the context of non-privileged account like www-data.

Technical audits or vulnerability scans will reveal a lot of findings. They can be overwhelmed and forcing the reviewer to freeze, not knowing where to start. To overcome this issue, we should prioritize the findings and determine the consequences of each finding for our company.

While an open directory listing on a web server might in one situation not be preferred, it would make sense for others. It is the context which makes a finding “serious” or completely harmless.

Protecting computer networks consists of implementing preventative measures, but especially properly implementing detection methods. These digital tripwires can be used for intrusion detection, or proper handling security events on Unix systems.

Security events

First we have to define a few events which are or can be security related. To get easily started, we focus on 3 tips to implement security events on Unix systems.

1. File changes

Some files you don’t want to change that often, like your DNS resolvers (/etc/resolv.conf). An unexpected change to this file could indicate compromise. Similar of your password file, if the only user is your account and that of the root user.

System hardening is an important part in securing computer networks. Each system should get the appropriate security measures to provide a minimum level of trust. In this post we have a look at some of the options when securing a Red Hat based system. This information applies to Red Hat Linux (RHEL), Fedora, CentOS, Scientific Linux and others.

Red Hat

Red Hat itself has a hardening guide for RHEL 4 and is freely available.

From the initial start of the Linux operating system, the first processes are already born. In this article we have a look on dealing with processes. In particular we look at how to do process auditing. Whenever you are an auditor, system administrator or just a Linux enthusiast, you can’t ignore processes and should know how to deal with them.

Process listing

For most people working on Linux systems, it might be obvious to display running processes with ps. For Linux it’s common to use ps -ef, which shows effectively a list of all processes with a full listing. Those who are used to work on BSD machines will prefer using ps aux. On Linux with the POSIX tools, both will work, however with a slightly different output.

In this article we answer the big question on Linux systems “what to audit?”. Where do you start and what is useful to audit? We apply our three C’s in this article to determine what we should look for when auditing a Linux system.

Current state

What is the current state of the system and how does it compare to previous time?

Ideal situation: compare current state of the system with a predefined baseline or previous scan

Determining the level of Linux server security can only by measuring the actual implemented security safeguards. This process is called auditing and focuses on comparing common security measures with the ones implemented. While there is almost no system with all possible safeguards implemented, we still can determine how well (or badly) the system is protected.

Security is about finding the weakest link(s) and associate risk with each weakness. Depending on the role of the system, sensitivity of data and possible threats, we can then select what security safeguards are appropriate. By implementing these safeguards, called hardening, we increase our security defenses. After these steps, we will compare implemented measures with our baselines to determine the level of compliance.

Auditing on Linux

Although Unix and Linux based systems are not new, getting an extensive knowledge of the operating system takes years of practice. Even then, with all changes it might be hard to keep up, especially when being an auditor. Examples of these are the differences between package managers, the way services are started and where binaries or configuration files are located. But no worries, there is help!

Why Lynis?

The goal of Lynis is to automate the difficulties between each system. Instead of using (outdated) benchmarks or check lists, Lynis will always be using the latest methods to extract data. In the end it is more interesting to know what packages are installed, then knowing the right commands.

In the world of compliance, reported break-ins on the news and many security incidents, it’s common to see a security audit showing up sooner or later. Still, many people in our field don’t like them. But what is a security audit and why should we actually embrace them?

Why audit?

Auditing has a simple goal: check if something is configured according to best practices, a baseline or a preferred state. In an ideal situation these values are all the same and part of a properly taken decision. The reason to audit is to discover any exceptions, weaknesses and determine where there is room for improvement.

Lynis development has its roots on a FreeBSD system, therefore FreeBSD hardening is also easy and supported when using Lynis. People who want to audit and harden their FreeBSD system will discover Lynis to be a powerful tool for this purpose. In this article we will focus on how to audit your system with Lynis.

Ports

Lynis is available from the ports tree and usually the version is close or at the latest version. To install Lynis this way:

Within the field of the audit profession the usage of CAAT (Computer-assisted audit techniques) or CAATTs (computer-assisted audit tools and techniques) is growing. Lynis is filling this gap for Linux and Unix based systems. It’s a well-known and stable tool in this area and improves the audit process by automation. Only a few items could then be checked manually. This saves time, makes the audit more predictable and increases the quality of the overall audit.

Within this article we have a look on how to audit and check the network configuration of Linux and other systems. The main focus is on gathering information and discover how systems are configured. By taking these steps we will do a manual audit. For efficiency reasons we suggest to use an automated tool like Lynis.

Where to start?

Each Linux distribution has their own way and files to configure the network. Therefore we look at the basic components needed to configure a system. Usually the most important components are: