what error is being reported back to sender, and how to avoid reporting back internal server ports?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

what error is being reported back to sender, and how to avoid reporting back internal server ports?

jasonsu
I added SPF and header_checks to my Postfix setup.

I'm following the message path, and have a couple questions about what error gets reported back to the sender.

After postscreen PASS, I check for SPF, then hand off to Amavis preque for DKIM

        psint pass - - n - - smtpd
          -o receive_override_options=no_address_mappings
          -o syslog_name=postfix/psint
          -o smtpd_authorized_xforward_hosts=127.0.0.0/8
          -o smtpd_proxy_filter=127.0.0.1:13001
          -o smtpd_relay_restrictions=permit_mynetworks,reject_unauth_destination,check_policy_service,unix:private/policyd-spf

Amavis returns, submits to DMARC, then passes to Amavis postqueue for A/V

        [127.0.0.1]:13002 inet n - n - - smtpd
          -o content_filter=amavis:[127.0.0.1]:13003
          -o syslog_name=postfix/prequeue
          -o mynetworks=127.0.0.0/8
          -o non_smtpd_milters=inet:127.0.0.1:8893
          -o receive_override_options=no_unknown_recipient_checks
          -o smtpd_authorized_xforward_hosts=127.0.0.0/8
          -o smtpd_client_restrictions=permit_mynetworks,reject
          -o smtpd_data_restrictions=
          -o smtpd_end_of_data_restrictions=
          -o smtpd_etrn_restrictions=
          -o smtpd_helo_restrictions=
          -o smtpd_milters=inet:127.0.0.1:8893
          -o smtpd_recipient_restrictions=permit_mynetworks,reject
          -o smtpd_relay_restrictions=permit_mynetworks,reject
          -o smtpd_sender_restrictions=

I turned on header checks

        main.cf
                header_checks = pcre:${config_directory}/header_checks.pcre

        header_checks.pcre
                /^(To|From|Cc|Reply-To):.*carmen_garcia*/i   REJECT

So, I expect that mail with any sender/recipient that includes "carmen_garcia" will get REJECTed

My logs show it does

        Apr  5 04:29:11 mail01 postfix/psint/smtpd[9355]: NOQUEUE: client=vps.capacit.cl[45.79.11.29]
        Apr  5 04:29:11 mail01 postfix/prequeue/smtpd[9362]: connect from localhost[127.0.0.1]
        Apr  5 04:29:11 mail01 postfix/prequeue/smtpd[9362]: 3qgDTM6nLdz31QN: client=localhost[127.0.0.1], orig_client=vps.capacit.cl[45.79.11.29]
        Apr  5 04:29:11 mail01 postfix/cleanup[9364]: 3qgDTM6nLdz31QN: reject: header To: [hidden email], [hidden email], [hidden email],?  [hidden email], [hidden email], [hidden email],? [hidden email], [hidden email] from vps.capacit.cl[45.79.11.29]; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<vps.capacit.cl>: 5.7.1
        Apr  5 04:29:11 mail01 postfix/prequeue/smtpd[9362]: disconnect from localhost[127.0.0.1] ehlo=1 xforward=1 mail=1 rcpt=1 data=0/1 quit=1 commands=5/6
        Apr  5 04:29:11 mail01 postfix/psint/smtpd[9355]: proxy-reject: END-OF-MESSAGE: 550 5.7.1 id=02796-15 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:13002): 550 5.7.1; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<vps.capacit.cl>
        Apr  5 04:29:12 mail01 postfix/psint/smtpd[9355]: disconnect from vps.capacit.cl[45.79.11.29] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 quit=1 commands=6/7

What's the sending server getting back here? Is the 550 REJECT message being delivered to the sending server? Or only to my internal server doing the handoff?

If it's seeing the 550, how can I stop exposing/reporting back "from MTA(smtp:[127.0.0.1]:13002):" ?  If it's just internal to my setup, then I don't care.

Jason
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

jasonsu


On Wed, Apr 6, 2016, at 11:49 AM, [hidden email] wrote:
> If it's seeing the 550, how can I stop exposing/reporting back "from MTA(smtp:[127.0.0.1]:13002):" ?  If it's just internal to my setup, then I don't care.

It's definitely being reported back to the sender.

        <[hidden email]>: host mail01.example.com[192.0.2.20]
            said: 550 5.7.1 id=14949-01 - Rejected by next-hop MTA on relaying, from
            MTA(smtp:[127.0.0.1]:13002): 550 5.7.1 (in reply to end of DATA
            command)

