I just found this off the back of Vbrites sandbox investigation. https://blogs.cisco.com/security/cisco-live-melbourne-soc-report The section titled "Mirai Botnet Attempts" is the interesting part. It details what vbrites has seen, almost line for line. It says that the process "tr069ta” is a daemon needed by Zyxel devices to run properly and these command injection attempts are commonly used to create "Mirai-like" Botnet nodes from Zyxel devices so i'm assuming that Meraki devices won't be affected (don't take my word for it)   ... View more

Thanks for this investigation. Its more than I've gotten from Meraki since this all started happening. Although the attempt might not be succeeding (hopefully), my original and continued issue of this affecting multiple meraki customers from the same public ips at the same time is worrying ... View more

I'd block 162.248.224.101. It seems to be what the attempt is trying to reach out to in order to download a malicous payload of some kind ... View more

Hi,   It's been happening almost daily for us since this was first posted. I've got into the habit of checking the alerts each morning and adding any new ips to the firewall rules block as well as layer 7 blocks and reporting the ip to the isp   Unfortuntely Meraki don't have plans to fix the annoying "allowed" action when its not truly allowed.   Its frustating that it keeps happening from the same ip range too   Thanks   Thanks ... View more

They've appeared again for us too. No response on the meraki ticket in nearly 24 hours either. ... View more

That would be helpful, otherwise everytime we see an allowed action, a support ticket will need to be raised for them to confirm it hasn't actually been allowed ... View more

I think Meraki explained to me before that the SNORT ids rules inspect the packet to see how it is structured and compares it against known vulnerabilties. So you can often get misleading alerts or false positives (e.g. an alert saying that theirs an apple ios vulnerabilty detected when it isn't an apple device) ... View more

Apologies, my poor research. It does use port 500 but not IKEv2.   However if you use the site to site vpn for sd wan connectivity it uses IKEv2 . Other site to site vpn to non meraki vpn peers can also use IKEv2.    Hopefully meraki support give you the reassuring answer about the IDS allow action not being as it seems. I've asked for a bit more information about it too ... View more

Hi All,   I've got a more thorough response from Meraki  "Whatever was trying to connect to you over IKEv2 eventually stopped sending data. When this happens while the MX is detecting the event, it will flag it as malicious but will also flag it as "allowed" because nothing is generating data through that flow it inspected anymore. This can be disregarded as you aren't peering with a remote location that has that IP, so no tunnel would form, and client VPN doesn't use IKEv2 for VPN on top of you having it disabled."   It looks like the Meraki VPN uses L2TP while this attack was targetting IKEv2 which uses port 500 which L2TP doesn't use. That on top of the explanation around the allowed behaviour is comforting. ... View more

Ive had an almost identical response. Multiple users getting the same alert from the same ip at the same time is surely a cause for concern. I understand they've updated their snort ruleset so theres alot of noise but its a very specfic alert in my eyes. We have no links with the ip address so there shouldn't be any attempts on port 500 from them, especially allowed ones. I'm going to ask them to esculate it and see what comes of it ... View more

Do you have the client vpn enabled by any chance? I checked our VPN connections and radius server too and didn't see anything either but I'm unsure if that would show anything anyway if its an unauthenticated attack? ... View more

Hi,   We had the exact same alerts at the exact same time from the exact same IP Address. We've logged a ticket with Meraki but haven't had anything helpful back yet.   We dont have Zyxel devices but with the port being 500 (Ike) and it hitting a meraki mx public ip address on a meraki device that has the client vpn functionality enabled, we're definintely worried that the action says it was allowed. We've turned off the client vpn until we get an acceptable answer from Meraki. We also had IDS set to prevention and the mode as security before the alert happened.   Similar, we want to know why it was allowed. We've blocked it at layer 7 now but we need to know if the action was actually allowed as then we've been compromised which means that they may already have persistence in our network   Its suspicous that 3 users all with meraki devices have seen these exact alerts though. I'm going to update our ticket with this information to hopefully get someone on the case to connect the dots.   Thanks ... View more