Postfix and compromised accounts

Question

First of all, sorry for my English.

I think it's very common to set the permit_mynetworks and permit_sasl_authenticated restrictions on first positions of the smtpd_recipient_restriction list, but, if an account is compromised (a virus uses stolen credentials -from Outlook configuration files, for example- to send SPAM), and authenticated clients can send email without further restriction, your last opportunity is your milters correctly reject SPAM messages from compromised accounts; but, isn't it less efficient?

I think postfix is more efficient rejecting SPAM since it uses information from the SMTP protocol and so on, but milters must scan the contents of the messages to detect if a mail is SPAM or not.

However, all of my clients uses TLS to connect to my server. Can viruses/spammers use encrypted connections to send email (provided they stole a password)? I don't think so since spammers try to delivery messages as fastest as possible, and encrypted connections are too slow for these purposes.

If it's the case, I've no problems to permit authenticated clients to send mail, but I would like to be sure about it.

Answer 1

Based on our discussion in the comments I can think of another way to approach the problem. This used to happen to me all the time in the hosting business- you have to let anybody with basically any client connect to your smtp server, and if their workstation is compromised, they can do what they want.

Again, my approach was defense in depth, with a little offense on the customer service side (ie, tell them if you cause us a spam problem again, we're dropping you).

1)Use Postfix's Rate Controls (you can google for more info- very extensive) This is good for saving cpu cycles and memory on your server in the event a user starts sending spam. This will slow down the damage and not drown a destination host if you have a problem- so it helps you be a polite citizen as well as protect yourself and other users.

local_destination_concurrency_limit = 2
default_destination_concurrency_limit = 10

2)Rate limit based on SMTP user

Postfix has the ability to use policy addons such as this one designed to do exactly what you want

http://wiki.policyd.org/

http://www.simonecaruso.com/limit-sender-rate-in-postfix/

You can be as aggressive as you want with these policies- including disabling the user's account completely so they can't log in until they call you.

3)Don't forget about viruses

Configure postfix to scan outbound mail with http://amavis.sourceforge.net/

I hope this was an acceptable answer. Let me know if you have other questions.

Cheers!

Answer 2

... if an account is compromised (a virus uses stolen credentials -from Outlook configuration files, for example- to send SPAM), and authenticated clients can send email without further restriction, your last opportunity is your milters correctly reject SPAM messages from compromised accounts; but, isn't it less efficient?

I think postfix is more efficient rejecting SPAM since it uses information from the SMTP protocol and so on, but milters must scan the contents of the messages to detect if a mail is SPAM or not.

As @Binary said in his posts, it's all about multi layer defense. At the first line, postfix have lightweight checks such as postscreen and stmpd_*_restriction (including permit_mynetworks and permit_sasl_authenticated). This defense will be efficient and save many resources.

After lightweight checks, postfix will pass the spam checking to external content_filter (before or after queue). Of course, it will consume more resources but this checks only invoke for (little percent of) emails that passed first line of defense. The deep of defense layer will be determined by your resources.

However, all of my clients uses TLS to connect to my server. Can viruses/spammers use encrypted connections to send email (provided they stole a password)? I don't think so since spammers try to delivery messages as fastest as possible, and encrypted connections are too slow for these purposes.

Of course TLS/encrypted connection is slower than unencrypted one. But the technique like TLS cache has improved performance of SSL handshake for long time. And of course, the spammer/infected client has little care about it. They just need an attack vector to launch the spam/virus email via your server.

Answer 3

I agree that using outbound spam filtering as a front line defense against sending spam is inefficient, but it is still important. The alternative is that spam gets through and lands you on a blacklist, then your whole domain is in trouble. So, I think a defense in depth approach is really the only approach here, including frequent password rotations, 2FA, etc. The outbound spam filter is just a layer of that onion- and its an important one. Think of it as the last line of defense, not the first one. Also, you should run this on separate hardware from your mail cluster.

The particular implementation (milters, vs everything else out there) is less important than the overall efficiency of your system. In the layered approach you can determine the effectiveness of each step by measuring the spam that gets through in relation to total email, thus establishing a quantitative way to measure efficiency- or effectiveness. Hopefully by the time outbound spam gets to milter, there will be so little of it that it won't hurt performance.

To answer your last question: I see no reason why any client should not use TLS in 2014. It is another layer in a solid security process. New spam techniques happen every day, and using TLS just protects you incrementally better than no TLS/other encryption.