Início / user-270731

user2690527's questions

Martin Hope
user2690527
Asked: 2024-07-30 05:09:56 +0800 CST
  • 5

Recentemente mudei meu hoster DNS (novamente), pois precisava de alguns recursos que meu hoster DNS anterior não oferece. Sempre que eu mudava de host DNS, meu servidor ficava indisponível por várias horas até que o DNS se corrigisse novamente. Eu sei que o DNS é um sistema distribuído que armazena entradas em cache por várias horas, mas deve haver uma maneira de mudar de provedor sem interrupção do serviço.

Estas são as principais etapas que tomei:

  1. Copiado todos os registros DNS do host DNS anterior para o novo.
  2. Consultou explicitamente os servidores DNS primários de ambos os hosters dig @<...>para garantir que ambos estavam configurados de forma idêntica
  3. Informei meu registrador sobre o novo servidor de nomes DNS e forneci-lhes as novas configurações de NS, DNSKEY e DS; meu registrador encaminhou essas informações para o registro de TLD (no meu caso, a .dezona, ou seja, DENIC)

Aproximadamente uma hora depois de executar a etapa 3, meus servidores ficaram indisponíveis via DNS. A resolução de DNS foi interrompida no meu domínio. Demorou aproximadamente mais seis horas até que tudo voltasse a funcionar.

A menos que não esteja totalmente enganado, neste caso específico a interrupção ocorreu devido a uma incompatibilidade entre os registros NS e DNSKEY, por um lado, e o registro DS, por outro, durante aquelas seis horas. Os registros NS e DNSKEY já foram atualizados e apontavam para o novo host DNS enquanto o registro DS permaneceu o antigo por mais seis horas.

Qual é a abordagem correta para evitar tais problemas?

Adendo (30/07/2024)

Hoje, eu queria migrar meu segundo domínio do hoster DNS anterior para o novo hoster DNS e pensei que seria inteligente.

Desativei o DNSSEC com 48 horas de antecedência para evitar erros de assinatura. (É melhor não ter nenhum DNSSEC do que um DNSSEC com falha.) Mas então me deparei com outra armadilha.

Primeiro configurei as informações da zona DNS em meu novo hoster DNS e depois disse ao meu registrador para alterar o NSregistro do antigo para o novo hoster DNS. No entanto, a mudança não foi atômica. Em vez de alterar o NSregistro do antigo para o novo, eles alteraram o NSregistro do valor antigo para o "espaço reservado" f.nic.de.e depois f.nic.de.para o novo valor real. Essas duas etapas tiveram um intervalo de 5 minutos. Infelizmente, essa janela de tempo de 5 minutos foi suficiente para que o DNS do Google (8.8.8.8) detectasse o valor intermediário errado f.nic.de.e tivesse um TTL de 14400, ou seja, 4h.

Claro, f.nic.de.não tinha informações sobre meu domínio real. Portanto, embora o erro tenha existido apenas por 5 minutos, ele produziu outra interrupção de resolução de DNS de 4 horas em meu domínio para alguns usuários, dependendo de qual servidor DNS eles consultaram.

Até agora, acredito que o hoster do meu servidor virtual privado, que também "é dono" dos meus endereços IP e que também é o registrador dos meus domínios (mas não do meu hoster DNS), é simplesmente estúpido. Eles fornecem apenas um formulário web que permite inserir um NSe um DNSKEYregistro. (O DSregistro é calculado implicitamente a partir de DNSKEY). No entanto, não há opção para adicionar (ou remover ) registros. Só é possível substituir os registros existentes (um de cada tipo). No entanto, mesmo que alguém altere ambos os valores correta e consistentemente e depois envie o formulário da web, a alteração upstream (entre meu registrador e o registro) é imprevisível e fora de ordem. Dada a resposta abaixo, acho que não há nada que eu possa fazer a não ser discutir com meu registrador que eles devem colocar seus processos em ordem.

domain-name-system
Martin Hope
user2690527
Asked: 2024-05-08 23:42:19 +0800 CST
  • 6

