Re: Prevent Backscatter

2017-01-21 Thread Postfix User
Bastian Blank-3 wrote
> On Fri, Jan 20, 2017 at 02:01:27PM -0700, Postfix User wrote:
>> check_sender_access $virtual_alias_maps,
> 
> You are creating an open relay, don't do that.

Actually I am not creating an open relay, $virtual_alias_maps contains only
internal addresses. When I try sending e-mail from not authenticated
internal user to external address, or from external to another external
address, I get "554 5.7.1 : Relay access denied"



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88375.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: logging username

2017-01-21 Thread Dusan Obradovic

> On Jan 21, 2017, at 07:31, Kiss Gabor (Bitman)  wrote:
> 
> My logs are fullfilled with this:
> 
> Jan 20 20:05:26 linzer postfix/smtpd[22308]: warning: hostname 
> c942452695-cloudp
> ro-214859053.cloudatcost.com does not resolve to address 167.88.40.162: Name 
> or 
> service not known
> Jan 20 20:05:26 linzer postfix/smtpd[22308]: connect from 
> unknown[167.88.40.162]
> Jan 20 20:05:28 linzer postfix/smtpd[22308]: warning: unknown[167.88.40.162]: 
> SA
> SL login authentication failed: authentication failure
> Jan 20 20:05:29 linzer postfix/smtpd[22308]: lost connection after AUTH from 
> unk
> nown[167.88.40.162]
> Jan 20 20:05:29 linzer postfix/smtpd[22308]: disconnect from 
> unknown[167.88.40.1
> 62]
> 
> Is there any way to know what username was used in these attempts.
> (An existing one every time or they are choosen from a dictionary?)
> 
> Gabor
> -- 
> The Meaning of Life of Brian

saslauthd is likely logging failure via LOG_AUTH facility, see 
/var/log/auth.log or /var/log/secure.

Re: Prevent Backscatter

2017-01-21 Thread Viktor Dukhovni
On Sat, Jan 21, 2017 at 04:38:57AM -0700, Postfix User wrote:

> Bastian Blank-3 wrote
> > On Fri, Jan 20, 2017 at 02:01:27PM -0700, Postfix User wrote:
> >> check_sender_access $virtual_alias_maps,
> > 
> > You are creating an open relay, don't do that.
> 
> Actually I am not creating an open relay,

Actually, if when a sender-address access(5) table appears before
reject_unauth_destination in smtpd_relay_restrictions (Postfix >=
2.10) or in smtpd_recipient_restrictions (Postfix <= 2.9) then you
would be creating an open-relay, since the attacker can forge any
sender address of his choice.

However, more critically, the virtual(5) table is NOT an access(5)
table.  The result associated with each lookup key in virtual(5)
is an email address, not "OK", "REJECT", "DUNNO", which are in
turn not especially valid email addresses.

Secondly if "$virtual_alias_maps" where to list contains multiple
tables or no tables, you get unexpected results or syntax errors
respectively.

Therefore, "check_sender_access $virtual_alias_maps" is rather
wrong.

-- 
Viktor.


Re: logging username

2017-01-21 Thread Wietse Venema
Kiss Gabor (Bitman):
> My logs are fullfilled with this:
> 
> Jan 20 20:05:26 linzer postfix/smtpd[22308]: warning: hostname 
> c942452695-cloudp
> ro-214859053.cloudatcost.com does not resolve to address 167.88.40.162: Name 
> or 
> service not known
> Jan 20 20:05:26 linzer postfix/smtpd[22308]: connect from 
> unknown[167.88.40.162]
> Jan 20 20:05:28 linzer postfix/smtpd[22308]: warning: unknown[167.88.40.162]: 
> SA
> SL login authentication failed: authentication failure
> Jan 20 20:05:29 linzer postfix/smtpd[22308]: lost connection after AUTH from 
> unk
> nown[167.88.40.162]
> Jan 20 20:05:29 linzer postfix/smtpd[22308]: disconnect from 
> unknown[167.88.40.1
> 62]
> 
> Is there any way to know what username was used in these attempts.
> (An existing one every time or they are choosen from a dictionary?)

