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

Ok, if this is indeed the case, Meraki needs to put a headline alert on every client's dashboard overview page or send out a mass email or something. I do find it curious that some random person coming from an IP in Poland the first round and now in Texas the second round is hitting numerous customers with at the exact same time with the exact same Zyxel unauthenticated IKEv2 command injection attempt  &  Zyxel unauthenticated IKEv2 overflow attempt alert. (I'm sure a lot more that just don't get on this community and report). ... View more

I have added to my original Meraki case about this issue 2 weeks ago with this new info, have not heard back yet..   From Snort site about this allowed action we are seeing.   Link to CVE listed on Zyxel site - https://www.cve.org/CVERecord?id=CVE-2023-28771   Makes no sense, is a public Zyxel firewall trying to access our Meraki MX's public WAN's..?   ... View more

Happened again, these IP's were allowed on (2) of my MX's external WAN IP's - 98.194.65.91:500; 98.195.67.12:500; 98.194.65.92:500   Zyxel unauthenticated IKEv2 command injection attempt   Zyxel unauthenticated IKEv2 overflow attempt   ... View more

I agree. I was the one that started this case last Tuesday and have been engaged with the community here and Meraki support ever since trying to determine what if anything malicious was allowed to access our MX public WAN's. Jess ... View more

Ok, thank you for the detailed response on this issue. ... View more

Latest from support on my case   Thank you for contacting Cisco Meraki Technical Support. We understand that you are having concerns over your MX being compromised, but after looking over some backend logs you should not worry about your MX being compromised. We could see that the alert was identified as malicious traffic, but it was dropped afterwards because it was no longer present. This caused dashboard to show the event as allowed. However, you should not have any issues with a breach on your Client VPN. If you're still experiencing issues feel free to reach back to us. ... View more

At this point I am just leaving VPN enabled, I tried layer3 outbound rule to deny any traffic within the VPN subnet as a precaution, but it's then pointless to enable VPN again since user can't access internet, shared drives, etc. ... View more

So I just tested connecting to VPN, as soon as I connected my internet went to blocked and I could not Remote Desktop into my work computer, so back to square one, I will need to remove that layer3 deny for the VPN subnet if I want to leave VPN enabled. ... View more

Ok, thanks for confirming that. One thing I did find out after adding the layer3 rule is that when I connect to our VPN over my phone to access my security cameras that was blocked until I removed the rule. Which does go along with what you were talking about as the cameras are on a separate internal subnet. So at least if a bad actor did connect to our VPN, they wouldn’t be able to attempt to access any of our internal computers or servers, which is a good thing. Thanks ... View more

So even though you left the VPN enabled, adding that layer3 rule to deny any internet traffic on your VPN subnet, won’t users that connect to VPN not be able to get to the Internet then? ... View more

From support:  We understand that you are expecting issues with 95.214.52.173 on port 500. However, there has been a recent update on the IDS/IPS ruleset and an improvement in terms of coverage and detection efficacy is expected. As result, certain traffic that before would not trigger an alert may now result in one.   that’s all fine and good but still doesn’t explain how an unauthenticated attempt from a foreign IP was allowed.. ... View more

How did you create a layer3 rule to isolate the VPN subnet? Thanks  ... View more