Sentinel & Cisco Meraki?

[David Caddick]

Has anyone had any experience with getting Cisco Meraki feeds ingesting into Sentinel?

Just checking for any gotcha's...

[#2]

@David Caddick I had to do it for a customer and it worked just fine using the Syslog server.

[#3]

@Gary Bushey Agreed. 

The instructions here (https://techcommunity.microsoft.com/t5/azure-sentinel/azure-sentinel-syslog-cef-logstash-and-other-3...) work pretty well. Search that page for 'Meraki'

[#4]

We are also working on this, but are running into an issue where some of the logs are getting chopped by the syslog server. It appears to be an issue only with vpn flow traffic on the MX firewall.

We have a case open trying to figure it out.

[#5]

Hi @Gary Bushey 

can you please confirm the sentinel table in which you are getting Meraki events. It is like custom log or coming under syslog ?

[#6]

They will show up under syslog.

[#7]

Hi @mperrotta 

Thanks for your reply. I did the same and event getting under syslog are not complete, they are truncating the events(by : in Rawdata).

Refer below details

Actual logs 1:
Mar 27 14:00:38 1.1.1.1 987654321.123456789 MerakiXXYY urls src=yy.yy.yy.yy:40206 dst=xxx.xxx.x.xx:443 mac=AA:AA:AA:BB:BB:BB request: UNKNOWN https://aaa.vbvbvb.com/...

SyslogMessage 1:
40206 dst=xxx.xxx.x.xx:443 mac=AA:AA:AA:BB:BB:BB request: UNKNOWN https://aaa.vbvbvb.com/...

Actual logs 2:
Mar 27 14:00:56 1.1.1.1 987654321.123456789 MerakiYYXX flows allow src=yy.yy.yy.yy dst=xxx.xxx.x.xx mac=FF:FF:FF:FF:FF:FF protocol=udp sport=60000 dport=1234

SyslogMessage 2:
FF:FF:FF:FF:FF protocol=udp sport=60000 dport=1234

have you observed same issue if not can you please help the method you followed.

Thanks in advance

[#8]

We are seeing the same symptom as well. We currently have a support case open to look into this. If we find the solution, I will update you.

[#9]

@mperrottawe're seeing the same problem, did you ever find a solution for this?

[#10]

Hi, after working with the MS support team and their dev's, they determined that Meraki logs don't follow the RFC standard for syslog message. Basically, what is happening is at the first = in the syslog message, Sentinel dropping everything before it and the remainder of the message get captured.

The workaround for this was to have rsyslog write the Meraki logs to a file then we have Sentinel ingest the files into a custom log table. You will want to have log rotation setup to ensure that it does not grow infinitely. Here are the config notes I have. To have Sentinel pull the custom log, that is configured in Log Analytics under Advanced settings.

Let me know if you have any questions.

Configure Log Rotate

Create directory:

sudo mkdir /var/log/meraki

Assign permission on folder:

sudo chown syslog /var/log/meraki

Create log rotation configuration file:

vi /etc/logrotate.d/meraki

/var/log/meraki/meraki {

    rotate 3

    missingok

    create 0640 syslog adm

    notifempty

    compress

    size 100M

    delaycompress

    sharedscripts

    postrotate

            /usr/lib/rsyslog/rsyslog-rotate

    endscript

}

Configure rsyslog to send meraki logs to file:

vi /etc/rsyslog.conf

Add the following line at the bottom

if ($fromhost-ip=='172.16.15.254') then /var/log/meraki/meraki

[#11]

Going to give this a try. I have used Meraki equipment for a long time but have to say the amount of times i find their implementation doesn't use standards is frustrating. Their syslog is not compliant, their client vpn implementation is odd, etc.

[#12]

@mhaasEFD 

I've done this Meraki recipe for two customers; it comes in via syslog, syslog puts it into its own file, it's read as a Custom Log by the Log Analytics Agent and is forwarded into Sentinel. Then within Sentinel we have a KQL function to extract the most common stuff. What's frustrating is that Cisco Meraki isn't always the most consistent with the log format.

Here's my GitHub with the extractors, which I have no problem with anyone else using, and if you guys have fixes, I'm happy to incorporate them:

https://github.com/jkatzmandu/sentinel_tricks

[#13]

Thanks,
I got syslog up and running already but looking over your info. I did setup a CEF output from my graylog server and found that cleaner but if you don’t need an internal graylog server it’s probably an extra step.

[#14]

@mperrotta, you suggest using log rotation so the file doesn't grow indefinitely, but Log Analytics Custom Log from file doesn't support file rotation. Does your workaround work anyway? 

[#15]

@Manresa The log rotation is for the sending side, the linux rsyslog files that are in the middle. Not on the azure side.

[#16]

@mhaasEFD, thanks for the quick response. I understand that, but Microsoft documentation in Collect custom logs with Log Analytics agent in Azure Monitor - Azure Monitor | Microsoft Docs says that:

• The log file must not allow circular logging or log rotation, where the file is overwritten with new entries.

If I understand correctly, this means that the log file in the syslog server can't be rotated, so Azure can accurately take the new entries from where it last read the file.

[#17]

@ManresaI am not sure the risk implication of this requirement. Maybe we end up missing some flow logs when the rotation occurs? 

There are no obvious logs missing that we can see. We have been running this solution for several months now without any issues. This is the only way that I am aware of how to capture the full message from Meraki at this time.

Unfortunately, we just consider this the least broken way of doing it. 

[#18]

Are you running this function when you query? or can this be used at collection without having to create individual custom fields?

[#19]

@mhaasEFD 

I use it when we query; so instead of "Cisco_Meraki_CL" as the "table" in my search, it's this function...

[#20]

@JKatzmandu good thread, the solution worked well to get the data separated. The only issue here is Sentinel has 0 analytics for Meraki, none of their scheduled/ML/Anomaly analytics will every query that table so I am going to work on getting the data into CommonSecurityLog in hopes it might catch something.