Stop spammers at the gate: Don’t blindly trust SASL authenticated connections
Recently a user’s email password was cracked. Not long after, she started receiving hundreds of bounce messages. My first thought was that these messages were back scatter, produced when spammers insert any random sending server address. So bounce messages are misdirected to that unsuspecting server. But the messages kept coming. So I started thinking she had a virus or malware on her computer. Even though we are 100% Mac here, it can happen. So I set about scanning her computer and did find some suspect bits. But the problem continued.
A deeper investigation into the mail logs revealed that these messages were being sent by this user, but not from within our network! By gum, her password had been cracked and a spammer was connecting to our server, authenticating as this user, and being allowed to relay whatever they liked. Ugh! One of my worst system administrator nightmares.
So why did this happen? It happened because I chose to trust SMTP connections from SASL authenticated users over any other precautions. This was fine for 10+ years, so… why would I have thought otherwise? Until now.
We run postfix, which is a fantastic and well regarded email system. This is what I had for smtpd_client_restrictions:
[code]
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unknown_reverse_client_hostname
check_client_access cidr:/etc/postfix/cidr_table_access.cidr
check_client_access hash:/etc/postfix/access
reject_rbl_client zen.spamhaus.org=127.0.0.10
reject_rbl_client zen.spamhaus.org=127.0.0.11
reject_rbl_client zen.spamhaus.org
reject_rbl_client bl.spamcop.net
reject_unauth_pipelining
permit
[/code]
That looks pretty good, right? But in light of recent events, not so much if someone’s password gets cracked…
So I changed this parameter and moved the reject_rbl_client entries before permit_sasl_authenticated:
[code]
smtpd_client_restrictions = permit_mynetworks
reject_rbl_client zen.spamhaus.org=127.0.0.10
reject_rbl_client zen.spamhaus.org=127.0.0.11
reject_rbl_client zen.spamhaus.org
reject_rbl_client bl.spamcop.net
permit_sasl_authenticated
reject_unknown_reverse_client_hostname
check_client_access cidr:/etc/postfix/cidr_table_access.cidr
check_client_access hash:/etc/postfix/access
reject_unauth_pipelining
permit
[/code]
Because items in this list are applied in order, with the first match winning, this change had an immediate positive impact on my server’s willingness to accept email from known spammers’ servers. I suppose one could argue that permit_sasl_authenticated could be moved even lower in this list, but I think its a game of diminishing returns at this point.
Perhaps this is an obvious configuration change, but 10+ years ago, to me at least, it wasn’t. So I post this for the benefit of anyone that might find it useful.