Microsoft Sentinel enables security teams to collect, detect, investigate, and respond to security threats across hybrid and multi-cloud environments.
A crucial part of this capability is log collection — especially from Linux systems and network/security appliances that generate Syslog and CEF (Common Event Format) messages.
With the Azure Monitor Agent (AMA) and Data Collection Rules (DCR), Microsoft now provides a unified, modern way to onboard Syslog and CEF data into Sentinel — replacing the older Log Analytics (OMS) agent.
🔍 What Are Syslog and CEF?
| Log Type | Description | Example Source | Default Sentinel Table |
|---|---|---|---|
| Syslog | Standard logging protocol on Linux/UNIX systems. Used for OS, authentication, and service logs. | RHEL, Ubuntu, CentOS servers | Syslog |
| CEF (Common Event Format) | Structured format for security logs with key-value pairs. | Firewalls, IDS/IPS, proxies, antivirus | CommonSecurityLog |
🧩 Why Use AMA and DCR?
The Azure Monitor Agent (AMA) is the new unified agent for all Azure monitoring needs — performance, metrics, and logs.
It’s more efficient and flexible than the legacy agent and supports fine-grained control through Data Collection Rules (DCRs).
Benefits of AMA + DCR:
- ✅ Unified collection for Syslog, CEF, and performance metrics.
- ✅ Modern, scalable data pipeline managed through Azure Policy or Portal.
- ✅ Granular filtering: choose which facilities and severities to collect.
- ✅ Full support for Azure Arc–enabled servers (hybrid and on-prem).
- ✅ Automatic agent deployment and updates.
🏗️ Architecture Overview
Linux Servers / Security Devices
↓ (Syslog / CEF over TCP/UDP)
Azure Monitor Agent (AMA)
↓
Data Collection Rule (DCR)
↓
Log Analytics Workspace
↓
Microsoft Sentinel
- AMA – collects and forwards logs securely to Azure.
- DCR – defines what data to collect and where to send it.
- Workspace – stores logs for analytics and queries.
- Sentinel – correlates and visualizes data for detection and response.
⚙️ Prerequisites
Before configuring the connector:
- 🧭 Log Analytics Workspace — Connected to your Sentinel instance.
- 🧰 Azure Monitor Agent (AMA) — Automatically installed via DCR or manually.
- 🌐 Outbound Internet Access — Port 443 to Azure Monitor endpoints.
- ☁️ Azure Arc — Required if collecting from non-Azure Linux servers (e.g., RHEL).
- 👩💻 Permissions — Owner, Contributor, or Security Admin on target machines.
🚀 Step-by-Step Setup (Portal Method)
Step 1 – Enable the Syslog/CEF Connector
- Go to Microsoft Sentinel → Data connectors.
- Search for “Syslog/CEF via AMA”.
- Click Open connector page → Create data collection rule (DCR).
Step 2 – Configure the Data Collection Rule (DCR)
In the DCR wizard:
- Choose your subscription, resource group, and region.
- Select the machines to collect from (Arc-enabled or Azure VMs).
- Define Syslog facilities (e.g.,
auth,authpriv,daemon,syslog,kern). - Select severities (e.g.,
Error,Critical,Alert,Warning,Info). - Set destination as your Log Analytics workspace.
💡 Tip: DCRs support multiple data types (Syslog, CEF, performance). You can reuse the same rule across servers.
Step 3 – Configure Syslog or CEF Forwarding on Linux
For RHEL or Ubuntu servers:
sudo vi /etc/rsyslog.d/60-sentinel.conf
Add the following lines:
# Listen for incoming CEF logs
module(load="imtcp")
input(type="imtcp" port="514")
# Optional: forward local logs to Sentinel
*.* @@127.0.0.1:514
Restart rsyslog:
sudo systemctl restart rsyslog
If using syslog-ng, configure a similar input block:
source s_net { tcp(port(514)); };
log { source(s_net); destination(d_logs); };
Step 4 – Send CEF Logs from Security Devices
For firewalls, IDS/IPS, or proxies:
- Configure the device to send CEF messages via Syslog (TCP 514) to the Linux forwarder VM.
- The forwarder then sends data to Sentinel via the Azure Monitor Agent.
Example:
Device → CEF message → rsyslog → AMA → Log Analytics → Sentinel
✅ Data arrives in the CommonSecurityLog table.
Step 5 – Verify Log Ingestion
Open the Sentinel workspace → Logs, and run:
Syslog check
Syslog
| take 10
CEF check
CommonSecurityLog
| take 10
If data appears, collection is successful 🎉
🧠 Troubleshooting Tips
| Issue | Cause | Fix |
|---|---|---|
| No data in Sentinel | DCR not associated or incorrect facilities | Recheck DCR association |
| Connection timeout | Port 514 or 443 blocked | Open outbound network ports |
| Duplicate logs | Device and server both forwarding | Keep only one source per log type |
| Wrong timestamps | Timezone mismatch | Sync server time (NTP) |
🧾 Example Data Collection Rule (JSON)
Here’s a sample DCR that collects Syslog and CEF from RHEL:
{
"location": "westeurope",
"kind": "Linux",
"properties": {
"dataSources": {
"syslog": [
{
"name": "syslog-source",
"facilityNames": ["auth", "authpriv", "daemon", "syslog"],
"logLevels": ["Error", "Critical", "Alert", "Emergency", "Warning"]
}
]
},
"destinations": {
"logAnalytics": [
{
"name": "la-destination",
"workspaceResourceId": "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/<workspace>"
}
]
},
"dataFlows": [
{
"streams": ["Microsoft-Syslog"],
"destinations": ["la-destination"]
}
]
}
}
📊 Where Logs Appear in Sentinel
| Log Type | Table Name | Use Case |
|---|---|---|
| Syslog | Syslog | Linux OS, authentication, kernel logs |
| CEF | CommonSecurityLog | Security device alerts and events |
🔗 References
- Connect Syslog and CEF to Sentinel using AMA
- Syslog and CEF via AMA Overview
- Data Collection Rules (DCR)
- Azure Monitor Agent
🧩 Summary
✅ Use AMA + DCR for both Syslog and CEF ingestion
✅ Configure rsyslog/syslog-ng on your RHEL or collector VM
✅ Associate DCRs with Arc or Azure machines
✅ Validate in Syslog or CommonSecurityLog tables
✅ Retire the old Log Analytics (OMS) agent