Forçar o Postfix a usar o TLS para MySQL Connection?

2

O problema

Não consigo descobrir como forçar o Postfix a usar uma conexão TLS com o MySQL. Eu posso conectar manualmente do servidor Postfix ao servidor MySQL com TLS como o usuário postfix, portanto não há nada quebrado com a autenticação MySQL. O problema é claro: o Postfix não está solicitando o TLS para a conexão do MySQL.

Versões:

  • SO: CentOS 7
  • Postfix: 2: 2.10.1-6.el7 e 2: 3.2.4-1.gf.el7
  • MySQL (MariaDB): 5.5.56

Como cheguei aqui

Eu tenho pesquisado em toda a web, incluindo os vários sites do StackExchange, como resposta a essa pergunta. Eu li a documentação do Postfix e MySQL com muito tempo, repetidamente. A melhor resposta que encontrei é uma que eu rejeito como desnecessariamente complicada: " Configure um túnel SSH entre seus servidores Postfix e MySQL, e então conecte-o. " Tem que haver uma maneira de instruir o Postfix para usar a criptografia TLS (SSL) com o cliente MySQL.

Antes de explorarmos a configuração, deixe-me fazer isso firme: Minha configuração do servidor de e-mail funciona perfeitamente sem o MySQL TLS . Estou usando com sucesso o TLS para SMTPS e IMAPS e isso não tem nada a ver com a minha pergunta. O correio está sendo transportado com segurança tanto dentro quanto fora da minha rede, exceto que as conexões MySQL entre o Postfix e o servidor MySQL não são criptografadas. Exceto pelo link Postfix-MySQL exposto, não há problemas com a minha infra-estrutura de e-mail.

No entanto, devido à alteração dos requisitos de segurança, devo atualizar minha infraestrutura existente para criptografar todas as conexões MySQL. Configurar o TLS para conexões MySQL foi fácil. Testes manuais mostram que os clientes MySQL podem se conectar com êxito através de um link criptografado por TLS de todos os hosts permitidos . Então, a configuração do MySQL TLS também é sólida e funciona para tudo exceto o Postfix .

O que eu tentei

Configuração relevante no servidor Postfix:

/etc/postfix/main.cf

Reduzido a apenas uma das várias conexões para manter o material o mais específico possível.

virtual_alias_maps = proxy:mysql:/etc/postfix/lookup_aliases.cf
proxy_read_maps = $virtual_alias_maps
/etc/postfix/lookup_aliases.cf

Credenciais e nomes de host ofuscados.

hosts = mysql-server.domain.tld
user = postfix
password = *****
dbname = mail
option_file = /etc/my.cnf.d/client.cnf
option_group = client
tls_verify_cert = yes
query = SELECT goto FROM alias WHERE address = '%s' AND active = '1'
/etc/my.cnf

Este arquivo não foi alterado. Estou incluindo-o apenas para mostrar que o próximo arquivo de configuração está incluído corretamente na configuração do MySQL Client.

!includedir /etc/my.cnf.d
/etc/my.cnf.d/client.cnf
[client]
ssl = true

Bem-sucedida - MANUAL - Saída de conexão TLS do MySQL do servidor Postfix como o usuário do postfix

Observe, em particular, que o TLS é empregado com sucesso:

# hostname -f
mail.domain.tld

# sudo -u postfix mysql -h mysql-server.domain.tld -u postfix -p mail
Enter password:
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 72
Server version: 5.5.56-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [mail]> \s
--------------
mysql  Ver 15.1 Distrib 5.5.56-MariaDB, for Linux (x86_64) using readline 5.1

Connection id:     72
Current database:  mail
Current user:      [email protected]
SSL:           Cipher in use is DHE-RSA-AES256-GCM-SHA384
Current pager:     stdout
Using outfile:     ''
Using delimiter:   ;
Server:            MariaDB
Server version:        5.5.56-MariaDB MariaDB Server
Protocol version:  10
Connection:        mysql-server.domain.tld via TCP/IP
Server characterset:   latin1
Db     characterset:   utf8
Client characterset:   utf8
Conn.  characterset:   utf8
TCP port:      3306
Uptime:            1 hour 27 min 23 sec