Existe um grande hoster de e-mail alemão (web.de) cujos servidores de e-mail não conseguem enviar e-mails para meu servidor Postfix auto-hospedado. Encontrei relatórios semelhantes, mas as soluções publicadas sempre foram registros TLSA mal configurados. No entanto, tenho certeza de que meu registro TLSA está bom.

Como resolvo o problema para que meu servidor Postfix receba e-mails desses servidores corretamente?

  • Versão Postfix: 3.8.5
  • Versão OpenSSL: 3.0.13-r2

Meus registros do Postfix:

May 08 12:05:37 server postfix/smtpd[90259]: initializing the server-side TLS engine
May 08 12:05:37 server postfix/smtpd[90259]: connect from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: setting up TLS connection from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: mout.web.de[212.227.15.4]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:!SEED:!IDEA:!3DES:!RC2:!RC4:!RC5:!kDH:!kECDH:!aDSS:!MD5:+RC4:@STRENGTH"
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:before SSL initialization
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:before SSL initialization
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS read client hello
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write server hello
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write change cipher spec
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 write encrypted extensions
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write certificate
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 write server certificate verify
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write finished
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 early data
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:TLSv1.3 early data
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS read finished
May 08 12:05:38 server postfix/smtpd[90259]: mout.web.de[212.227.15.4]: Issuing session ticket, key expiration: 1715164537
May 08 12:05:38 server postfix/smtpd[90259]: SSL_accept:SSLv3/TLS write session ticket
May 08 12:05:38 server postfix/smtpd[90259]: Anonymous TLS connection established from mout.web.de[212.227.15.4]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256
May 08 12:05:38 server postfix/smtpd[90259]: SSL3 alert read:fatal:insufficient security
May 08 12:05:38 server postfix/smtpd[90259]: warning: TLS library problem: error:0A00042F:SSL routines::tlsv1 alert insufficient security:../openssl-3.0.13/ssl/record/rec_layer_s3.c:1590:SSL alert number 71:
May 08 12:05:38 server postfix/smtpd[90259]: lost connection after STARTTLS from mout.web.de[212.227.15.4]
May 08 12:05:38 server postfix/smtpd[90259]: disconnect from mout.web.de[212.227.15.4] ehlo=1 starttls=1 commands=2
May

Não tenho certeza de qual lado está relatando “segurança insuficiente”. Meu próprio lado, ou seja, servidor Postfix/TLS? Ou o lado remoto, ou seja, o servidor de email web.de que é o cliente TLS?

Meu servidor fornece dois certificados Letsencrypt:

  • um certificado CE,
  • um certificado RSA.

As diretivas TLS relevantes do meu Postfix main.cf:

# TLS PARAMETERS
#

smtpd_tls_chain_files =
  /etc/letsencrypt/live/server.my-domain.tld:smtps-ec/privkey.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-ec/fullchain.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-rsa/privkey.pem,
  /etc/letsencrypt/live/server.my-domain.tld:smtps-rsa/fullchain.pem
smtpd_tls_CApath              = /etc/ssl/certs
# note: for port 587, smtpd_tls_security_level is overwritten to `encrypt` in master.cf
smtpd_tls_security_level      = may
smtpd_tls_received_header     = yes
smtpd_tls_auth_only           = yes
smtpd_tls_ciphers             = medium
smtpd_tls_protocols           = >=TLSv1.2
smtpd_tls_mandatory_ciphers   = high
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_loglevel            = 0

smtp_tls_CApath              = /etc/ssl/certs
smtp_tls_security_level      = may
smtp_tls_note_starttls_offer = yes
smtp_tls_ciphers             = medium
smtp_tls_protocols           = >=TLSv1.2
smtp_tls_mandatory_ciphers   = high
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_loglevel            = 0

Em ambos os casos, a âncora de confiança é “ISRG Root X1”. Meu registro TLSA é

$ dig TLSA _25._tcp.server.my-domain.tld.
_25._tcp.server.my-domain.tld.   12340 IN   CNAME   letsencrypt._dane.my-domain.tld.
letsencrypt._dane.my-domain.tld. 13104 IN   TLSA    0 1 1 0B9FA5A59EED715C26C1020C711B4F6EC42D58B0015E14337A39DAD3 01C5AFC3

