Mail on Such geek. Wow.

Blocking bad extensions and extortion with iRedMail

Mon, 12 Apr 2021 00:00:00 +1200

Turns out this is my third Amavis article. I guess it’s just one of those systems.

Heads up, if you’re trying to do this, make sure you also read my other article about the “banned_files_lover” thing.

Today I’m on a mission to:

Drop all incoming Office ‘97 files (they’re predominantly malicious these days)
Drop all incoming Macro-enabled Office 2007+ files (there aren’t legitimate reasons to receive these in my scenario)
Drop any emails containing a .onion address
Drop any emails containing a bitcoin wallet

Dropping Attachments

The attachment block is easily handled by Amavis. In iRedMail on Debian, the configuration file is found at /etc/amavis/conf.d/50-user. Open your config file, and scroll down to the section where the $banned_filename_re variable is set. Insert the following line:

 qr'.\.(doc|dot|docm|docb|xls|xlm|xlt|xlsm|xlsb|
 xla|xlam|ppt|pps|pptm|potm|ppam|ppsm|sldm)$'i, # Office '97-2003 and Macro-enabled files
 qr'.\.(adn|accdb|accdr|accdt|accda|mdw|accde|mam|maq|mar|mat|
 maf|laccdb|ade|adp|mdb|cdb|mda|mdn|mdt|mdf|mde|ldb)$'i, # Microsoft Access files
 qr'^\.pub$', # Microsoft Publisher files

That will block all core Office ‘97-2003 files, as well as all Macro-enabled Office 2007-365 files.

By default, this will silently reject mails containing these attachments. If you want senders to receive a bounce message, search for the $final_banned_destiny variable and make sure it’s set to D_BOUNCE.

Dropping .onion and BTC

This part happens in Postfix, and it’s more-super-easy than the last bit. To configure Postfix’s body checks, edit /etc/postfix/body_checks.pcre. I simply added the following:

/(\w+\.onion)/ REJECT This mail server does not accept references to .onion addresses (${1})
/(\b(bc1|[13])[a-zA-HJ-NP-Z0-9]{25,39})/ DISCARD Bitcoin wallet detected (${1})

I used the REJECT directive for testing, but to be honest I don’t want to send bounces back to these people, so I changed to DISCARD after it was working. You can see the difference above.

The text after the REJECT directive is returned to the sender, and the text after the DISCARD directive is logged. The variable ${1} contains the detected string, and is appended to the response message.

That’s the end! Safety. Yes.

Acknowledgements

Thanks to Brad and Hamish for this post - Brad for the regex, Hamish for the idea, and both of them for the review!

iRedMail, SpamAssassin, and Lynis

Mon, 02 Nov 2020 00:00:00 +1300

I really like iRedMail, and I also really like Lynis.

However, they don’t exactly like each other… or, more accurately, some of Lynis’ recommendations can cause a couple iRedMail components to fail. Today we’re talking about SpamAsassin.

One of the suggestions from Lynis is to turn off the ’execute’ bit on compilers for users who aren’t either the owner or in the owner group (the ‘other’ execute bit). For example:

:::bash
root@server:/# chmod o-x /usr/bin/as
root@server:/# chmod o-x /usr/bin/gcc

Easy peasy! But once you do this, you might start getting the following in your daily iRedMail Cron reports:

:::text
/etc/cron.daily/spamassassin:
/bin/sh: 1: x86_64-linux-gnu-gcc: Permission denied
make: *** [Makefile:346: body_0.o] Error 126
command 'make PREFIX=/tmp/.spamassassin23046Zmmrr9tmp/ignored INSTALLSITEARCH=/var/lib/spamassassin/compiled/5.028/3.004002 >>/tmp/.spamassassin23046Zmmrr9tmp/log' failed: exit 2

There are probably a bunch of ways to fix this. My way, I’m sure, is not the best way… however it was quick and easy, and it worked.