Threads: 1  Questions: 271  Slow queries: 0  Opens: 13  Flush tables: 2  Open tables: 39  Queries per second avg: 0.051
--------------

MariaDB [mail]> \q
Bye

Configuração relevante no servidor MySQL:

MySQL Grants

Observe que o TLS (SSL) é NECESSÁRIO, mas, caso contrário, as permissões são relativamente frouxas até que eu resolva esse problema de conexão TLS:

MariaDB [(none)]> SHOW GRANTS FOR 'postfix'@'10.0.101.%';
+-----------------------------------------------------------------------------------------------------+
| Grants for [email protected].%                                                                       |
+-----------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'postfix'@'10.0.101.%' IDENTIFIED BY PASSWORD '*SOMEPASSWORDHASH' REQUIRE SSL |
| GRANT SELECT ON 'mail'.* TO 'postfix'@'10.0.101.%'                                                  |
+-----------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

Registros

A conexão do postfix falha quando o SSL REQUERIDO

Mesmo que o teste de linha de comando manual da conexão TLS do MySQL tenha SUCCEEDS aqui, o Postfix ainda não usará o TLS do MySQL.

O Registro Geral do MySQL:

180217 14:45:15       16 Connect   [email protected] as anonymous on mail
      16 Connect   Access denied for user 'postfix'@'mail.domain.tld' (using password: YES)

O registro do postfix:

Feb 19 19:22:55 mail postfix/cleanup[11951]: warning: proxy:mysql:/etc/postfix/lookup_aliases.cf lookup error for "[email protected]"
Feb 19 19:22:55 mail postfix/cleanup[11951]: warning: E2CCA2069823: virtual_alias_maps map lookup problem for [email protected] -- message not accepted, try again later
Conexão Postfix SUCCEEDS quando o SSL REQUERIDO for removido

Este é o Postfix que se conecta com êxito após alterar a permissão de REQUIRE SSL para REQUIRE NONE. No entanto, a conexão não é criptografada .

180217 15:17:21       26 Connect   [email protected] as anonymous on mail
          26 Query show databases
          26 Query show tables
          26 Field List    admin
          26 Field List    alias
          26 Field List    alias_domain
          26 Field List    config
          26 Field List    domain
          26 Field List    domain_admins
          26 Field List    fetchmail
          26 Field List    log
          26 Field List    mailbox
          26 Field List    quota
          26 Field List    quota2
          26 Field List    vacation
          26 Field List    vacation_notification
          26 Query select @@version_comment limit 1

Conclusão

Tudo que preciso é que o Postfix honre o ssl = true por suas conexões de cliente MySQL. Por favor, deixe-me saber se você precisar de mais informações.

Atualização:

Depois de postar essa pergunta, descobri, com uma leitura mais cuidadosa, que as versões do Postfix anteriores à 2.11 não suportam a leitura dos arquivos de configuração do MySQL. Como tal, é impossível configurar a versão fornecida pelo fornecedor do Postfix (versão 2.10) para usar o MySQL TLS. Eu sinto uma escolha pobre de palavras na documentação do Postfix, onde a parte superior da documentação do Postfix para configuração do MySQL diz:

Postfix 3.1 and earlier don't read [client] option group settings unless a non-empty option_file or option_group value are specified. To enable this, specify, for example "option_group = client".

O autor não conseguiu soletrar:

These options are ignored for Postfix 2.10 and earlier.  Postfix 2.11 through 3.1 don't read [client] option group settings unless a non-empty option_file or option_group value are specified. To enable this, specify, for example "option_group = client".

Então, atualizei o Postfix no CentOS 7 da versão 2.10 fornecida pelo fornecedor para o GhettoForge Plus fornecido versão 3.2. Eu instalei o pacote postfix3-mysql adicional. Eu tinha grandes esperanças, mas elas foram frustradas. Agora, mesmo com o Postfix 3.2, o ainda não se conectará ao MySQL por meio de um link TLS .

Eu tentei os dois option_file = /etc/my.cnf (deve ser o padrão e desnecessário) e option_file = /etc/my.cnf.d/client.cnf sem nenhum benefício.