Executar a verificação SSL em meu próprio servidor Postfix produz:

# sslscan --verbose --starttls-smtp server.my-domain.tld:25
Version: 2.1.2-static
OpenSSL 3.0.12 24 Oct 2023

Some servers will fail to response to SSLv3 ciphers over STARTTLS
If your scan hangs, try using the --tlsall option

Testing SSL server server.my-domain.tld on port 25 using SNI name server.my-domain.tld

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Server supports TLS Fallback SCSV

  TLS renegotiation:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
use_unsafe_renegotiation_op
Session renegotiation not supported

  TLS Compression:
OpenSSL OpenSSL 3.0.12 24 Oct 2023 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
Compression disabled

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
SSL_connect() returned: 1
Preferred TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
SSL_connect() returned: -1
SSL_get_current_cipher() returned NULL; this indicates that the server did not choose a cipher from our list (TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256)
SSL_connect() returned: 1
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CHACHA20-POLY1305   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CHACHA20-POLY1305     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM8       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-CCM8           DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-CCM            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-ARIA256-GCM-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ARIA256-GCM-SHA384      Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-ARIA256-GCM-SHA384    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-GCM-SHA384         DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM8       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-CCM8           DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-CCM            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-ARIA128-GCM-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ARIA128-GCM-SHA256      Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-ARIA128-GCM-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-GCM-SHA256         DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-CAMELLIA256-SHA384  Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-SHA256             DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-CAMELLIA256-SHA256        DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-CAMELLIA128-SHA256  Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA256    DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-SHA256             DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-CAMELLIA128-SHA256        DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA       DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AECDH-AES256-SHA              Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-AES256-SHA                DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ADH-CAMELLIA256-SHA           DHE 3072 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA       DHE 2048 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AECDH-AES128-SHA              Curve 25519 DHE 253
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-AES128-SHA                DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ADH-CAMELLIA128-SHA           DHE 1024 bits
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384            
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-CCM8                  
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-CCM                   
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  ARIA256-GCM-SHA384           
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256            
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-CCM8                  
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-CCM                   
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  ARIA128-GCM-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-SHA256                
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-SHA256                
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA256           
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  AES256-SHA                   
SSL_connect() returned: 1
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA              
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  AES128-SHA                   
SSL_connect() returned: 1
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA              
SSL_connect() returned: -1
SSL_get_current_cipher() returned NULL; this indicates that the server did not choose a cipher from our list (ALL:COMPLEMENTOFALL:!ECDHE-ECDSA-AES256-GCM-SHA384:!ECDHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES256-GCM-SHA384:!ECDHE-ECDSA-CHACHA20-POLY1305:!ECDHE-RSA-CHACHA20-POLY1305:!DHE-RSA-CHACHA20-POLY1305:!ECDHE-ECDSA-AES256-CCM8:!ECDHE-ECDSA-AES256-CCM:!DHE-RSA-AES256-CCM8:!DHE-RSA-AES256-CCM:!ECDHE-ECDSA-ARIA256-GCM-SHA384:!ECDHE-ARIA256-GCM-SHA384:!DHE-RSA-ARIA256-GCM-SHA384:!ADH-AES256-GCM-SHA384:!ECDHE-ECDSA-AES128-GCM-SHA256:!ECDHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES128-GCM-SHA256:!ECDHE-ECDSA-AES128-CCM8:!ECDHE-ECDSA-AES128-CCM:!DHE-RSA-AES128-CCM8:!DHE-RSA-AES128-CCM:!ECDHE-ECDSA-ARIA128-GCM-SHA256:!ECDHE-ARIA128-GCM-SHA256:!DHE-RSA-ARIA128-GCM-SHA256:!ADH-AES128-GCM-SHA256:!ECDHE-ECDSA-AES256-SHA384:!ECDHE-RSA-AES256-SHA384:!DHE-RSA-AES256-SHA256:!ECDHE-ECDSA-CAMELLIA256-SHA384:!ECDHE-RSA-CAMELLIA256-SHA384:!DHE-RSA-CAMELLIA256-SHA256:!ADH-AES256-SHA256:!ADH-CAMELLIA256-SHA256:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-RSA-AES128-SHA256:!DHE-RSA-AES128-SHA256:!ECDHE-ECDSA-CAMELLIA128-SHA256:!ECDHE-RSA-CAMELLIA128-SHA256:!DHE-RSA-CAMELLIA128-SHA256:!ADH-AES128-SHA256:!ADH-CAMELLIA128-SHA256:!ECDHE-ECDSA-AES256-SHA:!ECDHE-RSA-AES256-SHA:!DHE-RSA-AES256-SHA:!DHE-RSA-CAMELLIA256-SHA:!AECDH-AES256-SHA:!ADH-AES256-SHA:!ADH-CAMELLIA256-SHA:!ECDHE-ECDSA-AES128-SHA:!ECDHE-RSA-AES128-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-CAMELLIA128-SHA:!AECDH-AES128-SHA:!ADH-AES128-SHA:!ADH-CAMELLIA128-SHA:!AES256-GCM-SHA384:!AES256-CCM8:!AES256-CCM:!ARIA256-GCM-SHA384:!AES128-GCM-SHA256:!AES128-CCM8:!AES128-CCM:!ARIA128-GCM-SHA256:!AES256-SHA256:!CAMELLIA256-SHA256:!AES128-SHA256:!CAMELLIA128-SHA256:!AES256-SHA:!CAMELLIA256-SHA:!AES128-SHA:!CAMELLIA128-SHA)

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.3  128 bits  x25519
TLSv1.3  224 bits  x448
TLSv1.3  112 bits  ffdhe2048
TLSv1.3  128 bits  ffdhe3072
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  x25519
TLSv1.2  224 bits  x448

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      secp384r1
ECC Key Strength:    192

