Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About ABR1988
Community Record
14
Posts
6
Kudos
0
Solutions
Badges
a week ago
1 Kudo
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
a week ago
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
a week ago
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
a month ago
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
Feb 23 2024
8:06 AM
They've appeared again for us too. No response on the meraki ticket in nearly 24 hours either.
... View more
Feb 22 2024
11:51 AM
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
Feb 22 2024
11:50 AM
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
Feb 11 2024
9:57 AM
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
Feb 9 2024
6:39 AM
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
Feb 9 2024
12:20 AM
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
Feb 8 2024
5:17 AM
1 Kudo
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
Feb 8 2024
1:03 AM
2 Kudos
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
Apr 11 2022
12:54 AM
1 Kudo
Hi Chptrk, Nice to know we're not alone! Can you let me know if you get any further in diagnosing it than i have? Thanks
... View more
Jan 6 2022
5:42 AM
1 Kudo
Hi, I recently updated our sites MX appliances to the latest version (MX 16.15) and since then, theres been a barrage of alerts from the IDS named "CA BrightStor stack buffer overflow attempt". I've investigated the snort rule that seems to relate to an old backup solution that we've never used and is no longer supported anyway. The alerts source is our SCCM CAS with the target the primary SCCM servers at each remote site. As far as i can tell, the running of the sccm system is uninpeded even though these connection attempts are blocked. The more i look into it, the more it seems like a false positive. I'm thinking it could be RPC being mislabelled as a vulnerability. I've got a few open vague questions- is anyone with the similar setup are seeing these alerts? What practices do you recommend for potential false positives like this? E.g. would you allow them or leave IDS to block regadless? How far would you go to investigate? Is there any literature regarding snort rules, merakis IDS systems to read? Thanks in advance!
... View more
Labels:
- Labels:
-
Other
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 2 | 16418 | |
| 1 | 602 | |
| 1 | 16378 | |
| 1 | 2917 | |
| 1 | 3288 |
© 2024 Cisco Systems, Inc.
