Preventing domain impresonation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Preventing domain impresonation

Marek Kozlowski-2
:-)

Let's assume my hostname is 'sth.mydomain.tld'
The following configuration:

#-------------------------------------------------
smtpd_recipient_restrictions =
         permit_mynetworks,
         permit_sasl_authenticated,
         reject_unauth_destination,
        check_sender_access hash:/etc/postfix/sender_checks_my,
        ...

# cat /etc/postfix/sender_checks_my
sth.mydomain.tld 554 Please enable SMTP AUTH
#-------------------------------------------------

accepts mail from '...@sth.mydomain.tld' only from authenticated users
or the hosts specified by the 'mynetworks' list.

I'm wondering if there is a simple way of extending the list of hosts
that may send me e-mails with '...@sth.mydomain.tld' as the sender
address to my whole network (lets say '1.2.3.4/24') but without
modifying the 'mynetworks' (which AFAIK grant much more privileges)
list. What takes the precedence is case of:

# cat /etc/postfix/sender_checks_my
1.2.3.4/24 OK
sth.mydomain.tld 554 Please enable SMTP AUTH

? Is there any other way? Thanks!

Best regards,
Marek


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Preventing domain impresonation

Jaroslaw Rafa
Dnia 27.08.2020 o godz. 14:30:21 Marek Kozlowski pisze:
> The following configuration:
>
> #-------------------------------------------------
> smtpd_recipient_restrictions =
>         permit_mynetworks,
>         permit_sasl_authenticated,
>         reject_unauth_destination,
> check_sender_access hash:/etc/postfix/sender_checks_my,
> ...

What does "check_sender_access" do in smtpd_recipient_restrictions ?
According to documentation, you can have "check_recipient_access" there, but
not "check_sender_access".

> accepts mail from '...@sth.mydomain.tld' only from authenticated
> users or the hosts specified by the 'mynetworks' list.

Looks like a bad idea.
Suppose someone is sending mail from [hidden email] to some
address that is forwarding mail back to [hidden email]. Under
your assumptions, you will reject that mail requiring authentication.

