Purpose
This guide explains how to forward the system log of Teltonika routers that run RutOS (for example RUT950 and RUT951) to Logsign USO over syslog. The integration covers access control events of the router (SSH and Web UI logins, failed logins, brute force counters and IP blocking), the dropbear SSH server, the web interface backend (uhttpd / vuci), OpenVPN server instances, scheduled commands (crond), firewall reloads, mobile and interface status messages and the Teltonika RMS cloud agent.
Prerequisites
- Administrator access to the RutOS WebUI of each router.
- Network connectivity from the router to the Logsign USO collector on your syslog port (TCP or UDP 514 by default).
- A Logsign USO release that includes the Teltonika RutOS parser. Contact Logsign Support if you are not sure which release you run.
Step 1: Send the RutOS System Log to Logsign USO
RutOS can forward its system log to a remote syslog server. Menu names differ between RutOS firmware releases and router models, so check the Teltonika wiki page for your model (the logging or Events Log page) if the steps below do not match your WebUI.
- Log in to the RutOS WebUI.
- Open the logging settings of the router and enable sending the system log to a remote syslog server.
- Enter the IP address of the Logsign USO collector as the remote server, set the port (514 by default) and choose UDP or TCP.
- Keep the default RutOS message format. Do not add a custom prefix to the messages.
- Save and apply the settings.
Step 2: Add the Data Source in Logsign USO
Open the Logsign USO web interface and click + Device under Settings > Data Collection. Choose Syslog as the collection method, select Teltonika as the vendor and RutOS as the product, and enter the IP address of the router as the host. Click Save. Repeat this for every router. Once a router starts sending, events appear under Search.
Supported Message Format
RutOS sends standard BSD syslog (RFC 3164) messages. After the syslog priority, every message has a timestamp, the router host name, an optional program tag with a process ID and the message text:
Oct 6 18:03:11 rut952 Web UI: Invalid password attempt for "administrator" from 10.18.0.6 to 192.168.10.1 via HTTP, attempt 5 of 10
Oct 6 18:00:37 rut952 dropbear[31571]: Child connection from 10.18.0.6:60221
Oct 6 19:35:41 rut951 connections: Failed connection from IP 10.101.0.16 to 192.168.100.12, attempt 5/5. Address blocked.
Oct 6 19:42:20 rut951 openvpn(OpenVpnSite)[7709]: 203.10.113.101:23416 [vpnuser] Peer Connection Initiated with [AF_INET]203.10.113.110:22416Program tags can contain spaces (Web UI, IP Block) or an OpenVPN instance name (openvpn(OpenVpnSite), openvpn@srv_site). Some messages, such as mobile data status lines, are sent with a literal <unknown> tag instead of a program name. These messages are still parsed, and Event.Prefix stays empty for them.
What Gets Collected
| Logsign Field | RutOS Value |
|---|---|
| Time.Generated | Message timestamp (Mmm dd HH:MM:SS) |
| Device.HostName | Router host name |
| Event.Prefix | Program tag (for example connections, Web UI, dropbear, openvpn(OpenVpnSite)) |
| Process.PID | Process ID in brackets after the program tag |
| Event.Info | Full message text |
| Event.Action | Action name of the classification (see Event Classification) |
| Source.UserName | User name in login, logout and cron messages, the OpenVPN client name, or the CN of the client certificate |
| Source.IP, Source.Port | Address and port of the client. Source.City and Source.Country are filled from Source.IP. |
| Destination.IP, Destination.Port | Router address and port in Web UI, IP Block and blocking entry messages |
| Service.Name | Service in access control messages (for example SSH, HTTP). It is SSH for dropbear messages. |
| Event.Count | Attempt number (attempt N) or the fail count of dropbear |
| Threshold.Value | Attempt limit (/M or of M) |
| Source.VirtualIP | Virtual IP address that OpenVPN gives to the client |
| VPN.Name | OpenVPN instance name from the program tag |
| Session.EndReason | Reason in dropbear exit messages |
| Process.CommandLine | Command in crond messages |
| Device.InterfaceName, Event.Reason | Interface and reason in firewall reload messages |
Every event is recorded with Vendor Teltonika, Product RutOS, EventSource Type Network System and Category Router.
Event Classification
Messages are classified by program tag and message text. When a classification has a fixed severity, that severity is used. The other classifications keep the syslog severity that the router sent.
| RutOS event | EventMap | Severity | Event.VendorID |
|---|---|---|---|
| Successful login (access control layer, dropbear, vuci) | Identity / User / Login | information | 1 |
| Failed login (bad or invalid password, nonexistent or locked user, rejected root login) | Identity / User / Deny | warning | 2 |
Failed connection counter (Failed connection from IP ... attempt N/M) | Network / Session / Deny | warning | 3 |
| Address blocked after too many attempts | Security / BruteForce / Block | warning | 4 |
| IP blocking entry deleted | Network / Session / Info | information | 5 |
SSH connection (dropbear Child connection from) | Network / Session / Open | information | 6 |
| SSH exit before authentication | Network / Session / Close | information | 7 |
SSH logout (dropbear Exit (user)) | Identity / User / Logout | information | 8 |
| OpenVPN peer connection initiated | VPN / User / Login | information | 9 |
| OpenVPN virtual IP assigned | VPN / Other / Info | information | 10 |
| OpenVPN inactivity timeout | VPN / User / Logout | information | 11 |
| OpenVPN client certificate verified | VPN / SSLVPN / Info | information | 12 |
| Other OpenVPN messages | VPN / SSLVPN / Info | syslog severity | 13 |
| Scheduled command (crond) | System / Command / Info | information | 14 |
| Firewall reload | System / Configuration / Info | syslog severity | 15 |
| Interface and mobile status (netifd, qmux, mobile data messages) | Network / Connection / Info | syslog severity | 16 |
| Other RMS agent (rms_mqtt) messages | System / Operation / Info | information | 17 |
RMS connection error (Failed to connect, ERROR CODE: N) | System / Operation / Error | error | 18 |
| SSH authentication step passed, extra authentication required | Identity / User / Info | information | 19 |
| OpenVPN TLS or certificate verification error | VPN / User / Deny | warning | 20 |
| OpenVPN client exiting after a signal | VPN / User / Logout | information | 21 |
Messages that match none of the entries above are still parsed and classified as System / Operation / Info with Event.VendorID 999. They keep the syslog severity that the router sent.
Notes and Limits
- RutOS can log one login attempt in more than one layer: the access control layer (
connections,SSH,Web UI,IP Block), the service itself (dropbearoruhttpd/vuci) and the brute force counter. Each line is kept and gets the same classification. If you count failed logins in a correlation rule, filter on Event.Prefix so that each attempt is counted once. - The syslog timestamp has no year and no time zone. Set the router clock to the same time zone as Logsign USO so that Time.Generated is correct.
- The crond and rms_mqtt programs send every line with the err severity, also for normal activity. For this reason Logsign uses the fixed severities in the table above for them.
- Most of the volume from a router is operational (interface, mobile modem, OpenVPN TLS detail and RMS lines). Take this into account when you plan EPS, and use a Data Policy to drop lines you do not need.
- Access control messages are matched with IPv4 addresses. dropbear messages are matched with IPv4 and IPv6 addresses.
Verification
After both sides are saved, you can check the integration with a single login.
- In Logsign USO, open Settings > Data Collection and confirm that the Teltonika RutOS source is receiving data.
- Log in to the RutOS WebUI to generate a test event. In Logsign USO, go to Search and look for events with Vendor Teltonika and Product RutOS. The login should appear with EventMap Identity / User / Login, your user name in Source.UserName and the login service (for example
HTTP) in Service.Name. - If the source is receiving data but no events show Vendor Teltonika, check that the router sends standard RFC 3164 messages without a custom prefix.