[SOLVED] Recognition of file types in encrypted archives does not work for me

[justthenextadmin]

Hello,

I'm installing, configuring and testing Proxmox Mailgateway for the first time.
Great product!

Now I have a problem with the application type and file extension recognition in encrypted archives.
Generally, the recognition works if the file does not arrive in an archive or in an unencrypted archive.

However, as soon as the archive is encrypted, recognition no longer works.

I have read a bit on the forum and apparently it should work even if an archive is encrypted.

But it doesn't work for me.


Logs from the unencrypted archive (works):

2024-07-23T15:59:31.066948+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: new mail message-id=<a0b08b4c-742c-43b2-a6e9-a04f0bc8f109@gmx.de>#012
2024-07-23T15:59:31.204680+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: found archive '123-1.zip' (application/zip)
2024-07-23T15:59:31.249923+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: unpack archive '123-1.zip' done (44 ms)
2024-07-23T15:59:36.385876+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: SA score=0/5 time=5.119 bayes=undefined autolearn=disabled hits=DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),DMARC_PASS(-0.1),FREEMAIL_FROM(0.001),HTML_MESSAGE(0.001),RCVD_IN_MSPIKE_H3(0.001),RCVD_IN_MSPIKE_WL(0.001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),URIBL_DBL_BLOCKED_OPENDNS(0.001)
2024-07-23T15:59:36.405774+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: moved mail for <xxx@yyy.de> to attachment quarantine - 141565669FB74861B3A (rule: Quarantine Office Files)
2024-07-23T15:59:36.407124+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: removed attachment 5 ('123.zip', rule: Quarantine Office Files)
2024-07-23T15:59:36.408001+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: added disclaimer (rule: Quarantine Office Files)
2024-07-23T15:59:36.408401+02:00 mx0 pmg-smtp-filter[10971]: 141561669FB7430DC57: added disclaimer (rule: Quarantine Office Files)

Logs from the encrypted archive (does not work):

2024-07-23T16:05:53.676551+02:00 mx0 pmg-smtp-filter[10970]: 141574669FB8C1A1F9D: new mail message-id=<fe8525af-6df0-47a6-b273-2f4dbccecedb@gmx.de>#012
2024-07-23T16:05:53.727075+02:00 mx0 pmg-smtp-filter[10970]: 141574669FB8C1A1F9D: found archive '123123-1.zip' (application/zip)
2024-07-23T16:05:53.771588+02:00 mx0 pmg-smtp-filter[10970]: 141574669FB8C1A1F9D: unpack failed - child '15158' failed: 512
2024-07-23T16:05:53.772017+02:00 mx0 pmg-smtp-filter[10970]: 141574669FB8C1A1F9D: unpack archive '123123-1.zip' done (44 ms)
2024-07-23T16:05:58.929811+02:00 mx0 pmg-smtp-filter[10970]: 141574669FB8C1A1F9D: SA score=0/5 time=5.142 bayes=undefined autolearn=disabled hits=DKIM_SIGNED(0.1),DKIM_VALID(-0.1),DKIM_VALID_AU(-0.1),DKIM_VALID_EF(-0.1),DMARC_PASS(-0.1),FREEMAIL_FROM(0.001),HTML_MESSAGE(0.001),RCVD_IN_MSPIKE_H3(0.001),RCVD_IN_MSPIKE_WL(0.001),RCVD_IN_VALIDITY_CERTIFIED_BLOCKED(0.001),RCVD_IN_VALIDITY_RPBL_BLOCKED(0.001),RCVD_IN_VALIDITY_SAFE_BLOCKED(0.001),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),URIBL_BLOCKED(0.001),URIBL_DBL_BLOCKED_OPENDNS(0.001),URI_HEX(0.1)

The archives 123.zip (unencrypted) and 123123.zip (encrypted) were created with 7zip v23.01 in ZIP format.

Does anyone here have an idea where the problem lies or what I am doing wrong?


Many thanks in advance and best regards

 

[justthenextadmin]

Hello again,

I've now managed to block encrypted archives completely (with the block option in 'Virus Detection' and a corresponding 'Heuristic Score' in 'Spam Detection' Options).

This means that encrypted archives are not delivered at all.

Nevertheless, it is strange why an analysis of the files in the encrypted archive did not work, especially as you can already see the files in the archive, even without the corresponding password.

However, in combination with changing the blocking of encrypted archives but not encrypted PDFs, I am coping well in my case.
(see here)

Thanks anyway.

 

[sw-omit]

Just a guess, but you might be able to see the NAMES of the files, but you could rename a .exe as .txt, but it would still be an .exe, so most checks run on the start of the file, which in fact is encrypted, so it can't be checked.
Also opening (which is reading the zip-header) and extracting (which is what it shows in the logs to be doing) are different things and the later does need a password.
On top of that, quite a few archive-methods allow you to choose if they want to encrypt the filename as well, so in that case you wouldn't even be able to check filenames without a password.

 

[justthenextadmin]

Just a guess, but you might be able to see the NAMES of the files, but you could rename a .exe as .txt, but it would still be an .exe, so most checks run on the start of the file, which in fact is encrypted, so it can't be checked.
Also opening (which is reading the zip-header) and extracting (which is what it shows in the logs to be doing) are different things and the later does need a password.
On top of that, quite a few archive-methods allow you to choose if they want to encrypt the filename as well, so in that case you wouldn't even be able to check filenames without a password.

All valid points, but I have configured the check not only for file types, but also for recognizing the file extensions in the file name (even if this is of course only conditionally meaningful for a file type, as you already write).
Here I would have at least expected that the files in an archive in which the contained file list is not encrypted, as in my example, would also apply the rule here.

But anyway, I'm happy with my solution so far.
It would be even better to differentiate this check as a rule for certain people, but that only works in a roundabout way with some side effects, as I read in another topic.
That's why I'm now implementing it as mentioned above and that's that.

Thank you for your efforts and the explanations.

Best regards