Supplement – Syslog Collector Testing

Written by Brian Rowe

This step is for organizations not utilizing BlueVoyant managed collectors and are standing up a Syslog collector to receive Syslog and Common Event Format logs from other hosts/devices.

Migration Process Syslog 2x 1

Create a Linux DCR to Collect CEF (Common Event Format) Logs

Note: This is a requirement if you are not using a BlueVoyant managed syslog collector.  If you are running your own Syslog server for collection of network/firewall logs, there are a couple things to keep in mind: 

  1. The AMA is more performant than the MMA, so you may need less collectors if you have a multi-collector deployment (redundancy or scaling purposes). Please review the Microsoft Learn article for AMA Performance
  2. The AMA handles Syslog & CEF collection differently than the MMA so you’ll need to review the options for avoiding data ingestion duplication available on Microsoft Learn
    1. The foremost recommendation is to dedicate certain facilities to CEF collection and certain facilities to Syslog collection. This provides the most straight-forward option, conserving collector resources and network bandwidth, but requires your devices to be configurable to send to specific target facilities. The configuration image in this guide (below) suggests configuring the CEF DCR to the local0-local7 facilities, while editing the Syslog DCR (created above) to only collect the traditional (non local*) Syslog facilities. 
    2. If changing the facility isn’t possible with your log sources, you can use an ingest time transformation within your Syslog DCR (created above) to drop CEF messages, while the CEF DCR (to be created below) will drop Syslog messages. 

Configuration 

  1. Multiple rules can be created to allow granularity for different verbosity rules, different filtering, and multiple log analytics workspaces if needed. Rule creation can be summarized in the following three steps with detailed instructions further below:
    1. Assign resources (servers, Azure & ARC managed) that are sending logs 
    2. Select data sources (log events) to be monitored 
    3. Select destinations (log Analytics workspaces) to receive logs 
  2. In the Azure portal, navigate to Sentinel -> workspace -> Data connectors -> Common Event Format (CEF) via AMA – > Open connector page -> +Create data collection rule 
    Note: If you cannot see this connector under Data connectors, you may have to install/update “Common Event Format” from the Content hub. 
  3. Under the basics tab, fill in the following: 
    1. Rule Name 
    2. Subscription 
    3. Resource Group 
  4. Under the Resources tab, select your syslog collector and any Linux machines that you would like to directly collect any logs from, then click Next: Collect> 
  5. Leave the checkbox selected to collect messages without PRI header then set all ONLY the local0-local7 facilities to the Minimum log level of LOG_INFO
  6. Select Next: Review + create > then Create. This will configure the data collection rule and queue up the AMA for installation on all selected systems. 
  7. Finally, you will need to run the Microsoft provided script to configure rsyslog/syslog-Ng on your collectors to listen/receive remote logs. 

The last step of this onboarding process helps us avoid Full Disk scenarios which will prevent the AMA from functioning. We recommend that you set the rsyslog configuration not to store remote logs as a Full Disk scenario disrupts the function of the AMA. If using rsyslog , one such resolution is to modify your configuration file encapsulating your existent logging configuration as illustrated below:

  • rsyslog: /etc/rsyslog.conf 
     

 

Additional Readings