Subject:  server.my-domain.tld
Altnames: DNS:server.my-domain.tld
Issuer:   R3

Not valid before: Mar 11 19:44:07 2024 GMT
Not valid after:  Jun  9 19:44:06 2024 GMT

Alguma idéia de por que o servidor de e-mail web.de não envia e-mails para o meu servidor Postfix?

postfix
Martin Hope
user2690527
Asked: 2023-12-26 23:30:50 +0800 CST
  • 5

Eu tenho uma configuração Postfix/Dovecot e uso OpenLDAP como back-end de usuário/senha. Os usuários devem fazer login com seu endereço de e-mail totalmente qualificado como nome de usuário devido à hospedagem virtual e, portanto, a parte do domínio é necessária para autenticação, ou seja, os nomes de usuário têm a aparência <local-part>@<fqdn-domain>.

No entanto, existem ataques constantes que tentam autenticar com nomes de usuário sem parte de domínio. Como isso leva a um DN inválido dentro da consulta LDAP, meus logs recebem muitas mensagens de erro devido a um DN LDAP inválido.

Existe alguma opção de configuração que permita ao Dovecot impor algumas verificações de sintaxe iniciais no nome de usuário fornecido e, se isso falhar, o Dovecot abrevia o processo de autenticação com uma resposta de negação imediata em vez de consultar o servidor LDAP e depois falhar?

A configuração LDAP no Dovecot é

uris = ldapi://%2frun%2fopenldap%2fslapd.sock
auth_bind = yes
auth_bind_userdn = uid=%n,ou=users,o=%d,dc=my-host,dc=my-domain,dc=my-tld
base = ou=users,o=%d,dc=server,dc=my-host,dc=my-domain,dc=my-tld

Como você pode ver, minha configuração LDAP usa os chamados "pontos de junção" para fornecer diferentes sub-ramos no DIT para os diferentes domínios hospedados. (A o=%d-parte no DN.) De acordo com o Manual de configuração do Dovecot - Variáveis ​​do usuário , %destará vazio se o nome de usuário não tiver nenhuma parte do domínio após o @.

Quando um invasor tenta se autenticar com um nome de usuário incompleto, isso leva a mensagens de erro supérfluas em meus registros, como

Dec 26 16:25:54 server dovecot[24946]: auth: Error: ldap(root,187.205.80.184): ldap_bind() failed: Invalid DN syntax

