Nick Lockheart's questions

Estou usando nsupdate -lum script local para atualizar registros DNS no Bind9.

Está funcionando, exceto que preciso que o PHP tenha acesso de leitura à chave em /run/named/session.key.

Posso conceder acesso ao PHP alterando o grupo da chave para o usuário do processo PHP e adicionando g+rpermissões de leitura a ele, mas as permissões são revertidas bind:bindsempre chmod 600que o Bind é reiniciado.

Existe uma maneira de configurar as permissões padrão no Bind9 para /run/named/session.keyque um grupo diferente seja o proprietário e a leitura do grupo seja habilitada ( chmod 640) quando o Bind for iniciado?

Estou trabalhando em um serviço seguro/isolado que gerencia certificados TLS usando o protocolo ACME. O servidor precisa responder com um registro TXT em um subdomínio específico. Este servidor não atenderá solicitações do público em geral, mas precisa estar disponível publicamente.

CNAMEregistros são permitidos e podem ser seguidos.

Nosso servidor de gerenciamento TLS que hospeda o TXTregistro dinâmico está executando o Bind9 e está localizado em um local onde IPs dinâmicos são a única opção.

Os principais registros DNS do domínio estão em um servidor DNS público com o registrador. Configuramos com sucesso um subdomínio que é atualizado usando DNS dinâmico, mas parece que o provedor de DNS dinâmico não permite NSregistros.

Então no registrador temos:

domain.com          A   xx.xx.xx.xx
www.domain.com      A   xx.xx.xx.xx
dynamic.domain.com  NS  dynamic.provider.com

No provedor dinâmico temos:

dynamic.domain.com  A yy.yy.yy.yy

Em nosso servidor bot TLS, temos o Bind9 rodando como autoridade dynamic.domain.comcom um TXTregistro de texto:

test  TXT     "A nice Test."

Portanto, o resultado desejado é que, de qualquer lugar na Internet, você seja capaz de executar dig TXT test.dynamic.domain.come obter arquivos A nice Test..

Parece que isso está falhando no provedor de DNS dinâmico:

dig TXT test.dynamic.domain.com

apenas dá:

;; AUTHORITY SECTION:
dynamic.domain.com. 2208    IN  SOA dynamic.provider.com.

A única maneira de configurar um NSregistro no provedor de DNS dinâmico (ou seja, mudar de provedor para um que suporte NSregistros ou lançar o nosso próprio)? Ou existe uma solução alternativa usando CNAMEregistros ou Aregistros para fazer isso funcionar?

Variações deste aviso aparecem muitas vezes nos logs do Postfix:

warning: hostname 107-174-39-133-host.colocrossing.com does not resolve
     to address 107.174.39.133: Name or service not known

Gostaria de saber o que esse aviso realmente significa.

Especificamente, é uma verificação de DNS direta ou reversa que está falhando? Está usando registros A, MX ou PTR? A falha é causada pelo servidor de e-mail remoto usando cloudflare.com? Ou o Postfix está pegando um spammer se passando por um servidor que não é dele?

Aqui está um exemplo ao vivo de digconsultas:

dig -x 107.174.39.133

;; ANSWER SECTION:
133.39.174.107.in-addr.arpa. 300 IN PTR 107-174-39-133-host.colocrossing.com.


dig 107-174-39-133-host.colocrossing.com

;; AUTHORITY SECTION:
colocrossing.com.   355 IN  SOA brad.ns.cloudflare.com. dns.cloudflare.com. 2324254619 10000 2400 604800 1800

A pesquisa reversa PTR corresponde o domínio ao endereço IP, mas a pesquisa direta não retorna um endereço IP.

Gostaria de saber se isso é spam ou uma configuração incorreta do Postfix?

Observação : eu já smtp_host_lookup = nativeconfigurei e o endereço IP real do servidor definido em /etc/hosts:

127.0.0.1       localhost
xx.xx.xx.xx     domain.com
xx:xx::xx:xx:xx:xx   domain.com

# The following lines are desirable for IPv6 capable hosts
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

Temos nossa própria CA para uso interno que protege cerca de dez servidores/serviços. Na verdade, não temos nem precisamos de uma lista de revogação de certificados.

Mas, enquanto tentamos configurar o Dovecot para verificar a identidade do nosso servidor Postfix, descobrimos que o Dovecot não aceitará nosso certificado CA, a menos que tenha uma CRL anexada ao mesmo arquivo.

Se tivermos um certificado de CA público, authority.crtpodemos adicionar alguns dados CRL fictícios a esse arquivo de certificado de autoridade para deixar o Dovecot feliz?

ATUALIZAR:

Acho que quase descobri isso:

openssl ca -config ca/authority.cnf \
-gencrl -crldays 365 -crl_hold holdInstructionCallIssuer

