Re: email address (u...@domain.tld) as username?
Stefan Foerster: > * Viktor Dukhovni : > > On Sat, Sep 28, 2013 at 12:47:22PM +0200, Peer Heinlein wrote: > > > Use dovecot with a simple passwd-file-setup in /etc/dovecot/userdb and a > > > simple relay-domains setup in Postfix and you'll be ready after half an > > > hour. > > > > Generally, with dovecot delivery to local files, the destination domain > > should be a virtual mailbox domain, not a relay domain. > > Can you explain the main differences with those two setups? Whether > the domain that is served by dovecot is in virtual_mailbox_domains or > relay_domains doesn't seem to make much of a difference. mydestination, virtual_mailbox_domains are preferred for final delivery. Here. Postfix is the final MTA. Example: postfix->dovecot. relay_domains is preferred for transit mail. Here, Postfix is not the final MTA. Example: postfix->exchange. Under the covers it is all bits and you can hook up Dovecot or Exchange in any address class, virtual, relay, whatever. Wietse
Re: email address (u...@domain.tld) as username?
On Wed, Oct 02, 2013 at 08:25:48AM +0200, Stefan Foerster wrote:
> * Viktor Dukhovni :
> > On Sat, Sep 28, 2013 at 12:47:22PM +0200, Peer Heinlein wrote:
> > > Use dovecot with a simple passwd-file-setup in /etc/dovecot/userdb and a
> > > simple relay-domains setup in Postfix and you'll be ready after half an
> > > hour.
> >
> > Generally, with dovecot delivery to local files, the destination domain
> > should be a virtual mailbox domain, not a relay domain.
>
> Can you explain the main differences with those two setups? Whether
> the domain that is served by dovecot is in virtual_mailbox_domains or
> relay_domains doesn't seem to make much of a difference.
Others will *understand* your configuration. When you need actual
relay domains in the future, there'll be a sensible address class
to add them to that is not already overloaded for an unrelated
purpose.
> virtual_mailbox_domains = example.com
> virtual_mailbox_maps = ${map}vmbox
> virtual_transport = dovecot
This is cleaner, no need for a transport entry for each domain.
> relay_domains = example.com
> relay_recipient_maps = ${map}vmbox
> transport_maps = ${map}/foo
> # and there: "example.com dovecot:" or
> # "example.com lmtp:..."
>
> Granted, when LMTP delivery is used, the second setup makes it easier
> to use dynamic recipient verification, but apart from that, with maps
> available for Postfix... what's the difference? Both solutions seem
> pretty equivalent to me.
Even with LMTP delivery, I'd use virtual mailbox domains, an LMTP
delivery is not an SMTP relay hop. You can do dynamic recipient
verification with either address class.
--
Viktor.
Disabling SMTP Auth per user
We are currently using dovecot for smtp auth, and due to an increase in spammers abusing smtp auth we setup dovecot to return an invalid login for user's that have been set to "disabled" in our provisioning system. This seemed to work for a while (preventing spammers that are using auth), but we are finding that a number of spammers are somehow keeping their smtp connection open after we have "disabled" smtp auth and continuing to send messages even though the authentication should be failing. We are not sure why this is the behavior or even what we should be looking for to determine how they are circumventing the authentication. postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases broken_sasl_auth_clients = yes command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 default_destination_recipient_limit = 1000 default_process_limit = 1000 header_checks = regexp:/etc/postfix/header_checks html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailbox_size_limit = 52224000 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 52224000 mydestination = $myhostname, localhost.$mydomain, localhost myhostname = server.domain.tld mynetworks = $config_directory/mynetworks newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES recipient_bcc_maps = hash:/etc/postfix/recipient_bcc relayhost = relay.domain.tld sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_data_done_timeout = 900s smtp_data_init_timeout = 900s smtp_data_xfer_timeout = 900s smtp_helo_timeout = 900s smtp_mail_timeout = 900s smtp_tls_note_starttls_offer = yes smtpd_client_event_limit_exceptions = static:all smtpd_helo_required = yes smtpd_recipient_restrictions = permit_mynetworks, check_client_access mysql:/etc/postfix/authb4smtp.cf, check_client_access cidr:/etc/postfix/access permit_sasl_authenticated, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_sender_restrictions = reject_unknown_sender_domain, reject_non_fqdn_sender,permit smtpd_tls_CAfile = /etc/postfix/tls.ca.crt smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/postfix/tls.crt smtpd_tls_key_file = /etc/postfix/tls.key smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_cache smtpd_tls_session_cache_timeout = 3600s tls_random_source = dev:/dev/urandom unknown_local_recipient_reject_code = 550
Re: Disabling SMTP Auth per user
On Wed, Oct 02, 2013 at 10:17:16AM -0500, List wrote: > We are currently using dovecot for smtp auth, and due to an increase > in spammers abusing smtp auth we setup dovecot to return an invalid > login for user's that have been set to "disabled" in our > provisioning system. This seemed to work for a while (preventing > spammers that are using auth), but we are finding that a number of > spammers are somehow keeping their smtp connection open after we > have "disabled" smtp auth and continuing to send messages even > though the authentication should be failing. We are not sure why > this is the behavior or even what we should be looking for to > determine how they are circumventing the authentication. The full story is in your logs. Find a message sent by a disabled user after the account was disabled. Find the associated stmpd(8) connect and disconnect log entries. If a single connection continues to generate messages long after the account is disabled, then indeed your description is correct. Regardless of whether you've disabled an account or not, you should probably use a policy service that limits the message rate from a a given SASL user account (returning a 421 error code when the rate is exceeded). The policy service can also check whether the account has been disabled. This check will not be cached (unlike the SASL login status of the SMTP connection). -- Viktor.
Re: Disabling SMTP Auth per user
On 10/2/13 10:32 AM, Viktor Dukhovni wrote:
On Wed, Oct 02, 2013 at 10:17:16AM -0500, List wrote:
We are currently using dovecot for smtp auth, and due to an increase
in spammers abusing smtp auth we setup dovecot to return an invalid
login for user's that have been set to "disabled" in our
provisioning system. This seemed to work for a while (preventing
spammers that are using auth), but we are finding that a number of
spammers are somehow keeping their smtp connection open after we
have "disabled" smtp auth and continuing to send messages even
though the authentication should be failing. We are not sure why
this is the behavior or even what we should be looking for to
determine how they are circumventing the authentication.
The full story is in your logs. Find a message sent by a disabled
user after the account was disabled. Find the associated stmpd(8)
connect and disconnect log entries. If a single connection continues
to generate messages long after the account is disabled, then indeed
your description is correct.
Regardless of whether you've disabled an account or not, you should
probably use a policy service that limits the message rate from a
a given SASL user account (returning a 421 error code when the rate
is exceeded). The policy service can also check whether the account
has been disabled. This check will not be cached (unlike the SASL
login status of the SMTP connection).
Indeed, we are actually writing a policy service now to deal with rate
limits and blacklisting/whitelisting SASL. One thing I noticed in the
documentation regarding smtpd_recipient_restrictions (under " Dangerous
use of smtpd_recipient_restrictions") is that recipient restrictions can
result in too permissive access. I wonder if moving the
check_client_access and permit_sasl_authenticated below
reject_unauth_destination would help?
smtpd_recipient_restrictions =
Permit networks defined in /etc/postfix/mynetworks
permit_mynetworks
reject_unauth_destination
POP/IMAP before SMTP
check_client_access mysql:/etc/postfix/authb4smtp.cf
check_client_access cidr:/etc/postfix/access
Permit SASL authenticated
permit_sasl_authenticated
Also I understand that smtp_client_restrictions is the first to be
evaluated, would it make sense to move the permit_sasl_authenticated
into this access restriction or not so much?
Re: Disabling SMTP Auth per user
On Wed, Oct 02, 2013 at 10:46:12AM -0500, List wrote: > One thing I noticed > in the documentation regarding smtpd_recipient_restrictions (under " > Dangerous use of smtpd_recipient_restrictions") is that recipient > restrictions can result in too permissive access. I wonder if > moving the check_client_access and permit_sasl_authenticated below > reject_unauth_destination would help? Don't. > > smtpd_recipient_restrictions = > Permit networks defined in /etc/postfix/mynetworks >permit_mynetworks >reject_unauth_destination > POP/IMAP before SMTP >check_client_access mysql:/etc/postfix/authb4smtp.cf >check_client_access cidr:/etc/postfix/access > Permit SASL authenticated >permit_sasl_authenticated Too late, their outbound mail has already been rejected. > Also I understand that smtp_client_restrictions is the first to be > evaluated, would it make sense to move the permit_sasl_authenticated > into this access restriction or not so much? No. Take time to understand how Postfix restrictions work. With Postfix 2.10 or later you can use "smtpd_relay_restrictions" to avoid being an open relay, and do anti-spam control in the various other restriction classes. Some duplication of permissive controls is then inevitable, but you're no longer at risk of becoming an open relay due to ordering problems. -- Viktor.
Re: Disabling SMTP Auth per user
On 10/02/2013 05:46 PM, List wrote: I wonder if moving the check_client_access and permit_sasl_authenticated below reject_unauth_destination would help? Moving 'check_client_access' below 'reject_unauth_destination' prevents you from wildcards in 'check_client_access' which can make you an open relay. Just best practice and not a must. smtpd_recipient_restrictions = Permit networks defined in /etc/postfix/mynetworks permit_mynetworks reject_unauth_destination POP/IMAP before SMTP check_client_access mysql:/etc/postfix/authb4smtp.cf check_client_access cidr:/etc/postfix/access Permit SASL authenticated permit_sasl_authenticated I'm wondering what 'permit_sasl_authenticated' effects? If you have already rejected unauth destination. Keep in mind "Restrictions are applied in the order as specified; the first restriction that matches wins". Also I understand that smtp_client_restrictions is the first to be evaluated, would it make sense to move the permit_sasl_authenticated into this access restriction or not so much? Do you mean 'smtpd_client_restrictions'? Since 'reject_unauth_destination' is not allowed in 'smtpd_client_restrictions' you will need 'permit_sasl_authenticated' in 'smtpd_recipient_restrictions' too. In general 'smtpd_client_restrictions' is not want you want. You don't want client side authentication. You want authentication for sending mails, I think. Finally authenticated users via 'permit_sasl_authenticated' can avoid 'spam checking', 'policy, gray listing' as early as it is checked. But that is only relevant for 'smtpd_relay_restrictions' http://www.postfix.org/SMTPD_ACCESS_README.html Manuel Bieling
Re: Disabling SMTP Auth per user
On Wed, Oct 02, 2013 at 07:08:48PM +0200, Manuel Bieling wrote: > >I wonder if moving the > >check_client_access and permit_sasl_authenticated below > >reject_unauth_destination would help? > > Moving 'check_client_access' below 'reject_unauth_destination' > prevents you from wildcards in 'check_client_access' which can make > you an open relay. Just best practice and not a must. No, it simply breaks POP before SMTP. So the original order is correct. However, now that we see that the OP is using POP before SMTP, it is quite likely the POP before SMTP cache, rather than SMTP auth that is at issue with the spammers in question. Once SASL is up and running, it is wise to stop supporting the POP before SMTP crutch. -- Viktor.
postfix hardening - what can we do?
>From my understanding of the way postfix currently operates, there is no smtpd/stmp TLS setting that can be set that would provide a configuration that would result in a more 'hardened' configuration, without causing interoperability problems. If I am wrong, I'm very interested in knowing where. A more hardened configuration would be something like promoting non-broken ciphers/protocols, refusing with meaningful rejections connections and not reverting to cleartext from MTAs that are either running software that is so out-of-date as to be guaranteed-compromised, or they are subject to a downgrade attack by an MITM. I think the only things that can reasonably be done right now are to set: smtp_tls_fingerprint_digest = sha1 smtpd_tls_eecdh_grade = ultra neither of those are particularly great improvements. What are some ways that we could improve the situation? One obvious one to me is that Postfix should allow for DH parameters that are larger than 1024bit, 512bit is a joke, and 1024bit is not strong enough. At the moment, these are the only two options. In my opinion, the flexibility here is too constrained, merely adding a 2048bit setting means that eventually you need to add a higher setting. Perhaps it is not possible to have a flexible and configurable bit length here? What other changes could we come up with that could improve the state of things? * SMTP servers should provide a mechanism for rejecting a cleartext or poor ciphersuite connections from clients without compromising delivery. * SMTP clients need a clear and unambiguous signal that they can note that tells them not to try fallback behaviors when connecting to [certain hosts|MXes for certain domains] - using a hand-maintained tls_policy table isn't going to cut it. * think bigger: out-of-band signalling, global lookup tables, internal TOFU-style caches of best-transport-status-achieved-per-peer, etc. figuring out the parameters of what would need to be stored/retained, how it would be bound to peers (e.g. by IP address, by EHLO name, by MX name, by delivery zone, etc), how it would be shared/propagated between servers (if at all), and how it would distinguish intentional key rollover/expiry from MITM. These would take a lot of work, and a lot of buy-in, but could really step up the game and pave the way for tougher blacklist-style hardening in the future
Re: Disabling SMTP Auth per user
On 10/02/2013 07:12 PM, Viktor Dukhovni wrote: However, now that we see that the OP is using POP before SMTP Aha I see, interesting relict Manuel Bieling
Re: postfix hardening - what can we do?
Micah Anderson: > > From my understanding of the way postfix currently operates, there is no > smtpd/stmp TLS setting that can be set that would provide a > configuration that would result in a more 'hardened' configuration, > without causing interoperability problems. If I am wrong, I'm very > interested in knowing where. You can certainly narrow things on the Postfix SMTP client side, and set up hardened TLS profiles for sites that you care about with mandatory parameters that don't permit downgrade attacks. On the SMTP server side things are not that simple. Why do you care that some random stranger encrypts their mail that you might not even want? Let the client worry about that. Wietse
Does my configuration reflect the current best practices?
Hello friends, I used The Book of Postfix (thanks Ralf!) to help configure the installation of Postfix for my website. I would like to ask the community to examine closely for any flaws or weaknesses in the form I have it now. I have two domains: timothylegg.com cherokeenewtestament.org that I collect mail for. There will be couple others in the future. I have a username on this machine that I log in with, but choose to not have that username be an e-mail address. Instead, I use 'tdl' for the first and 'cnt' for the second. For the first domain, I may have multiple addresses that I use for different mailing lists that end up being sorted into a single file (mbox). All my configuration is described in this text file located on my domain. http://www.timothylegg.com/postfix.txt http://www.timothylegg.com/postfix.txt&lang=en Given my configuration, does anybody see any exploits or weaknesses? I'm not sure of myself that I have done all that I need to. If I am clear here, I'll mo ve on towards Dovecot so I can get Squirrelmail working. I welcome your thoughts and appreciate your effort. Tim Legg
Re: Does my configuration reflect the current best practices?
I am so sorry, mail.com seems to have stripped out every one of my carriage returns! Never seen that before. You'd think they'd have that figured out... I switched to text from HTML formatting. I'll reformat the message below. Tim Legg - Original Message - Hello friends, I used The Book of Postfix (thanks Ralf!) to help configure the installation of Postfix for my website. I would like to ask the community to examine closely for any flaws or weaknesses in the form I have it now. I have two domains: timothylegg.com cherokeenewtestament.org that I collect mail for. There will be couple others in the future. I have a username on this machine that I log in with, but choose to not have that username be an e-mail address. Instead, I use 'tdl' for the first and 'cnt' for the second. For the first domain, I may have multiple addresses that I use for different mailing lists that end up being sorted into a single file (mbox). All my configuration is described in this text file located on my domain. http://www.timothylegg.com/postfix.txt Given my configuration, does anybody see any exploits or weaknesses? I'm not sure of myself that I have done all that I need to. If I am clear here, I'll move on towards Dovecot so I can get Squirrelmail working. I welcome your thoughts and appreciate your effort. Tim Legg
Re: Does my configuration reflect the current best practices?
On 10/02/2013 10:39 PM, Tim Legg wrote: I have a username on this machine that I log in with, but choose to not have that username be an e-mail address. Hopefully this user is not called root. I recommend to disable root login. And I also recommend to disable any other user how has an e-mail address. Actually I recommend to disable password login at all. HTTP/S and SMTP on the same machine? Given my configuration, does anybody see any exploits or weaknesses? Didn't read I'm not sure of myself that I have done all that I need to. Monitoring will show you where you are now. Security is a process. Manuel Bieling (layman)
Re: postfix hardening - what can we do?
On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote: > From my understanding of the way postfix currently operates, there is no > smtpd/stmp TLS setting that can be set that would provide a > configuration that would result in a more 'hardened' configuration, > without causing interoperability problems. If I am wrong, I'm very > interested in knowing where. You get no benefit from hardening the Postfix SMTP server on port 25 (tighter mandatory parameters on the submission port may work for some). This has little to do with Postfix and everything to do with the fact that SMTP servers accept messages from total strangers (many of the clients don't support TLS at all). > smtp_tls_fingerprint_digest = sha1 This setting hardly matters, but with OpenSSL 1.0.0 or later, or with current Postfix releases, you can also use "sha256" if you like. The sha1 digest is quite resistant to second preimage attacks, even "md5" is reasonably secure in this context. > smtpd_tls_eecdh_grade = ultra Perhaps, though if the NIST curves are "cooked", it is not clear that 512 bits is better than 256, and if not, then 256 may well be enough. Here you need new non-suspect curves, and none are described in relevant RFCs or available in OpenSSL at this time. > What are some ways that we could improve the situation? You could disable SSLv3 in the SMTP client, and use only TLSv1, TLSv1.1 or TLSv1.2. > One obvious one to me is that Postfix should allow for DH parameters > that are larger than 1024bit, 512bit is a joke, and 1024bit is not > strong enough. Neither Postfix nor OpenSSL actually care about the size of the prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits, and likely get away with it. See recent thread on Exim TLS interop. YMMV, some clients may choke on 2048-bit EDH (though more typically these limited implementations are in are browsers, ... not MTAs). > At the moment, these are the only two options. In my > opinion, the flexibility here is too constrained, merely adding a > 2048bit setting means that eventually you need to add a higher > setting. OpenSSL needs to tell Postfix which grade is appropriate for a given session. It does not. The cipher-suite is either "export" or "non-export", and OpenSSL requests a corresponding EDH curve. We should perhaps have called these parameters: # 512 bits smtpd_tls_dh_export_param_file # 1024 bits historically, but possibly larger smtpd_tls_dh_param_file > Perhaps it is not possible to have a flexible and configurable > bit length here? It is not, until OpenSSL introduces a new callback that communicates a more fine-grained security requirement to the application. > What other changes could we come up with that could improve the state of > things? Implement DNSSEC for your domain and publish DANE TLSA RRs: example.com. IN MX 0 mail.example.com. mail.example.com IN TLSA 3 1 1 ... plus appropriate RRSIG records ... > * SMTP servers should provide a mechanism for rejecting a cleartext or > poor ciphersuite connections from clients without compromising delivery. Only with submission. Rejecting weak TLS on port 25 is counter-productive, the message is resent in the clear! > * SMTP clients need a clear and unambiguous signal that they can note > that tells them not to try fallback behaviors when connecting to > [certain hosts|MXes for certain domains] - using a hand-maintained > tls_policy table isn't going to cut it. That's what DANE TLSA is for. Deploy Postfix 2.11-20130825 or later, on a platform where OpenSSL is 1.0.0 or later (and EC algorithms are not disabled is in Fedora or RedHat), make sure /etc/resolv.conf points at 127.0.0.1 and that resolver is a DNSSEC validating one. Then in main.cf: smtp_dns_support_level = dnssec smtp_tls_security_level = dane -- Viktor.
dkimproxy signing
I have a working postfix server (2.8.11) which looks for incoming mail on socket, localhost, and my local network. It is also listening on port 587 for authenticated users and on port 25 for WAN input. I installed dkproxy (dkimproxy.sourceforge.net) so I can sign my outgoing mail. I have it working after a fashion. Correctly, I am not signing anything that comes in from the internet on port 25. But I am signing everything that comes in on all the other sockets/ports even if the final destination is local or virtual. This is clearly unnecessary, but I cannot figure out how to sign only those emails not being delivered locally or virtually. Here is the relevent piece of master.cf smtpunix - - n - - smtp 127.0.0.1:smtpinetn-n--smtpd -o content_filter=dksign:[127.0.0.1]:10027 # LAN clients 10.0.1.128:smtpinetn-n--smtpd -o myhostname=maila.office -o smtp_bind_address=10.0.1.128 -o content_filter=dksign:[127.0.0.1]:10027 # Authenticated clients from the WAN :587inetn-n--smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o content_filter=dksign:[127.0.0.1]:10027 -o smptd_client_restrictions=permit_sasl_authenticated,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject # General, unautenticated mail from the WAN (no relaying permitted) :smtp inetn-n--smtpd -o content_filter=smtp-amavis:127.0.0.1:10024 # mail to be dkim signed via content_filter dksignunix - - n - 4 smtp -o smtp_send_xforward_command=yes -o smtp_discard_ehlo_keywords=8bitmime,starttls And Postconf -n alias_maps = hash:/etc/aliases biff = no broken_sasl_auth_clients = no config_directory = /etc/postfix daemon_directory = /usr/lib/postfix default_privs = nobody mail_owner = postfix mydomain = mydomain.com myhostname = host.mydomain.com mynetworks = 127.0.0.0/24 10.0.1.0/24 setgid_group = maildrop smtp_bind_address = smtp_sasl_mechanism_filter = plain smtp_tls_security_level = may smtpd_reject_unlisted_recipient = yes smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_CApath = /etc/postfix/certs/ smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/postfix/ssl/maila-cert.pem smtpd_tls_key_file = /etc/postfix/ssl/maila-key.pem smtpd_tls_received_header = yes smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache tls_random_source = dev:/dev/urandom virtual_alias_maps = pgsql:/etc/postfix/pg_virtual.cf virtual_gid_maps = pgsql:/etc/postfix/pg_gids.cf virtual_mailbox_base = /var/spool/vmail/ virtual_mailbox_domains = pgsql:/etc/postfix/pg_domains.cf virtual_mailbox_limit = 0 virtual_mailbox_maps = pgsql:/etc/postfix/pg_mailbox.cf virtual_transport = maildrop virtual_uid_maps = pgsql:/etc/postfix/pg_uids.cf Lynn -- Lynn Dobbs Chief Technical Officer CreditLink Corporation
Re: postfix hardening - what can we do?
Viktor Dukhovni writes: > On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote: > >> From my understanding of the way postfix currently operates, there is no >> smtpd/stmp TLS setting that can be set that would provide a >> configuration that would result in a more 'hardened' configuration, >> without causing interoperability problems. If I am wrong, I'm very >> interested in knowing where. > > You get no benefit from hardening the Postfix SMTP server on port > 25 (tighter mandatory parameters on the submission port may work > for some). This has little to do with Postfix and everything to > do with the fact that SMTP servers accept messages from total > strangers (many of the clients don't support TLS at all). Agreed. I suppose there is no way to achieve some middle ground of doing opportunistic encryption, but for those who are only talking with bad protocols and ciphers (or clear-text) do a non-permanent failure with a message about their bad protocol so at least some admin eventually may see that information (perhaps when the user complains that their messages are slow to be delivered). A more way would be to do a permanent reject, causing a bounce with a message that might cause some complaints to the admin. >> smtp_tls_fingerprint_digest = sha1 > > This setting hardly matters, but with OpenSSL 1.0.0 or later, or > with current Postfix releases, you can also use "sha256" if you > like. The sha1 digest is quite resistant to second preimage attacks, > even "md5" is reasonably secure in this context. > >> smtpd_tls_eecdh_grade = ultra > > Perhaps, though if the NIST curves are "cooked", it is not clear > that 512 bits is better than 256, and if not, then 256 may well be > enough. Here you need new non-suspect curves, and none are described > in relevant RFCs or available in OpenSSL at this time. When you say 'Here you need new non-suspect curves' - do you mean with using eecdh ciphers in general? If there is suspicion that they are cooked, maybe these should be disabled? >> What are some ways that we could improve the situation? > > You could disable SSLv3 in the SMTP client, and use only TLSv1, > TLSv1.1 or TLSv1.2. Do you mean in the MUA, or in the 'smtp' configurations in postfix? If the latter, what happens when you disable SSLv3 and connect to a remote MTA to make a delivery and they do not support anything but SSLv3? >> One obvious one to me is that Postfix should allow for DH parameters >> that are larger than 1024bit, 512bit is a joke, and 1024bit is not >> strong enough. > > Neither Postfix nor OpenSSL actually care about the size of the > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits, > and likely get away with it. See recent thread on Exim TLS interop. > YMMV, some clients may choke on 2048-bit EDH (though more typically > these limited implementations are in are browsers, ... not MTAs). Interesting, what interoperability problems are there here? If you set the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a client chokes on this? Does it fall back to clear text, or a non-EDH cipher, or does it cause a connection reset... or? > Implement DNSSEC for your domain and publish DANE TLSA RRs: > > example.com. IN MX 0 mail.example.com. > mail.example.com IN TLSA 3 1 1 > ... plus appropriate RRSIG records ... Agreed here! >> * SMTP servers should provide a mechanism for rejecting a cleartext or >> poor ciphersuite connections from clients without compromising delivery. > > Only with submission. Rejecting weak TLS on port 25 is > counter-productive, the message is resent in the clear! Yeah, this is too bad. >> * SMTP clients need a clear and unambiguous signal that they can note >> that tells them not to try fallback behaviors when connecting to >> [certain hosts|MXes for certain domains] - using a hand-maintained >> tls_policy table isn't going to cut it. > > That's what DANE TLSA is for. Deploy Postfix 2.11-20130825 or > later, on a platform where OpenSSL is 1.0.0 or later (and EC > algorithms are not disabled is in Fedora or RedHat), make sure > /etc/resolv.conf points at 127.0.0.1 and that resolver is a DNSSEC > validating one. Then in main.cf: > > smtp_dns_support_level = dnssec > smtp_tls_security_level = dane Thanks for your answers! micah
Re: postfix hardening - what can we do?
On Wed, Oct 02, 2013 at 07:38:42PM -0400, micah wrote: > I suppose there is no way to achieve some middle ground of doing > opportunistic encryption, but for those who are only talking with bad > protocols and ciphers (or clear-text) do a non-permanent failure with a > message about their bad protocol so at least some admin eventually may > see that information (perhaps when the user complains that their > messages are slow to be delivered). What would be the point? You accept plaintext mail, but reject mail encrypted with algorithms vulnerable to a costly, but not infeasible brute-force effort? > > > smtpd_tls_eecdh_grade = ultra > > > > Perhaps, though if the NIST curves are "cooked", it is not clear > > that 512 bits is better than 256, and if not, then 256 may well be > > enough. Here you need new non-suspect curves, and none are described > > in relevant RFCs or available in OpenSSL at this time. > > When you say 'Here you need new non-suspect curves' - do you mean with > using eecdh ciphers in general? If there is suspicion that they are > cooked, maybe these should be disabled? I don't have anything substantive to say on the topic of the NIST EC curves. All I know is that some people no longer trust them, apparently not because they know the curves have backdoors, but because they no longer trust the good faith of those who proposed the curve parameters. The magic PRNG seed constants that generate the "verifiably random" curve parameters remain a mystery. They could be simply random in the first place, or the SHA-1 digests of some (unpublished) inside joke, or the result of exhaustive brute-force search for desirably weak curves (based on mathematical results not known outside NSA). This said, I also see a great deal of over-reaction, with bogus rumours about deliberate weakening of AES-256 by NIST (false), or deliberate sabotage of SHA3 (I am confident also false). So it is far from clear whether: - The NIST curves are cooked and should be avoided - Prime EDH is weak as a result of NSA break-throughs and should be avoided. - RSA is weak as a result of NSA break-throughs and should be avoided. ... So, when security matters, use the strongest crypto available, but worry a lot more about end-point security, not the crypto. With SMTP, I do nothing other than perhaps implement DNSSEC + DANE. > >> What are some ways that we could improve the situation? > > > > You could disable SSLv3 in the SMTP client, and use only TLSv1, > > TLSv1.1 or TLSv1.2. > > Do you mean in the MUA, or in the 'smtp' configurations in postfix? If > the latter, what happens when you disable SSLv3 and connect to a remote > MTA to make a delivery and they do not support anything but SSLv3? In all SMTP clients, since SMTP servers almost universally support TLSv1. There are exceedingly few servers that don't. You'd end up sending in the clear to these. Disabling SSLv3 is not very useful yet, the benefits only become real when TLS extensions sent by the client allow servers to choose more secure parameters for EECDH or EDH, which is not possible yet due to API and protocol limitations. This said it is unlikely to cause any significant problems. > > Neither Postfix nor OpenSSL actually care about the size of the > > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits, > > and likely get away with it. See recent thread on Exim TLS interop. > > YMMV, some clients may choke on 2048-bit EDH (though more typically > > these limited implementations are in are browsers, ... not MTAs). > > Interesting, what interoperability problems are there here? If you set > the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a > client chokes on this? Does it fall back to clear text, or a non-EDH > cipher, or does it cause a connection reset... or? Some clients don't implement EDH for primes larger than some limit, possibly as low as 1024 bits. Such issues are common in browsers, and perhaps MUAs, but very uncommon in MTAs. When the TLS handshake fails, the MTA behaviour is implementation dependent. Postfix (which does not have such limits) retries with plaintext, unless constrained by out-of-band policy (administrative or DANE). -- Viktor.
Re: Does my configuration reflect the current best practices?
It is rare for me to log in as root. I have considered seriously about disabling that login. Yes, HTTP/S and SMTP will be on the same machine. Is there a hazard to that end? They are completely different protocols communicating on different ports, after all. It does appear to work, my installation, that is. I basically followed a recipe, but lacked the knowledge of the chemistry that occurs within. And that can be as correct as the authors of blogs, websites, books. Beyond access to this data, it is easy for me to mis-interpret the meanings of the parameters I'm filling out. I have a feeling that I did something stupid and that it works simply by happen-chance. Thanks for your feedback - Original Message - From: Manuel Bieling Sent: 10/02/13 04:10 PM To: postfix-users@postfix.org Subject: Re: Does my configuration reflect the current best practices? On 10/02/2013 10:39 PM, Tim Legg wrote: > I have a username on this machine that I log in with, but choose to not have that username be an e-mail address. Hopefully this user is not called root. I recommend to disable root login. And I also recommend to disable any other user how has an e-mail address. Actually I recommend to disable password login at all. HTTP/S and SMTP on the same machine? > Given my configuration, does anybody see any exploits or weaknesses? Didn't read > I'm not sure of myself that I have done all that I need to. Monitoring will show you where you are now. Security is a process. Manuel Bieling (layman)
Re: postfix hardening - what can we do?
Viktor Dukhovni writes: > On Wed, Oct 02, 2013 at 07:38:42PM -0400, micah wrote: > >> I suppose there is no way to achieve some middle ground of doing >> opportunistic encryption, but for those who are only talking with bad >> protocols and ciphers (or clear-text) do a non-permanent failure with a >> message about their bad protocol so at least some admin eventually may >> see that information (perhaps when the user complains that their >> messages are slow to be delivered). > > What would be the point? You accept plaintext mail, but reject > mail encrypted with algorithms vulnerable to a costly, but not > infeasible brute-force effort? No, both plaintext and bad crypto would either be soft rejected with message to give a delay annoyance. >> > You could disable SSLv3 in the SMTP client, and use only TLSv1, >> > TLSv1.1 or TLSv1.2. >> >> Do you mean in the MUA, or in the 'smtp' configurations in postfix? If >> the latter, what happens when you disable SSLv3 and connect to a remote >> MTA to make a delivery and they do not support anything but SSLv3? > > In all SMTP clients, since SMTP servers almost universally support > TLSv1. There are exceedingly few servers that don't. You'd end > up sending in the clear to these. Disabling SSLv3 is not very > useful yet, the benefits only become real when TLS extensions sent > by the client allow servers to choose more secure parameters for > EECDH or EDH, which is not possible yet due to API and protocol > limitations. This said it is unlikely to cause any significant > problems. > >> > Neither Postfix nor OpenSSL actually care about the size of the >> > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits, >> > and likely get away with it. See recent thread on Exim TLS interop. >> > YMMV, some clients may choke on 2048-bit EDH (though more typically >> > these limited implementations are in are browsers, ... not MTAs). >> >> Interesting, what interoperability problems are there here? If you set >> the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a >> client chokes on this? Does it fall back to clear text, or a non-EDH >> cipher, or does it cause a connection reset... or? > > Some clients don't implement EDH for primes larger than some limit, > possibly as low as 1024 bits. Such issues are common in browsers, > and perhaps MUAs, but very uncommon in MTAs. When the TLS handshake > fails, the MTA behaviour is implementation dependent. Postfix (which > does not have such limits) retries with plaintext, unless constrained > by out-of-band policy (administrative or DANE). Thanks for the explanation. micah
