AMP/IDS seems to block file download without logging to security center

[hinewwiner]

Hi - 

My users are having problem downloading a file from one of trusted sites. (The site is listed in 'Whitelisted URLs' under AMP section)

When one tries to download a file (related to ActiveX), the download starts but it hangs (it is 4mb file) then fails the download after few minutes. 

However, when I look at the Security Center, nothing is logged.  So I can't add the SHA256 to the AMP Whitelisted files.

Has anyone experienced this?  The file can be downloaded from home so I don't think it's their server's problem.  

FYI, I currently have AMP enabled and IDS set to prevention and balanced.

Thank you

[ITzhak · Accepted solution]

Hi,

Yes, we've had that extensively and disabling AMP temporarily would let it through. Upgrading to MX 12.26 helped a lot, but we still get it occasionally. Apparently in MX 13.xx it's addressed further but we have not updated to it yet since it's not a Stable release yet.

[Mr_IT_Guy]

We've done a lot of testing with AMP at various levels of Beta and we run into this issue constantly with one of our important programs during upgrades. Disable for the upgrade.. re-enable afterwards is still the best solution we have even in the 14.xx series 

[Andre]

We are running 13.36 and the issue still persists. Tried to download any *.diagcab file from Microsofts site directly and it fails right away with AMP turned on. Nothing gets logged and even if I try to whitelist Microsofts download site it still fails. If I turn off AMP the download works fine.

[PhilipDAth]

Try going to the 14.x firmware.  Most networks are now being upgraded to it.

[MRSupportAdm]

Cisco Meraki acknowledged this is a bug around Sept 2018 for us.  The fix has been in development for months and it is a problem with the AMP engine.  We check in weekly with our technical contact and they told us last week that 14.39 does not have any code included to address this, but upgrading can't hurt as some situations may differ.  Cheers!

[Adoos]

We recently moved to 14.39 and today had one problem where a site was unable to download PDF files. The resolution was whitelisting the clients via policy and moving them back to normal. Initially we tried to turn off/on AMP but that made no difference. Raised a support case just incase, stay tuned. 

[Xoncomms]

Hi

I have just been working on similar incident with Sharepoint files not able to download internally over VPN.  We turn off AMP and all is fine.  So created a whitelist, which didnt work.  After further investigation we see in the security dashboard that AMP is actually allowing the file, hence the whitelist not doing what we thought it should, however AMP seems to break the file with the following reported in the security dashboard:- "ArchiveFile_Empty downloaded" from http://path.

I have raised a case with Meraki and waiting on their advise.

[MRSupportAdm]

The fix is in MX firmware beta 15.12 or greater.  We have been testing for weeks and no issues now with AMP enabled.  Whitelist exclusions appear to be working also.  No other issues reported with this firmware in our environment so far. Contact Meraki to request testing 15.12 -- only they can provide it.  

[MRSupportAdm]

Disabling AMP is a workaround, but I wouldn't call that a solution. The issue is due to a bug and Meraki has a fix in a beta firmware (15.12).

[JayPrint]

disabling AMP might be a workaround, but it should not be the "accepted solution"

[PhilipDAth]

We have all out customers running 13.28, and I have not had a single one contact me with false positives.

[Mr_IT_Guy]

@PhilipDAth, I've had been testing with Meraki support for over a year before we found a version that kinda worked for us, but ultimately has failed after a new version of our software came out. We had even whitelisted the server and added additional rules and still nothing happened. When AMP was enabled, the file would begin to download, get to 74%, and then just stop. Nothing would be reported in Security Center and the only way we would know about the failure/block is by users calling in. 

As far as my issue is concerned, I believe it has more to do with the application we are downloading rather than AMP, but I feel that if I have a WHITELIST applied I should be able to bypass whatever algorithm is prompting the block.

[ITzhak]

@Mr_IT_Guy Since whitelisting, whether of the URL or of the hash, doesn't work, I'm inclined to think that it has to do with the way the AMP examines the data. That purely it's process crashes the download. I.e. it's not that it recognises it as malicious but rather before any definition is made.

[Maicon_Vieira]

We are on version 13.28 too and i'm having the problem  @hinewwiner mentioned.

I'm gonna do some tests and i will come back with some results.

[mike318]

We used to have this issue constantly on several different MXs.

After the 13.x upgrade, the issue was apparently resolved (for us). 

[Adoos]

We are just starting to roll out over 35 sites with the Meraki stack and hit AMP issues straight away. (Appears to only be PDF at this point)

*Running firmware mx 14.31

*False/positives are occuring for PDF but not being logged in the security centre.

Turned off AMP and the issue went away, turned it back on but whitelisted one domain and PDFs were flying through once again. Removed the domain and it stopped again. We have left one network which strangely is working fine with no whitelists to see if it breaks. 

Little scary.

We did raise a support ticket but until it happens again I don't think much will happen. 

[MRSupportAdm]

We're experiencing similar issues with .Net downloads from and IIS server and PDF files for a paperless solution even with servers whitelisted.  As soon as we turn off AMP, everything sails through no problem.  And, as others have stated here, nothing in the logs so it's very difficult to troubleshoot.  We've spent several hours troubleshooting with Meraki support.  Issue happening on sable release firmware for MX (13.33) and BETA (14.31).  We're hopeful engineering can address quickly, but the issues have been time consuming.

[Adoos]

Sad we have to turn off AMP.