Mas eu entendo:

unable to load number from ssl/crlnumber
error while loading CRL number
140581396727104:error:0D066096:asn1 encoding routines:a2i_ASN1_INTEGER:short line:../crypto/asn1/f_int.c:140:

O crlnumberarquivo não existia. Tentei touchimplementá-lo, o que não funcionou, e depois adicionei o número 1ao topo, o que também não funcionou. Provavelmente preciso configurar algo no authority.cnfarquivo de configuração do crlnumberarquivo.

Estou tentando fazer com que o Postfix encaminhe mensagens via LMTP para o Dovecot. Isso funciona bem quando o TLS está desativado nas configurações de ambos os lados.

Depois que as configurações de TLS são habilitadas, o Postfix se conecta via LMTP e o Dovecot vê a conexão, mas ambos os servidores parecem ficar presos lá, sem mais informações nos logs (logs abaixo).

Quais são as configurações corretas de TLS para que isso funcione?

Estas são as partes relevantes dos arquivos de configuração para ambos os servidores configurados atualmente:

/etc/dovecot/dovecot.conf:

protocols = imap lmtp

# Enable SSL (global) for IMAP connections
ssl = required
ssl_cert = </etc/ssl/imap.domain.com/imap.domain.com.crt
ssl_key = </etc/ssl/imap.domain.com/imap.domain.com.key


protocol lmtp {
    ssl_cert = </etc/ssl/imap.domain.com/imap.domain.com.crt
    ssl_key = </etc/ssl/imap.domain.com/imap.domain.com.key
    ssl_ca = </etc/ssl/imap.domain.com/authority.crt
    ssl_verify_client_cert = yes
    auth_ssl_require_client_cert = yes
    ssl=required
}


service lmtp {
  user = vmail
  inet_listener lmtp {
    address = * ::
    port = 24
    ssl=yes
  }
}

/etc/postfix/main.cf:

lmtp_use_tls = yes
lmtp_tls_security_level=encrypt
lmtp_tls_loglevel = 2
lmtp_tls_session_cache_database = btree:${data_directory}/lmtp_cache    
lmtp_tls_CApath = /etc/ssl/certs
lmtp_tls_CAfile=/etc/ssl/domain.com/authority.crt
lmtp_tls_cert_file=/etc/ssl/domain.com/domain.com.client.crt
lmtp_tls_key_file=/etc/ssl/domain.com/domain.com.key    
lmtp_tls_note_starttls_offer = yes

Log de e-mail do servidor Dovecot:

lmtp(1939): Info: Connect from xx.xx.xx.xx
lmtp(2500): Debug: SSL: where=0x10, ret=1: before SSL initialization
lmtp(2500): Debug: SSL: where=0x2001, ret=1: before SSL initialization
lmtp(2500): Debug: SSL: where=0x2002, ret=-1: before SSL initialization
lmtp(2500): Debug: SSL: where=0x2002, ret=-1: before SSL initialization
lmtp(2500): Debug: SSL: where=0x2002, ret=-1: before SSL initialization
lmtp(1944): Info: Disconnect from xx.xx.xx.xx: Disconnected for inactivity (state=GREETING)

O log de e-mail do servidor Postfix:

Nov  1 22:35:18 servername postfix/lmtp[65067]: initializing the client-side TLS engine
Nov  1 22:35:18 servername postfix/lmtp[65050]: 9935F2317D: to=<[email protected]>, relay=remote.server.com[yy.yy.yy.yy]:24, delay=1220, delays=920/0.02/300/0, dsn=4.4.2, status=deferred (lost connection with remote.server.com[yy.yy.yy.yy] while receiving the initial server greeting)

Atualizar

Se eu correr:

openssl s_client -connect domain.com:24 -CAfile /etc/ssl/domain.com/authority.crt

na máquina Postfix, ele se conecta via TLS ao servidor Dovecot via LMTP, e posso emitir comandos telnet para o Dovecot. Parece que o Dovecot está aceitando conexões TLS, mas quando o Postifx tenta se conectar, a negociação é interrompida.

Se eu correr:

openssl s_client -starttls lmtp -connect domain.com:24 -CAfile /etc/ssl/domain.com/authority.crt

Eu apenas entendo:

CONNECTED(00000003)

e não pode emitir nenhum comando telnet.

Cenário:

Um servidor Postfix é executado em um VPS com uma empresa de hospedagem.

Um servidor Dovecot IMAP é executado dentro do escritório.

Queremos que o Postfix envie as mensagens recebidas para o servidor IMAP Dovecot, usando a menor quantidade de software intermediário. Essa transferência ocorre pela Internet aberta.

