We run all 4 of our MX's in prevention mode and security ruleset as well. 3 of our 4 MX's are running MX 18.107.10, the 4th one is running 18.211.2 as it is a newer MX. I have ordered MX replacements for our MX84, MX64, MX64W due to them not being able to update to firmware 18.200 and above. ... View more

Latest IP addresses that show destination to our public WAN IP's as action of Allowed for Zyxel IKEv2 overflow attempt and command injection attempt..I know in the past Meraki support has stated these attempts aren't actually being allowed to pass onto our LAN, but still concerning. I've added blocks on layer 7 and outbound layer 3 ... View more

Go back into - Threat Protection / Intrusion Detection & Prevention / click X under Actions for the rule / save changes ... View more

Response I got:   Thank you for contacting Cisco Meraki support. There is an issue with the new SNORT update and as a workaround for now, please whitelist the rule. We are working to get this fixed as soon as possible. Thank you for your patience and co-operation. ... View more

I may have to allow for now too, Remote site needs access to our mapped drive. ... View more

Ok. Meaning you are running in Prevention mode like we are where these actions are being blocked? Like I said in my previous reply to someone, this is still causing issues for us I just don’t want to whitelist until I know for sure it’s safe to do so. Thanks  ... View more

OK, thank you for confirming that. I do have a ticket open with Meraki support, I don’t want to whitelist these blocked alerts until I hear back from them but sounds like it’s a false positive..? ... View more

Both source servers in the alerts are running Microsoft Windows Server 2022 Standard, so not sure if the snort explanation applies...   The SMB client in Microsoft Windows Server 2008 R2 and Windows 7 does not properly handle (1) SMBv1 and (2) SMBv2 response packets, which allows remote SMB servers and man-in-the-middle attackers to execute arbitrary code via a crafted packet that causes the client to read the entirety of the response, and then improperly interact with the Winsock Kernel (WSK), aka "SMB Client Message Size Vulnerability." ... View more

The Meraki logging the alerts is a MX67W running - 18.211.2 ... View more

ok, yes i did open a case with support. I just know in the past some alerts were false positives, just wanted to see if anyone else is getting same alert.  thanks ... View more

Latest hit that was allowed on one of our external WAN IP's.   Snort shows this -  Missing documentation for 3-46125 There is currently no documentation for a rule with the id 3-46125 ... View more

Got allowed actions on my (2) WAN's over past 2 days - 98.27.28.56:500 - same Server-WebApp  Zyxel unauthenticated IKEv2 command injection attempt Zyxel unauthenticated IKEv2 overflow attempt Since numerous customers are getting exact same hits, is there nothing Meraki backend can do to once and for all block these attempts? ... View more

Yes doing that now, thanks  ... View more

I guess at this point, does adding layer 7 and layer 3 outbound deny rules for this IP 98.27.28.56 and others do anything, I would sure hope so. Or does the Meraki IDS action of allowed supersede my deny rules? I’m still shocked that months since I started this thread Meraki support still hasn’t addressed this security issue. ... View more

Yep, same here, see my growing list. Sometimes it goes a few days with nothing and then bam my (2) external WAN's get the allowed action. Meraki has to know that even though they claim the connections are not actually penetrating customers networks that continued false positives create doubt of what is actually being blocked and allowed. I could realistically take the jump to even though it shows blocked, maybe it was actually allowed..   ... View more

Ok, which Source / Destination / Details are you referring to? The ones I've seen have various IP addresses as the Source and Zyxel IKEv2 command injection or overflow attempt.  thanks ... View more

