>>>>> On January 2, 2025 Bill Cole via Postfix-users >>>>> <postfix-users@postfix.org> wrote:
> On 2025-01-01 at 20:13:35 UTC-0500 (Wed, 01 Jan 2025 20:13:35 -0500) > Greg Klanderman via Postfix-users <g...@klanderman.net> is rumored to > have said: >> I just noticed a single unknown host is connecting ~1000x per day, >> with fingerprint 'ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4' so >> that's my first target. > Failed auth like that is a good basis for targeting, provided you > are 100% certain that it isn't a real user with a typo'd > password. Thank you for your response, Bill. Yes, I'm the only actual user (delivered locally) and my password wouldn't be typed. Failed auth sounds like a good place to start, and probably just for unkown hosts (which I wouldn't allow mail from anyway, due to reject_unknown_client_hostname). Over the last month all failed auth attempts were from unknown hosts with the exception of 2 from a single host of the form vps-xxxx.vps.ovh.net, and one from each of 6 hosts of the form ec2-xxxxx.compute-1.amazonaws.com. I've additionally got a few dozen connections from ec2-XXXX.<geography>.compute.amazonaws.com sending mostly unknown commands or nothing at all (commands=0/0). A few did 'ehlo=2 starttls=1 commands=3', and one additionally gave me a bogus from address at gmail and failed a rcpt with a bogus address at one of my domains. Seems all the actual good mail from amazon comes via *.smtp-out.amazonses.com so if fail2ban blocked a host under amazonaws it wouldn't be terrible, but the auth failure traffic from known hosts is so small it would never take action, and it's safer to start with unknown hosts only and then continue to monitor the situation. Is there any good reason to send ehlo multiple times? > Beyond that it may be perilous to interpret command > failures or non-delivering sessions as suspicious. For example, a > non-sending session that just does ehlo/starttls/ehlo/quit may only > be noticing a message size limit in the EHLO reply and giving up on > an oversize message, i.e. doing the right thing. Right, I plan to first implement some additions to my postfix logwatch script (already locally enhanced) to get a better handle on the situation. What do you think about 'unknown=0/*', is that fairly safe to target? How about 'commands=0/0'? A bit of hand analysis of the last month's logs seems to indicate that ~10 tld's representing questionable scanners, plus ~4 tld's which are cloud/vps/compute providers' hosts, account for effectively all errors and non-delivering sessions. No hosts matching these patterns actually delivered mail (whether spam or not, but I'm pretty aggressive about spam). Interestingly, I seem not to have been connected to from an IPv6 host, at least in the last month.. cheers, Greg _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org