Topic: block iso email attachment

[SchulzStefan]

The original reporter SchulzStefan, could always monitor the iso's etc that he receives & creates patterns from those.
While they may not work appropriately for everyone as common patterns, they would work on his own SME server system quite well, as he wants to block all iso's, so he could just keep adding patterns for every iso file he receives.

That's exactly the point: I don't want to monitor emails with iso-attachments. I'd like to block any email - without any investigation - with an iso-attachment. Saying it's a company rule. Sending iso's as an email-attachment is IMVHO just nonsense. Therefore spending time for an investigation in this case is not helpful.

regards,
stefan

[SchulzStefan]

Has anyone tested/integrated this in the smeserver?

http://qmail-scanner.sourceforge.net/

https://www.tldp.org/HOWTO/Qmail-ClamAV-HOWTO/x179.html

If I understand correct, this should do it?

[ReetP]

Your problem still remains unless you block every single attachment

cp some.iso some.jpg

Mail the jpg.....

I don't believe there is a 'one size fits all' simple solution.

[SchulzStefan]

Your problem still remains unless you block every single attachment

cp some.iso some.jpg

Mail the jpg.....

I don't believe there is a 'one size fits all' simple solution.

I don't get it.

Are you saying there's a solution for blocking every jpg-attachment?

Where is the problem, if I want to reject every email with an attachment which is an iso? I don't want to investigate the attachment (or the content of the email), I just want to reject the email in case, that there's an iso-attachment. I dont' want to know anything about the email nor the attachment. If the ending of the attachment is dot iso, I want this email to be rejected or quarantined. If the iso has been copied to a jpeg (or anything else) this would be another problem to me.

Question to the specialists: there's really no solution/addon for qmail  (like black- or whitelist in the server-panel) to block/reject an email with an unwanted file-suffix? It's just stupid blocking, no investigation. Email with an unwanted attachment comes in, reject. End. Nothing else.

regards,
stefan

[ReetP]

Please don't get so hot under the collar just because no has provided you with a 'simple' solution you want (because there isn't really a 'good' simple one)

You miss my point and did not really read what I wrote.

For sure block *.iso or *.whatever

BUT. Anyone who wants to bypass it can easily change the extension.

So you block .iso

I copy somefile.iso to somefile.jpg and mail it to my friend and tell him to save it as somefile.iso

Your super blocking code is instantly rendered completely useless because it blocks .iso but allows .jpg (or whatever... don't read this literally)

So simply blocking by extension is not a foolproof solution. Why antivirus doesn't rely on it.

Hence people are trying to see if there is another method.

But it seems there is no fool proof one currently - it is a really tricky area.

If you have a way to do it then let us know.

[ReetP]

Question to the specialists:

If you write stuff like that you may find you don't get much help.

I help fix stuff here for fun. Not abuse. I'm not trying to make fun of you. Just looking at facts.

If you want it fixed then you can:

1. Get build access and do it yourself so everyone benefits

2. Hope people like me write a patch for you. If it is actually possible.

Please, save the sarcasm, and don't bite the hand that feeds you.

[Jean-Philippe Pialasse]

there's really no solution/addon for qmail  (like black- or whitelist in the server-panel) to block/reject an email with an unwanted file-suffix? It's just stupid blocking, no investigation. Email with an unwanted attachment comes in, reject. End. Nothing else.

regards,
stefan

this is not qmail work, this is qpsmtpd that receive emails from outside.

Reetp did answer you why this is not the solution to simply check for file extension.

nowaday most attacks will be using pdf, docx, odt and other files you can not simply bloc the extension or you will just make your user move to another service to get the file they want .

[janet]

SchulzStefan

It would be helpful to know what your real motivation is.
"Saying it's a company rule. Sending iso's as an email-attachment is IMVHO just nonsense."

Is it that you just think sending iso's is nonsense, or perhaps do you object to large attachments slowing down the mailserver.

Instead of blocking file suffix types, a workaround is that you could limit the size of emails, & anything that has a big iso or img attachment will be blocked (as well as all other attachments that are bigger than the set limit).
See the FAQ for size setting commands.
https://wiki.contribs.org/SME_Server:Documentation:FAQ:Section04#Set_max_email_size

eg
config setprop qpsmtpd MaxScannerSize 10000000
signal-event email-update

would probably stop most iso's & img's but still allow large other types of attachments (depending on your personal interpretation of large), & depending on the setting of your other size limits.

Here is another possibility, I have not looked at it so cannot comment on effectiveness or usefulness.
https://wiki.contribs.org/Qpsmtpd:exe_filter

[SchulzStefan]

Please don't get so hot under the collar just because no has provided you with a 'simple' solution you want (because there isn't really a 'good' simple one)