The user name is in the SASL protocol messages. Postfix does not
implement the SASL protocol, it just passes the bits to Cyrus SASL
or Dovecot Auth. 

Perhaps you can configure Cyrus SASL or Dovecot Auth to log it.

Wietse


Re: Prevent Backscatter

2017-01-21 Thread Charles Marcus
Maybe I'm blind, but I don't see any recipient restrictions at all

On January 20, 2017 5:41:29 PM EST, Postfix User  wrote:
>My test procedure follows
>telnet domain.com 25
>ehlo me
>mail from: 
>rcpt to: 
>At this point I get "Ok" message, and I can continue writing the body
>of the
>e-mail. Because account doesn't exist, Postfix sends bounce
>notification
>back to sender address. 
>
>This is the output of postconf -n
>
>append_dot_mydomain = no
>biff = no
>broken_sasl_auth_clients = yes
>config_directory = /etc/postfix
>dovecot_destination_recipient_limit = 1
>inet_interfaces = all
>inet_protocols = ipv4
>mailbox_size_limit = 0
>message_size_limit = 10240
>milter_default_action = accept
>milter_protocol = 2
>mydestination = localhost
>myhostname = domain.com
>mynetworks = 127.0.0.0/8
>non_smtpd_milters = inet:localhost:8891
>readme_directory = no
>recipient_delimiter = +
>relayhost =
>resolve_numeric_domain = yes
>smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
>smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
>smtpd_milters = inet:localhost:8891
>smtpd_relay_restrictions = permit_mynetworks,
>permit_sasl_authenticated,
>check_sender_access $virtual_alias_maps, reject_unauth_destination
>smtpd_sasl_auth_enable = yes
>smtpd_sasl_path = private/auth
>smtpd_sasl_security_options = noanonymous
>smtpd_sasl_tls_security_options = noanonymous
>smtpd_sasl_type = dovecot
>smtpd_tls_CAfile = /etc/ssl/certs/domain.com.chain.crt
>smtpd_tls_cert_file = /etc/ssl/certs/domain.com.crt
>smtpd_tls_key_file = /etc/ssl/private/domain.com.key
>smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
>smtpd_use_tls = yes
>virtual_alias_maps = mysql:/etc/postfix/sqlconf/virtual_mailbox_maps.cf
>virtual_mailbox_domains = mysql:/etc/postfix/sqlconf/mydestination.cf
>virtual_transport = dovecot
>
>
>
>--
>View this message in context:
>http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88372.html
>Sent from the Postfix Users mailing list archive at Nabble.com.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [postfix-users] logging username

2017-01-21 Thread Kiss Gabor (Bitman)
> > Is there any way to know what username was used in these attempts.
> > (An existing one every time or they are choosen from a dictionary?)

> saslauthd is likely logging failure via LOG_AUTH facility, see 
> /var/log/auth.log or /var/log/secure.

Bingo! :-)
Names came from dictionary.
Thanks.

Gabor


Re: Prevent Backscatter

2017-01-21 Thread Postfix User
Thanks for the tips Viktor,

For some reason the order of restrictions in smtpd_relay_restrictions
(Postfix 2.11.0) was wrong. Luckily expected check_sender_access values are
not valid email addresses. After I fix both problems I will post a new
postconf -n output.

Robin


Viktor Dukhovni wrote
> On Sat, Jan 21, 2017 at 04:38:57AM -0700, Postfix User wrote:
> 
>> Bastian Blank-3 wrote
>> > On Fri, Jan 20, 2017 at 02:01:27PM -0700, Postfix User wrote:
>> >> check_sender_access $virtual_alias_maps,
>> > 
>> > You are creating an open relay, don't do that.
>> 
>> Actually I am not creating an open relay,
> 
> Actually, if when a sender-address access(5) table appears before
> reject_unauth_destination in smtpd_relay_restrictions (Postfix >=
> 2.10) or in smtpd_recipient_restrictions (Postfix <= 2.9) then you
> would be creating an open-relay, since the attacker can forge any
> sender address of his choice.
> 
> However, more critically, the virtual(5) table is NOT an access(5)
> table.  The result associated with each lookup key in virtual(5)
> is an email address, not "OK", "REJECT", "DUNNO", which are in
> turn not especially valid email addresses.
> 
> Secondly if "$virtual_alias_maps" where to list contains multiple
> tables or no tables, you get unexpected results or syntax errors
> respectively.
> 
> Therefore, "check_sender_access $virtual_alias_maps" is rather
> wrong.
> 
> -- 
>   Viktor.





