> On Dec 18, 2015, at 12:35 PM, Noel Jones <njo...@megan.vbhcs.org> wrote: > > On 12/17/2015 4:16 PM, Ben Greenfield wrote: >> I reset rgarrity’s password and things have been quiet. >> >> In my effort to understand what was happening let me describe what I think >> happened. >> >> Someone got ahold of rgarrity’s password. > > Yes. (or rgarrity went rogue) > >> With that password they were able to craft emails with forged headers that >> appeared to spawn new messages to different recipients when being processed. > > With password in hand, spammer was able to send out payload using > different MAIL FROM sender names since you don't restrict this. No > magic spawning going on, just "normal" email traffic from an > unauthorized/malicious source.
Yes, I realized alter that all they needed was username password and they can send whatever they want. > > Preventive actions to consider: > > - consider using a rate limiter such as postfwd to slow down and > notify the admin if a user sends an unusual amount of mail. This is > a pretty standard thing to do these days, and doesn't usually cause > disruption as long as you set the limits way higher (eg. 10x) than > any normal traffic. This probably would have slowed this attack and > alerted you sooner. I will look into this. > - consider using > http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch > to reject messages where the MAIL FROM address doesn't match the > SASL username. This won't prevent the user/spammer from using a > different From: display header name, but does make debugging easier. > This would have stopped this attack, or (more likely?) made the > attacker change tactics. I would consider this option but it seems if you have any virtual domains one also has to prepare a mapping file between virtual domain addresses and actual addresses. > - consider using a dnsbl that rejects known spamming IPs before > permit_sasl_authenticated, such as sbl.spamhaus.org or > cbl.abuseat.org. Careful with this one; it's impolite to reject > real users' email and it's very possible a real user will get > infected and listed, generating a support call to you. In > particular, do not use a dnsbl that lists all home/dynamic/dialup IP > addresses. The IP you reported is listed in both cbl and sbl and > would be rejected (listed now, maybe it wasn't then). > We have people that travel in europe all the time. If they tried to use an internet cafe for access they would be blocked by placing the blacklist in front of the permit_sasl_authenticated if the cafe ip was on the blacklist. That is what I would need to watch-out for? Thanks for the suggestions. Ben > > > -- Noel Jones