Eu até tentei forçar o Postfix a considerar o TLS adicionando tls_verify_cert = yes . Isso também não teve efeito. Observe que o nome do certificado corresponde, portanto, essa verificação será aprovada se alguma vez for realmente tentada.

    
por seWilliam 17.02.2018 / 17:58

1 resposta

2

Sinopse

Para estabelecer uma conexão TLS do MySQL a partir do Postfix, você precisa:

  1. Versão do postfix 2.11 ou mais recente . O CentOS 7 fornece apenas a versão Postfix 2.10 . Você deve adquirir uma atualização para o Postfix a partir de meios não-CentOS. Eu escolhi usar os pacotes postfix3 e postfix3-mysql do GhettoForge Plus porque parece bem recomendado pela comunidade CentOS .
  2. Defina nos arquivos de configuração mysql_table :
    1. Pelo menos uma configuração tls_ciphers permissível;
    2. Um certificado TLS do lado do cliente e sua chave privada correspondente, assinado por uma Autoridade de Certificação que é comum ao servidor MySQL e ao seu cliente Postfix ; ou
    3. ambos.
  3. Não confie em configurá-los em seus arquivos /etc/my.cnf ou /etc/my.cnf.d/*! O código Postfix do MySQL não lê esses arquivos para determinar se deve ser Conexão TLS do MySQL; eles são analisados muito tarde. A maneira somente de instigar o Postfix a abrir uma conexão TLS do MySQL é especificar as configurações de TLS nos arquivos de configuração mysql_table . Período.

Como cheguei aqui

Eu finalmente recorri a ler o código fonte do Postfix 3.2. As linhas 653-658 de src / global / dict_mysql.c foram especialmente informativas.

Solução final

Se você deseja emular o comportamento de ssl = true , basta adicionar uma linha semelhante à seguinte em seus arquivos de configuração mysql_table :

tls_ciphers = TLSv1.2

Nossa configuração requer que apenas o TLS 1.2 seja usado - e já tenha sido aplicado por muito tempo na configuração de nossos servidores MySQL, portanto, não ocorreu automaticamente para eu aplicá-lo também nos clientes - mas você está livre para adicionar outras cifras se sua organização tolerar cifras mais antigas.

Note que estamos perfeitamente satisfeitos por não usar certificados do lado do cliente. Usamos outros meios para proteger e monitorar ativamente nossas conexões com o banco de dados; nós simplesmente não queremos complexidade adicional.

Solução Alternativa

Se você preferir impor que apenas clientes conhecidos e confiáveis se conectem aos seus servidores MySQL - e você não pode fazê-lo através de outros mecanismos de imposição de diretivas como firewalls rígidos, complexidade de senha restrita, periodicidade de rotação de senhas, auditoria de conexão etc. então você também pode usar certificados do lado do cliente por meio dessas configurações adicionais nos arquivos de configuração mysql_table :

tls_key_file = /path/to/private.key
tls_cert_file = /path/to/public.certificate
tls_CAfile = /path/to/common.CA.certificate # OR tls_CApath = /path/to/CA-and-intermediate-chain-certificates/

Novamente, defini-los em /etc/my.cnf ou /etc/my.cnf.d/* não ajudará . Esses arquivos não são analisados até após o tipo de conexão (TLS ou não-TLS) já ter sido decidido .

Se você optar por usar certificados do lado do cliente, faça com que eles sejam aplicados no servidor ! Você não precisa de certificados do lado do cliente quando tudo que você quer é criptografar o tráfego do MySQL; em vez disso, use apenas a alternativa tls_ciphers , acima. Adicionar certificados do lado do cliente permite que o MySQL verifique se um cliente de conexão é conhecido e confiável, mas somente se você informar ao MySQL como fazer isso ! Ele não vai adivinhar e confiar apenas na presença de uma autoridade de certificação comum entre cliente e servidor é apenas uma implementação parcial dessa ferramenta poderosa. Se você está interessado neste modelo de segurança do MySQL, eu encontrei pelo menos um Como guia que fornece bons exemplos de como empregar a validação do certificado de cliente .

    
por 20.02.2018 / 00:13