Microsoft Sentinel is a cloud-native Security Information Event Management (SIEM) and Security Orchestration Automated Response (SOAR) solution. Microsoft Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.
In this article, we will describe how to simulate and validate CEF logs (Common Event Format) to the Microsoft Sentinel workspace so you can test your deployment end-to-end even if you don’t have network or security devices that support CEF.
Table of Contents
As you probably know, there are many networking and security devices and appliances that can send their system logs over the Syslog protocol in a specialized format known as Common Event Format (CEF). CEF format includes more information than the standard Syslog format, and it presents the information in a parsed key-value arrangement. The Log Analytics Agent accepts CEF logs and formats them especially for use with Microsoft Sentinel, before forwarding them on to your Microsoft Sentinel workspace.
As shown in the diagram below, CEF Collection in Microsoft Sentinel uses a Linux machine that is used as a log forwarder between your security solution and Sentinel. The Linux machine can be in your on-premises environment, in Azure, or in other clouds. As part of the deployment process, the Log Analytics agent is installed on the Linux machine and serves to relay the events securely to your Microsoft Sentinel workspace.
The number of systems supporting Syslog or CEF is in the hundreds, please make sure to check out the Microsoft Sentinel list for a comprehensive list of sources that support CEF.
To follow this article, you need to have the following:
1) Azure subscription — If you don’t have an Azure subscription, you can create a free one here.
2) Log Analytics workspace — To create a new workspace, follow the instructions to create a Log Analytics workspace. A Microsoft Sentinel workspace is required in order to ingest CEF data into Log Analytics. You also must have read and write permissions on this workspace. Additionally, you need the Workspace ID and Workspace Primary Key when you install the Log Analytics agent — You can find them in the workspace settings, under the Agents management section. (more on this in the next section).
3) Microsoft Sentinel — To enable Microsoft Sentinel at no additional cost on an Azure Monitor Log Analytics workspace for the first 31-days, follow the instructions here.
4) CEF collector — You need to create and configure a Linux machine that will collect the logs from your devices and forward them to the Microsoft Sentinel workspace. This machine will play two roles, collector and forwarder. Please note that this machine can be a physical or virtual machine in your on-premises environment, an Azure VM, or a VM in another cloud. It’s also recommended to deploy the CEF collector machine close to the source (devices and appliances).
5) Log Analytics agent — You need to install the Log Analytics agent on the Linux machine (more on this in the next section).
Install the Log Analytics agent
In this section, we will describe the installation of the CEF collector on the Linux machine. In this example, we are using (ubuntu 20.04).
Please note that these steps are based on the Log Analytics agent for Linux (also known as the OMS legacy agent) and not on the new Azure Monitor Agent (AMA) agent.
You must have elevated permissions (sudo) on your designated Linux machine. The Linux machine must not be connected to any Log Analytics workspaces before you install the Log Analytics agent.
Copy and paste the command below into the command line on your CEF log forwarder machine, and run it. Please note that you need to update the [WorkspaceID] and [Workspace Primary Key] at the end of this command.
sudo wget -O cef_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_installer.py&&sudo python cef_installer.py [WorkspaceID] [Workspace Primary Key]
If you received the message: sudo: python: command not found. Then you could simply install python-is-python3 by running the following command. This is the case if you like “python” to refer to “python3”.
sudo apt-get install python-is-python3
Once the log analytics (OMS) agent is installed and configured on the CEF collector machine, you will receive the following success message:
You will also see the following warning message at the end of the script:
Warning: please make sure your Syslog daemon configuration does not store unnecessary logs. This may cause a full disk on your machine, which will disrupt the function of the oms agent installed.
Please note that this warning message will appear every time you install the log analytics agent because Microsoft has observed many customers that have run into a disk space issue, in which the agent is unable to function properly.
Next, we will show you how to configure the Syslog daemon configuration so it does not store unnecessary logs and resolve the disk space issue. This is useful in a production environment, however, for testing and simulation purposes, you can skip this step and move into the next section (log simulation and verification).
By default, all the logs are stored locally at the following location: /var/log/Syslog – those are local behavior (logs) happening on the CEF machine, for example, every incoming CEF request to the machine is logged.
ls -la cd /var/log/
# Default rules for rsyslog. # # For more information see rsyslog.conf(5) and /etc/rsyslog.conf # # First some standard log files. Log by facility. # auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog #cron.* /var/log/cron.log #daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log #lpr.* -/var/log/lpr.log mail.* -/var/log/mail.log #user.* -/var/log/user.log # # Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files. # #mail.info -/var/log/mail.info #mail.warn -/var/log/mail.warn mail.err /var/log/mail.err # # Some "catch-all" log files.
Back at your command line on your CEF log forwarder machine, type the following command:
sudo nano /etc/rsyslog.d/50-default.conf
For example, if you don’t want to store the kern or mail error log, you just simply put a hashtag (#) at the beginning of the line as shown in the figure below. Then save the file by pressing Ctrl+o, press enter, and then exit Ctrl+x.
Please note that for every change you make to the configuration, you must restart the rsyslog service to take effect by running the following command:
sudo service rsyslog restart
Next, you can confirm that the rsyslog service is up by running the following command:
# You might need to install first "net-tools" depending on your Linux distro version sudo apt install net-tools # Verify rsyslog service sudo netstat -lnpvt
You can see that the rsyslog service is running and listening on TCP port 514, as well as, the Log Analytics agent on localhost using TCP port 25226.
Next, you can check the free disk space on your CEF collector by running the following command. As time goes by and you proceed to continue working on the CEF collector machine, it’s important once in a while to keep looking at the disk space and make sure you don’t have 90% used space.
Simulate CEF Logs
Now let’s simulate CEF logs and test the deployment.
Jump back to your CEF collector machine and run the following command to capture messages coming in from a logger or a connected (network and appliance) device.
sudo tcpdump -i any port 514 -A -vv &
Please note that even if you have a device that supports only Syslog and not CEF, you can still perform the same test. In this example, we have an HPE Proliant Server that we can use to test iLO Remote Syslog.
Switch back to your CEF machine and confirm that Syslog is configured correctly as shown in the figure below. You will see this message: [The receipt of this message confirms that Syslog is configured correctly].
Important: After the validation phase has been completed, it is recommended to stop the tcpdump by typing “fg” which brings the background job to the foreground, and then press Ctrl+C.
The next step is to send CEF demo messages to the Microsoft Sentinel workspace from the CEF collector machine locally without any device.
Switch back to your CEF machine and run the following command:
logger -p local4.warn -P 514 -n 127.0.0.1 --rfc3164 -t CEF "0|DeviceVendorName-Test|DeviceProduct-Test|common=event-format-test|end|TRAFFIC|1|rt=$common=event-formatted-receive_time"
What this command does is the following: The logger command allows us to generate a Syslog request, and we are telling it to do it on the local4 facility, we are sending a severity of (.warn) warning on port 514 to the local IP address (127.0.0.1) using RFC 3164 (The BSD Syslog Protocol) followed with the initial of CEF, and finally, we have the event itself.
In this example the CEF message contains, DeviceVendorName-Test | DeviceProduct-Test | common=event-format-test. You could play and change the DeviceVendorName, the DeviceProduct, and the event format message. But please do NOT do this in production.
Now if you try to send the same exact message (logger command) again without changing the CEF message after “0|——“, the message won’t be forwarded to Sentinel workspace because Microsoft has “Filter duplicated messages” configuration set to ON.
If you want to override this and able to send duplicates CEF messages, then switch back to your CEF machine and run the following command:
# Changing the configuration file for rsyslog sudo nano /etc/rsyslog.conf
You need to update this line: $RepeatedMsgReduction from on to off as shown in the figure below (for testing purposes). Then save the conf file by pressing Ctrl+o, press enter, and then exit Ctrl+x.
Last, you need to restart the rsyslog service for the duplicate messages to take effect.
sudo service rsyslog restart
Now you can start sending duplicate CEF messages.
Verify Logs in Log Analytics
Finally, we need to verify and validate that CEF logs have arrived in the Log Analytics workspace.
Please note that it may take up to 5-10 minutes maximum after the connection is made for data to appear in Log Analytics.
To search for CEF events in Log Analytics, query the CommonSecurityLog table in the query window.
Open Microsoft Sentinel dashboard blade and navigate to Logs under the General section.
Next, run the following sample KQL query to verify the logs have arrived:
CommonSecurityLog | sort by TimeGenerated
If we open any of the CEF log messages, you will see the following details.
That’s it there you have it!
In this article, we described how to simulate and validate CEF logs to a Linux collector machine which in return will forward the logs to the Microsoft Sentinel workspace so you can test your deployment end-to-end even if you don’t have network or security devices that support CEF.
The common event format (CEF) is a standard for the interoperability of event- or log-generating devices and applications. The standard defines a syntax for log records. It comprises a standard prefix and a variable extension that is formatted as key-value pairs.
To learn more on how to deploy the Log Analytics agent to connect CEF appliances to Microsoft Sentinel, please check the official documentation.
To learn more on how to troubleshoot your CEF or Syslog data connector, please check the official documentation.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.