Some recent responses from Meraki Support   To break it down even more, there are two possible outcomes when an allow is logged: 1. The malicious traffic never made it into the network due to it being blocked by another process. 2. A single packet or two of the malicious flow was allowed but the flow was dead by the time Threat Protection made a determination. The current allowed threats I see in the network fall into the first category. To be specific, it was the inbound firewall rule that terminated this flow immediately with IDS/IPS following up after the fact with the malicious detection. This can be determined by looking at the firewall page and seeing that there are no port forwards configured for port 500 to allow the remote IPs. Thus, the deny any any rule of the inbound firewall would have blocked this traffic. In the second scenario, let's pretend there is a port forward allowing that remote IP. In this case, a packet or two may make it past before IDS/IPS makes a determination but once it does, it will block the rest of the flow. However, when logged as allowed, a packet or two of the malicious flow was allowed to flow into the network to the end destination however, this was all that was passed through as the flow itself was dead after this. No new packets after the malicious packet was received. In short for scenario 2, the MX will still block the malicious attack. Initial packets may go through, but the engine will block the flow.   We've acknowledged your concerns about potential compromises with your MX, and upon reviewing the backend logs, there's no need for alarm. The alert was indeed flagged as malicious traffic, but it was promptly blocked and is no longer present. This may have caused the dashboard to display the event as allowed. However, you can rest assured that there shouldn't be any issues with a breach on your MX.   My response:   Ok, I get what you are saying, but this way of discerning what is an actual threat and what is a false positive is different that it used to be, would you agree? When anyone reviewing their security center sees an action of Allowed from a rogue, potentially malicious IP or URL going to one of their endpoints or server our first reaction is not, well even though it's marked allowed I'm going to assume nothing malicious was allowed get through..there really needs to be an explanation put out on the dashboard for everyone to see. ... View more

Hi, got another allowed action in security center, false positive, actual threat, why wasn't it blocked..?   Source: 172-234-96-249.ip.linodeusercontent.com 172.234.96.249:39664   Destination: internal server   Allowed SSH_EVENT_SECURECRT https://snort.org/rule_docs/128-3 ... View more

Yes we do have ISP router before Meraki MX84   Referring to this:  If yes, I think the best way to dealing with this is to configure this router to only allow incoming connections to this redirected port if coming from your collaborators public IP.    [ISP ROUTER]* : Only allow collaborators public IPs and then Redirect 500 and 4500 ports to Meraki.     So from this ISP router I need to set a rule to only allow incoming connections to port 500 & 4500 to redirect to our Meraki's (2) external WAN IP's?  thanks ... View more

More allowed similar IP’s with Zyxel, I keep denying in 3 locations on firewall and they keep getting allowed, am I compromised am I not? Meraki support won’t give a confident yes or no. Support is becoming unreliable as of late, creating a dark cloud over my head for over 3 weeks now, argh! ... View more

Latest Meraki support reply:   Thank you for contacting Cisco Meraki Technical Support! This situation happens sometimes on older models like the MX64/65/84/100 which run threat detection out-of-band. Traffic is duplicated over to the threat detection engine, which then examines the traffic and makes a decision to allow/block it. This situation emerges when the traffic flow ends before we make the decision to block - for example, if it's only a packet or two long. We're still making the decision to block, but since the flow is gone by that time, it gets logged as allowed since nothing was actually blocked. This behavior is outlined in our documentation: "Intrusion prevention on the MX used to block triggering malicious packets is designed to be best effort. Subsequent packets within the same malicious flow will be blocked.   Below I have provided a document that goes over this in more detail:  https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Threat_Protection#Intrusion_Detection_and_Prevention     My response:  I think the only thing that is concerning is when do I need to be actually aware a successful breach has happened if allowed doesn’t really mean allowed, when should I note it as a false positive vs an actual breach that someone has made it inside our network to potentially set off a ransomware attack? ... View more

Ok, the list of customers experiencing this keeps getting longer since I opened this issue over 2 weeks ago, Meraki support keeps giving this answer or something similar, doesn't give me confidence yet that an external IP is gaining access via external WAN IP's.   IDS allowing known malicious signatures usually happens when the MX sees a single packet that matches the signature, but the flow terminates because the remote party reset the connection, so the MX can’t take action to “block” the flow. The security center still logs the event as "allowed" but no real malicious traffic was allowed for the flow since it was terminated.     ... View more

ok, crud. Ya in a real bind now if even after deny rules are added to firewall that the action still comes up allowed... ... View more

Same alerts in the early morning today, with same IP as yesterday.   98.194.65.91:500 allowed on one of my MX (2) public IP’s   yesterday I added denied this IP in these locations on MX   Content filtering- block URL   Layer 3 outbound rule deny   Layer 7 deny remote IP range & port  ... View more