Snort rule breaking scan to email

[lesliebright]

Users reported scan to email being broken and after troubleshooting for a couple of days, we found that our MXes were blocking the SMTP connection (SMTP_COMMAND_OVERFLOW). 

We have been using scan to email successfully forever and need it. Why would this rule change in such a way to break this critical, basic functionality? I have had to whitelist this rule in security center. 

[Mloraditch]

These sorts of changes are not designed to deliberately break things. It's possible something was loaded into the ruleset incorrectly, it's also possible whatever SMTP server or scanners you use don't comply with the RFCs for SMTP and some sort of attack has been developed using similar methods and this caused a rule to be added. Could be other issues as well.

If you didn't work with support already, you need to. That way the issue can be logged and sent back to the Snort team for analysis.

[lesliebright]

I opened a case with Meraki, yes. They threw up their hands and just said it was the snort rule, not our problem. The scanners are MFP copiers and various office printer across many brands and models. It may be that they don't comply with the RFC, but doubtful across all of those manufacturers. 

Meraki support: "There's really nothing we can say or do to address this here. TALOS has a feedback page that customers can submit false positive reports to if they have Cisco accounts, but beyond that, they'll need to continue working around these rules to address this: https://talosintelligence.com/reputation_center/ips_ids"

[Mloraditch]

May want to escalate to your account rep. Were you able to confirm with them that there was an update to the rule? I can certainly understand if it ends up being deal with it, but they should be able to document what the rule is, and that a change took place.