Configure Syslog Options on a Meraki

Meraki has a syslog option. To configure a Meraki to push logs to a syslog server, open your Meraki Dashboard and click on a device. From there, click on “Alerts & administration”. Screen Shot 2014-04-12 at 8.29.16 PM At the “Alerts & administration” page scroll down to the Logging section. Click on the “Add a syslog server” link and type the IP address of your syslog servers name or IP. Put the port number into the Port field. Choose what types of events to export. This could be Event Log, Flows or URLs, where:
  • Event Log: The messages from the dashboard under Monitor > Event log.
  • Flows: Inbound and outbound traffic flows generate syslog messages that include the source and destination and port numbers.
  • URL: HTTP GET requests generate syslog entries.
Note that you can direct each type of traffic to a different syslog server.

Use Syslog on Windows

There are a number of tools available for using Syslog in a Windows environment. I’ll look at Snare as it’s pretty flexible and easy to configure. First download the snare installation executable from Once downloaded run the installer and simply follow all of the default options, unless you’d like to password protect the admin page, at which point choose that. Note that the admin page is by default only available to localhost. Once installed, run the “Restore Remote Access to Snare for Windows” script. Screen Shot 2014-04-10 at 10.56.43 AM Then open and click on Network Configuration in the red sidebar. There, we can define the name that will be used in syslog (or leave blank to use the hostname), the port of your syslog server (we used 514 here) and the address of your syslog server (we used logger here but it could be an IP or fqdn). Screen Shot 2014-04-08 at 10.58.04 AM   Once you have the settings you’d like to use, scroll down and save your configuration settings. Then, open Services and restart the Snare service. Screen Shot 2014-04-08 at 10.56.22 AM Then run the Disable Remote Access to Snare for Windows option and you’re done. Now, if you’re deploying Snare across a lot of hosts, you might find that scripting the config is faster. You can send the Destination hostname (here listed as meh) and Destination Port (here 514) via regedit commands (Destination and DestPort respectively) and then restart the service. Screen Shot 2014-04-08 at 10.56.51 AM I’ll do another article at some point on setting up a logstash server to dump all these logs into. Logstash can also parse the xml so you can search for each attribute in the logs and with elasticsearch/hadoop/Kibana makes for an elegant interface for parsing through these things.

Stashbox: Turning a Mac Mini Into A Logstash and Kibana Server

