Postscreen newb questions

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

Postscreen newb questions

Fazzina, Angelo

Hi, i am learning/testing Postscreen on Postfix 2.10.1

I read the man page and need a little help understanding this :

 

This program should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical

       deployment,  postscreen(8)  handles  the  MX service on TCP port 25, while MUA clients submit mail via the

       submission service on TCP port 587 which requires client authentication.  Alternatively, a site could  set

       up  a  dedicated, non-postscreen, "port 25" server that provides submission service and client authenticaâ[m

       tion, but no MX service.

 

What does "MX service" mean ?

 

I am not sure how to leverage postscreen for authenticated smtp traffic to my server over ports 587 and 465, or is that not

what postscreen was meant to handle ?

 

i changed main.cf and master.cf as advised on www.postfix.org/ POSTSCREEN_README.html#enable

but did not do step #7.

Then did a systemctl reload postfix

 

I sent  test emails with T-bird directly to the server testing port 25,587, and 465 to see what shows up in logs.

Postscreen logs only show up when i send over port 25 as i think they should.

 

Oct 31 16:03:27 mta5 postfix/postscreen[3944]: CONNECT from [137.99.80.129]:51476 to [137.99.25.249]:25

Oct 31 16:03:27 mta5 postfix/postscreen[3944]: WHITELISTED [137.99.80.129]:51476

Oct 31 16:03:27 mta5 postfix/smtpd[3945]: connect from angelo.uits.uconn.edu[137.99.80.129]

Oct 31 16:03:27 mta5 postfix/smtpd[3945]: 61D353000A3A: client=angelo.uits.uconn.edu[137.99.80.129]

Oct 31 16:03:27 mta5 postfix/cleanup[3968]: 61D353000A3A: warning: header Subject: new testing from angelo.uits.uconn.edu[137.99.80.129]; from=<[hidden email]> to=<[hidden email]> proto=ESMTP helo=<[137.99.80.129]>

Oct 31 16:03:27 mta5 postfix/cleanup[3968]: 61D353000A3A: message-id=<[hidden email]>

Oct 31 16:03:27 mta5 opendkim[1446]: 61D353000A3A: DKIM-Signature field added (s=dkim1, d=mta5.uits.uconn.edu)

Oct 31 16:03:27 mta5 postfix/qmgr[3936]: 61D353000A3A: from=<[hidden email]>, size=676, nrcpt=1 (queue active)

Oct 31 16:03:27 mta5 postfix/smtpd[3945]: disconnect from angelo.uits.uconn.edu[137.99.80.129]

Oct 31 16:03:29 mta5 postfix/smtp[3971]: 61D353000A3A: to=<[hidden email]>, orig_to=<[hidden email]>, relay=uconn-mail-onmicrosoft-com.mail.protection.outlook.com[216.32.180.170]:25, delay=1.9, delays=0.11/0.02/0.05/1.8, dsn=2.6.0, status=sent (250 2.6.0 <[hidden email]> [InternalId=3019362009548, Hostname=BN7PR05MB5859.namprd05.prod.outlook.com] 9969 bytes in 0.262, 37.150 KB/sec Queued mail for delivery)

 

I guess what i am getting at is, if i only allow port 25 traffic from within my network via this setting

mynetworks = /etc/postfix/files/mynetwork 

                /etc/postfix/files/mynetwork contains

                                137.99.0.0/16

then everything postscreen will ever see will be whitelisted. If i got that right then, am i not a good use case for using it

and should just keep it off ?

 

 

More of my random thoughts:

If i wanna send an email through the server from home i have to use port 587 or 465 and it seems like postscreen is not

part of the equation from this line in master.cf

smtp      inet  n       -       n       -       1       postscreen

 

Still trying to wrap my head around if my environment is a good candidate for using postscreen.....

thanks for any replies.

 

-ANGELO FAZZINA

 

ITS Service Manager:

Spam and Virus Prevention

Mass Mailing

G Suite/Gmail

 

[hidden email]

University of Connecticut,  ITS, SSG, Server Systems

860-486-9075

 

Reply | Threaded
Open this post in threaded view
|

Re: Postscreen newb questions

Noel Jones-2
On 10/31/2018 3:52 PM, Fazzina, Angelo wrote:

> Hi, i am learning/testing Postscreen on Postfix 2.10.1
>
> I read the man page and need a little help understanding this :
>
>  
>
> This program should not be used on SMTP ports that receive mail from
> end-user clients (MUAs). In a typical
>
>        deployment,  postscreen(8)  handles  the  MX service on TCP
> port 25, while MUA clients submit mail via the
>
>        submission service on TCP port 587 which requires client
> authentication.  Alternatively, a site could  set
>
>        up  a  dedicated, non-postscreen, "port 25" server that
> provides submission service and client authenticaâ[m
>
>        tion, but no MX service.
>
>  
>
> *What does "MX service" mean ?*

In this context, MX Service means "receive incoming mail from random
unauthenticated internet sources".


>
> * *
>
> I am not sure how to leverage postscreen for authenticated smtp
> traffic to my server over ports 587 and 465, or is that not
>
> what postscreen was meant to handle ?

Postscreen *should not* be used on ports used for client
authenticated SMTP.

Typically, authenticated clients will use the "submission" port 587
or "smtps" port 465 to submit mail.

>  
>
> I guess what i am getting at is, if i only allow port 25 traffic
> from within my network via this setting
>
> mynetworks = /etc/postfix/files/mynetwork 
>
>                 /etc/postfix/files/mynetwork contains
>
>                                 137.99.0.0/16
>
> then everything postscreen will ever see will be whitelisted. If i
> got that right then, am i not a good use case for using it
>
> and should just keep it off ?

Postscreen is intended for internet traffic on an internet-facing
mail gateway.

Does this server also accept incoming unauthenticated mail from the
general internet?  If no, then postscreen is not for you.





  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen newb questions

Bill Cole-3
On 31 Oct 2018, at 17:12, Noel Jones wrote:

> Postscreen *should not* be used on ports used for client
> authenticated SMTP.

Generally, this has been true...

However, I have recently seen spambots using compromised accounts on
port 587 without properly waiting for the greeting banner. This was on a
Sendmail installation, which already (inadvertently) had a GreetPause
applied to port 587.

I intend to experiment with postscreen on 587 on the next Postfix system
I work with where compromised accounts are a problem. I hope that by
then someone else will have pioneered that tactic and worked through all
the pitfalls here.


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

Re: Postscreen newb questions

Viktor Dukhovni
> On Nov 1, 2018, at 11:30 AM, Bill Cole <[hidden email]> wrote:
>
> I intend to experiment with postscreen on 587 on the next Postfix
> system I work with where compromised accounts are a problem.

Don't waste your time.  Postscreen cannot help you with this.
Postscreen maintains dynamic IP-address whitelists/blacklists,
which are of little use in submission, because submission users
routinely use dynamic IP addresses.

Also MUAs are interactive, and users are not terribly fond of
having their mail submission temporarily rejected and having
to try again later.  Postscreen never accepts a message on
the first try when the IP address is not already whitelisted.

Postscreen also gets most of its effectiveness from RBLs,
these too are not terribly appropriate for submission, as
legitimate submission users will dynamically get IPs that
botnets have previously abused.

You probably know all this, and perhaps you'll still be able
to figure out some usable deployment model, but I'm not
optimistic...

--
--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Postscreen newb questions

Wietse Venema
In reply to this post by Bill Cole-3
Bill Cole:

> On 31 Oct 2018, at 17:12, Noel Jones wrote:
>
> > Postscreen *should not* be used on ports used for client
> > authenticated SMTP.
>
> Generally, this has been true...
>
> However, I have recently seen spambots using compromised accounts on
> port 587 without properly waiting for the greeting banner. This was on a
> Sendmail installation, which already (inadvertently) had a GreetPause
> applied to port 587.
>
> I intend to experiment with postscreen on 587 on the next Postfix system
> I work with where compromised accounts are a problem. I hope that by
> then someone else will have pioneered that tactic and worked through all
> the pitfalls here.

You would not be able to use many DNSBLs such as zen.spamhaus.org,
nor any of the 'after 220' protocol tests.

It wouod take a ton of master.cf configuration.

master.cf:
  submission inet ....  postscreen
        -o smtpd_service=submission-smtpd
        -o postscreen_cache_map=$submission_cache_map
        -o postscreen_dnsbl_sites=$submission_dnsbl_sites
        -o postscreen_xxx=$submission_xxx
        ...
  submission-smtpd pass ... smtpd
        -o smtpd_xxxx=$submission_xxxx
        ...

With suitable submission_mumble parameter settings in master.cf.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen newb questions

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:

> > On Nov 1, 2018, at 11:30 AM, Bill Cole <[hidden email]> wrote:
> >
> > I intend to experiment with postscreen on 587 on the next Postfix
> > system I work with where compromised accounts are a problem.
>
> Don't waste your time.  Postscreen cannot help you with this.
> Postscreen maintains dynamic IP-address whitelists/blacklists,
> which are of little use in submission, because submission users
> routinely use dynamic IP addresses.
>
> Also MUAs are interactive, and users are not terribly fond of
> having their mail submission temporarily rejected and having
> to try again later.  Postscreen never accepts a message on
> the first try when the IP address is not already whitelisted.

That depends. I don't use 'after 220' tests, and never have
client forced to reconnect.

> Postscreen also gets most of its effectiveness from RBLs,
> these too are not terribly appropriate for submission, as
> legitimate submission users will dynamically get IPs that
> botnets have previously abused.
>
> You probably know all this, and perhaps you'll still be able
> to figure out some usable deployment model, but I'm not
> optimistic...

I think that there are DNSBLs that explicitly target bots,
so a remote IP address may get flagged for that (whether it
will be flagged soon enough is a different matter).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen newb questions

Bill Cole-3
In reply to this post by Viktor Dukhovni
On 1 Nov 2018, at 12:03, Viktor Dukhovni wrote:

>> On Nov 1, 2018, at 11:30 AM, Bill Cole
>> <[hidden email]> wrote:
>>
>> I intend to experiment with postscreen on 587 on the next Postfix
>> system I work with where compromised accounts are a problem.
>
> Don't waste your time.  Postscreen cannot help you with this.
> Postscreen maintains dynamic IP-address whitelists/blacklists,
> which are of little use in submission, because submission users
> routinely use dynamic IP addresses.

Not the ones who show up in an office carrying something infective from
Vegas that didn't stay in Vegas.

> Also MUAs are interactive, and users are not terribly fond of
> having their mail submission temporarily rejected and having
> to try again later.  Postscreen never accepts a message on
> the first try when the IP address is not already whitelisted.

It does if you don't use the after-220 tests, which I do not and would
not.

> Postscreen also gets most of its effectiveness from RBLs,

For me, it gets most of its UNIQUE effectiveness from the banner delay.
YMMV obviously.

> these too are not terribly appropriate for submission, as
> legitimate submission users will dynamically get IPs that
> botnets have previously abused.
>
> You probably know all this, and perhaps you'll still be able
> to figure out some usable deployment model, but I'm not
> optimistic...

I'm attacking the problem of an authenticating account on a network that
others may just toss into mynetworks and forget, using an
idiosyncratically bot-like behavior to send spam that ends up carrying
lots of ham indicators.