Então vejo que o Postfix pode usar LMTP para transporte virtual sobre TCP, e o Dovecot pode escutar LMTP sobre TCP.

Mas o que impede um servidor de e-mail desonesto de ignorar o Postfix e apenas inserir e-mail no Dovecot na porta LMTP aberta?

O serviço LMTP pode ser protegido por um método de autenticação, como uma senha sobre TLS (no mínimo), ou verificação de certificado TLS bidirecional assinada por uma CA comum para que os dois servidores possam ter certeza da identidade um do outro (mais idealmente )?

Estou configurando um novo servidor Postifx no Debian 12. Instalei o pacote Debian e confirmei que o Postfix está rodando e escutando nas portas 25, 465e 587.

O Postfix está em execução e não há erros no log. Desativei as jails master.cfe este servidor não possui um firewall de software em execução.

Postifx está vinculado a todas as interfaces, por netstat:

netstat -plnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      8417/master
tcp        0      0 0.0.0.0:465             0.0.0.0:*               LISTEN      8417/master         
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      8417/master
tcp6       0      0 :::587                  :::*                    LISTEN      8417/master 
tcp6       0      0 :::465                  :::*                    LISTEN      8417/master         
tcp6       0      0 :::25                   :::*                    LISTEN      8417/master 

Posso fazer telnet no próprio servidor e conectar-me ao Postfix através de seu IP público:

telnet xx.xx.xx.xx 587
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
220 mydomain.com ESMTP Postfix

Mas se eu tentar isso de fora do servidor, ele não conectará:

telnet mydomain.com 587
Trying xx.xx.xx.xx...
Trying xxxx:xxxx::xxxx:xxxx:xxxx:xxxx...
telnet: Unable to connect to remote host: Network is unreachable

Confirmei que o DNS é resolvido corretamente para o servidor da perspectiva do cliente.

O ISP do meu trabalho/casa não bloqueia portas de saída, pois posso fazer telnet para o servidor SMTP do Gmail de casa e acessar o EHLO.

A empresa de hospedagem do servidor afirma que nenhuma porta está sendo bloqueada.

Posso acessar o servidor do meu cliente doméstico com, traceroute -Imas não sem, a -Iopção.

Sinceramente, não sei mais o que tentar. Eu deveria receber algo do Postfix ao tentar fazer telnet. A maioria das opções para bloquear e-mails ocorre após o EHLO, e ainda não chegamos tão longe.

Quais configurações possíveis no servidor impediriam o Postifx de escutar ou responder na interface externa, quando netstatmostra que está vinculado, não há erros no log e o Postfix responde ao telnet no IP externo do servidor ao fazer telnet a partir do próprio servidor?

inet_interfaces = allestá definido. inet_protocols = allestá definido.

Há alguma configuração que faria com que o Postfix descartasse silenciosamente uma solicitação de conexão sem qualquer saída?

O que mais posso verificar ou tentar? Quais configurações no Postfix seriam descartadas ou não aceitariam uma solicitação de conexão inicial?

Tenho um servidor Dovecot que usa MariaDB para caixas de correio virtuais. O servidor MariaDB está em outra máquina na mesma LAN.

Recentemente habilitamos o TLS na máquina MariaDB.

O Dovecot funciona bem quando require_secure_transportestá desligado, mas não consegue se conectar quando ligamos require_secure_transportno arquivo de configuração MariaDB.

O erro é:

Error: mysql(xxx.xxx.xxx.xxx): Connect failed to database (db_name): Access denied for user 'db_user'@'xxx.xxx.xxx.xxx' (using password: YES)

Parece um erro de autenticação, mas a conexão com o mesmo usuário e senha funciona bem quando require_secure_transportestá desativada, então o MariaDB está recusando a conexão porque o Dovecot não está usando TLS.

A string de conexão /etc/dovecot/dovecot-sql.conf.extse parece com:

connect = host=db0.mydomain.com dbname=my_db user=the_user password=secret ssl_ca=/etc/ssl/authority/authority.crt

O arquivo de configuração diz:

ssl_ca, ssl_ca_path - Defina um ou ambos para ativar SSL

Posso obter detalhes mais detalhados do erro? Por exemplo, se for uma incompatibilidade de versão TLS, posso mostrar isso em algum lugar?

Existe uma configuração no Dovecot que preciso alterar?

ATUALIZAÇÃO: Adicionar ssl_verify_server_cert=noà string de conexão /etc/dovecot/dovecot-sql.conf.extpermite que a conexão funcione.

Portanto, parece ser um erro de verificação de certificado. Mas sem um registro mais detalhado, não tenho certeza do que não gosta no certificado.

O certificado é assinado pela CA na string de conexão. Seria bom saber qual nome comum ele está verificando e também se o Dovecot usará algum dos valores SAN para o certificado.