Aqui, um invasor de 187.205.80.184 tentou se autenticar como usuário roote o Dovecot tentou procurar, uid=root,ou=users,o=,dc=my-host,dc=my-domain,dc=my-tldo que obviamente é inválido, porque não há nada depois o=.

ldap
Martin Hope
user2690527
Asked: 2023-12-02 02:45:10 +0800 CST
  • 5

Eu tenho uma máquina virtual rápida e o serviço systemd systemd-zserdbd.servicefalha com

Dec 01 17:45:32 server-new systemd[1]: Starting systemd-remount-fs.service...

...

Dec 01 17:45:32 server-new (-userdbd)[183]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[185]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new systemd[1]: Started systemd-journald.service.
Dec 01 17:45:32 server-new (-userdbd)[186]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[187]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system
Dec 01 17:45:32 server-new (-userdbd)[188]: systemd-userdbd.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-userdbd: Read-only file system

...

Dec 01 17:45:32 server-new systemd-fsck[180]: /usr/bin/fsck.xfs: XFS file system.
Dec 01 17:45:32 server-new systemd[1]: Finished systemd-remount-fs.service.

...

Dec 01 17:45:32 server-new systemd[1]: Reached target local-fs-pre.target.

...

Dec 01 17:45:33 server-new systemd[1]: Reached target local-fs.target.

O erro é bastante óbvio: systemd-userdbd.servicerequer um sistema de arquivos raiz gravável, mas é iniciado antes que o sistema de arquivos seja remontado como gravável.

Portanto, eu queria adicionar a dependência necessária via systemctl edit systemd-userdbd.service --drop-in=wait-for-rw-rootwith

[Unit]
Wants=local-fs.target
After=systemd-userdbd.socket systemd-remount-fs.service local-fs.target

Mas isso parece criar uma dependência circular no momento da inicialização. A remontagem dos sistemas de arquivos leva uma eternidade até que o systemd atinja o tempo limite.

  1. Como posso garantir que isso systemd-userdbd.serviceseja iniciado depois que o sistema de arquivos raiz se tornar gravável sem criar uma dependência circular?
  2. (Uma questão mais geral) Como analiso o que cria a dependência circular?
systemd
Martin Hope
user2690527
Asked: 2023-11-11 22:47:58 +0800 CST
  • 5

Estou executando o Postfix 3.8.1 no Ubuntu 23.10. O Postfix atende a porta 25 para mensagens recebidas de outros MTAs e a porta 587 para MUAs autenticados.

O Postfix deve verificar o SPF para e-mails de outros MTAs na porta 25, mas não para e-mails de MUAs autenticados na porta 587. No entanto, o Postfix faz isso falsamente para MUAs autenticados e o SPF falha (porque o MUA não está listado como um servidor de e-mail permitido ).

Tenho a sensação de que o Postfix simplesmente ignora as regras especiais para MUAs, mas não encontro meu erro de configuração.

Meumaster.cnf

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (no)    (never) (100)
# ==========================================================================
smtp      inet  n       -       y       -       -       smtpd
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o cleanup_service_name=header_cleanup
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_relay_restrictions=$mua_relay_restrictions
header_cleanup unix n   -       -       -       0       cleanup
  -o header_checks=regexp:/etc/postfix/submission_header_cleanup.cf

A ideia da configuração acima é que smtpdna porta 587 ( submission) seja utilizada alguma configuração especial.

Meumain.cf

smtpd_delay_reject = yes

smtpd_client_restrictions =
  reject_unauth_pipelining,
  reject_unknown_client_hostname
mua_client_restrictions =
  reject_unauth_pipelining

smtpd_helo_required = yes

smtpd_helo_restrictions =
  reject_invalid_helo_hostname,
  reject_non_fqdn_helo_hostname,
  reject_unknown_helo_hostname
mua_helo_restrictions =
  reject_invalid_helo_hostname

strict_rfc821_envelopes = yes

smtpd_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain
mua_sender_restrictions =
  reject_non_fqdn_sender,
  reject_unknown_sender_domain
  reject_plaintext_session,
  reject_sender_login_mismatch

smtpd_relay_restrictions =
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  reject_unauth_destination
mua_relay_restrictions =
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  permit_sasl_authenticated,
  reject