And I *finally* found the source of the message.  It's amavis

        amavisd.conf-default
                # %smtp_reason_by_ccat = (
                #   # currently only used for blocked messages only, status 5xx
                #   # a multiline message will produce a valid multiline SMTP response
                ...
                #   CC_MTA.',1',    'id=%n - Temporary MTA failure on relaying',
>>> #   CC_MTA.',2',    'id=%n - Rejected by next-hop MTA on relaying',
                #   CC_MTA,         'id=%n - Unable to relay message back to MTA',
                ...
                # );

So far though I haven't figure out what I can DO about it.

There's this thread

  Re: [AMaViS-user] Amavis should not send DSN if D_REJECT is active
  https://sourceforge.net/p/amavis/mailman/message/23018531/

that originally made it possible to REJECT.

That's not the problem, though.  It's that that REJECT is making it back out to the sender.

In my amavisd.conf if I change

  %smtp_reason_by_ccat = (
    CC_MTA.',2',    'JUNK',
  );


I get just

        <[hidden email]>: host mail01.example.com[192.0.2.20]
            said: 550 5.7.1 JUNK, from MTA(smtp:[127.0.0.1]:13002): 550 5.7.1
            (in reply to end of DATA command)

where that

        from MTA(smtp:[127.0.0.1]:13002)

is still there.

I think that's "in postfix".  Looking around to see.

Jason
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

jasonsu


On Sat, Apr 9, 2016, at 02:25 PM, [hidden email] wrote:
> I think that's "in postfix".  Looking around to see.

is the issue of changing

... MTA(smtp:[127.0.0.1]:13002) ...

to something descriptive that I specify

... MTA(my_internal_server_A) ...

a matter of http://www.postfix.org/ADDRESS_REWRITING_README.html ?

Can it be changed at all?

Jason


Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

Wietse Venema
[hidden email]:
>
>
> On Sat, Apr 9, 2016, at 02:25 PM, [hidden email] wrote:
> > I think that's "in postfix".  Looking around to see.
>
> is the issue of changing
>
> ... MTA(smtp:[127.0.0.1]:13002) ...

Who cares? No-one can connect to this from outside.
But, if you must, see

    $ man 5 postconf | less +/'^smtp_reply_filter'

This feature is available in Postfix 2.7.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

jasonsu
On Sat, Apr 9, 2016, at 05:40 PM, Wietse Venema wrote:
> Who cares?

Obviously you don't.

But I do.  That's why I'm asking.  That's good enough for me.

> No-one can connect to this from outside.

That's correct.  Not currently, to this current machine/port, in this configuration.

> But, if you must, see

'must'?  

>     $ man 5 postconf | less +/'^smtp_reply_filter'
>
> This feature is available in Postfix 2.7.

There, that wasn't so hard.

And thanks.

Jason
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

Wietse Venema
> > No-one can connect to this from outside.
>
> That's correct.  Not currently, to this current machine/port, in
> this configuration.

If someone can connect from outside to your 127.0.0.1 port, then
you have a serious infrastructure problem.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

jasonsu


On Sun, Apr 10, 2016, at 06:42 AM, Wietse Venema wrote:
> > > No-one can connect to this from outside.
> >
> > That's correct.  Not currently, to this current machine/port, in
> > this configuration.
>
> If someone can connect from outside to your 127.0.0.1 port, then
> you have a serious infrastructure problem.

Yes, that's obvious for the current configuration.

Like I said, " ... currently, to this current machine/port, in this configuration."

it will change.
Reply | Threaded
Open this post in threaded view
|

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

Curtis Villamizar
In reply to this post by Wietse Venema
In message <[hidden email]>
Wietse Venema writes:

>
> > > No-one can connect to this from outside.
> >
> > That's correct.  Not currently, to this current machine/port, in
> > this configuration.
>  
> If someone can connect from outside to your 127.0.0.1 port, then
> you have a serious infrastructure problem.
>  
> Wietse

Or (assuming that there are no user account on the server) another
service running on the same host that has been compromised.

This is further leveraging a breach.  Of course that means that there
had to already be a non-root breach of something else (which would
already be a bad thing).  But that can't possibly happen (right?).

I'm not a fan of mistaking the loopback interface for a hardenned
security feature.  Unix domain sockets or fifo (ala mkfifo and chmod)
are a better choice than inet with loopback IMO, reducing the chance
of leverage.  Loopback is like a socket or fifo with ugo+rw perms.

Curtis