This guide to setting up a syslog server

This guide walks you through how to set up syslog forwarding for Microsoft Sentinel using three common configurations. You don’t need to be a Linux expert to follow along.

What is syslog  

Syslog is a standardized logging protocol defined in RFC 5424 that specifies how log messages are formatted and transmitted over a network.

By default, Syslog uses UDP port 514, though it can also operate over TCP - commonly on port 6514 when secured with TLS. It's a lightweight, efficient way to centralize logging from a wide variety of sources.

Syslog is widely supported across:

Unix/Linux systems

Network appliances like firewalls and routers

Many security products and enterprise applications

Here’s an example of a raw syslog message:

<134>1 1515988859.626061236 appliance flows src=172.21.84.107 dst=10.52.193.137 mac=5C:E0:C5:22:85:E4 protocol=tcp sport=50395 dport=443 pattern: allow all

What is syslog forwarding

Syslog forwarding sends log messages from a device like a server, router, or firewall to a remote system such as a log server or SIEM. This enables centralized logging for easier monitoring and analysis.

It's especially important because most firewalls send logs in syslog format.

Example FortiGate syslog setup

What is syslog forwarder

A syslog forwarder is typically a Linux machine that receives logs in syslog format and forwards them over the network to a monitoring platform like a SIEM. Some forwarders can also parse, filter, or transform messages before sending them.

Common syslog forwarding tools include rsyslog, syslog-ng, NxLog, and Graylog.

In this guide, we’ll use rsyslog, a popular and lightweight option included by default in most Linux distributions.

Syslog forwarding for Microsoft Sentinel

At a high level, syslog forwarding to Microsoft Sentinel works like this:

The data source (e.g. a firewall or server) is configured to send syslog messages to a Linux machine running a syslog daemon. In this guide, that’s rsyslog.

The Azure Monitor Agent (AMA) on that machine collects the syslog messages.

AMA then forwards the logs to Microsoft Sentinel via a configured Data Collection Rule (DCR).

High level view of syslog forwarding for MS Sentinel

Considerations

Before setting up a syslog forwarder, it’s worth thinking through a few key points:

Log Volume: How many logs are you sending? The size and specs of your VM will depend heavily on log throughput.

Deployment Location: Will your forwarders run on-premises or in the cloud?

Reliability: Is a single VM enough, or do you need a load-balanced setup for high availability?

In production, there are other technical considerations too like UDP vs TCP, mutual TLS, Private Link, traffic inspection, access control, auditing, alerting on silent sources and more.

But honestly in most cases, these are dictated by your broader security and network architecture. If you're just getting started don’t stress about them too much :)

Demo setup

In this demo, I’ll walk through a simple, single VNet setup:

One Ubuntu VM generates logs in syslog format.

Another Ubuntu VM, running rsyslog, receives those logs.

That VM then forwards the logs to Microsoft Sentinel using the Azure Monitor Agent.

No complexity, no HA, no Bicep, no Terraform just a straightforward example to show how syslog forwarding works end to end.

single VNET demo setup

[OPTIONAL] Syslog generator

This step is optional, but useful for testing. You can simulate syslog traffic using tools like logger, echo, or by exporting data from an application that supports syslog output.

We’ll start by creating a VM that will generate syslog messages. For this demo, we'll use a Standard_D2ls_v5 VM (2 vCPUs, 4 GiB memory).

Go to portal.azure.com → Virtual Machines → Create.

Below are the key configuration settings to focus on - we'll skip the defaults and highlight only what matters.

Select Ubuntu Server 22.04:

Ubuntu 22.04

2. Set public network ports to 'None' (we will change that later):

No public inbound ports

3. OPTIONAL: enable auto shutdown under Management:

Optional auto shutdown

Create the VM. You will be asked to download a SSH key.

4. Generate script that generates dummy syslog data. Below script will do:

import socket

import time

import random

# Configuration

SYSLOG_SERVER = 'YOUR COLLECTOR'S IP ADDRESS'  # Change to your syslog server IP

SYSLOG_PORT = 514            # Syslog UDP port

EPS = 20                     # Events Per Second

FACILITY = 20  # local4

SEVERITY = 6   # informational

PRI = (FACILITY * 8) + SEVERITY

