On Tue, Dec 06, 2016 at 08:59:56AM +0100, Julian Kippels wrote: > Am Mon, 5 Dec 2016 20:52:21 -0500 > schrieb Alex <mysqlstud...@gmail.com>: > > > I have a postfix-3.0.5 system with a few hundred users. They > > have access to submission, webmail, and dovecot to send and > > receive mail. > > > > On occasion, user's local desktop are compromised, and with it > > their account on this system. This leads to their local desktop > > using the submission service to send hundreds or thousands of > > spam emails through this compromised account.
As another poster pointed out, sometimes the credentials have been shared with a botnet, and the spam can come from around the world. It's not only a matter of a desktop machine compromise. Sometimes mobile devices (phones, tablets) are involved. And sometimes the software holds secure but social engineering prevails! A user might be fooled into providing his/her email credentials in the wrong place. > > They're only stopped after the user receives a ton of bounce > > messages, or we happen to see it somehow while watching logs. > > > > What mechanisms are available to say, control the number of > > messages sent per day or otherwise be made aware of a pattern > > of messages being sent by an account that could be indicative > > of account compromise? There were numerous suggestions upthread which are of varying usefulness, depending on site-specific requirements, but Julian's answer here is the best overall for generic use, of what I have seen before starting this post. But it's not complete and can stand some improvement. :) > I use a policy deamon that registers every mail that is sent by > our servers. The metadata is stored in a SQL Database. Every two > minutes a cronjob is run which checks the metadata for which > sasl_sender has send how many mails. If a sasl_sender surpasses > a certain threshold the cronjob automatically blocks this user > in our LDAP so that he can't submit any more mails. First, I don't understand the need for the cron job. Just let the policy service keep track of the number of mails sent per SASL user and reject (or quarantine, via HOLD action, if that is better for your site) when the quota is reached. Likewise, there is no need to have the interaction with LDAP. The policy daemon should be able to do this all natively. What I have seen of these things suggests that the malware goes like a fire hose. They know they have a limited time before your site gets listed as a spam source, so they launch as much as they can as long as they can. A human sender is generally more like a squirt gun than like a fire hose. We can't spew unless we use software to do it for us. This generally is easy to detect with a policy service. If you look around you can probably find recipes for cbpolicyd and postfwd. Now, as for what Julian's reply was missing: first, maintain strict separation of user submission from MX (inbound, port 25) mail. Perhaps you already do this. The best practice recommendation is that SASL AUTH should only be offered on the submission service, by means of an " -o smtpd_sasl_auth_enable=yes" in master.cf. If you have legacy users you don't control, submitting on port 25, use a separate IP address for that. And the hostname given to your users to set up their MUAs must not be one of the published MX names. Next, use content filtering on submission. You can't use the same kind of tests that you use on MX mail, which is why the above separation is mentioned. But URIBL lookups are extremely effective against these. Another potential improvement to the policy daemon is as Sebastian suggested upthread: geoip lookups. If you're seeing connections originate from widely separate locations in the same time period, you're pretty certain that the account is compromised. I'm not an advocate of geoip in general, but it can be useful in this context. These are things anyone can safely use, whilst many of the other ideas might not be useful for some sites. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
