Loading ...
Sorry, an error occurred while loading the content.

Re: SV: Re: Configure postfix to reject forged mail?

Expand Messages
  • Wietse Venema
    ... Postfix restrictions are not a Turing-complete access control language. For complex policies use a policy plug-in such as postfwd. http://www.postfwd.org/
    Message 1 of 11 , May 7, 2014
    • 0 Attachment
      Sebastian Nielsen:
      > I want to reject senders, that are relaying, using a domain not
      > on a approved list. eg all sender domains that aren?t @...
      > but are relaying, should be rejected.

      Postfix restrictions are not a Turing-complete access control
      language. For complex policies use a policy plug-in such as
      postfwd. http://www.postfwd.org/

      Wietse
    • Viktor Dukhovni
      ... But in this case there is a simpler solution: main.cf: indexed = ${default_database_type}:${config_directory}/ smtpd_sender_restrictions =
      Message 2 of 11 , May 7, 2014
      • 0 Attachment
        On Wed, May 07, 2014 at 10:28:46AM -0400, Wietse Venema wrote:

        > Sebastian Nielsen:
        > > I want to reject senders, that are relaying, using a domain not
        > > on a approved list. eg all sender domains that aren?t @...
        > > but are relaying, should be rejected.
        >
        > Postfix restrictions are not a Turing-complete access control
        > language. For complex policies use a policy plug-in such as
        > postfwd. http://www.postfwd.org/

        But in this case there is a simpler solution:

        main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_sender_restrictions =
        check_sender_access ${indexed}relay-sender-check,
        reject_unauth_destination

        relay-sender-check:
        sebbe.eu permit_mynetworks, permit_sasl_authenticated

        --
        Viktor.
      • Sebastian Nielsen
        THANKS! Works EXCELLENTLY. Did fine-tune it a little bit, but then it works excellently now. smtpd_relay_restrictions = check_sender_access
        Message 3 of 11 , May 7, 2014
        • 0 Attachment
          THANKS!
          Works EXCELLENTLY. Did fine-tune it a little bit, but then it works
          excellently now.

          smtpd_relay_restrictions = check_sender_access hash:/etc/postfix/access,
          reject_unauth_destination
          smtpd_recipient_restrictions = reject_unknown_sender_domain,
          reject_unknown_recipient_domain, reject_unauth_pipelining,
          check_sender_access hash:/etc/postfix/access, reject_unauth_destination
          smtpd_sender_restrictions = reject_unknown_sender_domain,
          check_sender_access hash:/etc/postfix/access
          mynetworks = 127.0.0.0/8 192.168.0.0/16

          /etc/postfix/access:
          sebbe.eu permit_mynetworks, reject


          This causes the "sebbe.eu" sender domain to be only available to
          "mynetworks" regardless of in relaying or delivery context. (since "reject"
          will also reject permitted destinations)
          And on top of that, this also makes it impossible for a sender on
          "mynetworks" to relay using a sender adress not ending in @....
          Also, this makes it impossible for a sender outside of "mynetworks" to relay
          using a spoofed FROM adress.
          EXACTLY as I wanted!

          (On top of that: I never use SASL/SMTP authentication for obvious security
          reasons - a leaked password can be used for spamming. Easier to just
          restrict it to "users behind the firewall" and then theres no authentication
          to hack)

          -----Ursprungligt meddelande-----
          From: Viktor Dukhovni
          Sent: Wednesday, May 07, 2014 4:34 PM
          To: postfix-users@...
          Subject: Re: SV: Re: Configure postfix to reject forged mail?

          On Wed, May 07, 2014 at 10:28:46AM -0400, Wietse Venema wrote:

          > Sebastian Nielsen:
          > > I want to reject senders, that are relaying, using a domain not
          > > on a approved list. eg all sender domains that aren?t @...
          > > but are relaying, should be rejected.
          >
          > Postfix restrictions are not a Turing-complete access control
          > language. For complex policies use a policy plug-in such as
          > postfwd. http://www.postfwd.org/

          But in this case there is a simpler solution:

          main.cf:
          indexed = ${default_database_type}:${config_directory}/
          smtpd_sender_restrictions =
          check_sender_access ${indexed}relay-sender-check,
          reject_unauth_destination

          relay-sender-check:
          sebbe.eu permit_mynetworks, permit_sasl_authenticated

          --
          Viktor.
        • Viktor Dukhovni
          ... The fine-tuning makes it likely that your system will be an open relay some day. I chose smtpd_sender_restrictions for this deliberately. Do NOT use
          Message 4 of 11 , May 7, 2014
          • 0 Attachment
            On Wed, May 07, 2014 at 07:58:26PM +0200, Sebastian Nielsen wrote:

            > Works EXCELLENTLY. Did fine-tune it a little bit, but then it works
            > excellently now.

            The fine-tuning makes it likely that your system will be an open
            relay some day. I chose smtpd_sender_restrictions for this
            deliberately. Do NOT use sender-based whitelisting in relay
            restrictions.

            > smtpd_relay_restrictions = check_sender_access hash:/etc/postfix/access,
            > reject_unauth_destination
            > smtpd_recipient_restrictions = reject_unknown_sender_domain,
            > reject_unknown_recipient_domain, reject_unauth_pipelining,
            > check_sender_access hash:/etc/postfix/access, reject_unauth_destination
            > smtpd_sender_restrictions = reject_unknown_sender_domain,
            > check_sender_access hash:/etc/postfix/access
            > mynetworks = 127.0.0.0/8 192.168.0.0/16
            >
            > /etc/postfix/access:
            > sebbe.eu permit_mynetworks, reject

            DO NOT use a single generic access(5) file for semantically different
            access checks. Sender lookups are not recipient lookups are not
            client lookups, ...

            I used an access table dedicated to sender policy. The fine-tuning
            removed all the carefully considered safety measures.

            --
            Viktor.
          • Sebastian Nielsen
            I know. check_sender_access does always check MAIL_FROM, regardless of in which access context they are in. (else it would be check_recipient_access or
            Message 5 of 11 , May 7, 2014
            • 0 Attachment
              I know. "check_sender_access" does always check MAIL_FROM, regardless of in
              which access context they are in. (else it would be check_recipient_access
              or check_client_access)
              smtpd_recipient_restrictions can contain "sender" rejections too, like
              "reject_unknown_sender_domain".
              But a sender access policy cannot contain a recipient policy (like
              reject_unauth_destination) because MAIL_FROM comes before RCPT_TO (unless
              smtpd_delay_reject is set to yes)

              Did test the policy carefully both using a external tool (that queries the
              server externally) and internally, and all test cases did pass thorugh with
              the result I wanted.
              This tool is GREAT to test complex relay restrictions:
              http://smtper.nanogenesis.fr/

              Of course, I will never put anything else than something I want to relay, in
              the "access" file, eg only "permit_mynetworks" and such.


              -----Ursprungligt meddelande-----
              From: Viktor Dukhovni
              Sent: Wednesday, May 07, 2014 8:10 PM
              To: postfix-users@...
              Subject: Re: Configure postfix to reject forged mail?

              On Wed, May 07, 2014 at 07:58:26PM +0200, Sebastian Nielsen wrote:

              > Works EXCELLENTLY. Did fine-tune it a little bit, but then it works
              > excellently now.

              The fine-tuning makes it likely that your system will be an open
              relay some day. I chose smtpd_sender_restrictions for this
              deliberately. Do NOT use sender-based whitelisting in relay
              restrictions.

              > smtpd_relay_restrictions = check_sender_access hash:/etc/postfix/access,
              > reject_unauth_destination
              > smtpd_recipient_restrictions = reject_unknown_sender_domain,
              > reject_unknown_recipient_domain, reject_unauth_pipelining,
              > check_sender_access hash:/etc/postfix/access, reject_unauth_destination
              > smtpd_sender_restrictions = reject_unknown_sender_domain,
              > check_sender_access hash:/etc/postfix/access
              > mynetworks = 127.0.0.0/8 192.168.0.0/16
              >
              > /etc/postfix/access:
              > sebbe.eu permit_mynetworks, reject

              DO NOT use a single generic access(5) file for semantically different
              access checks. Sender lookups are not recipient lookups are not
              client lookups, ...

              I used an access table dedicated to sender policy. The fine-tuning
              removed all the carefully considered safety measures.

              --
              Viktor.
            • Viktor Dukhovni
              ... When using check_sender_access use a separate lookup table whose keys are sender addresses/domains, DO NOT use a single generic file called access for
              Message 6 of 11 , May 7, 2014
              • 0 Attachment
                On Wed, May 07, 2014 at 08:33:18PM +0200, Sebastian Nielsen wrote:

                > I know. "check_sender_access" does always check MAIL_FROM, regardless of in
                > which access context they are in. (else it would be check_recipient_access
                > or check_client_access)

                When using "check_sender_access" use a separate lookup table whose
                keys are sender addresses/domains, DO NOT use a single generic file
                called "access" for everything. This just leads to trouble.

                > But a sender access policy cannot contain a recipient policy (like
                > reject_unauth_destination) because MAIL_FROM comes before RCPT_TO (unless
                > smtpd_delay_reject is set to yes)

                You SHOULD have smtpd_delay_reject set to "yes".

                > Did test the policy carefully both using a external tool (that queries the
                > server externally) and internally, and all test cases did pass thorugh with
                > the result I wanted.

                Sure, it works now, but it is fragile, and will land you or your
                successor in trouble some day.

                > This tool is GREAT to test complex relay restrictions:
                > http://smtper.nanogenesis.fr/

                Tests only report things that are already broken. Only
                design reviews report things that are fragile.

                > Of course, I will never put anything else than something I want to relay, in
                > the "access" file, eg only "permit_mynetworks" and such.

                Some day you will forget, or someone else won't know the constraints.

                --
                Viktor.
              • Sebastian Nielsen
                aaah now I understand. You did not like the _naming_ of the access file. I of course do not use any client maps or recipient maps, only sender maps. So I found
                Message 7 of 11 , May 7, 2014
                • 0 Attachment
                  aaah now I understand. You did not like the _naming_ of the access file.
                  I of course do not use any client maps or recipient maps, only sender maps.
                  So I found it wise to call the file just "access".

                  Of course, if I start using client maps or recipient maps, files will be
                  renamed accordingly.


                  About the test:
                  The test I linked is excellent to test all possible permutations of a access
                  policy, so you can be sure it works the way you want.
                  In my access policy, there is 8 possible permutations, whose 4 can be tested
                  by the tool, and the 4 other can be tested using telnet.

                  outside mynetworks, known sender, known recipient (did fail as it should)
                  outside mynetworks, unknown sender, known recipient (did success as it
                  should)
                  outside mynetworks, known sender, unknown recipient (did fail as it should)
                  outside mynetworks, unknown sender, unknown recipient (did fail as it
                  should)

                  inside mynetworks, known sender, known recipient (did success as it should)
                  inside mynetworks, unknown sender, known recipient (did success as it
                  should)
                  inside mynetworks, known sender, unknown recipient (did success as it
                  should)
                  inside mynetworks, unknown sender, unknown recipient (did fail as it should)
                  (successing this would make the server open relay)

                  About the "forgetting" of the purpose of the access file:
                  Did put a comment block in the access file:

                  #NEVER EVER PUT ANYTHING YOU DONT WANT TO BE OPEN RELAY FOR IN THIS FILE#
                  #ONLY USE PERMIT_MYNETWORKS OR SIMILIAR RESTRICTIONS#
                  sebbe.eu permit_mynetworks, reject

                  Then I will never forget, and successors of me wont break the open relay
                  prevention system.


                  -----Ursprungligt meddelande-----
                  From: Viktor Dukhovni
                  Sent: Wednesday, May 07, 2014 8:51 PM
                  To: postfix-users@...
                  Subject: Re: Configure postfix to reject forged mail?

                  On Wed, May 07, 2014 at 08:33:18PM +0200, Sebastian Nielsen wrote:

                  > I know. "check_sender_access" does always check MAIL_FROM, regardless of
                  > in
                  > which access context they are in. (else it would be check_recipient_access
                  > or check_client_access)

                  When using "check_sender_access" use a separate lookup table whose
                  keys are sender addresses/domains, DO NOT use a single generic file
                  called "access" for everything. This just leads to trouble.

                  > But a sender access policy cannot contain a recipient policy (like
                  > reject_unauth_destination) because MAIL_FROM comes before RCPT_TO (unless
                  > smtpd_delay_reject is set to yes)

                  You SHOULD have smtpd_delay_reject set to "yes".

                  > Did test the policy carefully both using a external tool (that queries the
                  > server externally) and internally, and all test cases did pass thorugh
                  > with
                  > the result I wanted.

                  Sure, it works now, but it is fragile, and will land you or your
                  successor in trouble some day.

                  > This tool is GREAT to test complex relay restrictions:
                  > http://smtper.nanogenesis.fr/

                  Tests only report things that are already broken. Only
                  design reviews report things that are fragile.

                  > Of course, I will never put anything else than something I want to relay,
                  > in
                  > the "access" file, eg only "permit_mynetworks" and such.

                  Some day you will forget, or someone else won't know the constraints.

                  --
                  Viktor.
                • Sebastian Nielsen
                  meant this: outside mynetworks, known sender, known recipient (did fail as it should) outside mynetworks, unknown sender, known recipient (did success as it
                  Message 8 of 11 , May 7, 2014
                  • 0 Attachment
                    meant this:
                    outside mynetworks, known sender, known recipient (did fail as it should)
                    outside mynetworks, unknown sender, known recipient (did success as it
                    should)
                    outside mynetworks, known sender, unknown recipient (did fail as it should)
                    (successing this would make the server open relay)
                    outside mynetworks, unknown sender, unknown recipient (did fail as it
                    should) (successing this would make the server open relay)

                    inside mynetworks, known sender, known recipient (did success as it should)
                    inside mynetworks, unknown sender, known recipient (did success as it
                    should)
                    inside mynetworks, known sender, unknown recipient (did success as it
                    should)
                    inside mynetworks, unknown sender, unknown recipient (did fail as it should)


                    The reason I wanted this policy from the beginning, is that is makes it
                    harder for bots and zombies inside network, to send mail through the server.
                    Only way would be for a bot to actually use a valid sender adress belongning
                    to the server when relaying, the bot cannot spoof the sender, making the
                    email easly traced
                    and actions being taked (computers inside network being cleaned).

                    -----Ursprungligt meddelande-----
                    From: Viktor Dukhovni
                    Sent: Wednesday, May 07, 2014 8:51 PM
                    To: postfix-users@...
                    Subject: Re: Configure postfix to reject forged mail?

                    On Wed, May 07, 2014 at 08:33:18PM +0200, Sebastian Nielsen wrote:

                    > I know. "check_sender_access" does always check MAIL_FROM, regardless of
                    > in
                    > which access context they are in. (else it would be check_recipient_access
                    > or check_client_access)

                    When using "check_sender_access" use a separate lookup table whose
                    keys are sender addresses/domains, DO NOT use a single generic file
                    called "access" for everything. This just leads to trouble.

                    > But a sender access policy cannot contain a recipient policy (like
                    > reject_unauth_destination) because MAIL_FROM comes before RCPT_TO (unless
                    > smtpd_delay_reject is set to yes)

                    You SHOULD have smtpd_delay_reject set to "yes".

                    > Did test the policy carefully both using a external tool (that queries the
                    > server externally) and internally, and all test cases did pass thorugh
                    > with
                    > the result I wanted.

                    Sure, it works now, but it is fragile, and will land you or your
                    successor in trouble some day.

                    > This tool is GREAT to test complex relay restrictions:
                    > http://smtper.nanogenesis.fr/

                    Tests only report things that are already broken. Only
                    design reviews report things that are fragile.

                    > Of course, I will never put anything else than something I want to relay,
                    > in
                    > the "access" file, eg only "permit_mynetworks" and such.

                    Some day you will forget, or someone else won't know the constraints.

                    --
                    Viktor.
                  • Viktor Dukhovni
                    ... Belt and suspenders, apply the check in smtpd_sender_restrictions, and don t set smtpd_delay_reject = no . Document this requirement. In the dedicated
                    Message 9 of 11 , May 7, 2014
                    • 0 Attachment
                      On Wed, May 07, 2014 at 09:04:37PM +0200, Sebastian Nielsen wrote:

                      > About the "forgetting" of the purpose of the access file:
                      > Did put a comment block in the access file:
                      >
                      > #NEVER EVER PUT ANYTHING YOU DONT WANT TO BE OPEN RELAY FOR IN THIS FILE#
                      > #ONLY USE PERMIT_MYNETWORKS OR SIMILIAR RESTRICTIONS#
                      > sebbe.eu permit_mynetworks, reject
                      >
                      > Then I will never forget, and successors of me wont break the open relay
                      > prevention system.

                      Belt and suspenders, apply the check in smtpd_sender_restrictions,
                      and don't set "smtpd_delay_reject = no". Document this requirement.

                      In the dedicated access file (yes, not named "access") the comments
                      should state that this must never return an unconditional OK for
                      any lookup keys. Only "permit_mynetworks", "permit_sasl_authenticated"
                      or similar are acceptable, because this access file is for relay
                      access by sender domain, and sender domains are easy to forge, so
                      real access control must still be applied.

                      --
                      Viktor.
                    • Sebastian Nielsen
                      yep know. It is a dedicated access file. Renamed it to relay_auth, to make it more clear what the file is for. But a question: Why do you like sasl
                      Message 10 of 11 , May 7, 2014
                      • 0 Attachment
                        yep know. It is a dedicated access file. Renamed it to relay_auth, to make
                        it more clear what the file is for.

                        But a question: Why do you like sasl authentication? Isn't it more secure to
                        have no authentication at all and instead
                        rely on client IP?
                        Then theres no authentication to hack.
                        I even have "smtpd_sasl_auth_enable = no", so theres absolutely nothing a
                        outsider can do to get a mail relayed through my server.

                        About delay_reject, I did set it to yes to be sure (so even in case that
                        postfix was compiled - it was shipped with lubuntu - with "no", it will
                        still be a yes)

                        -----Ursprungligt meddelande-----
                        From: Viktor Dukhovni
                        Sent: Wednesday, May 07, 2014 9:15 PM
                        To: postfix-users@...
                        Subject: Re: Configure postfix to reject forged mail?

                        On Wed, May 07, 2014 at 09:04:37PM +0200, Sebastian Nielsen wrote:

                        > About the "forgetting" of the purpose of the access file:
                        > Did put a comment block in the access file:
                        >
                        > #NEVER EVER PUT ANYTHING YOU DONT WANT TO BE OPEN RELAY FOR IN THIS FILE#
                        > #ONLY USE PERMIT_MYNETWORKS OR SIMILIAR RESTRICTIONS#
                        > sebbe.eu permit_mynetworks, reject
                        >
                        > Then I will never forget, and successors of me wont break the open relay
                        > prevention system.

                        Belt and suspenders, apply the check in smtpd_sender_restrictions,
                        and don't set "smtpd_delay_reject = no". Document this requirement.

                        In the dedicated access file (yes, not named "access") the comments
                        should state that this must never return an unconditional OK for
                        any lookup keys. Only "permit_mynetworks", "permit_sasl_authenticated"
                        or similar are acceptable, because this access file is for relay
                        access by sender domain, and sender domains are easy to forge, so
                        real access control must still be applied.

                        --
                        Viktor.
                      • lists@rhsoft.net
                        ... how can it be more secure to blindly trust an IP address comapred to a combination of username + password? in case of open your doors for an IP you do it
                        Message 11 of 11 , May 7, 2014
                        • 0 Attachment
                          Am 07.05.2014 21:27, schrieb Sebastian Nielsen:
                          > But a question: Why do you like sasl authentication?
                          > Isn't it more secure to have no authentication at all and instead
                          > rely on client IP?

                          how can it be more secure to blindly trust an IP address
                          comapred to a combination of username + password?

                          in case of open your doors for an IP you do it for any
                          malware running there, in case auf SASL the malware needs
                          to find valid credentials

                          if you want to get 100% sure you use both - specific
                          credentails only allowed from limited and known IP's
                        Your message has been successfully submitted and would be delivered to recipients shortly.