Re: [exim] 419 spammer - Help with AUTH ACL

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] 419 spammer - Help with AUTH ACL
Thomas kinghorn wrote:
> Good afternoon all.
>
> Please forgive me if I am asking a stupid question.
>
> My server is currently being used, via a compromised account, to send junk
> to various freemail accounts.
>
> An extract of the message looks like:
>
> 208P Received: from [125.76.228.201] (helo=User)
>         by smtp01.gennex.co.za with esmtpa (Exim 4.69)
>         id 1MB4KF-000Nhu-W3 by authid <smith1@???> with
> login_authenticator; Mon, 01 Jun 2009 12:01:36 +0200
> 041R Reply-To: <songlile.private00@???>
> 056F From: "Mr. Song Lile"<songlile.private012@???>
> 228  Subject: Good Day,I am LILE, I work with the Hangs bank,I need your
> assistance in effecting a transaction worth $19.5m I intend to give 30% of
> the total funds as compensation for your assistance. Full names,Private
> phone number

>
> If I were to create a list of compromised accounts (until we can get the
> users to use decent passwords), how would I go about this
> as everything I have tried thus far has failed.


It should not be as easy for an attack to suceed as you claim - your
authentication may have holes in it.

Rather than parse a 'new' list, it is *FAR* easier to do a forced change to the
compromised user's password....

ELSE set a flag that it is invalid-until-changed for smtp (optionally POP / IMAP).

As authentication would fail at login, no new logic would be required.

Go do that NOW before your entire user community finds themselves on a
blacklisted server......


..waiting ...



Presume you have gone off and done so by now....

Now then ...

Show us what you have for:

daemon_smtp_ports

tls_advertise_hosts

auth_advertise_hosts


The entirely of:


- Your acl's as 'mapped' from:

acl_smtp_connect =

acl_smtp_rcpt    =


acl_smtp_auth    = (if used. ELSE your authenticator acl's)


Any clauses elsewhere that include an authenticated conditional.

>
> I was thinking of something along these lines:
>
> # ACL MACRO
>
> # authenticated id {$authenticated_id}
> ACL_C_AUTHID          = acl_c_authid

>
>
> # Connect phase #
> acl_check_connect:
>
> #Set ACL for AUTHID
> warn
> condition = ${if
> match{$authenticated_id}{lsearch;/usr/local/etc/exim/reject/rejected_authid}}
> set ACL_C_AUTHID = Yes
>
>
> # Compromised Accounts
>    deny
>      message          = '$authenticated_sender' classified as compromised -
> Please change your account password
>      condition          = ${if eq {$ACL_C_AUTHID}{Yes}}
>      logwrite            = :main: Compromised Account: $authenticated_sender

>
> The list rejected_authid would contains the email addresses of the
> compromised accounts.
>
> Many thanks in advance for your assistance.
>
> regards
>
> Tom
> (exim wannabe)



'going forward' ....

- Neither Exim, nor whatever you are using for POP/IMAP absolutely require UID
be in the form of a <$local_part@$domain>.

Clearly, so doing 'publishes' HALF the information required for login as a 'free
gift' to the world at large.

All that remains is finding, guessing, or brute-forcing the PWD.

So....

- Decouple the login UID from the email address or anything ELSE published.

- Make BOTH UID and PWD *LONGER* than 16 characters. Even a 17 or 18 character
minimum is beyond what most attackers will try.

- Make sure to handle all that *inside* an SSL or TLS session, on port 587, not
25, and DO NOT allow fallback to unencrypted.

- 'system' or 'shell' login UID and email addresses do not need to be related,
and IMNSHO, should NEVER be. 'Virtualize' and keep those worlds *separate*.

If a compromised mail account is bad news, a compromised shell login is doubly so.


Bill