3. FortiAnalyzer Getting Started v6.4. Working with logs

Welcome to the third lesson of the FortiAnalyzer Getting Started course. In the last lesson, we deployed the layout required for laboratory work. In this lesson, we will look at the basic principles of working with logs on FortiAnalyzer, we will get acquainted with event handlers, and also consider the mechanisms for protecting logs. The theoretical part, as well as the complete recording of the video lesson, are under the cut.

In order to collect logs from devices, they must be registered with FortiAnalyzer. There are two registration options:
The first option – the option “send logs to FortiAnalyzer” is activated on the registered device and its IP address is indicated. After that, a request is sent to FortiAnalyzer to register this device. The administrator must approve or reject the received request. If the technology of administrative domains is activated, FortiGate can be added both to the main ADOM (which is called root, we worked with it in the last lesson), and to a custom-created ADOM, which is intended for FortiGate devices.
The second option is the so-called Device Registration Wizard. Device registration takes place on the FortiAnalyzer itself. Registration requires information about the device to be registered – serial number, IP address, device type, and operating system version. If the data verification is successful, the device is added to the FortiAnalyzer list. If Administrative Domain technology is activated, the device will automatically register with the correct Administrative Domain. If you have created several similar administrative domains, then you need to register the device from the administrative domain to which you want to add it.

Each device generates different types of logs. The main types of logs that Fortinet devices can generate are shown in the figure below.

We already talked about the initial processing of logs in the last lesson, but I think it’s worth refreshing your memory. Logs sent to FortiAnalyzer are compressed and saved to a log file. When this file reaches a certain size, it is overwritten and archived. Such logs are called archived. They are considered offline logs because they cannot be analyzed in real time. They are available for viewing only in RAW format. The retention policy for the administrative domain determines how much of these logs will be stored in the memory of FortiAnalyzer.
At the same time, the logs are indexed in the SQL database to support analytics. These logs are analyzed in FortiAnalyzer in real time using the Log View, FortiView and Reports mechanisms. The data retention policy in the administrative domain determines how much such logs will be stored in the memory of FortiAnalyzer. After these logs are removed from the memory of FortiAnalyzer, they may remain in the form of archived logs, but this depends on the data storage policy in the administrative domain.
A schematic of the log processing process is shown in the figure below.

When the logs arrive on the device, they are checked by event handlers. They allow you to track events of interest using pre-configured conditions. Conditions are set for the parameters contained in the RAW format logs. The system has a set of predefined events for each administrative domain, but if necessary, you can create your own event handlers. The main use of event handlers is that when the events of interest occur, the system can send notifications to email or syslog servers also via SNMP. This allows you to quickly react to events occurring on the network.

Now let’s talk about protecting logs. Since the logs store important information about what is happening on the network, they need to be protected both from possible loss as a result of various failures and from external compromise. The first technology to help protect logs in the event of various failures is RAID. It allows you to divide the space from the available disks into several logical segments so that if one or more disks (depending on the RAID type) fail, data will not be lost. The main RAID types that can be used in FortiAnalyzer are shown in the figure below.

  • RAID 0 distributes information across 2 or more drives. The main goal is speed and performance. If one or more disks fail, the entire disk array will suffer;
  • RAID 1 distributes copies of information across 2 or more drives. If one disk fails, the disk array will continue to operate as usual;
  • RAID 5 distributes information across multiple disks, and also allocates one disk for recovery data in each so-called “chain of information”. If one disk fails, the disk array will continue to operate as usual;
  • RAID 6 works in a similar way, only two disks are already allocated for recovery data;
  • RAID 10 combines the options RAID 0 and RAID 1. With this, you can continue to work with information if 2 disks fail (one from each raid, otherwise it will be impossible to read the information);
  • RAID 50 combines the functionality of RAID 0 and RAID 5. In this case, stable operation with information will continue even if one disk fails in each RAID 5;
  • RAID 60 combines the functionality of RAID 0 and RAID 6. In this case, stable operation of information will continue even if 2 disks in each RAID 6 fail.

The next mechanism is log backups. There are several options for backups – from the Log View menu, where you can use a specific filter to save the necessary logs, or Log Browse, from where you can download the recorded log files. It is also possible to backup logs to external servers using the CLI interface.

Another mechanism that allows you to protect important information contained in the logs is redundancy. There are also several options here:
The first, in which devices send logs to 2 FortiAnalyzers at once – one of them is the main one, the other is backup.
We already discussed the second method in the last lesson – one FortiAnalyzer works in collector mode and collects logs from various devices. According to the schedule, collected logs are sent to FortiAnalyzer, which operates in Analyzer mode. If the second fails, the collector will be able to forward the logs to another FortiAnalyzer.
And the third option is to transfer logs from FortiAnalyzer to external servers, for example, to Syslog. In this case, the transfer of logs will occur in real time.

There are two main mechanisms used to protect logs from compromise:

  1. Encryption of the data transmission channel between FortiAnalyzer and other devices;
  2. Protecting logs from modification by adding a checksum.

The video tutorial presents the theoretical material discussed above, and also discusses the practical aspects of working with logs – filtering them, viewing them in various modes, setting up event handlers. Happy viewing!

In the next lesson, we will take a closer look at the aspects of working with reports. In order not to miss it, subscribe to our Youtube channel

You can also follow the updates on the following resources:

Vkontakte community
Yandex Zen
Our website
Telegram channel

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *