The MikroTik Security Guide and Networking with MikroTik: MTCNA Study Guide by Tyler Hart are available in paperback and Kindle!
Syslog is one of the most widely supported event reporting mechanisms, across almost all manufacturers and OS distributions. Using Syslog to report events happening on routers, switches, and servers is pretty standard, and being able to centrally monitor reportable events on network infrastructure is critical. Most organizations don't report every single event, because that would create a huge, unmanageable mess of logs. Instead administrators focus on hardware events, authentication issues, interface up/down events, and network adjacency changes.
So, with that being said, we'll set up a Mikrotik router to report important events to a Syslog server, and use The Dude as a dashboard for monitoring. This is a no-cost solution that centralizes the administrative task of monitoring infrastructure, and it is surprisingly flexible. The topology in this scenario is pretty basic - two branch routers, both with an Internet connection, both with a connection to a management network as well. Do you absolutely need to send Syslog events over a management network? No. Should you be handling monitoring and reporting over a management network? Yes, it's best practice. The server is just an instance of The Dude, running on a Windows Server.
Topology, with Mikrotik routers connected to Syslog server via management network
First, we'll set up a logging action on the router. This is just a logging action that tells the router to send the event to a Syslog server. We'll then assign that logging action to different events.
On both routers:
/system logging action add bsd-syslog=yes name=Syslog remote=192.168.88.234 target=remote
The bsd-syslog=yes option forces the router to send Syslog events in RFC-3164 format, which is very well-supported. Next we'll configure the logging itself, sending important entries (Account, Critical, and Error type events) to the Syslog server using the action we just created.
On both routers:
/system logging add topics=critical,error,account action=Syslog disabled=no
Now that the routers are taken care of, let's set up the Syslog server. Mikrotik's The Dude isn't the only Syslog server freely available - there are many - but it's one of the few that's easily installed and you'd actually want to look at on a big screen display for dashboarding. First, download and install the latest copy of The Dude from Mikrotik's download page. Open up The Dude, and make sure that the Syslog server process is running, as shown below:
Enabling Syslog in The Dude
Now that the routers are logging to Syslog, and The Dude is listening, let's create some events. I'm going to log into the Seattle router with the wrong username and password multiple times, and a few times successfully, to show what you'd see if someone were trying to guess the admin username or password.
Failed and successful login attempts
This is now your running record of who logged into (or failed to log into) devices, from what IP, and via which service. Also, very importantly, this gets your log entries off of your devices and onto a separate, hopefully secure server. If a device has been compromised there is a good chance the logs on the device have been too, but if you're shipping events off to a separate server there is another record that can be trusted. Assuming that all routers are syncing their clocks via NTP, you can use the timestamps as well to create a chronological order of events, which is critical when handling a security incident.
We've just covered the basics here, and there is a lot more you can report on with Syslog and monitor using The Dude. I encourage you to ship critical and error events to a Syslog server, and put the Syslog window up where people can see it and keep an eye out for unusual entries. The last thing we want is someone trying to bruteforce the admin password and no one even knows it's happening.