Nessus Scan - results in MX crash

[JF1]

When performing a Nessus security scan, our MX250 appliance becomes unresponsive and crashes. 

We have noted that if we disable IPS / IDS this behaviour does not occur.

Therefore whilst the scan was running we disabled IPS / IDS and have since re-enabled. 

However we don't believe this is normal behaviour.

Does anyone have any experience of this? We do have a ticket open with Meraki support however feedback to date hasn't been helpful.

thanks in advance

[BrandonS]

Might be worth submitting here? https://bugcrowd.com/ciscomeraki

[PhilipDAth]

Are you running the current stable firmware?

If so, I would open a support case and log a bug.  That could be used for a classic denial of service.

[CptnCrnch]

I'd open a case even if I was running a Beta release. Something that mustn't happen IMO.

[AlexP]

100% agreed; if they've found a possible DoS vector, I want to ensure this gets the attention it deserves.

[AlexP]

We take all possible DoS vectors seriously, so if you're still running into issues with this, please post your case number, and I'll try to follow up internally.

[JF1]

We do have an open case reference 07832365

[StevePhipps]

We recently ran a Nessus scan across our entire inside 10 subnet and internal traffic slowed to less than 1/3. Once the scan was stopped, the issue disappeared. Has anyone heard anything more about this issue? I don't have access to the ticket mentioned above.

[JF1]

For those interested some further feedback on this issue. The firmware we are running 16.16 - there are some known issues relating to IPS / IDS that can result in a memory leak and hardware crash. A new firmware release is expected early June that addresses this issue. Also, in regards to StevePhipps comment - from our experience when the scan was ran there are a number of "connections" initiated to the security appliances (prior to the scan under BAU this connection count was around 100k, when we initiated the scan this jumped to over 500k), these "connections" lead to an increase in CPU and memory usage and in our scenario this led to a drop in performance. 

[Eric9]

Was this ever resolved for you? Was the scan of the actual appliance IP or was the scan running through it?

We recently transitioned from a vMX100 to a vMX-Medium running in Azure. We have been having an issue where, once a week, it just locks up and needs to be restarted via the Azure console. It is unreachable from the Meraki console. It happens a few minutes after a scheduled Nessus scan. That scan does not scan the vMX IPs but runs through the S2S VPN for some portions. We're not yet sure if this is the root cause. I opened a ticket with Meraki but haven't received a response after 48 hours!

[StevePhipps]

Scan included Meraki VPN hub sites. Fix was to exclude those. Only scanning assets in the two data centers now. Haven't tried this again out of caution.

[JF1]

Our issue appeared to be resolved by a firmware upgrade. The issue first started occurring on security appliances running firmware 16.16. Meraki advised there were known issues in this version relating to memory leaks in certain scenarios that resulted in the appliance failing. Following lengthy discussions and analysis from meraki we upgraded to MX16.16.3 and touch wood since we havent had any further repeats (we have carried out 2 Nessus scans across all networks including hubs). During our discussions Meraki support did also mention they have means to temporarily whitelist IP addresses of scanners to alleviate potential knock on compute complications on security appliances - in our scenario this ultimately wasnt required however it may be an option. Id suggest chasing Meraki...

[CptnCrnch]

Thanks for letting us know! Very interesting finding 👍

[jbrotschul1]

We have this issue as well.  MX450's acting as vpn concentrators in 1-armed mode running latest firmware.  The issue is actually the 'frames per second' table maximum of 500k is reached when scanning through to the branch locations.  When the FPS table is maxed it causes major performance degradation.  There's no solution support has provided other than to add more MXs and split up our remote auto-vpns to multiple concentrators to try and limit the impact.  We have about 150 branch locations.