Practical Linux Security Cookbook. - Second Edition

Chapter 1. Linux Security Problem

A Linux machine is only as secure as the administrator configures it to be. Once we have installed the Linux distribution of our choice and have removed all the unnecessary packages post installation, we can start working on the security aspect of the system by fine-tuning the installed software and services.

In this chapter, we will discuss the following topics:

Configuring server security
Security policy—server security
Defining security controls
Missing backup plans

The following recipes will be covered in the chapter:

Checking the integrity of installation medium using checksum
Using LUKS disk encryption
Making use of sudoers—configuring sudo access
Scanning hosts with Nmap
Gaining root on a vulnerable Linux system
Missing backup plans

Security policy

A security policy is a definition that outlines the rules and practices to be followed for computer network security in an organization. How the organization should manage, protect, and distribute sensitive data is defined in the security policy.

Developing a security policy

When creating a security policy you should keep in mind that it should be simple and easy for all the users to follow. The objective of the policy should be to protect the data while keeping the privacy of the users.

It should be developed around these points:

Accessibility to the system
Software installation rights on the system
Data permission
Recovery from failure

When developing a security policy, a user should be using only those services for which permission has been granted. Anything that is not permitted should be restricted in the policy. Let's look at some common Linux security myths.

Linux security myths

You might feel nervous while planning to use Linux-based systems in your business. This may be due to some false rumors about security in Linux that the systems might have fallen prey to any of the myths out there.

Myth – as Linux is open source, it is considered to be insecure

Linux, being a free and open source operating system, has its own advantages. It includes a large base of developers who constantly audit the source code for any possible security risks; the Linux community can provide fast support and fixes for any potential security problem. Patches are released quickly for testing by the community so they don't have to deal with the clumsy administration that other Unix vendors may have to deal with.

Due to the massive worldwide user base, Linux's security gets tested across huge range of computing environments, thus making it one of the most stable and secure operating systems. As Linux is open to scrutiny by developers across the world, it helps Linux derive superior security in the ways the privileges are assigned. The way in which these privileges are assigned in a Linux system is also a security feature derived from the open source code of the system.

Myth – Linux is an experts-only system, and only they know how to configure their systems in terms of security

Assuming that Linux is for experts who know how to deal with viruses is a misconception. Linux has evolved to become one of the friendliest OSes that can be used by anyone, whether novice or experts.

Linux is secure because of its strong architecture. Regular users on a Linux system possess low-privileged accounts rather than having root privileges.

Myth – Linux is virus free

Due to its strong architecture, even if a Linux system gets compromised, viruses would not have root access and thus will not be able to cause any major damage to the system.

Even on Linux servers, several levels of security are implemented and they are updated more often, again helping to secure the servers from viruses.

There are still a number of viruses that target Linux, thus making it not completely virus free. But most of the viruses that exist for Linux are non-destructive in nature.

Configuring server security

Once a Linux server is created, the immediate next step is to implement security procedures to make sure that any kind of threat should not cause the system to be compromised. A major reason for malicious attacks on Linux servers have been poorly implemented security or existing vulnerabilities. When configuring a server, the security policies need to be implemented properly to create a secure environment that will help prevent your business from getting hacked.

How to do it...

Let us have a look for each and every configuration.

User management

Follow these steps to configure server security:

When a Linux server is created, the first user created by default is always the root user. This root user should be used for initial configuration only.
Once initial configuration is done, this root user should be disabled via SSH. This will make it difficult for any hacker to gain access to your Linux machine.
Further, a secondary user should be created to log in and administer the machine. This user can be allowed sudo permissions if administrative actions need to be performed.

Password policy

Follow these steps to configure server security:

When creating user accounts, ensure the use of strong passwords. If allowed, keep the length of the password to between 12 to 14 characters.
If possible, generate passwords randomly, and include lowercase and uppercase letters, numbers, and symbols.
Avoid using password combinations that could be easily guessed, such as dictionary words, keyboard patterns, usernames, ID numbers, and so on.
Avoid using the same password twice.

Configuration policy

Follow these steps to configure server security:

The operating system on the server should be configured in accordance with the guidelines approved for InfoSec.
Any service or application not being used should be disabled, wherever possible.
Every access to the services and applications on the server should be monitored and logged. It should also be protected through access-control methods. An example of this will be covered in Chapter 3, Local Filesystem Security.
The system should be kept updated and any recent security patches, if available, should be installed as soon as possible
Avoid using the root account as much as possible. It is better to use the security principles that require least access to perform a function.

Any kind of privileged access must be performed over a secure channel connection (SSH) wherever possible.
Access to the server should be in a controlled environment.

Monitoring policy

All security-related actions on server systems must be logged and audit reports should be saved as follows:

For a period of one month, all security-related logs should be kept online
For a period of one month, the daily backups, as well as the weekly backups should be retained
For a minimum of two years, the monthly full backups should be retained

Any event related to security being compromised should be reported to the InfoSec team. They shall then review the logs and report the incident to the IT department.
Some examples of security-related events are as follows:

Port-scanning-related attacks
Access to privileged accounts without authorization
Unusual occurrences due to a particular application on the host

How it works...

Following the policies as given here helps in the base configuration of the internal server that is owned or operated by the organization. Implementing the policy effectively will minimize unauthorized access to any sensitive and proprietary information.

Security policy – server security

A major reason for malicious attacks on Linux servers has been poorly implemented security or existing vulnerabilities. When configuring a server, the security policies need to be implemented properly and ownership needs to be taken for proper customization of the server.

How to do it…

Let's have a look and various security policies

General policy

Let's discuss the various security policies:

The administration of all the internal servers in an organization is the responsibility of a dedicated team that should also keep watch for any kind of compliance issues. If a compliance issues occurs, the team should immediately review and implement an updated security policy.
When configuring internal servers, they must be registered in such a way that the identification of the servers can be done on the basis of the following information:
- Location of the server
- Operating system version and hardware configuration
- Services and applications running on the server
Any kind of information in the organization's management system must always be kept up to date.

Configuration policy

Let's discuss the various security policies:

The operating system on the server should be configured in accordance with the guidelines approved for InfoSec.
Any service or application not being used should be disabled, wherever possible.
Every access to the services and applications on the server should be monitored and logged. It should also be protected through access-control methods. An example of this will be covered in Chapter 3, Local FileSystem Security.
The system should be kept updated and any recent security patches, if available, should be installed as soon as possible
Avoid using the root account as much as possible. It is better to use security principles that require least access to perform a function.
Any kind of privileged access must be performed over a secure channel connection (SSH), wherever possible.
Access to the server should be in a controlled environment.

Monitoring policy

Let's discuss the various security policies:

All security-related actions on server systems must be logged and audit reports should be saved as follows:
- For a period of one month, all the security-related logs should be kept online
- For a period of one month, the daily backups, as well as the weekly backups, should be retained
- For a minimum of two years, the monthly full backups should be retained
Any event related to security being compromised should be reported to the InfoSec team. They shall then review the logs and report the incident to the IT department.
Some examples of security related events are as follows:
- Port-scanning-related attacks
- Access to privileged accounts without authorization
- Unusual occurrences due to a particular application on the host

How it works…

Following the policies as given here helps the base configuration of the internal server that is owned or operated by the organization. Implementing the policy effectively will minimize unauthorized access to any sensitive and proprietary information.

Defining security controls

Securing a Linux server starts with the process of hardening the system, and to do this it's important to define a list of security controls. A security controls list (or security checklist) confirms that proper security controls have been implemented.