Hi all,
I've been having issues with compromised accounts used to send spam via
authenticated connections to my servers. Don't ask me how those people
lost their passwords, but they did.
I have ratelimiting in place to avoid the worst issues, but some people
and systems really send tons of messages, so the limit is quite
generous. Defining exceptions for specific senders isn't an option,
since it would involve to much maintenance.
Now I'm looking for ideas how to identify issues faster. One of them is
to check for senders causing lots of bounces, which in my experience is
a good indication for bad behavior.
My configuration to count bounces looks like this:
acl_not_smtp = acl_check_local
[...]
acl_check_local:
warn ratelimit = 100 / 60m / per_mail / strict / bounce_$recipients
log_message = bounce rate exceeded: $recipients
Of cource not only bounces are processed by acl_not_smtp, but the only
other reason for locally generated messages should be cronjobs on the
system, which I can safely ignore for the moment. Still, I would like to
have a better identification of bounce messages, but since a check for
"senders = : " didn't work in my lab, I have no idea how to add checks.
Later I check in acl_smtp_rcpt like this:
defer message = $sender_address causing bounces: $sender_rate
authenticated = *
ratelimit = 50 / 60m / per_mail / readonly / bounce_$sender_address
defer message = $sender_address sending at high volume: $sender_rate
authenticated = *
ratelimit = 1000 / 60m / per_rcpt / strict / $sender_address
My worries:
- the identification of bounces in the acl_not_smtp is certainly not perfect
- the limits are just a guess
- the bounce rate will drop again, so the lock-out by
bounce_$sender_address isn't permanent and just slowing things down.
I'll try to catch that via the second limit, which might take longer to
build up, but once it kicks in it should be active as long as the abuse
continues.
Did I miss something obvious? Are there any more things to consider? Any
input would be greatly appreciated.
--
CU,
Patrick.