You miss my point and did not really read what I wrote.

For sure block *.iso or *.whatever

BUT. Anyone who wants to bypass it can easily change the extension.

So you block .iso

I copy somefile.iso to somefile.jpg and mail it to my friend and tell him to save it as somefile.iso

Your super blocking code is instantly rendered completely useless because it blocks .iso but allows .jpg (or whatever... don't read this literally)

So simply blocking by extension is not a foolproof solution. Why antivirus doesn't rely on it.

Hence people are trying to see if there is another method.

But it seems there is no fool proof one currently - it is a really tricky area.

If you have a way to do it then let us know.

ReetP

I didn't want to offend you or anybody else here in this forum. Sorry, if you got me wrong. I do know about the difficulties you wrote about.

regards,
stefan

[SchulzStefan]

SchulzStefan

It would be helpful to know what your real motivation is.
"Saying it's a company rule. Sending iso's as an email-attachment is IMVHO just nonsense."

Is it that you just think sending iso's is nonsense, or perhaps do you object to large attachments slowing down the mailserver.

Instead of blocking file suffix types, a workaround is that you could limit the size of emails, & anything that has a big iso or img attachment will be blocked (as well as all other attachments that are bigger than the set limit).
See the FAQ for size setting commands.
https://wiki.contribs.org/SME_Server:Documentation:FAQ:Section04#Set_max_email_size

eg
config setprop qpsmtpd MaxScannerSize 10000000
signal-event email-update

would probably stop most iso's & img's but still allow large other types of attachments (depending on your personal interpretation of large), & depending on the setting of your other size limits.

Here is another possibility, I have not looked at it so cannot comment on effectiveness or usefulness.
https://wiki.contribs.org/Qpsmtpd:exe_filter

Janet

what do you mean with real motivation? I want to block any email with an iso file attached. No investigation, if the file suffix is dot iso, rejection. I simply don't want my users receiving emails with iso files attached.

I already limited the size of emails.

https://wiki.contribs.org/Qpsmtpd:exe_filter - I'll have a look into this. Until today I didn't know the existance of this... Thank you for the hint.

regards,
stefan

[janet]

SchulzStefan

stefan wrote:
what do you mean with real motivation?
 I simply don't want my users receiving emails with iso files attached.

Why ?
What is your reason, is it a technical  reason, & if so, what ?

I already limited the size of emails.

To what size & which setting or settings ?
Has that helped stop iso & img attachments ?

[janet]

Hi michael mccarn

It seems you may have added this:
https://wiki.contribs.org/Qpsmtpd:exe_filter

Do you have any more details about usage & implementation ?
It seems similar to executable content blocking, but part of the text refers to blocking all attachments of a certain type eg zip (implies by name).

I understand this is "dumb" blocking, but it could still be useful as part of a layered protection approach.

I, too, have long wished for an easier way to block emails by attachment type on SME servers

[mmccarn]

Do you have any more details about usage & implementation ?

Sadly, no.  (I created the various qpsmtpd pages using 'perldoc' so I could find things in them using google)

exe_filter looked to me like another flavor of the virus filter -- it seemed to be using pattern matching rather than simple name matching.

[mmccarn]

Here are some details on how to block by filetype using spamassassin.

1. Review your current spamassassin settings in case you want to revert them.
Make sure that status=enabled and RejectLevel" is a positive non-zero number that is smaller than the custom score we will assign later.
# config show spamassassin
spamassassin=service
    BayesAutoLearnThresholdNonspam=0.10
    BayesAutoLearnThresholdSpam=12.00
    DNSAvailable=yes
    MessageRetentionTime=90
    OkLanguages=all
    OkLocales=all
    RejectLevel=50
    ReportSafe=0
    Sensitivity=custom
    SkipRBLChecks=0
    SortSpam=enabled
    Subject=[SPAM]
    SubjectTag=disabled
    TagLevel=5
    UseBayes=1
    status=enabled


To set the values shown above:

Code: [Select]

config setprop spamassassin RejectLevel 50
config setprop spamassassin status enabled

2. Create a custom template fragment for spamassassin
This example will block ".rtf", ".iso" and ".img". 

Code: [Select]

mkdir -p /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/
cd /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/
echo '# 80custom_rules
mimeheader MIME_FAIL   Content-Type =~ /\.(rtf|iso|img)\b/i
describe   MIME_FAIL   Blacklisted file extension detected
score      MIME_FAIL   95' > 80custom_rules

3. Activate

Code: [Select]

signal-event email-update

4. Monitor
Note the score is around the value we specified in our custom rule - 95 in this example (it will be slightly higher or lower depending on the results of the other tests that spamassassin has applied):

Code: [Select]

# tail -f /var/log/qpsmtpd/current |tai64nlocal |grep logterse
2019-05-29 09:12:30.238271500 23921 (deny) logging::logterse: ` 209.85.167.179 mail-oi1-f179.google.com mail-oi1-f179.google.com <mmccarn@myotherdomain.org> <mmccarn@mmsmeserver.tld> spamassassin 901 spam score exceeded threshold Yes, score=95.9 required=5.0 autolearn=disable


If something is misconfigured, all email will be blocked


To revert these changes:

1. Restore spamassassin to its original configuration (you made notes in step 1, right?)
2. Delete the custom template fragment and reconfigure email

Code: [Select]

'rm' /etc/e-smith/templates-custom/etc/mail/spamassassin/local.cf/80custom_rules
signal-event email-update

Note: while working on this my server started blocking all incoming attachments with an error saying "Unable to scan for viruses".  I disabled clamd using config setprop clamd status disabled.  I don't know if this is related to these notes, or to another issue with my server.

[ReetP]

Here are some details on how to block by filetype using spamassassin.

Note to the OP - as per previous comments again this this will ONLY block attachments NAMED with an extension eg rtf|iso|img

Anyone mildly enterprising can just rename the file and it will pass regardless.

Unless a file can be pattern matched I don't think there is a "fast and easy" nor foolproof way of doing this (I don't disagree that it would be nice to be able to do it)

From earlier posts:

Sending iso's as an email-attachment is IMVHO just nonsense

It may well be. It doesn't making blocking them any easier....

Therefore spending time for an investigation in this case is not helpful

https://wiki.contribs.org/Qpsmtpd:exe_filter

Unfortunately this method appears to use the same method as the virus filter - it looks for a MIME signature as illustrated above. It still requires patterns. It may also seriously stress your server with a very large file.

"exe_filter slurps the entire email into memory and uses Email::MIME to do the mime parsing, so it's reasonably memory hungry"

So the point that janet made is you might have to roll up your sleeves and get your hands dirty and do some investigating and monitoring to start with and see if you can see any common file patterns, which is probably the most effective way of blocking attachments.

Some basic file patterns were suggested. You might need to test for more.

Whether or not there are some patterns that cover all eventualities, I don't know, but testing is the only way to find out and that would probably be your best route. From what I can see testing on a few ISOs (confirming what Warren said above)  there doesn’t seem to be much in common so I don't think this is going to work. YMMV.

The simplest thing is, as suggested, just block attachments over a certain size (and again, use something like DL for anything larger). It is what we do here where he have a lot of large artwork files coming and going.

https://wiki.contribs.org/DownloadTicketService

The only issue is the Thunderbird plugin doesn't yet work with the latest Thunderbird 0.60.x, but hopefully will before long.

Personally I wish we could block all attachments, but hey ho. Such is life.