RE: smtpd_sasl_security_options clarification

[Michael Fox]

> In other words, how do I know which mechanisms will be
> > disallowed with "noactive" or "nodictionary" or allowed by
> "forward_secrecy"
> > or "mutual_auth"?  I'm unable to connect the dots.
> 
> You can find out about SASL active etc. attacks in RFC 4422
> https://tools.ietf.org/html/rfc4422
> 
>   Wietse

Thanks.  Yes, that describes the attack categories.  But it doesn't answer
the above question.  Is the categorization documented somewhere?  If not,
how are we to know?

Michael

Re: smtpd_sasl_security_options clarification

[Wietse Venema]

Wietse:
> Dovecot tells Postfix the supported mechanism names and their
> security properties.  Postfix intersects that with the main.cf
> settings, and announces the mechanisms that remain.

Michael Fox:
> O.K.  Thanks. 
> 
> Can be more specific about which SASL mechanisms are allowed or disallowed
> by each option?  In other words, how do I know which mechanisms will be
> disallowed with "noactive" or "nodictionary" or allowed by "forward_secrecy"
> or "mutual_auth"?  I'm unable to connect the dots.

You can find out about SASL active etc. attacks in RFC 4422
https://tools.ietf.org/html/rfc4422

Wietse

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> 
> Michael Fox:
> > http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says
> "the
> > following security features are defined for the cyrus server .".
> Dovecot is
> > not mentioned.  So, is it correct to interpret this to mean that this
> > postfix setting is a noop when dovecot is used for sasl authentication?
> 
> Hmm. that file hasn't been updated in a while. The list appears to
> be the same for dovecot.
> 
> > And how does Postfix know which authentication mechanisms to offer the
> > client?  Does dovecot communicate this to postfix somehow?
> 
> Dovecot tells Postfix the supported mechanism names and their
> security properties.  Postfix intersects that with the main.cf
> settings, and announces the mechanisms that remain.
> 
>   Wietse

O.K.  Thanks. 

Can be more specific about which SASL mechanisms are allowed or disallowed
by each option?  In other words, how do I know which mechanisms will be
disallowed with "noactive" or "nodictionary" or allowed by "forward_secrecy"
or "mutual_auth"?  I'm unable to connect the dots.

Thanks,
Michael

Re: smtpd_sasl_security_options clarification

[Wietse Venema]

Michael Fox:
> http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the
> following security features are defined for the cyrus server .".  Dovecot is
> not mentioned.  So, is it correct to interpret this to mean that this
> postfix setting is a noop when dovecot is used for sasl authentication?

Hmm. that file hasn't been updated in a while. The list appears to
be the same for dovecot.

> And how does Postfix know which authentication mechanisms to offer the
> client?  Does dovecot communicate this to postfix somehow?

Dovecot tells Postfix the supported mechanism names and their
security properties.  Postfix intersects that with the main.cf
settings, and announces the mechanisms that remain.

Wietse

smtpd_sasl_security_options clarification

[Michael Fox]

http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the
following security features are defined for the cyrus server .".  Dovecot is
not mentioned.  So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?

 

And how does Postfix know which authentication mechanisms to offer the
client?  Does dovecot communicate this to postfix somehow?

 

Thanks,

Michael

 

 

 

Re: server / client configuration for Authenticated Relay server

[Bill Cole]

On 11 Jul 2016, at 4:30, Zalezny Niezalezny wrote:


Dear Colleagues,

I`m trying to configure authenticated relay server (SASL) using RHEL
Postfix 2.6.6.

System will transport E-mails only from authenticated clients.
1) Most of that clients are in the same subnet, does it make sense to
authtenicate that clients with passwords ?


Yes. Also: do so with a submission service on port 587 and require TLS.


Do we need to use sasl if host
is in the same subnet ?


Authenticating by IP is weak, barely worth calling "authentication" at 
all. If it is possible for a rogue device to get on that subnet or for a 
legitimate machine to be subverted by a spambot, requiring a REAL 
authentication mechanism (i.e. SASL) can prevent a spam run through your 
server.


Some of the defaults and widely-recommended Postfix settings originate 
in an era when port 587 submission was not supported widely enough to 
make it the only route for submission. In the modern world, you may 
never need "permit_mynetworks" anywhere or any SASL support on a port 25 
smtpd service, since mail for outbound relay should be submitted via 
port 587 submission with SASL authentication there.


2) How to understand, permit_mynetworks and permit_sasl_authenticated. 
If
host is mentioned in the mynetworks list, what will happend with it if 
we

will use that settings:

smtpd_relay_restrictions = permit_mynetworks, 
permit_sasl_authenticated,

reject

Postfix will also ask for user name and password ?


That's not how SMTP AUTH works.

When a client connects and uses the "EHLO" command to introduce itself, 
the server replies with a list of extensions to basic SMTP that it 
supports, possibly including the AUTH extension with a list of SASL 
mechanisms that are supported. The *client* is expected to try 
authentication if it can. The server never explicitly "asks" for 
authentication, it merely offers the option and MAY be configured to 
reject mail without it.


So, the configuration you show will let clients in $mynetworks relay 
with or without authentication and let any other client relay if they 
authenticate, and reject other mail.


 I`m strugling that topic since days and I do not how to manage that. 
SASL
documentation from Wietse I read already multiple times, but it still 
not

working.
Does any one can send me client / server (main.cf) config which is 
working.


