WOW, just wow. Thank you for continuously improving ASSP.
The HLMSOLE option could be very useful if we apply is correctly.
What do you consider "executable code" in a macro? Do you mean a macro
that calls an external executable?
Unfortunately this specific sender uses Office 365 primarily, but also a
ton of other SMTP sources through their automated services. Really puts us
in a jam.
Future thinking: I believe that bombHeaderRE allow for something like:
\nfrom:[^\r\n]+?\@sender_domain\.com.+?\nto:[^\r\n]+?the_recipient\@your_domain\.com
as a way to search for a sender and recipient pair. If there's some
magical way for you to build this kind of thing into userattach, that would
be incredible. Then we could granularly allow/prohibit certain kinds of
attachments based on the sender/recipient PAIR.
On Fri, Jun 15, 2018 at 1:28 AM Thomas Eckardt <thomas.ecka...@thockar.com>
wrote:
> Such a scenario seems to be a common problem. To solve this, the ASSP_AFC
> plugin got some improvements. Because these changes are security related,
> I'm still testing the new code.
> The new code (assp.pl and APPS_AFC.pm) are available at SF-SVC in the
> test folder.
>
> What is changed?
>
> A new exception ':HLMSOLE' (HarmLess MS-OLE files) was added. If this
> exception is used and a MSOLE file is detected in an attachment, the OLE
> file is extracted and every single content (file) in the OLE is scanned for
> virus and (if configured) for executable code.
> A MS-Office-Macro is an OLE file in every case. Using a combination like :
> exe\-bin|:MSOM|:HLMSOLE|:CSC
> will lead in to the following behavior.
> - macros are not blocked
> - script code (VBA for example) is not blocked
> - MS-OLE (also macros) are not blocked as long as they not contain
> executable code or a virus
>
> What are the requirements?
>
> The perl modules OLE::Storage_Lite and Email::Outlook::Message must be
> installed.
>
> >They regularly violate SPF
>
> Override the SPF record for this domain in assp and block strictly on SPF
> faults for this domain.
> Record all the sender addresses, put them in to a group and configure an
> attachment blocking (at runtime) exception for this group of people.
>
> How ever, if the company uses a large email provider (gmail, microsoft,
> ....) to deliver there mails - you are lost in case spammers using the same
> provider. SPF will pass and usinf the right sender addess is easy.
>
> If there is no way to get this 100% solved, create an email account for
> your company (gmail, ms, ....), give the email address to the shipping
> company. Collect the emails from the provider and rewrite the recipient
> address in assp to hide the original recipient address..
>
> Thomas
>
>
>
>
> Von: "K Post" <nntp.p...@gmail.com>
> An: "ASSP development mailing list" <
> assp-test@lists.sourceforge.net>
> Datum: 14.06.2018 17:34
> Betreff: [Assp-test] UserAttach sender & recipient matching?
> ------------------------------
>
>
>
>
> I'm looking for a magical way to do do something where a UserAttach rule
> could work for a pair, like
> to:OurOneUser@OurCharity.org_from:*@TheShippingCo.com=>block=> (the list)
>
> Here's the scenario:
> A giant international shipping company that we work with needs to be able
> to send us excel files with macros in them. They will not provide the
> files any other way and they are critical to our charity. A seemingly ever
> changing list of people at this external domain send these files, but only
> to ONE of our people here. They regularly violate SPF, don't consistently
> DKIM sign - and they're so incredibly large that there is no hope of change
> on their end.
>
> I am trying to avoid doing the exception for the whole sender domain
> because it's a domain that's commonly used to send spam/scam emails too.
> So, an exception like:
> *@ABC.com => block =>
> exe\-bin|:MSOM|:MSOLE|url|ade|adp|asx|bas|bat|dot|dotx|xlt|xlts|bin|chm|cmd|com|cpl|crt|dbx|dll|exe|hlp|hta|htb|inf|ifs|isp|js|jse|lnk|mda|mdb|mde|mdz|mht|msc|msi|msp|mst|nch|pcd|pif|prf|ps1|reg|scf|scr|sct|shb|shs|vb|vbe|vbs|vba|wms|wsc|wsh|rar|dotm
> (which has the :MSOM exception and doesn't have xlsm listed like our
> regular block does)
> would work, but then lets the scammers send scam Excel macro files to
> everyone. No good.
>
> With my idea of having user attach be matched only for one recipient only
> if it's from the shipper domain, we limit the exposure a bit.
>
> Thoughts? Other ideas?
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
>
>
>
>
> DISCLAIMER:
> *******************************************************
> This email and any files transmitted with it may be confidential, legally
> privileged and protected in law and are intended solely for the use of the
> individual to whom it is addressed.
> This email was multiple times scanned for viruses. There should be no
> known virus in this email!
> *******************************************************
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Assp-test mailing list
> Assp-test@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/assp-test
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Assp-test mailing list
Assp-test@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/assp-test
