Need help securing your Ubiquiti routers? Configuring IPSEC links between locations? The extended guides for Ubiquiti EdgeRouter Hardening and IPSEC Site-to-Site VPNs are now available on the Solutions page.
Syslog is one of the most widely supported event reporting mechanisms, across almost all manufacturers and OS distributions including Ubiquiti and EdgeOS. Using Syslog to report events happening on routers, switches, and servers is typical in the networking industry, and being able to centrally monitor reportable events on network infrastructure is critical as you scale up. Most organizations don't report every single event because that would create a huge, unmanageable mess of logs. Instead, administrators focus on hardware, authentication, interface up/down, and network adjacency events.
Beyond the convenience of centralizing logs in one place for monitoring, Syslog plays an important part in an organization's network security framework. If a device is breached, or if a breach is suspected, the logs on that local device become suspect. An attacker may wipe the local device logs wholesale, or modify them specifically to cover their tracks or focus attention elsewhere. Having logs shipped to another device, that preferably uses separate authentication, allows some assurance that the logs have not been tampered with and can be used for investigation.
Event archiving also becomes possible when shipping events to a centralized server. An organization's policy may require 90 days of log retention, or a legal requirement may exist that sets a certain standard. Either way, this gives you a rolling historical record of what's happened on your devices. This wouldn't be possible if you're just storing logs locally, because many devices purge logs on reboot or power cycle, or lack the embedded storage capacity for long-term log storage.
Syslog has varying degrees of event severity - 8 in total, 0 through 7. You can find the severity levels here. Familiarize yourself with the severity levels, because they are used across almost all device manufacturers. The protocol itself runs on UDP, port 514, but that is automatically included in the configuration and doesn't have to be specified manually.
With that being said, we'll set up a Ubiquiti router to report important events to a Syslog server, and use The Dude as a dashboard for monitoring running on 192.168.90.183. We'll be monitoring for all events level 4 (Warning) and up. This is a no-cost solution that centralizes the administrative task of monitoring infrastructure, and it's surprisingly flexible.
First, put your Ubiquiti device in configuration mode.
Next, configure the device for the IP of your Syslog server (in this case 192.168.90.183), and the minimum severity level of events that should be shipped. If you use the "warning" level like in the command below, then all events that are warning, error, critical, alert, and emergency levels will be shipped. It's up to you to determine what minimum level of events is most appropriate for your organization.
set system syslog host 192.168.90.183 facility all level warning
The "facility" portion of the command specifies what router functions are being monitored. In this case it's "all" functions, though you can specify specific levels for specific functions. This is really useful for troubleshooting, or monitoring specific router functions that you suspect are misbehaving. Available functions include protocols, security, auth, and more. Starting out with the "all" facility helps you capture a broad swath of events, and then you can narrow down your reporting if necessary for your organization's specific needs. It's always best with logging to start broadly, then whittle it down from there - you may see something that you wouldn't have otherwise that demands your attention.
Lastly, commit and save your configuration, then generate some events. Try logging into the device with a wrong username and password on purpose to generate an event, and verify it's been shipped to the Syslog server. Play around with it, so that when actual events are triggered in production you know why they happened, and how to respond.