Re: [exim] To prevent spamming from the server

Top Page
Delete this message
Reply to this message
Author: Lena
Date:  
To: exim-users
Subject: Re: [exim] To prevent spamming from the server
> From: Todd Lyons

> > https://github.com/Exim/exim/wiki/BlockCracking
>
> Lena, exim 4.82 contains a new expansion $authenticated_fail_id which
> you might be able to use in your smtp_quit and smtp_not_quit ACL's to
> further refine which connections get used as input to the blocking
> logic.


4.82 has also ${acl{ expansion item. I use it in current version
of the code at the above URL. $authenticated_fail_id contains username only.
Using ${acl{ , I grab password too (in PLAIN and LOGIN authenticators).
So, the current version of my code can distinguish the same wrong password
tried multiple times (benign) from trying multiple passwords
for the same username (cracking attempt).

> I have slightly modified your ACL in this manner:
>
>   warn    condition      = ${if def:authentication_failed}
>           condition      = $authentication_failed
>           condition      = ${if def:authenticated_fail_id}
>           condition      = ${perl{is_using_diff_password}{$acl_c_pwhash}}
>           logwrite       = $smtp_notquit_reason after authentication failed: \
>                              ${sg{$sender_rcvhost}{\N[\n\t]+\N}{\040}}\
>                              $authenticated_fail_id
>           condition      = ${if eq{$smtp_notquit_reason}{connection-lost}}
>           ratelimit      = BRUTEFORCE_LIMIT / BRUTEFORCE_PERIOD /
> strict / per_conn
>           continue       = ${run{SHELL -c "echo $sender_host_address:
>    $tod_full >>BRUTEFORCE_IPS "}}
>           logwrite       = :main,reject: Added $sender_host_address to
> blacklist for bruteforcing passwords

>
> There are actually three changes that are made above to your code:
> 1) condition = ${if def:authenticated_fail_id}
> 2) condition = ${perl{is_using_diff_password}{$acl_c_pwhash}}
> 3) Added "$authenticated_fail_id" to the logwrite commands
> Item #1 handles a common false-positive case we have, where (all of) a
> small office with 5 or 6 machines behind a simple Linksys/DLink/Netger
> router gets blocked when one device tries to use our mail servers as a
> relay without a username defined.


Authentication with empty username?
Or without authentication?

Did you encounter athentication with empty username in practice?
If without authentication then the MUA gets "5xx relaying denied",
and the code isn't triggered.
I'd think that if username isn't defined then the MUA shouldn't try
to authenticate.

> Item #2 handles a second common false-postive case we have where (all
> of) the office is blocked if one person's computer has a password
> wrong on only 1 mailbox. It is a collection of perl subs which
> compares a hash of the password if they are using PLAIN authentication
> (doesn't work for LOGIN auth since the password is not available in
> $smtp_command at the time this is checked). The bruteforce check is
> allowed to continue only if the password is different from previous
> passwords submitted. If LOGIN is used, the perl sub can't tell if if
> it's different and also lets the bruteforce test continue.


Current version of my code does all that with both PLAIN and LOGIN.

Lena