Skip to main content
Cisco Meraki Documentation

Syslog Server Overview and Configuration

A syslog server can be configured to store messages for reporting purposes from MX Security Appliances, MR Access Points, and MS switches. This document will provide examples of syslog messages and how to configure a syslog server to store the messages.

Types of Syslog Messages

The MX Security Appliance supports sending four categories of messages/roles: Event Log, IDS Alerts, URLs, and Flows.  MR access points can send the same roles with the exception of IDS alerts. MS switches currently only support Event Log messages. 

If the Syslog Server is across a VPN tunnel, the Syslog traffic source will be a 6.X.X.X address.  This is especially true in VPN Concentrator mode or in Routed/NAT mode in Single LAN configuration.

URL

Any HTTP GET requests will generate a syslog entry.

 

Example:

Apr 20 14:36:35 192.168.10.1 1 948077314.907556162 MX60 urls src=192.168.10.3:62526 dst=54.241.7.X.X mac=00:1A:A0:XX:XX:XX request: GET http://www.meraki.com

Summary:

A client with IP address 192.168.10.3 sent a HTTP GET request for http://www.meraki.com.

Flows

Inbound and outbound flows will generate a syslog message showing the source and destination along with port numbers and the firewall rule that they matched. For inbound rules, 1=deny and 0=allow.

Examples:

Inbound Flow:

948077334.886213117 MX60 flows src=39.41.X.X dst=114.18.X.X protocol=udp sport=13943 dport=16329 pattern: 1 all

Outbound Flow:

948136486.721741837 MX60 flows src=192.168.10.254 dst=8.8.8.8 mac=00:18:0A:XX:XX:XX protocol=udp sport=9562 dport=53 pattern: allow all

Note: In Firmware MX18.101 and newer, the syslog messages for "flows" has been changed to "firewall", "vpn_firewall", "cellular_firewall" or "bridge_anyconnect_client_vpn_firewall" depending on which rule was matched. Using the outbound flow as an example, the syslog message has been updated to this:  

948136486.721741837 MX60 firewall src=192.168.10.254 dst=8.8.8.8 mac=00:18:0A:XX:XX:XX protocol=udp sport=9562 dport=53 pattern: allow all

 

Summary: 

The inbound flow example shows a blocked UDP flow from 39.41.X.X to the WAN IP of the MX. The outbound flow shows an allowed outbound flow for a DNS request.   
 

Note: Syslog Flows are a shared MR and MX category. Flows cannot be separated so that only MX flows or MR flows contribute the flows syslog category.

Appliance/Switch/Wireless Event Log

A copy of the messages found in the dashboard under Network-wide > Monitor > Event log.

 

Example:

May 10 18:46:04 192.168.10.1 1 948080570.911780502 MX60 events dhcp lease of ip 192.168.10.252 from server mac 00:18:0A:XX.XX.XX for client mac 58:67:1A:XX.XX.XX from router 192.168.10.1 on subnet 255.255.255.0 with dns 8.8.8.8, 8.8.4.4

Summary: 

A client with MAC address 00:18:0A:XX.XX.XX leased an IP address from the MX and the MX provided 8.8.8.8 and 8.8.4.4 as DNS servers to the client.

Security Events

Any security events will generate a syslog message (MX security appliance only role).

 

Example:

1490031971.951780201 ANB_MX80 security_event ids_alerted signature=1:39867:3 priority=3 timestamp=1490031971.693691 shost=00:15:5D:1E:08:04 direction=egress protocol=udp/ip src=192.168.30.10:49243 dst=71.10.216.1:53 message: INDICATOR-COMPROMISE Suspicious .tk dns query

Summary:

A IDS syslog message was generated when a .tk DNS query was sent from 192.168.30.10 to 71.10.216.1.

Air Marshal Events

Air Marshal events will generate a syslog message describing the wireless traffic detected.

 

Example:

Oct 20 17:21:33 192.195.83.210 0.0 syslog2 airmarshal_events type= rogue_ssid_detected ssid='' vap='0' bssid='FF:FF:FF:FF:FF:FF' src='02:18:6A:XX:XX:XX dst='FF:FF:FF:FF:FF:FF' wired_mac='00:18:0A:XX:XX:XX' vlan_id='0' channel='44' rssi='60' fc_type='0' fc_subtype='4'

Summary:

A beacon was sent by a device that exists on the LAN, generating a rogue SSID event that resulted in a syslog message.

Log Samples and More Information

For more information on Syslog Event Types and a list of log samples for each product, please refer to this article.

Configuring a Syslog Server

A syslog server can easily be configured on a Linux system in a short period of time, and there are many other syslog servers available for other OSes (Kiwi Syslog for Windows, for example).

The following commands detail an example syslog server configuration on Ubuntu 13.04 using syslog-ng, to gather syslog information from an MX security appliance.

Note: The following commands outline an example configuration for demonstration purposes. Please refer to your server documentation for specific instructions and information.

 

The first step is to install the syslog application:

sysadmin@ubuntu:~$ sudo apt-get install syslog-ng

 

