URL phishing protection in mailcow

pooh22

I’m using mailcow at home (well on a vps) and when discussing this at work, the question came up if mailcow had a kind of url protection, like microsoft EOP or proofpoint have for example.
When thinking about it, it wouldn’t be that complicated, since everything is on the same system, once the e-mail’s dkim has been verified, it should be entirely OK to rewrite the URLs to something that lets mailcow sit in between the browser and the target site. If the URL turns out to be bad, you could snip snip the link and show some warning instead.
For a home server, this is not realistic to help, but if mailcow would be an option for us at work, this would be a requirement, so either mailcow should do it, or we’d have to get additional “protection” from proofpoint… This complicates the setup.

Obviously having a large customer base like proofpoint has helps to find more bad urls quicker…. I haven’t thought about this part yet.

I guess this is a feature request, of a kind ;-)

esackbauer

Phishing protection is built in into the browsers already.
https://support.mozilla.org/en-US/kb/how-does-phishing-and-malware-protection-work
https://support.google.com/chrome/answer/13844634?hl=en&co=GENIE.Platform%3DDesktop#zippy=%2Cfunktionsweise-von-safe-browsing

pooh22

esackbauer I’m sure the browser protection will help in a lot of cases, but there are a few properties of the phishing protection with URL rewriting in the e-mail that are not covered by that:

User tracking
Early blocking of “bad” URLs

ad 1) I work at a university (not in the central IT) and in the central IT (with an unfortunate corporate mindset) there’s a SOC (security operations centre) which monitors and tracks “bad” stuff going on, like clicking on “bad” links, if they can know about this. The browser features you mentioned do not report to the SOC, but the URL-rewriting in-between has logs which can link a rewritten URL with a user upon use. This is useful if you (as SOC member) want to block an account based on clicking on the wrong URL.

ad 2) If some users notice the “bad” URL and report this, the IT department can block the link before it can do much damage. I’m sure the phishing protection of browsers will not be as quick to block URL, because of the scale and potential false positives. In a single organisation, the risk of false positives vs clicking on phishing links has a completely different priority structure.

Anyway, at the university there’s growing awareness of the risks of using American cloud based solutions and the digital sovereignty voices are gaining ground. Mailcow is definitely on our radar to promote as alternative, and such a URL rewriting tool would be another checkmark on the list of requirements. (Not to mention that proofpoint is also American and very expensive at the scale of a whole university)

esackbauer

I have a Sophos Firewall in front of my mailcow and for users in my home. This will give some additional protection.

pooh22 the IT department can block the link before it can do much damage

if you have a centrally managed Chrome Browser you can do that as well:
https://support.google.com/chrome/a/answer/7532419?hl=en

However there won’t be a 100% solution… This is why in our 40000 employee company we still educate the users and send out test phishing mails.

maiyannah

You can also dip into the rspamd rulesets as it has some rules with 0.00 value for fishy URLs. The reason they are 0.00 value is because they can also have false positives but you can adjust the values to some amount you’re comfortable with.

In addition, make sure you feed any actual risky spam (like phishing or scams) to rspamd’s learning engine so it will better catch them.

D4niel

I’d also say that blocking phishing or other dangerous URLs should be the responsibility of a firewall or a proxy. If you don’t have control over the Internet access for the respective devices, you will face completely different problems.

maiyannah

D4niel I tend to think an ounce of prevention is worth a pound of cure - but, there isn’t just some switch that you flip somewheres that makes a server secure, mail, web, or whatever. It comes with layers of protection, and user education.

pooh22

From my experience there were a few phishing runs where I would have liked it when users would have needed to go through a URL redirect, this would have made two things, that were really hard afterwards, very easy. Getting a feel for how many and which users may have typed their login and password on a malicious site.
Changing the redirect to a warning site, instead of the malicious site is nice to have, but usually the damage is done before this kicks in.

Phishing has been getting better and users have become less wary (or worn down), and it’s not helped by html e-mails and mail clients hiding important information like the exact URL and the exact e-mail addresses, but instead opt for showing more readable human friendly names. And frankly the URL rewrites are not helping the users either, because the whole thing becomes unreadable.

My question originally was if such a thing existed within the mailcow suite, and I guess the answer is no, which is a good answer as well. It just means that if we were to try mailcow as a full blown solution to replace our current mail setup and potentially that of the entire university, we would probably have to get an additional service for the URL rewriting…

esackbauer

pooh22 and I guess the answer is no

If you want to set it up for such a large userbase, maybe a feature request makes sense, as well as asking the guys at servercow.de for support.

CK_beats

As the saying goes: no system is safe.

Mailcow, with all the integrations via fuzzy learning, various blacklists, and virus scanners, is definitely on a par with other systems.
Routing the browser traffic via a proxy with SSL offloading provides additional security.
Then, before that, various block lists that block both incoming and outgoing data traffic to known IPs and URLs make the setup a complete one.

If suspicious URL activities have to be checked and blocked manually, in my opinion it is far too time-consuming and too slow.
A healthy combination of all measures should make a system very secure.

Either way, you are extremely vulnerable to a zero-day attack.