# Sample data pools

source_ips = ['172.21.84.107', '192.168.1.10', '10.0.0.55', '192.168.100.23']

dest_ips = ['10.52.193.137', '8.8.8.8', '172.16.0.1', '192.168.1.100']

macs = ['5C:E0:C5:22:85:E4', '00:1A:2B:3C:4D:5E', 'D4:EE:07:11:22:33']

protocols = ['tcp', 'udp', 'icmp']

actions = ['allow all', 'deny all', 'allow http', 'deny ftp']

def get_local_ip():

  """Attempt to get the local IP address used to reach the SYSLOG_SERVER."""

  try:

      s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

      # Doesn't need to be reachable; just to get the outbound interface

      s.connect((SYSLOG_SERVER, SYSLOG_PORT))

      local_ip = s.getsockname()[0]

      s.close()

      return local_ip

  except Exception:

      return '0.0.0.0'

def generate_syslog_message():

  timestamp = time.time()

  version = 1

  device_type = 'appliance'

  log_type = 'flows'

  src_ip = random.choice(source_ips)

  dst_ip = random.choice(dest_ips)

  mac = random.choice(macs)

  protocol = random.choice(protocols)

  sport = random.randint(1024, 65535) if protocol in ['tcp', 'udp'] else 0

  dport = random.choice([80, 443, 53, 22, 0]) if protocol in ['tcp', 'udp'] else 0

  pattern = random.choice(actions)

  msg = (f"<{PRI}>{version} {timestamp:.9f} {device_type} {log_type} "

         f"src={src_ip} dst={dst_ip} mac={mac} protocol={protocol} "

         f"sport={sport} dport={dport} pattern: {pattern}")

  return msg

def send_syslog_messages(eps):

  sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

  interval = 1.0 / eps

  local_ip = get_local_ip()

  print(f"Sending syslog messages at {eps} EPS to {SYSLOG_SERVER}:{SYSLOG_PORT}... (Press Ctrl+C to stop)")

  try:

      while True:

          msg = generate_syslog_message()

          sock.sendto(msg.encode(), (SYSLOG_SERVER, SYSLOG_PORT))

          print(f"Sent from {local_ip} to {SYSLOG_SERVER}: {msg}")

          time.sleep(interval)

  except KeyboardInterrupt:

      print("\nStopped by user.")

  finally:

      sock.close()

if __name__ == "__main__":

  send_syslog_messages(EPS)

5.Go to 'Network Settings' and create a new Inbound port rule to allow SSH over port 22 from your IP address:

Example NSG rule allowing SSH in

6. Use SSH to connect to your VM:

ssh -i 'your-ssh-key' your-username@public-ip-of-your-vm

7. Create a .py file using a text editor, for example nano:

nano syslog_generator.py

8. Paste the scripts content into the file, subtitute the IP address for your collector's IP address and save. Run the file to see if it works correctly. Console output should look as follows:

python3 syslog_generator.py

Example console output

Perfect. Our syslog generator script works. Now we will create syslog forwarders.

Syslog forwarder scenarios

Scenario 1: Single Syslog Forwarer aka "Big Boy"

Sometimes you just want to keep it simple and I respect that. One large server acting as your dedicated syslog forwarder. This setup works well for:

Demos and testing

Smaller production environments

Environments with predictable or low event volume

One key thing to keep in mind: log forwarding to Microsoft Sentinel is done through the Azure Monitor Agent (AMA), which has a recommended limit of 10,000 events per second (EPS) per agent. While it can technically handle up to 20,000 EPS, 10,000 EPS is the supported and recommended ceiling.

📚 AMA performance guidance

This means a single-forwarder architecture can be a good choice only if your total incoming syslog volume stays below that threshold. If that’s the case, the "Big Boy" setup is straightforward and gets the job done.

Single syslog VM setup.

Scenario 2: Load-Balanced VMs

For production environments, a load-balanced syslog forwarder setup is a solid choice. This involves deploying two or more VMs behind an internal Azure Load Balancer, each running a syslog daemon like rsyslog.

This approach offers:

Improved reliability and scalability

Redundancy, in case one forwarder goes down

A clean path to horizontal scaling if log volume grows