--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88384.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: Prevent Backscatter

2017-01-21 Thread Postfix User
You are right, there are no recipient restrictions, except
permit_sasl_authenticated restricting remote recipients for authenticated
clients only.



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88385.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: Prevent Backscatter

2017-01-21 Thread Postfix User
Postfix User wrote
> After I fix both problems I will post a new postconf -n output.

I removed completely check_sender_access, it is not required anymore.


Wietse Venema wrote
> Is your server MX host for domains that are delivered to a different
> mail server?
> If not:
> Set relay_domains to empty.
> If yes:
> DO Specify ONLY THOSE DOMAINS in relay_domains
> DO specify ONLY THOSE recipients in relay_recipient_maps
> 
> DO NOT specify virtual (alias or mailbox) stuff in relay_domains
> 
> DO NOT specify virtual (alias or mailbox) stuff in relay_recipient_maps
> 
> DO specify virtual alias DOMAINS in virtual_alias_DOMAINS. 

After specifying virtual_alias_domains, all messages sent from remote to
local addresses are answered with error bounce message "User unknown in
virtual alias table". I removed this line temporarily, and I set
relay_domains to empty.

At the moment all works like expected, except the backscatter problem. This
is latest postconf

append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
dovecot_destination_recipient_limit = 1
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
message_size_limit = 10240
milter_default_action = accept
milter_protocol = 2
mydestination = localhost
myhostname = domain.com
mynetworks = 127.0.0.0/8
non_smtpd_milters = inet:localhost:8891
readme_directory = no
recipient_delimiter = +
relay_domains =
relayhost =
resolve_numeric_domain = yes
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters = inet:localhost:8891
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CAfile = /etc/ssl/certs/domain.com.chain.crt
smtpd_tls_cert_file = /etc/ssl/certs/domain.com.crt
smtpd_tls_key_file = /etc/ssl/private/domain.com.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_alias_maps = mysql:/etc/postfix/sqlconf/virtual_mailbox_maps.cf
virtual_mailbox_domains = mysql:/etc/postfix/sqlconf/mydestination.cf
virtual_transport = dovecot



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88386.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: Prevent Backscatter

2017-01-21 Thread Wietse Venema
Postfix User:
> smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
> reject_unauth_destination

This will be an open relay if all your SMTP mail is logged with the
same client IP address, i.e. your SMTP mail comes from some box
that is in mynetworks, and Postfix never sees the original SMTP
client IP address.

Wietse


Re: Prevent Backscatter

2017-01-21 Thread Postfix User
Wietse Venema wrote
> This will be an open relay if all your SMTP mail is logged with the
> same client IP address, i.e. your SMTP mail comes from some box
> that is in mynetworks, and Postfix never sees the original SMTP
> client IP address.

I can remove permit_mynetworks, but only trusted people that have direct
access to the server or authenticated webmail users can send from localhost



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Prevent-Backscatter-tp88359p88388.html
Sent from the Postfix Users mailing list archive at Nabble.com.


Re: Prevent Backscatter

2017-01-21 Thread Wietse Venema
Wietse Venema:
> Postfix User:
> > smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated,
> > reject_unauth_destination
> 
> This will be an open relay if all your SMTP mail is logged with the
> same client IP address, i.e. your SMTP mail comes from some box
> that is in mynetworks, and Postfix never sees the original SMTP
> client IP address.

Meh, that wasn't the problem.

Wietse