Practical training in pentest laboratories. Part 5

“Corporate laboratories” is a training program in the field of information security, consisting of theoretical (webinar courses) and practical training (work in pentest laboratories). This article will consider the content of the practical base, which constitutes about 80% of the total training program. The article contains a brief analysis of one of the tasks of practical training.



Ideal impenetrable protection is almost impossible to build, so you need to be prepared for the fact that in theory a compromise can occur. At the same time, with a correctly constructed scheme and worked-out response processes, it is often possible to minimize damage.

')

To ensure an adequate level of security infrastructure requires constant monitoring of its components. For these purposes, it is necessary to conduct an audit of system security, study logs and event logs, and obtain data from other monitoring sources.



Such information allows you to improve protection and upgrade response processes, using data from the incident that occurred. System security audit allows you to:

• Find out who committed a specific action in the system, identify the possible person involved;
• Set the date of the action;
• Identify the resources affected during the compromise process;
• Find out whether there is a fault of a particular person, or it is a system (software) error;
• To develop measures for the recovery and prevention of the incident in the future;
• Assess the risks.

Event logging

First of all, it is necessary to use the standard means of the system; security log. The security log contains events such as successful and unsuccessful login attempts, as well as events related to the use of resources, such as the creation, opening, and deletion of files and other objects. Administrators can select events to be logged in the security log. For example, if logon auditing is enabled, all logon attempts are recorded in the security log.







The main parameters of the records:

• Audit logins;
• Audit changes to important system objects: files, folders;
• Audit of the use of administrator rights on the machine.

These values ​​are configured in local group policies, in the configuration of the advanced audit policy. It should be noted the important fact that by default these policies are turned off. This is due to some factors:

• There is a huge number of events (difficult to process and analyze);
• Difficult separation of user actions from system actions and programs.
• The default log size is insufficient (20 MB).

In * nix systems there is a utility auditd .







Starting with version 2.6, the Linux kernel includes a subsystem specifically designed for auditing, allowing you to track system events such as:

• Starting and shutting down the system (reboot, stop);
• Reading / writing or changing file permissions;
• Initiate a network connection or change network settings;
• Changing information about a user or group;
• Change date and time;
• Start and stop applications;
• Make system calls.

How it works

No event in any operating system can occur without the use of kernel system calls. Starting a new process, opening files and working with them, requesting a time or type of OS, accessing equipment, creating a network connection, displaying information on the screen - all these operations are performed using access to the functions of the operating system kernel for brevity called system calls. If an application does not resort to kernel calls in its work, it turns out to be closed in itself and is simply not capable of any interaction with its environment, let alone a user. Consequently, in order to track any system event, it is sufficient to simply intercept all calls to system calls.



This is exactly what the audit subsystem does. It sets the “before” and “after” triggers of all functions responsible for handling system calls, and waits. When a system call occurs, the trigger fires, the audit subsystem receives all the information about the call and its context, passes it to the auditd daemon and gives further control to the function that processes the system call. After its completion, the "output" trigger is triggered, and all information about the system call is returned to the audit subsystem and the auditd daemon.



Naturally, keeping all these triggers active for the entire operating time of the OS is expensive and too redundant (only during the start, the application can make several thousand system calls and it will take a lot of time to fully analyze the audit log). Therefore, by default, triggers are disabled and can be selectively activated using rules that specify the name of the system call, the status of the run, the user on whose behalf the call occurred, etc.

Log analysis

The logical development of journaling systems are IDS (intrusion detection system), IPS (intrusion prevention system), SIEM (security infromation and event management) systems. They allow in a more convenient way to interpret events in the system and reduce the burden on IT staff. They contain certain sets of patterns of system behavior and components for detecting attacks. Those. in essence, they collect a certain range of events by which they can judge the presence of a particular type of attack / incident. They can provide information both in real time and by analyzing some events (in this case, the reaction to the anomaly may be delayed). These systems collect data from several sources, which are divided into the following types:

• Network;
• Protocol based;
• Based on application protocol;
• Nodal;
• Hybrid.

These systems can contain collection agents, as well as modules for working with various protocols and devices. In today's reality, a bundle of several systems is usually used to increase the level of protection and prompt response to incidents: securing the network perimeter using Snort, OSSEC and Prelude SIEM .

Integrity

The issue of trust coming from data audit logs or from specialized systems is particularly high in those systems that have been compromised. Many people forget about the fact that the log files are not protected. They can easily be changed, changed or destroyed by gaining access to the machine on which they are located. In theory, after the system has been compromised, the data on it, including the log files, cannot be trusted. There is no guarantee that they are not intentionally altered by attackers.



To have reliable data for analysis, you can use a centralized event log storage scheme. It is desirable for a centralized repository to have a separate server on which nothing but the event reception service will be installed and running. Such a service should only be able to receive events, and its functionality should not initially contain functions for changing and deleting data.



After receiving events in the repository, you can take an additional step - backup. You can also think about assigning checksums to backup files and storing them in a different place (or sending them immediately to a special mailbox). There are many options for such a scheme; its use significantly increases the degree of confidence in the event logs.



Using incident logging and response systems gives IT staff the opportunity to prevent most modern infrastructure attacks and protect the critical data of their systems.

---

Practical training in pentest laboratories. Part 1

Practical training in pentest laboratories. Part 2

Practical training in pentest laboratories. Part 3

Practical training in pentest laboratories. Part 4