:::bash
root@server:/# chgrp debian-spamd /usr/bin/as
root@server:/# chgrp debian-spamd /usr/bin/gcc
root@server:/# runuser -l debian-spamd -c sa-compile

Look ma, no more errors!

This solution really only works for me because debian-spamd is the only non-root user that calls these compilers. If I had another user which needed to call them, I’d have to come up with a better fix. But for a standalone iRedMail server, this does the trick!

iRedMail: Daily user unknown entries from backup_sogo.sh

Sun, 01 Nov 2020 00:00:00 +1300

If you’ve been running iRedMail for a while, eventually you’ll probably start seeing ‘user unknown’ events in your daily logs:

:::text
* Backup all users' data under /var/vmail/backup/sogo/2020/11/01
<0x0x5574a64c36b0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds
<0x0x5574a64c36b0[SOGoCache]> Using host(s) '127.0.0.1' as server(s)
2020-11-01 09:29:12.784 sogo-tool[29749:29749] user 'abdulm' unknown
2020-11-01 09:29:12.786 sogo-tool[29749:29749] user 'bent' unknown
2020-11-01 09:29:12.786 sogo-tool[29749:29749] user 'brettr' unknown
2020-11-01 09:29:12.786 sogo-tool[29749:29749] user 'catalinar' unknown
2020-11-01 09:29:12.787 sogo-tool[29749:29749] user 'clinth' unknown
2020-11-01 09:29:12.787 sogo-tool[29749:29749] user 'danield' unknown
2020-11-01 09:29:12.787 sogo-tool[29749:29749] user 'dannyn' unknown
2020-11-01 09:29:12.788 sogo-tool[29749:29749] user 'darcyk' unknown
2020-11-01 09:29:12.788 sogo-tool[29749:29749] user 'davidl' unknown
* Compress backup files.

This is because removal of an iRedMail user doesn’t remove the corresponding SOGo user data. You can take care of this with sogo-tool:

:::bash
root@server:/# sogo-tool remove abdulm@<domain.xyz> bent@<domain.xyz> brettr@<domain.xyz>

… etc. Once you’re done, run the backup again to make sure you’ve got them all:

:::bash
root@server:/# /bin/bash /var/vmail/backup/backup_sogo.sh
* Backup all users data under /var/vmail/backup/sogo/2020/11/01
<0x0x563fd0e2b6b0[SOGoCache]> Cache cleanup interval set every 300.000000 seconds
<0x0x563fd0e2b6b0[SOGoCache]> Using host(s) '127.0.0.1' as server(s)
* Compress backup files.

Zentyal 6.0 to 6.1 upgrade getting stuck

Tue, 17 Dec 2019 00:00:00 +1300

So I faced a little challenge with a Zentyal server the other day. I was upgrading from ye olde 6.0 to 6.1, when everything just stopped. I let it sit in the corner for about an hour or so, but it never picked up the thread. All the services were still live, so I logged in to have a look.

(Note, my DNS server is named RIMU; yours may be something else!)

Running ps aux, I discovered this line:

:::bash
sh -c /usr/bin/sudo -p sudo: /var/lib/zentyal/tmp/x2M7gkZVvm.cmd 2> /var/lib/zentyal/tmp/stderr

So, I had a quick look at the contents of that stderr file:

:::bash
# cat /var/lib/zentyal/tmp/stderr 
Password has expired
dns-RIMU@ad.ericlight.com's Password:

And what does that temp .cmd file contain?

:::bash
# cat /var/lib/zentyal/tmp/x2M7gkZVvm.cmd 
kinit -k -t /var/lib/samba/private/dns.keytab dns-RIMU

Running that kinit command indeed prompts for a password reset, but the interesting thing is that samba-tool shows me this password shouldn’t expire:

:::bash
# pdbedit -u dns-RIMU -v | grep change
Password can change: Wed, 31 Oct 2018 21:47:30 NZDT
Password must change: never

… riiiiiiight, that’s a bit interesting. And yet I’m still being prompted to set a new password. I used samba-tool to remind samba that this password shouldn’t expire:

