Sending Logs (Syslog)

End devices, servers, firewalls, and network devices send their logs to SentriaOne xSIEM using syslog — the standard protocol for forwarding log messages over a network. Each device is pointed at the IP address of the SentriaOne xSIEM log collector and its syslog port.

Once logs arrive they are normalized and enriched like any other data, become searchable in Records, and can be used to build custom Dashboards. See Log Sources for the concept.

What you need

Item	Typical value	Notes
Collector address	<collector-address>	The IP address or hostname of the SentriaOne xSIEM log collector
Port	514 (the default syslog port)	Confirm the port used in your deployment
Protocol	UDP or TCP	UDP is the default for syslog; TCP is more reliable and keeps message order
Encryption (optional)	TLS, commonly on port 6514	Use it when logs cross untrusted networks, if your deployment supports it

note

<collector-address> and the port are placeholders in the examples below. Your SentriaOne xSIEM deployment team provides the values for your environment, and confirms which sources and formats are supported.

Before configuring a device

1. Allow the traffic. Firewalls between the device and the collector must allow the syslog port (for example UDP 514) from the device to the collector.
2. Synchronize the clock. Configure NTP on every log source. Wrong clocks put events at the wrong time and break correlation with other data.
3. Use a stable source address. If a device has several interfaces, set the source interface or source IP so the logs always arrive from the same address — this is how the device is identified.

Choosing what to send

Syslog messages carry a facility (which part of the system produced the message) and a severity. Most devices let you choose the minimum severity to forward.

Severity	Name	Typical use
0	Emergency	System unusable
1	Alert	Immediate action required
2	Critical	Critical conditions
3	Error	Errors
4	Warning	Warnings
5	Notice	Normal but significant events
6	Informational	Informational messages — includes most security-relevant events
7	Debug	Debugging; usually too verbose to forward

Informational (6) is a common starting point: it includes authentication, connection, and policy events without the noise of debug logging.

Servers and end devices

Linux — rsyslog

Most Linux distributions use rsyslog.

1. Create /etc/rsyslog.d/90-sentriaone.conf:

   # UDP
   *.* @<collector-address>:514
   
   # TCP (recommended) — use two @ characters
   *.* @@<collector-address>:514

2. Check the configuration and restart the service:

   sudo rsyslogd -N1
   sudo systemctl restart rsyslog

3. Send a test message:

   logger "SentriaOne xSIEM syslog test"

Linux — syslog-ng

destination d_sentriaone {
    syslog("<collector-address>" transport("tcp") port(514));
};

log {
    source(s_src);
    destination(d_sentriaone);
};

Reload the service after saving the configuration:

sudo syslog-ng-ctl reload

Windows

Windows writes events to the Windows Event Log, not to syslog. To forward them, install a log forwarding agent on the host (or on a collector server that receives events through Windows Event Forwarding) and configure it to send to <collector-address> on port 514.

Ask your SentriaOne xSIEM deployment team which agent is supported and for its configuration.

Firewalls and security devices

Fortinet FortiGate

config log syslogd setting
    set status enable
    set server "<collector-address>"
    set port 514
    set mode udp
    set facility local7
end

Then make sure the policies you care about have logging enabled.

OPNsense / pfSense

1. Go to System › Settings › Logging / Targets (OPNsense) or Status › System Logs › Settings (pfSense).
2. Add a remote log target: Transport UDP, Hostname <collector-address>, Port 514.
3. Select the log types to forward, for example firewall, system, and authentication events.
4. Save and apply.

Palo Alto Networks

1. Device › Server Profiles › Syslog — add a profile with the server <collector-address>, port 514, transport UDP.
2. Objects › Log Forwarding — create a profile that forwards the log types you need to that syslog profile.
3. Apply the log forwarding profile to the security policy rules, then Commit.

Cisco ASA

configure terminal
 logging enable
 logging timestamp
 logging host inside <collector-address>
 logging trap informational
 end

Routers and switches

Cisco IOS / IOS XE

configure terminal
 logging host <collector-address> transport udp port 514
 logging trap informational
 logging source-interface GigabitEthernet0/0
 service timestamps log datetime msec localtime show-timezone
 end

Check with:

show logging

MikroTik RouterOS

/system logging action
add name=sentriaone target=remote remote=<collector-address> remote-port=514
/system logging
add topics=info action=sentriaone
add topics=error action=sentriaone
add topics=warning action=sentriaone

Juniper Junos

set system syslog host <collector-address> any info
set system syslog host <collector-address> port 514
commit

Aruba CX

configure terminal
 logging <collector-address> udp port 514 severity info
 end

Verify that logs arrive

After configuring a device, confirm the logs are received:

Check	Expected result
Data Feed Health › Log Ingest Rate — per Log Source	The device appears with a rate above zero
Records	Records from the device can be found — search its IP address, or look for event types such as syslog_event
License › Log Sources	The daily log volume (GB/day) increases

Send a test message from the device (for example with logger on Linux) and search for it with a short time range, such as Last 15 minutes.

If logs do not arrive

Check	How
Destination	Confirm the collector address, port, and protocol (UDP or TCP) on the device
Path	Check firewall rules between the device and the collector for the syslog port
Source address	Confirm the device sends from an address that is allowed to reach the collector
Device logging level	Confirm the severity threshold is not stricter than the events you expect
Clock	Confirm NTP is configured — events with a wrong timestamp may fall outside the time range you search
Volume	Check the License page: if the licensed daily volume is exceeded, new events can be dropped

Security recommendations

• Prefer TCP, or TLS where supported, for logs that cross untrusted networks. Plain UDP syslog is neither encrypted nor acknowledged.
• Restrict which source addresses may send logs to the collector, at the network level.
• Forward the events you need. Debug-level logging fills storage and the licensed daily volume quickly.
• Keep device clocks synchronized so that events line up with network records.

Related pages

• Log Sources — the concept behind log collection
• Integration Overview — all integrations at a glance
• Packet Mirroring — sending network traffic instead of logs