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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.