Logs are kept only on the router
RouterOS keeps its log in memory. It is gone after a reboot, and anyone who takes over the router can erase it. Sending a copy to a syslog server is the difference between knowing what happened and guessing.
/system logging action
What the audit found
Your configuration has no active logging action whose target is remote under System → Logging → Actions. That means the router's log exists only in its own RAM: the default memory action holds a limited number of recent lines, and nothing is sent anywhere else.
The audit reports this as info. It is a hygiene point about being able to investigate incidents, not a weakness that can be attacked. It matters most on routers that serve a business or an ISP; for a home router it is optional.
Why it matters
The log is where the evidence goes. Failed login attempts, successful logins from unexpected addresses, configuration changes, interface flaps, VPN connections, firewall rules with logging enabled — all of it lands in the log and nowhere else. On a router that keeps the log in memory, three things limit its usefulness.
The first is size. The memory buffer holds a fixed number of lines (1000 by default) and discards the oldest. On a busy router, an event from this morning may already be gone by the afternoon.
The second is reboots. A power cut, an upgrade or a crash clears the buffer completely. Ironically, the moments you most want a log for are the moments the router is most likely to have restarted.
The third is the attacker. Anyone who gains administrative access can read what was recorded and then simply reboot the device or clear the buffer. The compromises of MikroTik routers in 2018 and 2021 were often discovered months after the fact precisely because there was nothing left to look at. A log that lives on another machine cannot be erased from the router.
A remote syslog server also makes it possible to keep logs for as long as you need, to search across several routers at once, and to alert on specific messages such as repeated login failures.
What it looks like in Winbox
Open System → Logging. The Actions tab lists the destinations: by default memory, disk, echo and remote, where the remote action has no address configured. The Rules tab lists which topics go to which action; you will see everything pointing at memory. The Log window in the left-hand menu shows the current buffer.
How to fix it
You need something to receive the logs — a syslog server. This can be any Linux machine with rsyslog or syslog-ng, a NAS with a syslog package, a dedicated appliance, or a monitoring system such as Zabbix or Graylog. It should be on a network the router can reach that is not itself dependent on the router being healthy, ideally on your management LAN.
On the router, the change has two halves under System → Logging. On the Actions tab, a logging action with the remote target carries the server's address (and a port, if the server does not listen on the standard UDP 514). On the Rules tab, a rule decides which topics go to that action. The set critical, error, warning and account covers serious events and every login attempt without flooding the server with debug output; add the system topic to record configuration changes, and the firewall topic if you have firewall rules with logging turned on.
Keep the existing rules that point at memory as they are — a local copy is still handy for quick checks in Winbox. Nothing here affects routing or management, so Safe Mode is unnecessary. One caution: syslog over UDP is unencrypted, so keep the server on your internal network and do not send logs across the internet without a VPN.
Afterwards, generate an event — log out and back in to Winbox, or make a harmless setting change — and check the syslog server for the corresponding line within a few seconds. Then re-run the audit; the finding disappears once a remote action is in use.
The full MKRouterKit report gives the exact commands for your configuration — with your server address and the recommended topics filled in.
FAQ
I only have one home router. Is a syslog server overkill?
For a single home router, probably. That is why the finding is informational. If you have a NAS or a small always-on machine, adding syslog reception takes a few minutes and costs nothing, and it is pleasant to have when something odd happens. If you do not, ignore this finding with a clear conscience.
Can I log to the router's disk instead?
You can, with the disk action, which survives reboots on devices with storage. It does not, however, survive an attacker with admin access, who can delete the files. It is better than memory only, and a reasonable compromise on a router that has nowhere to send logs to.
Will remote logging slow the router down or fill my link?
No. With the recommended topics a router sends a handful of lines per hour under normal conditions. Even under an active brute-force attempt, syslog traffic is negligible compared to the attack itself. Avoid sending the debug topic remotely, which can be chatty.
This article explains the finding in general terms. Test any configuration change with Safe Mode enabled in Winbox. MKRouterKit analyses configuration exports only; it does not replace an external port scan or a professional penetration test.