This is not an abstract example, one of large email providers in Poland that
you probably know (Onet) was once configured that way that it required
authentication for *all* incoming mail if the sender was from
@poczta.onet.pl (yes, it required authentication on port 25 - I don't know
if it's still configured that way). I was at that time managing an email
server at some university. A lot of people forwarded mail from their
university account to private accounts and some of them had accounts at
Onet. When someone other with account at Onet sent them mail to their
university address, they didn't receive the email that was forwarded to
their private account, because it was rejected by Onet.

> # cat /etc/postfix/sender_checks_my
> 1.2.3.4/24 OK
> sth.mydomain.tld 554 Please enable SMTP AUTH

What is an IP address doing in "check_sender_access" table?
As the documentation says, "check_sender_access" does the following: "Search
the specified access(5) database for the MAIL FROM address, domain, parent
domains, or localpart@, and execute the corresponding action." I don't see
any IP addresses mentioned here.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
Reply | Threaded
Open this post in threaded view
|

Re: Preventing domain impresonation

Bill Cole-3
On 27 Aug 2020, at 9:26, Jaroslaw Rafa wrote:

> What does "check_sender_access" do in smtpd_recipient_restrictions ?
> According to documentation, you can have "check_recipient_access"
> there, but
> not "check_sender_access".

Incorrect.

 From `man 5 postconf`:

   smtpd_recipient_restrictions (default: see postconf -d output)
        Optional  restrictions that the Postfix SMTP server applies in
the con-
        text of a client RCPT TO command, after
smtpd_relay_restrictions.   See
        SMTPD_ACCESS_README,   section   "Delayed  evaluation  of  SMTP  
access
        restriction lists" for a discussion of evaluation context and
time.

        [...]

        Other restrictions that are valid in this context:

        o Generic restrictions that can be used in any SMTP  command  
con-
          text, described under smtpd_client_restrictions.

        o SMTP    command    specific    restrictions    described  
under
          smtpd_client_restrictions,      smtpd_helo_restrictions      
and
          smtpd_sender_restrictions.

--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
Reply | Threaded
Open this post in threaded view
|

Re: Preventing domain impresonation

ruprechtsberger
Hi,
we utilize something along these lines. And yes: the forwarding problem
needs to be addressed.

in main.cf:

smtpd_sender_restrictions =
        permit_mynetworks,
        reject_non_fqdn_sender,
        reject_authenticated_sender_login_mismatch,
        permit_sasl_authenticated,
        check_sender_access hash:/etc/postfix/check_sender_access.hash.cf,
        permit


in check_sender_access.hash.cf:

## list of exceptions
# a subdomain that sends mail for $reason, this is what you wanted?
somesubdomain.volkshilfe-ooe.at OK
# external systems that send mail to us with fake address
[hidden email]
# receipients that needs forwards (buggy list software from a partner)
[hidden email]
...

# require auth
volkshilfe-ooe.at       REJECT authentication required


The hash map is versatile enough for our use. But this method seen
better days... 3,4 years ago this nuked like 80-90% of incomming spam.
Now it's below 5% of incomming traffic. Not sure if I would implement it
now again (was worth it when we implemented it though).

It works only if you have a small number of users that need forwarding
back to you.

lg,
rupi

--
Rainer Ruprechtsberger
Volkshilfe Oberösterreich
IT
4020 Linz, Glimpfingerstrasse 48
Tel.: +43 732 3405 123
Mobil.: +43 676 8734 1123

ZVR Zahl: 064371505

Volkshilfe. Wir sind für die Menschen da.
Reply | Threaded
Open this post in threaded view
|

Re: Preventing domain impresonation

Viktor Dukhovni
In reply to this post by Marek Kozlowski-2
On Thu, Aug 27, 2020 at 02:30:21PM +0200, Marek Kozlowski wrote:

> #-------------------------------------------------
> smtpd_recipient_restrictions =
>          permit_mynetworks,
>          permit_sasl_authenticated,
>          reject_unauth_destination,
>   check_sender_access hash:/etc/postfix/sender_checks_my,
>   ...

I assume that perhaps you also have "smtpd_relay_restrictions" defined
as a safety net, but it is good to see "reject_unauth_destination"
safely above the sender checks.

> # cat /etc/postfix/sender_checks_my
> 1.2.3.4/24 OK
> sth.mydomain.tld 554 Please enable SMTP AUTH

Well that can't work, because "1.2.3.4/24" is not a sender address,
and CIDR syntax doesn't work in a hashed file anyway.

> ? Is there any other way? Thanks!

Yes, there is another way:

  main.cf:
    default_database_type = hash
    indexed = ${default_datbase_type}:${config_directory}/
    cidr = cidr:${config_directory}/

    # See http://www.postfix.org/RESTRICTION_CLASS_README.html
    smtpd_restriction_classes = check_impersonator
    check_impersonator =
        check_client_access ${cidr}impersonators.cidr

    smtpd_recipient_restrictions =
         permit_mynetworks,
         permit_sasl_authenticated,
         reject_unauth_destination,
         check_sender_access ${indexed}sender_checks_my,
         ...

  sender_checks_my:
    # Restricted sender domains
    sth.mydomain.tld check_impersonator

  impersonators.cidr:
    # Order matters, list permitted clients above the final REJECT
    # No need to return "OK", a DUNNO suffices to avoid the reject.
    1.2.3.4/24      DUNNO
    0.0.0.0/0       REJECT 5.7.1 Please enable SASL AUTH

--
    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Preventing domain impresonation

Bill Cole-3
In reply to this post by Marek Kozlowski-2
On 27 Aug 2020, at 8:30, Marek Kozlowski wrote:

> :-)
>
> Let's assume my hostname is 'sth.mydomain.tld'
> The following configuration:
>
> #-------------------------------------------------
> smtpd_recipient_restrictions =
>         permit_mynetworks,
>         permit_sasl_authenticated,
>         reject_unauth_destination,
> check_sender_access hash:/etc/postfix/sender_checks_my,
> ...
>
> # cat /etc/postfix/sender_checks_my
> sth.mydomain.tld 554 Please enable SMTP AUTH
> #-------------------------------------------------
>
> accepts mail from '...@sth.mydomain.tld' only from authenticated users
> or the hosts specified by the 'mynetworks' list.

Why offer AUTH on port 25 at all? Enable initial mail submission (port
465 with SSL 'wrappermode' and/or port 587 with STARTTLS) with AUTH and
disable AUTH for port 25. Removing support for initial mail submission
from port 25 SMTP allows for a more tightly defined configuration and
depending on what your specific needs are, you may be able to eliminate
IP-based authentication altogether.

> I'm wondering if there is a simple way of extending the list of hosts
> that may send me e-mails with '...@sth.mydomain.tld' as the sender
> address to my whole network (lets say '1.2.3.4/24') but without
> modifying the 'mynetworks' (which AFAIK grant much more privileges)
> list.

Viktor wrote up the standard approach to do what you asked in his reply,
using a restriction class.

A simpler solution may be to limit the privilege given to $mynetworks by
adding an explicit definition for smtpd_relay_restrictions:

   smtpd_relay_restrictions = permit_sasl_authenticated,
reject_unauth_destination

With that set, the permit_mynetworks directive in
smtpd_recipient_restrictions only applies to inbound mail, not relayed
mail, so you may feel more comfortable adding more addresses to
$mynetworks.


--
Bill Cole
[hidden email] or [hidden email]
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)