It's especially effective when log volumes are predictable (and honestly in most environments, they are). This setup strikes a good balance between simplicity and production readiness.

Load balanced VMs

Scenario 3: Load-Balanced VM Scale Set (VMSS)

A Virtual Machine Scale Set (VMSS) is a dynamic group of VMs that can automatically scale in or out based on resource usage such as CPU load or custom metrics.

In the context of syslog forwarding, this means:

When the load on existing forwarders exceeds a set threshold, a new VM is automatically added to handle the traffic.

When the load decreases, VMs are deprovisioned, saving costs and keeping the system efficient.

This setup combines scalability, resilience, and automation, making it ideal for larger or more dynamic environments where log volume can spike or fluctuate. The VMSS is placed behind an internal load balancer, just like in the fixed VM scenario, but with added elasticity.

Load balanced VMSS

Big Boy (single VM)

To deploy a single syslog forwarder, follow the same steps outlined earlier for creating the syslog generator VM, but this time it will act as the forwarder.

Create the VM:

Go to portal.azure.com → Virtual Machines → Create.

Choose Ubuntu 22.04 LTS as the image.

Select a size based on expected log volume (e.g., Standard_D2s_v3 or larger).

2. Install the Syslog Connector in Sentinel:

Syslog content pack installation

3. Create a DCR:  

Go to Microsoft Sentinel and open your workspace.

In the left-hand menu, select Data connectors.

Find "Syslog via AMA" in the list and click to open the connector page.

Click Create DCR to start the setup process.

Data Collection Rules (DCRs) define what data is collected and from which resources.

In the wizard, select the VM you just deployed as the resource to collect from.

Resorce selector

Next, in the Collect section, choose what types of syslog messages you want to collect.

For this demo, I'm selecting LOG_LOCAL4 as the facility and LOG_DEBUG as the severity, since that’s where my script writes logs.

In a production setup, this may vary depending on the source device or application.

If you’re unsure, you can initially select all facilities and severities, then narrow it down later based on what you actually receive.

Facility / severity selector

Create the Data Collection Rule. It will automatically deploy Azure Monitor Agent to your syslog server.

3. Connect to your VM using SSH and run this script:

sudo wget -O Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py&&sudo python3 Forwarder_AMA_installer.py

Successfully executed script

This script will:

Detect if rsyslog or syslog-ng is running

Enable TCP/UDP listeners on port 514.

Restart the appropriate daemon to apply changes.

The config is done and we can test the forwarding.  

Important: in this demo environment the traffic is sent within a single VNET. Network security groups (NSG) allow inter-VNET traffic. If you're sending syslog from outside of your VNET you need to allow it on NSG:

Allowing logs from outside of the VNET

Load balanced VMs

A Load Balancer distributes traffic between VMs in its backend pool, making it ideal for high availability and horizontal scaling.

You can add a single VM to the backend pool for testing, but in production, you’ll likely want at least two forwarder VMs. If needed, follow the same steps from earlier to create an additional syslog forwarder VM.

Go to Azure Portal, search for Load balancers, and create a new Standard Load Balancer.

This will be used to route incoming syslog traffic (UDP/TCP 514) across your forwarder VMs.

Configure Internal Load Balancer:

In the Basics section of the Load Balancer setup, select SKU: Standard and Type: Internal.

This creates an internal-only Load Balancer, ideal for receiving traffic from devices within the same VNet.

If you need to accept traffic from outside your VNet (e.g., from on-prem devices or external sources), you can choose Type: Public instead and associate a Public IP address with the Load Balancer.

Load Balancer 'Basics' tab

Create a Frontend IP configuration and choose a dynamic IP address.

Next, go to the Backend pools section and select the Virtual Machine(s) you want to include in the pool.

These will be your syslog forwarders that receive traffic from the Load Balancer.

Example backend pool

Go to Inbound rules and select 'Add a load balancing rule':

Frontent IP address: your Frontend IP configuration

Backend pool: your backend pool

Protocol: UDP

Port: 514

Backend port: 514

Create a health probe that checks TCP port 514.

The setup script we use when configuring the syslog daemon on each VM opens both UDP and TCP port 514, so the probe will be able to verify VM availability.

Once the probe is configured, go ahead and create the Load Balancer.

