>>>>> 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

Reply via email to