Listen to this Post
Introduction:
Syslog forwarding is a critical capability for any robust Security Information and Event Management (SIEM) implementation, enabling the collection of security events from network devices, servers, and applications that don’t natively support Azure agents. For Microsoft Sentinel users, configuring a Syslog forwarder on Linux is an essential but often intimidating task that bridges the gap between on-premises infrastructure and cloud security monitoring.
Learning Objectives:
- Understand the core architecture and components of a Syslog forwarding pipeline to Microsoft Sentinel.
- Deploy and configure a Linux machine as a dedicated Syslog collector and forwarder.
- Master the essential Linux commands and file edits required to implement and troubleshoot the solution.
You Should Know:
1. Architecting Your Syslog Forwarding Solution
The foundation of a successful deployment is choosing the right architecture. The most common pattern involves deploying a dedicated Linux virtual machine (in Azure or on-premises) that acts as a central Syslog collector. This machine receives Syslog messages from your network devices and servers, then forwards them to your Microsoft Sentinel Log Analytics workspace using the Log Analytics agent.
2. Initial Linux Server Hardening
Before installing any services, secure your baseline Linux image. These commands update the system, install critical security tools, and configure the firewall to only allow Syslog traffic from authorized sources.
Update the entire system package repository and installed packages sudo apt update && sudo apt upgrade -y Install a basic firewall and the Uncomplicated Firewall (UFW) management tool sudo apt install ufw Configure UFW to allow SSH and Syslog traffic (port 514) from specific subnets sudo ufw allow from 192.168.1.0/24 to any port 22 sudo ufw allow from 10.0.0.0/8 to any port 514 proto udp sudo ufw enable Verify the firewall rules are active sudo ufw status verbose
This step-by-step guide ensures your collector is not openly exposed. The `apt update && upgrade` refreshes the package list and installs security patches. The UFW firewall is then configured to only allow SSH management from your internal management subnet and Syslog data (typically on UDP port 514) from your designated network segments, significantly reducing the attack surface.
3. Installing and Configuring the Syslog Daemon (rsyslog)
Most Linux distributions use `rsyslog` as the default Syslog daemon. It is highly configurable and capable of receiving messages from remote systems and relaying them.
Install the rsyslog application if not already present sudo apt install rsyslog -y Edit the main rsyslog configuration file sudo nano /etc/rsyslog.conf
Within the `/etc/rsyslog.conf` file, you must enable the modules and rules to accept remote messages.
Uncomment the following lines to enable UDP and TCP syslog reception module(load="imudp") input(type="imudp" port="514") module(load="imtcp") input(type="imtcp" port="514")
After editing, save the file and restart the service.
Restart the rsyslog service to apply changes sudo systemctl restart rsyslog Check the status to ensure it's running without errors sudo systemctl status rsyslog
This configuration loads the `imudp` and `imtcp` input modules, instructing `rsyslog` to listen for incoming Syslog messages on the standard port 514 for both UDP and TCP protocols. Restarting the service activates this new configuration.
4. Installing the Microsoft Log Analytics Agent
The Log Analytics Agent (also known as the OMS agent) is the component that forwards the logs from the Linux machine to your Microsoft Sentinel workspace.
Download and install the Log Analytics agent wrapper script wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh Make the script executable and run it with your Workspace ID and Key chmod +x onboard_agent.sh sudo sh onboard_agent.sh -w YOUR_WORKSPACE_ID -s YOUR_PRIMARY_KEY -d opinsights.azure.com
Replace `YOUR_WORKSPACE_ID` and `YOUR_PRIMARY_KEY` with the values from your Log Analytics workspace under Agents management. This script installs the agent and registers the machine with your Sentinel workspace.
- Configuring rsyslog to Forward to the Local Agent
The Log Analytics agent reads logs from a local file. You must configure `rsyslog` to write the received remote messages to this specific file.
Create a new rsyslog configuration file for forwarding rules sudo nano /etc/rsyslog.d/90-sentinel.conf
Add the following line to this new file. This rule uses a template to format the message and sends all messages (represented by “) to the file monitored by the agent.
Template to format the message for the agent $Template MicrosoftSentinelSyslog,"%timestamp% %hostname% %syslogtag% %msg%" Rule to write all messages to the agent's source file . @@127.0.0.1:25226;MicrosoftSentinelSyslog
Save the file and apply the changes.
Restart the rsyslog service to load the new forwarding configuration sudo systemctl restart rsyslog
This step is the core of the forwarding pipeline. It creates a rule that takes every incoming Syslog message, applies a defined format, and sends it to a local TCP port where the Log Analytics agent is listening.
- Configuring the Log Analytics Agent for Syslog Collection
You must now tell the agent which Syslog facilities and severity levels to collect and forward.
Edit the syslog configuration for the OMS agent sudo nano /etc/opt/microsoft/omsagent/YOUR_WORKSPACE_ID/conf/omsagent.d/syslog.conf
Locate the `auth, authpriv, daemon) and severities (e.g., info, notice, warning).
<source> @type syslog port 25226 bind 127.0.0.1 protocol_type tcp tag syslog </source>
After editing, restart the agent.
Restart the Log Analytics agent to apply the new syslog filter sudo /opt/microsoft/omsagent/bin/service_control restart YOUR_WORKSPACE_ID
This configuration defines the source for the agent, telling it to listen on the local TCP port 25226 for the formatted Syslog messages and process them according to the defined filters.
7. Validating and Troubleshooting the Data Flow
Once configured, you must verify that data is flowing end-to-end. Use these critical commands to check each stage of the pipeline.
1. Check if rsyslog is listening on port 514 for remote messages sudo netstat -tulnp | grep :514 <ol> <li>Check if the OMS agent is listening on the local forwarder port 25226 sudo netstat -tulnp | grep :25226</p></li> <li><p>Monitor the local syslog file for incoming messages in real-time tail -f /var/log/syslog</p></li> <li><p>Check the OMS agent logs for any errors tail -f /var/opt/microsoft/omsagent/YOUR_WORKSPACE_ID/log/omsagent.log</p></li> <li><p>Run a test query in Microsoft Sentinel to confirm data arrival In the Log Analytics workspace, run: Syslog | limit 10
This step-by-step troubleshooting guide helps you isolate failures. `netstat` confirms the services are running on the correct ports. `tail -f` on the syslog file shows if messages are being received from network devices, while the omsagent log reveals any issues with processing or forwarding. The final validation is a successful query in the Sentinel Logs blade.
What Undercode Say:
- The operational burden of managing the Linux collector is non-trivial and often underestimated, encompassing patching, security hardening, and performance monitoring.
- This architecture introduces a single point of failure; if the collector VM goes down, all Syslog data from downstream sources is lost until it is restored.
The guide provided is technically sound for a proof-of-concept or small environment, but the critical analysis from the community highlights significant operational and architectural considerations. As Matthew Schofield pointed out, this self-managed approach adds a system to your inventory that requires ongoing maintenance and falls under your security responsibility. For enterprise-scale deployments, a high-availability pair of collectors or a commercial managed collector service is strongly recommended to mitigate the single point of failure risk. Furthermore, the initial security hardening is just the beginning; this VM becomes a high-value target as it aggregates security data and must be subject to rigorous, ongoing security controls and monitoring, potentially increasing the total cost of ownership beyond initial estimates.
Prediction:
The foundational skill of configuring log forwarding will become increasingly automated and abstracted away by cloud-native services. We predict that within the next 2-3 years, major SIEM providers like Microsoft will offer fully managed, agentless ingestion endpoints for common protocols like Syslog, reducing the need for self-managed Linux middlemen. This will shift the security professional’s focus from infrastructure management to data normalization, analytics, and threat-hunting logic, while simultaneously eliminating a common attack vector and point of failure in modern SOC architectures.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Rafal Kitab – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