smtpd_recipient_restrictions =
  check_policy_service unix:private/policyd-spf,
  permit

policyd-spf_time_limit = 3600

smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=no

A ideia é que mua_relay_restrictionsclientes autenticados passo a passo sejam permitidos incondicionalmente e todo o resto rejeitado. Isso significa que para clientes autenticados o controle de acesso deve parar por aí. Esta é também a razão pela qual existe apenas smtpd_recipient_restrictionspara clientes na porta 25 e nenhum correspondente mua_recipient_restriction, porque o Postfix nunca deve chegar a esse ponto.

No entanto, se eu usar um cliente de e-mail para enviar um e-mail através do meu servidor de e-mail Postfix para outra caixa de e-mail minha (hospedada externamente), vejo os seguintes logs no meu servidor de e-mail:

postfix/submission/smtpd[515502]: Anonymous TLS connection established from pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-sign>
policyd-spf[515508]: : prepend Received-SPF: Softfail (mailfrom) identity=mailfrom; client-ip=217.236.242.123; helo=my-touchpad.localnet; [email protected]; receiver=other-domain.tld

Que o SPF tem que falhar é óbvio. O MUA é um cliente (my-touchpad.localnet) em uma linha dial-up (pd9ecf27b.dip0.t-ipconnect.de[217.236.242.123]) que não está listado pela política SPF para my-domain.tld. Claro, não é porque a política SPF lista apenas o próprio servidor de e-mail.

No entanto, eu me pergunto por que o Postfix executou essa verificação em primeiro lugar. A verificação do SPF é apenas parte do smtpd_recipient_restrictionsque não deve ser aplicado a MUAs autenticados.

postfix
Martin Hope
user2690527
Asked: 2023-10-29 19:29:21 +0800 CST
  • 5

Como desativo a notificação de não entrega (e-mail devolvido) no Postfix?

Eu configurei o Postfix 3.8.1 com rspamd 3.6. A filtragem de spam está funcionando

admin@host123456:~ $ wget http://spamassassin.apache.org/gtube/gtube.txt -P /tmp
admin@host123456:~ $ sendmail [email protected] < /tmp/gtube.txt

resulta em

root@host123456:~ # egrep 4873D80B30 /var/log/mail.log
2023-10-28T21:41:00.297436+02:00 host123456 postfix/pickup[151929]: 4873D80B30: uid=1000 from=<admin>
2023-10-28T21:41:00.301825+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: message-id=<[email protected]>
2023-10-28T21:41:00.352027+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Gtube pattern; from=<[email protected]> to=<[email protected]>
2023-10-28T21:41:00.359127+02:00 host123456 postfix/cleanup[151958]: 4873D80B30: to=<[email protected]>, relay=none, delay=0.07, delays=0.07/0/0/0, dsn=5.7.1, status=bounced (Gtube pattern)
2023-10-28T21:41:00.365073+02:00 host123456 postfix/bounce[151960]: 4873D80B30: sender non-delivery notification: 58B2E81258

Como você pode ver na última linha de log, o postfix envia de volta uma notificação de não entrega ao remetente original (neste caso, admin@host123456). Como configuro o Postfix para simplesmente rejeitar emails de spam?

postfix
Martin Hope
user2690527
Asked: 2023-10-28 23:18:45 +0800 CST
  • 5

Em que ordem o Postfix > 2.10 avalia as seguintes diretivas?

  1. smtpd_client_restrictions
  2. smtpd_helo_restrictions
  3. smtpd_relay_restrictions
  4. smtpd_recipient_restrictions

Eu li o relé SMTP do Postfix e o controle de acesso (ACCESS README) e os parâmetros de configuração do Postfix , bem como os comentários em main.cf, mas IMHO os conselhos não são absolutamente claros ou mesmo contraditórios.

Nota: Quando falo sobre um "endereço local", refiro-me a qualquer endereço de destinatário cujo Postfix seja de alguma forma o destino final, ou seja, um endereço cuja parte do domínio esteja listada em mydestination, virtual_alias_domainsou virtual_mailbox_domains. Todo o resto é um endereço não local e o Postfix deve encaminhar o email para outro MTA.