:::bash
# samba-tool user setexpiry dns-RIMU --noexpiry
Expiry for user 'dns-RIMU' disabled.

And now…

:::bash
# pdbedit -u dns-RIMU -v | grep -i change
Password can change: Wed, 31 Oct 2018 21:47:30 NZDT
Password must change: Tue, 19 Jan 2038 16:14:07 NZDT

Now I can run kinit against dns-RIMU perfectly fine, and indeed the Zentyal upgrade succeeded!

Respecting Amavis' "Banned Extensions" setting

Sun, 13 Aug 2017 00:00:00 +1200

I’ve been dabbling a little bit with iRedMail, mostly just to have a play with a mail server, but also to see what’s involved in mail security. iRedMail is a package that pulls together Postfix as an MTA, Dovecot as a POP3 & IMAP server, SOGo for ActiveSync, Roundcube for Webmail, SpamAssassin for spam protection, and ClamAV for virus scanning.

Okay I have no idea why I have to write this, but apparently it’s a thing.

Amavis has a list of banned file extensions. In Debian, they live in /etc/amavis/conf.d/20-debian_defaults, and /etc/amavis/conf.d/50-user, and are set in the $banned_filename_re variable. THIS MAKES PERFECT SENSE.

But of course, there’s always something that doesn’t make sense, and that is the fact that there is a SQL backend (at least in the environment created by iRedMail), and settings in here take precedence over the Amavis config files somehow.

And even more bizarrely, there exists in this SQL environment, a policy setting entitled “banned_files_lover”, which was set to “Y”. I shit you not. My only hope is that this only defaults to “Y” for postmaster.

To fix this, you need to hop into the database, and update the appropriate column in the policy table:

$ mariadb
MariaDB [none]> \u amavis
MariaDB [amavisd]> update policy set banned_files_lover="N";

And now, Amavis will obey your file extension filters!

Thankfully, I found this information at http://www.iredmail.org/forum/topic13147-iredmail-support-amavisd-passed-but-setup-at-ddiscard.html – I never would have found it otherwise!

Making Amavis work with ESET Antivirus

Sat, 12 Aug 2017 00:00:00 +1200

But of course, ClamAV has shown disappointing performance, and it would be really nice to use something more… commercially suitable.

To tie together mail receipt and scanning, iRedMail uses Amavis (strictly speaking, ‘amavisd-new’). Amavis uses ClamAV by default, but it comes with a bunch of configuration blocks to bring together other antivirus applications.

But although amavisd-new is stable and still maintained, some parts of it are really old. In particular, many of these av-scanner config blocks are… uhh… “deprecated”. There’s one particular entry for ESET that is dated 2002 - things have changed a lot in the last fifteen years. *shudder*

So, with the help of some documentation, I managed to piece together a code block that works:

['ESET File Security for Linux',
 ['/opt/eset/esets/sbin/esets_scan','esets_scan'],
 '--subdir --unsafe --unwanted --clean-mode=strict {}',
 [0,10,100],[1,50],
 qr/threat="([^"]+)"/m
],

That would be the end of the story, except I also had to hunt around to find out the right place to put my beautiful codeblock into. It turns out that Debian’s Amavis config structure is quite different to the CentOS config that is most-frequently mentioned in the iRedMail forums. I spent a lot of time playing with /etc/amavis/conf.d/15-av_scanners, and nothing seemed to work. Eventually I found out that Debian features a /etc/amavis/conf.d/50-users file that overwrites the settings from 15-av_scanners. Finally I had progress!

Somewhere around line 154 in /etc/amavis/conf.d/50-users, you’ll find an @av_scanners codeblock. I deleted the ClamAV section in there, and replaced it with the ESET codeblock above. I left the ClamAV settings in the @av_scanners_backup section, because Amavis will fall back to that if ESET fails.

That seems to be all! At least, it works with the EICAR anti-malware test file.