Re: [LIST][SECURITYBASICS] Sender Spoofing via SMTP

[Devdas Bhagat <devdas () dvb homelinux org>]

On 09/11/05 12:57 +0100, Tomasz Nidecki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: MD5
>
> Tuesday, November 8, 2005, 2:56:46 PM, Matt wrote:
>
> > I still haven't figured out a way to completely stop what you are
> > referring to from happening.
>
> I don't think there is a product on the market that would implement
> such a strategy [I wish there was... maybe I'll write one some time in
> the future? 8], which would have the following strategy applied:

Almost any MTA available today allows for this kind of policy.

> 1. SMTP AUTH for all users who want to realy
>
> Implement a forced SMTP AUTH strategy for all your users, even the
> local ones [from local IPs]. If a user does not authenticate, the user
> is not able to relay.
>
> 2. For an UNAUTHENTICATED user:
>
> 2.1. Check the domain in MAIL FROM against a list of your local
>      domains
> 2.2. DENY the mail if it matches, since there should be no such case
>      where an unauthenticated user is sending mail with your MAIL
>      FROM.

Clue: .forward

> 2.3. Additionally, if possible, also check the domain in From: header
>      in the DATA section, before queueing it, and do the same as
>      above.

Clue: Mailing lists.

> This will deal with all mail sent by external entities to your
> servers, as your roaming users will have to authenticate.
>
> This will ensure that anyone from the outside will be able to send
> mail to your domains, unless they use your domain as part of their
> address. If they do, this must be a spoofing attempt, because your
> user would authenticate first.
>
> 3. For an AUTHENTICATED user [SMTP AUTH]:
>
> 3.1. Check whether the username given in the SMTP AUTH dialogue
>      matches the username given in MAIL FROM and later From: headers.
>      If it doesn't, deny mail. This might be problematic, if you have
>      for example a user who wants to send mail as boss () yourdomain com,
>      whilst the account name is johndoe () yourdomain com [boss is an
>      alias], therefore an alternative method could be used:

I can think of a few dozen reasons to use different addresses
legitimately (clue: role accounts). 

> 3.2. Replace the MAIL FROM header with the true account name and valid
>      domain for that account name, and possibly add a separate header
>      [or at the end of the From: header] stating "(Authenticated as
>      johndoe)". This will then make it clearly visible, who actually
>      sent the mail [because that person must have authenticated].

Exposing internal username information, allowing easier attempts at
bruteforcing passwords. You might want to dump this to syslog only.

> What do you think of such a strategy? Obviously this is only to
> protect your domains and your users, you won't be able to do anything
> about a third party sending mail to a fourth party with your mail
> address. SPF tries to address this, but fails on other accounts.
This strategy is broken for the above reasons.

Devdas Bhagat