Since I never set up submission for relaying and inbound transport in 
the same service, none of my configs would make sense for what you seem 
to be doing. I also don't use any antique versions of Postfix so my 
configs would break with your 2.6.6.


Beyond that, you really shouldn't blindly trust that a "working" config 
for a complex system like Postfix is going to be portable between sites. 
I manage multiple Postfix systems, but don't use identical Postfix 
configs on any 2 sites that accept mail over the network, even allowing 
for the obviously local settings like the various my* parameters.



Maybe somebody here will be able to support me.


Actual postconf -n output would be more useful, but I do see one 
problem:



smtpd_client_restrictions = permit_mynetworks, reject


That does exactly what it says.
It is not possible to recover from a REJECT in  
smtpd_client_restrictions by getting a PERMIT in any later restriction 
list, because you never evaluate the later restriction lists.

Re: New SASL generic failure

[Viktor Dukhovni]

> On Jul 11, 2016, at 9:27 AM, Rick Zeman  wrote:
> 
> Explicitly filtering in:
> 
> smtp_sasl_mechanism_filter = plain, login
> 
> did the trick.  I didn't need to filter out XOAUTH2.

Whether through an explicit deny, or by omission, either way
the effect is to disable XOAUTH2.  So the best hypothesis as
to the cause of the problem is that XOAUTH2 is supported and
preferred by Apple's SASL stack, but is not usable without
additional configuration and/or supporting application code.

So either Comcast added support for it recently, or your
machine was recently upgraded to support the new mechanism.

-- 
Viktor.

Re: New SASL generic failure

[Rick Zeman]

On Sat, Jul 9, 2016 at 9:57 AM, Viktor Dukhovni
 wrote:
>
>> On Jul 8, 2016, at 10:09 PM, Rick Zeman  wrote:
>>
>> How might 'filtering out that mechanism" be done, Viktor?  Doesn't
>> sound (or look like, based on SASL_README) that it's something done in
>> postfix.
>
> The first occurrence of the word "filter" in SASL_README is the section
> that describes filtering of SASL mechanisms in the Postfix SMTP client:
>
>http://www.postfix.org/SASL_README.html#client_sasl_filter
>
> You really should have been able to find this...

You are entirely correct:  I should have been able to find that (after
all, I was so close, and that was the readme I used when I set up the
damn thing), and I just missed it on my skim.  Explicitly filtering
in:

smtp_sasl_mechanism_filter = plain, login

did the trick.  I didn't need to filter out XOAUTH2.

As always, thank you, Viktor.

Re: server / client configuration for Authenticated Relay server

[Wietse Venema]

Please define "is not working".

Wietse

Re: Brutal attacks

[Allen Coates]

I found this in  "man iptables-extensions"


 Examples:

# allow 2 telnet connections per client host
  
 iptables  -A  INPUT  -p  tcp  --syn  --dport  23  -m   connlimit 
--connlimit-above 2 -j REJECT


It could be adapted to offer basic DoS protection for postfix.

Unfortunately my MXhost does not have the extension module   :-(

Allen C

server / client configuration for Authenticated Relay server

[Zalezny Niezalezny]

Dear Colleagues,

I`m trying to configure authenticated relay server (SASL) using RHEL
Postfix 2.6.6.

System will transport E-mails only from authenticated clients.
1) Most of that clients are in the same subnet, does it make sense to
authtenicate that clients with passwords ? Do we need to use sasl if host
is in the same subnet ?

2) How to understand, permit_mynetworks and permit_sasl_authenticated. If
host is mentioned in the mynetworks list, what will happend with it if we
will use that settings:

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject

Postfix will also ask for user name and password ?



 I`m strugling that topic since days and I do not how to manage that. SASL
documentation from Wietse I read already multiple times, but it still not
working.
Does any one can send me client / server (main.cf) config which is working.

Maybe somebody here will be able to support me.



Here is my client configuration main.cf:
# SASL client configuration
smtp_sasl_auth_enable = yes
smtp_tls_security_level = encrypt
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
#smtp_sasl_mechnism_filter = digest-md5
broken_sasl_auth_clients = yes

smtp_use_tls=yes
smtp_sasl_auth_enable = yes

# 


and here You have my server configuration:

#TLS Server configuration
smtpd_use_tls = yes
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/postfix/ssl/mail.domain.tld.key
smtpd_tls_cert_file = /etc/postfix/ssl/mail.domain.tld.crt
smtpd_tls_CAfile = /etc/postfix/ssl/cacert.pem
tls_random_source = dev:/dev/urandom
# SASL configuration - user authentication
smtpd_sasl_path = smtpd
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_mechanism_filter = plain, login

smtpd_client_restrictions = permit_mynetworks, reject
smtpd_helo_restrictions = reject_unknown_helo_hostname
smtpd_sender_restrictions = reject_unknown_sender_domain
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject
smtpd_recipient_restrictions = permit_sasl_authenticated, reject


My sasl configuration is located in /etc/postfix/sasl/smtpd.conf.
pwcheck_method: saslauthd
mech_list: PLAIN LOGIN


Thanks in advance for Your support


Zalezny

Re: Brutal attacks

[Benning, Markus]

On 2016-07-09 18:34, Robert Schetterer wrote:

additional fail2ban, but log parse was to slow at my side
and for sure use postscreen


Its possible to trigger fail2ban from a policyd:

https://www.mtpolicyd.org/documentation.html#Mail::MtPolicyd::Plugin::Fail2Ban


Markus
--
https://markusbenning.de/