Once syslog-ng has been installed it needs to be configured to receive log messages from the MX.  These instructions will configure syslog-ng to store each of the role categories in their own log file.  There will be an individual log file for URLs, Event Logs, etc.  Alternatively, it could be configured to store all logs in one file.  Use any appropriate editor to make changes to the syslog-ng configuration file.  In this example nano is used to edit the file.

sysadmin@ubuntu:~$ sudo nano /etc/syslog-ng/syslog-ng.conf

 

The LAN IP of the MX in this example will be 192.168.10.1. The syslog server is listening on 192.168.10.241 UDP port 514. Update as needed to reflect the LAN IP of the MX and the syslog server being configured.  The first section of code will configure all syslog messages from the MX to be stored in /var/log/meraki.log.  The second section of code will use regular expressions to match each of the role categories and store them in individual log files.  Only one of the options needs to be configured.

Option 1 - Log all messages to /var/log/meraki.log:

#define syslog source
source s_net { udp(ip(192.168.10.241) port(514)); };

#create filter to match traffic (this filter will catch all syslog messages that come from the MX)
filter f_meraki { host( "192.168.10.1" ); };

#define a destination for the syslog messages
destination df_meraki { file("/var/log/meraki.log"); };

#bundle the source, filter, and destination rules together with a logging rule
log { source ( s_net ); filter( f_meraki ); destination ( df_meraki ); };

Option 2 - Log different message types to individual log files: 

#define syslog source
source s_net { udp(ip(192.168.10.241) port(514)); };

#create individual filters to match each of the role categories
filter f_meraki_urls { host( "192.168.10.1" ) and match("urls" value ("MESSAGE")); };
filter f_meraki_events { host( "192.168.10.1" ) and match("events" value ("MESSAGE")); };
filter f_meraki_ids-alerts { host( "192.168.10.1" ) and match("ids_alerted" value ("MESSAGE")); };
filter f_meraki_flows { host( "192.168.10.1" ) and match("flows" value ("MESSAGE")); };

#define individual destinations for each of the role categories
destination df_meraki_urls { file("/var/log/meraki_urls.log"); };
destination df_meraki_events { file("/var/log/meraki_events.log"); };
destination df_meraki_ids-alerts { file("/var/log/meraki_ids-alerts.log"); };
destination df_meraki_flows { file("/var/log/meraki_flows.log"); };

#bundle the source, filter, and destination rules together with a logging rule for each role category
log { source ( s_net ); filter( f_meraki_urls ); destination ( df_meraki_urls ); };
log { source ( s_net ); filter( f_meraki_events ); destination ( df_meraki_events ); };
log { source ( s_net ); filter( f_meraki_ids-alerts ); destination ( df_meraki_ids-alerts ); };
log { source ( s_net ); filter( f_meraki_flows ); destination ( df_meraki_flows ); };

 

The final step will restart the syslog-ng process:

sysadmin@ubuntu:~$ sudo /etc/init.d/syslog-ng restart 

Configure Dashboard

Syslog servers can be defined in the Dashboard from Network-wide > Configure > General.

Click the Add a syslog server link to define a new server.  An IP address, UDP port number, and the roles to send to the server need to be defined.  Multiple syslog servers can be configured.

Syslog Server IP

In Appliance-only, Switch-only, and Wireless-only Dashboard Networks, syslog servers will be added under the "Logging" section instead of "Reporting".

If the Flows role is enabled on an MX security appliance, logging for individual firewall rules can be enabled/disabled on the Security & SD-WAN > Configure > Firewall page, under the Syslog column:

Enabling Syslog for firewall rules
 

Additional Considerations for Syslog

Storage Allocation

Syslog messages can take up a large amount of disk space, especially when collecting flows. When deciding on a host to run the syslog server, make sure to have enough storage space on the host to hold the logs. Consult the syslog-ng man page for further information on only keeping logs for a certain amount of time.

Expected Traffic Flow

Syslog traffic may flow to the syslog in one of three scenarios depending on the route type that is used to reach the syslog server. Below are example scenarios and a detailing of expected traffic behavior. 

Scenario 1 - Reachable via LAN

The MX will source traffic from the VLAN interface that the server resides in if the syslog server is located on the LAN of the MX. The transit VLAN interface would be used if the device is only accessible via static route.

Scenario 2 - Reachable via Public Interface

The MX will source traffic from the public interface (WAN) if the syslog server is accessible via the WAN link. 

Scenario 3 - Reachable via AutoVPN or non-Meraki VPN

In the event that the MX is sending syslog traffic across a VPN tunnel, the MX will use its source IP associated with the highest-numbered VLAN participating in VPN. It is important to note this behavior for firewall design.

Traffic passing through the site-to-site AutoVPN or non-Meraki VPN connection will be subject to the 'Site-to-site outbound firewall' rules and as such an allow rule may be required. This can be configured in Security & SD-WAN > Configure > Site-to-site VPN > Organization-wide settings > Add a rule as shown in the example below.

Site to Site outbound firewall rule

  • Was this article helpful?