Re: [exim] restricting access to AUTH check based on user's …

Inizio della pagina
Delete this message
Reply to this message
Autore: Dave Lugo
Data:  
To: exim-users
Oggetto: Re: [exim] restricting access to AUTH check based on user's IP
On Fri, 22 Apr 2005, Fred Viles wrote:
>
> If by username, you mean the username part of the AUTH credentials,
> sure. If by username you mean the local_part of the sender address
> (which isn't know until MAIL FROM), of course not.
>


Yes, the former.

> |...
> | My more
> | recent reading of spec.txt suggests that acl_smtp_auth (or the
> | authenticator itself) is likely the correct place to do what I'd
> | like.
>
> The authenticator itself is the only spot, if you want the
> authentication to fail. The credentials are not available in the
> acl_smtp_auth ACL - it runs before the credentials have even been
> sent in most cases.
>
> You want to get creative in the expansion of server_secret in your
> CRAM-MD5 authenticator, and server_condidtion in your PLAIN/LOGIN
> authenticators. At that point the username credential is available
> in $1 or $2, and you can use it in a ${if to see if you want to
> accept it from the client host, and fail the expansion if not.
>



Thanks very much for the hints. This is what I've ended up with (for
PLAIN at least; I haven't done the others yet):


CFG_DIR = /var/exim/userprefs
AUTH_DOM = ${extract{2}{@}{$2}}
AUTH_LOC = ${extract{1}{@}{$2}}


plain:
    driver = plaintext
    public_name = PLAIN
    server_condition = ${lookup{$sender_host_address}\
              iplsearch\
                {${if exists{CFG_DIR/AUTH_DOM/AUTH_LOC/auth-hosts}\
                  {CFG_DIR/AUTH_DOM/AUTH_LOC/auth-hosts}\
                  {CFG_DIR/AUTH_DOM/.DEFAULT/auth-hosts}}}{\
      ${if crypteq{$3}{${extract{1}{:}{${lookup{$2}\
      lsearch{CFG_DIR/.DEFAULT/users.passwd}{$value}fail}}}}{1}{0}}}{0}}
    server_set_id = $2



The iplsearch'd auth-hosts file contains (for a default 'allow from
anywhere'):

0.0.0.0/0

I don't think I can do a real 'hosts' type list in an authenticator,
but this is good enough in case a user (or domain) ends up being the
recipient of a brute-force AUTH attack.


-- 
--------------------------------------------------------
Dave Lugo   dlugo@???    LC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.
--------------------------------------------------------
Are you the police?  . . . .  No ma'am, we're sysadmins.