(Note: I have an older blog on this topic but based on new insights this article supersedes the old one)
Microsoft has already labeled the old ‘OMS’ syslog collector agent as legacy, so it’s important to think about switching to the new AMA agent.
If you have the word ‘syslog’ stuck in your brain you might think that in order to configure syslog you’d go into the Sentinel data connectors and search for ‘syslog’ – don’t do this.
The procedure for getting syslog into Sentinel is a bit different for VMs that are in Azure vs on-prem.
I’ve tested the recommendations below with the latest versions of Redhat And Ubuntu, on both on-prem VMs and in Azure.
For Azure VMs:
– Create a DCR and configure your syslog facilities. Done..
– Note that a DCR is a Data Collection Rule. This is a fairly new way to define what data needs to be collected. It somewhat hides the underlying method of collection – eg. you tell it to collect syslog from a list of servers in scope, and it takes care of communicating with the AMA agent to make it happen.
– In Sentinel, you don’t need to do anything! The DCR points the data to the servers in scope and the log analytics workspace.
For an on-prem VM
– Just make sure you install the Arc agent first, then create your DCR for syslog, just like for the Azure VM. Done!
A very simple test:
On your linux server, ssh in and type “logger testing123”
In Sentinel > Logs, type “search testing123” . You will see your logs show up in the Syslog table in about 5-10 minutes, depending on when you pushed out your DCR.
(TIP: If you don’t see your logs in Sentinel but you see them with tcpdump, then check your firewall rules, eg. by default RedHat7 will block incoming syslog)
To check if your logs are event getting to your syslog server use tcpdump eg:
tcpdump -i any port syslog -A -s0 -nn
And note that you could be seeing your logs with the above tcpdump command but they’re still not getting to Sentinel. In that case check if the local firewall rules are blocking syslog.
If you need to troubleshoot the actual AMA agent on linux (or windows), there’s a script for that here.
What about CEF Logs?
If you need to collect CEF formatted syslog then you will need to go into Sentinel > Data Connectors – and search for “Common Event Format (CEF) via AMA (Preview)”. There’s a script in here you’ll need to run for both your Azure VMs and your on-prem linux VMs/servers.
The AMA/CEF script is commonly used for when you are trying to collect CEF logs from somewhere like PaloAlto firewalls and you want to forward them into Sentinel.
After installing the CEF forwarder script, create a DCR to forward the logs to Sentinel’s workspace. MAKE SURE YOU CREATE THIS DCR from Sentinel> Data Connectors CEF Via AMA. This will provide a special CEF configuration with the string ‘SECURITY_CEF_BLOB’ inside a json file located at /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/nnn.json. If this configuration doesn’t exist, your CEF data will only be forwarded to the Syslog table, not the CommonSecurityLog table.
Tip: Don’t use the same ‘syslog facility’ for CEF as you use for syslog or you may get log duplications. eg. if you use ‘user.info’ for CEF, don’t use it for your ‘regular’ syslog DCR.
There’s a great troubleshooter script for CEF:
Read this or jump the bottom of the page and run the troubleshooter:
sudo wget -O sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py &&sudo python sentinel_AMA_troubleshoot.py
Don’t get this confused with the ‘old’ CEF troubleshooter that was created for the OMS agent.
After running all of the troubleshooting tests, go to the Sentinel logs and look for the ‘MOCK’ test logs:
CommonSecurityLog
| where DeviceProduct == "MOCK"
If you need to run the MOCK test manually, here’s the command (sometimes the troubleshooting script doesn’t catch the test log so you may need to run it in another terminal session while running the script):
echo -n "<164>CEF:0|Mock-test|MOCK|common=event-format-test|end|TRAFFIC|1|rt=$common=event-formatted-receive_time" | nc -u -w0 <YOUR IP ADDRESS> 514
Another tip: Keep the /var mount point separate from root and give it about 500GB of disk space just for /var. Keep an eye on your disk space and increase this if necessary.
Another tip: There’s no need to keep the incoming syslog data in /var/log, so disable any default filters in /var/log/syslog.d/* that would store data there. The AMA agent will queue the data it needs in /var/opt/microsoft/azuremonitoragent/events/user.info and clear it out daily or sooner. If you don’t disable these default filters you may need to double the disk you need for /var.
References:
https://learn.microsoft.com/en-us/azure/sentinel/forward-syslog-monitor-agent
https://learn.microsoft.com/en-us/azure/sentinel/connect-cef-ama