Pergunta 1: As duas primeiras diretivas são sempre avaliadas para qualquer tipo de cliente (MUA e outros servidores SMTP) e qualquer endereço de destino na ordem especificada? Presumo que sim.

Pergunta 2: a) é smtpd_relay_restrictionssempre avaliado ou b) avaliado apenas para domínios de correio não locais?

Pergunta 3: a) é smtpd_recipient_restrictionssempre avaliado ou b) avaliado apenas para endereços locais?

Algumas citações da documentação

A documentação indica smtpd_recipient_restrictionsrestrições opcionais que o servidor Postfix SMTP aplica no contexto de um comando RCPT TO do cliente, após smtpd_relay_restrictions. Isso sugere que smtpd_relay_restrictionsé sempre avaliado, incl. endereços locais. Mas o nome da diretiva implica que ela só é considerada para endereços não locais que são encaminhados/retransmitidos.

A documentação para smtpd_recipient_restrictionsestados a partir do Postfix 2.10, regras de permissão de retransmissão são preferencialmente implementadas com smtpd_relay_restrictions, de modo que uma política permissiva de bloqueio de spam smtpd_recipient_restrictionsnão resultará mais em uma política permissiva de retransmissão de e-mail. Isto sugere que isso smtpd_recipient_restrictionsé considerado apenas para endereços locais, mas ignorado para endereços não locais.

No entanto, há um comentário smtpd_relay_resrictionsno padrão main.cfque afirma que nenhuma ação padrão (permitir ou rejeitar) é colocada no final, porque para servidores de correio externos, esta lista é combinada smtpd_recipient_restrictionse, portanto, uma ação antecipada rejectseria abortada prematuramente. Isso sugere que smtpd_recipient_restrictionsé sempre avaliado.

postfix
Martin Hope
user2690527
Asked: 2023-10-28 17:03:08 +0800 CST
  • 5

Eu tenho uma única máquina com uma única instância do Postfix que hospeda diferentes domínios de correio virtual.

É possível configurar o Postfix de forma que use diferentes certificados de servidor TLS (com nomes de domínio diferentes) com base no domínio que o cliente SMTP usou para se conectar ao servidor?

Estou procurando um recurso semelhante à hospedagem virtual do Apache baseada em SNI (indicação de nome de servidor).

Minha configuração DNS (fictícia) se parece com

host12345678.my-hoster.tld.   IN  A           203.0.113.1
1.113.0.203.in-addr.arpa.     IN  PTR         host12345678.my-hoster.tld.

mail.my-1st-domain.tld.       IN  CNAME       host12345678.my-hoster.tld.
my-1st-domain.tld.            IN  MX     10   mail.my-1st-domain.tld.

mail.my-2nd-domain.tld.       IN  CNAME       host12345678.my-hoster.tld.
my-2nd-domain.tld.            IN  MX     10   mail.my-2nd-domain.tld.

Minha configuração (fictícia) do Postfix se parece com

myhostname              = host12345678.my-hoster.tld
mydomain                = host12345678.my-hoster.tld
myorigin                = $myhostname
mydestination           = $myhostname
virtual_mailbox_domains = my-1st-domain.tld my-2nd-domain.tld
virtual_mailbox_maps    = ldap:/etc/postfix/ldap-virtual-mailboxes.cf
virtual_transport       = lmtp:unix:/run/dovecot/dovecot-lmtp

Como adiciono certificados TLS diferentes ao Postfix de forma que ele use my-cert-chain-for-1st-domain.pemou my-cert-chain-for-2n-domain.pemdependendo se o cliente usou mail.my-1st-domain.tldou mail.my-2nd-domain.tldpara resolver 203.0.113.1?

ssl
Martin Hope
user2690527
Asked: 2023-10-23 03:00:50 +0800 CST
  • 5

Estou usando o OpenLDAP 2.6. Quando eu defino a senha de um objeto via

ldappasswd -x -D <dn of root user> -W -S <dn of object whose pwd shall be set>

então algum hash da senha acaba no atributo userPassword.

Qual função hash ldappasswdusa? Como configuro a função hash? Pelo que parece, presumo que o padrão seja um SHA1 que não é mais seguro.

ldap