You have a lot of boxes. You would like to be able to parse through the logs of all those boxes at the same time, searching for a given timestamp across a set of machines for a specific string (like a filename or a port number). elasticsearch, logstash and kibana are one way to answer that kind of need. This will involve downloading three separate packages (which for this article, we’ll do in /usr/local) and creating a config file. First, install the latest Java JDK. This is available at jdk8-downloads-2133151.html. The following is going to download the latest version of logstash and untar the package into /usr/local/logstash (I like nesting that logstash-1.4.0 inside logstash so when the next version comes out I can have it there too, I have plenty of space so keeping a couple versions back helps in the event I need some old binary and can’t get to it ’cause they revved out the version I wrote a script against at some point): curl -O mkdir /usr/local/logstash tar zxvf logstash-1.4.0.tar.gz -C /usr/local/logstash Once we have log stash, we’ll grab elastic search similarly: curl -O mkdir /usr/local/elasticsearch tar zxvf elasticsearch-1.0.1.tar.gz -C /usr/local/elasticsearch Then we’ll untar kibana in the same manner: curl -O mkdir /usr/local/kibana tar zxvf kibana-3.0.0.tar.gz -C /usr/local/kibana Next we’ll make a very simple config file that we call /usr/local/stashbox.conf that listens on port 514 for syslog: input { tcp { port => 514 type => syslog } udp { port => 514 type => syslog } } filter { if [type] == "syslog" { grok { match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" } add_field => [ "received_at", "%{@timestamp}" ] add_field => [ "received_from", "%{host}" ] } syslog_pri { } date { match => [ "syslog_timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ] } } } output { elasticsearch { host => localhost } stdout { codec => rubydebug } } Next, we’ll enable elastic search: /usr/local/elasticsearch/elasticsearch-1.0.1/bin/elasticsearch And finally, in a different window we’ll call logstash with that file as the config file: /usr/local/logstash/logstash-1.4.0/bin/logstash -f /usr/local/stashbox.conf Having each of these open in different Terminal windows allows you to see logs in stdout. Next, point a host at your new syslog box. You can use for installing Windows clients or for  a Mac. Once done, let’s get Kibana working. To do so, first edit the config.js. vi /usr/local/kibana/kibana-3.0.0/config.js Locate the elastic search setting and put the name of the host running logstash in there (yes, it can be the same as the actual logstash box as long as you install a web server on the logstash box). Then save the changes. Now move the contents of that kibana-3.0.0 folder into your web directory. Let’s say this is a basic OS X Server, that would be: cp -R /usr/local/kibana/kibana-3.0.0/* /Library/Server/Web/Data/Sites/Default/ You can then check out your Kibana site at http://localhost or http://localhost/index.html#/dashboard/file/logstash.json for the actual search pages, which is what I’ve bookmarked. Screen Shot 2014-04-10 at 10.37.51 PM For example, to see the impact of periodic scripts in System Logs: Screen Shot 2014-04-12 at 9.07.44 AM  

Logger In Bash

When bash scripting, a useful command is logger. The logger command allows you to “make entries in the system log.” When using the logger command, you can write to your own entries to the system log. To show how this command works, we’re going to open two terminal windows, preferably side-by-side. In one window, we’re going to look at the output of the system.log file interactively using the tail command with the -f option tail -f /private/var/log/system.log In the other window, we’re going to simply enter the logger command followed by the word frogger: logger frogger This will show you an entry similar to the following: Jun 3 00:34:44 krypted[77276]: frogger Congrats, you’ve successfully written your own log entry into the system log. Now that you’ve done that, go ahead and press the up arrow on your keyboard to see the line again and then hit enter. You’ll then see the same line, with the pid more than likely incremented up by one. The pid is the process id of the logger command you just ran. If you run ps you’ll note that the pid is no longer in use. Next, we’ll create a text file called froggerlog in our home directory, populating it with just the string: mylogdata. This is meant to emulate having written some data into a log file. We’ll do so using the echo command: echo mylogdata > froggerlog Now that we have a file, use the -f option to include the contents of the file into the system.log, specifying the path to the file: logger -f ~/froggerlog You will then see something like the following, with your mylogdata string in it: Jun 3 00:37:24 krypted[77279]: mylogdata Using that structure, you can write data into a file and then later dump that data into the log, so as not to fill up the system.log file with tons of random data as it happens. Or you can write directly into the log as needed. It’s good to have choices. The -i option is used to include the pid for the logger process in each line. But if you go back and add a second line of data into your log file, and re-run the logger command against that file you’ll notice that the pid is included with each line the same no matter whether you use the -i or not, making the -i unnecessary. You will also note that consecutive rows with the same information simply say — last message repeated 1 time —. This helps to keep log files a bit more trim than they otherwise might be if you have, say, 10,000 lines with the same content: Jun 3 00:50:57 krypted[588]: mylogdata Jun 3 00:51:17 krypted[588]: 1234 Jun 3 00:51:17 --- last message repeated 1 time --- Jun 3 00:51:17 krypted[588]: abc Now, you might find it difficult to see only the pertinent lines to your script. Use the -t option to tag a line, followed by the tag. For example, let’s add myscript into our lines, continuing to write into the system.log using the froggerlog file from earlier: logger -t myscript -f ~/froggerlog Note the output contains the myscript tag in front of the pid, in place of the username you were writing entries as: Jun 3 00:56:28 myscript[601]: mylogdata Jun 3 00:56:28 myscript[601]: 1234 Jun 3 00:56:28 --- last message repeated 1 time --- Jun 3 00:56:28 myscript[601]: abc Messages can be written at various priorities. To set the priority of your entries, use the -p option. After that enter the priority as an integer, using the following:
  • Alert: Level 1
  • Error: Level 3
  • Warning: Level 4
  • Notice: Level 5
  • Info: Level 6
  • Debug: Level 7
For example, to write an alert entry (everyone should see this): logger -t myscript -f ~/froggerlog -p alert To write a debug log: logger -t myscript -f ~/froggerlog -p debug The alert log is shown but the debug is not. Levels 5-7 are not displayed using a tail of system.log. If you need to verify success or failure of entries, note that logger exits 0 on success but not when an error is encountered. If you’d like to output entries to standard error, you can do so by adding the -s option as well.