Your Load-Balanced VM setup for syslog forwarding is now ready for testing.

Refer to the steps in the “Testing Syslog forwarder scenarios” section to validate that logs are being received and forwarded correctly.

Load balanced VMSS

At this point, we’ve covered how to create a Load Balancer and configure syslog forwarders to relay logs to Microsoft Sentinel.

If you want more flexibility and the ability to handle log volume spikes, consider using a Virtual Machine Scale Set (VMSS). VMSS is a group of VMs that can automatically scale out (add instances) or scale in (remove instances) based on resource utilization.

Configure Azure Policy to automatically install Azure Monitor Agent on VMSS

This step ensures that any new VM instances created within the scale set are automatically configured with:

The Azure Monitor Agent (AMA) installed.

The correct Data Collection Rule (DCR) associated.

In other words, this guarantees that the agent responsible for sending logs is present and knows what to collect and where to send it.

To configure the policy:

Go to Azure Policy in the portal.

Search for "Enable Azure Monitor for VMSS with Azure Monitoring Agent (AMA)".

Click Assign.

Set the scope - ideally just the resource group that contains your VMSS.

Enable Policy enforcement to ensure compliance.

Once assigned, this policy will apply AMA and DCR configuration automatically to any VM instance created within the scale set.

Go to 'Parameters' and select:

Bring Your Own User-Assigned Managed Identity: false

VMI Data Collection Rule Resource Id: your DCRs resource ID

Configuring 'false' for the first setting will create a system assigned managed identity. In production environments thats not ideal, but its fine for small scale testing.

To get the DCR's resource ID go to the DCR resource, click 'JSON View' and cop the Resource ID from the top of the page:

DCR Resource ID

2. Create a Virtual Machine Scale Set:

Go to Azure Portal, search for Virtual Machine Scale Sets, and select Create.

In the setup wizard, set the scaling mode to Autoscaling.

Choose Ubuntu Server 22.04 as the image.

Select Standard_D2ls_v5 as the VM size.

This configuration provides a solid baseline for syslog forwarding with enough headroom to scale based on load.

VMSS 'Basics' UI

The next mandatory setting is enabling 'Application health monitoring'. For Azure orchestrated scaling this needs to be done. Use the following settings:

Health states: Binary - healthy or unhealthy

Protocol: TCP

Port number: 514

And probably the most important part of setting your Virtual Machine Scale Set right is the cloud-init script. You want to run the syslog configuration script as soon as a new VM is provisioned so that its ready to go immediately. Under advanced paste this into 'Custom data':

#cloud-config

runcmd:

- wget -O /tmp/Forwarder_AMA_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Forwarder_AMA_installer.py

- python3 /tmp/Forwarder_AMA_installer.py

Perfect. We can now create the VMSS.

Testing Syslog forwarder scenarios

In your syslog generator script, update the SYSLOG_SERVER variable to match the private IP address of your syslog forwarder VM or Load Balancer (if you're using one).

Script variables

Run the script on syslog generator VM:

python3 syslog_generator.py

Then validate if the logs are being received on syslog forwarder by running tcmdump:

tcpdump -i any port 514 -A -vv &

You should see an output like in the below screenshot.

Logs are flowing in

The last step is to verify if those logs are being received in Microsoft Sentinel. Go to Sentinel -> Logs and type 'Syslog':

Logs arrived at Microsoft Sentinel

In this guide, we walked through the process of setting up syslog forwarding to Microsoft Sentinel using several deployment scenarios. Starting with a simple single VM ("Big Boy"), we then explored more scalable and production-ready setups using load-balanced VMs and Virtual Machine Scale Sets (VMSS).

We covered key concepts like:

What syslog and syslog forwarding are, and why they matter for security monitoring.

How to configure a Linux-based syslog forwarder using rsyslog and the Azure Monitor Agent (AMA).

How to set up Data Collection Rules (DCRs) and connect your forwarders to Microsoft Sentinel.

How to use Azure Load Balancer and Azure Policy to automate and scale your logging infrastructure.

Whether you’re setting up a quick test environment or laying the foundation for a production deployment, these steps help ensure your logs flow reliably into Microsoft Sentinel even if you’re not a "Linux person."

‍