Esa Jokinen's questions

Let's Encrypt começou a emitir certificados ECC por padrão desde o Certbot 2.0 . Isso não é um problema para navegadores modernos, mas os certificados Let's Encrypt também podem ser usados ​​para outros fins além de HTTPS. Ou seja, alguns servidores SMTP ainda não suportam certificados ECC. Se esse servidor tentar estabelecer STARTTLSconexão com o Postfix que usa certificados ECC, ele falhará.

Os logs indicam que não há cifra compartilhada, apesar de, por exemplo, o Wireshark mostrar que o Client Hello no handshake TLS possui claramente cifras comuns com a lista configurada via smtpd_tls_mandatory_ciphers = medium.

postfix/smtpd[1337]: connect from mail.example.net[198.51.100.1]
postfix/smtpd[1337]: SSL_accept error from mail.example.net[198.51.100.1]: -1
postfix/smtpd[1337]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher:../ssl/statem/statem_srvr.c:2220:
postfix/smtpd[1337]: lost connection after STARTTLS from mail.example.net[198.51.100.1]
postfix/smtpd[1337]: disconnect from mail.example.net[198.51.100.1] ehlo=1 starttls=0/1 commands=1/2

O problema é causado pelo tipo de certificado. É possível obter certificados ECC e RSA do Let's Encrypt usando Certbot? Como configurar o Postfix para usar os dois ao mesmo tempo?

O wrapper de filtro de vírus de e-mail para ClamAV clamassassinanexa seus cabeçalhos aos cabeçalhos das mensagens.

X-Virus-Status: No
X-Virus-Checker-Version: clamassassin 1.2.4 with clamscan / ClamAV 1.0.3/27134/Mon Dec 25 11:40:06 2023

Seria melhor que qualquer MTA que entregasse a mensagem apenas precedesse os cabeçalhos, como sugere a RFC 5322, 3.6 :

No entanto, para efeitos desta especificação, os campos de cabeçalho NÃO DEVEM ser reordenados quando uma mensagem é transportada ou transformada. Mais importante ainda, os campos de cabeçalho de rastreamento e os campos de cabeçalho reenviados NÃO DEVEM ser reordenados e DEVEM ser mantidos em blocos anexados à mensagem. Consulte as seções 3.6.6 e 3.6.7 para obter mais informações.

Por exemplo, spamassassinacrescenta seus X-Spam-*cabeçalhos acima dos cabeçalhos existentes. Por que clamassassinnão faz o mesmo e como alterar esse comportamento? Se, por exemplo, .procmailrctivesse o seguinte, esperaria que esses cabeçalhos aparecessem no mesmo lugar.

:0 fw
| clamassassin

:0 fw
| spamassassin

O Manual de Referência do Administrador do BIND 9, por exemplo, para a versão 9.14.11 ou 9.17.1 afirma em

• 5.2. GRAMATICA DO ARQUIVO DE CONFIGURAÇÃO
  • A categoryfrase
    • queries

A entrada do log de consulta relata primeiro um identificador de objeto do cliente em @0x<hexadecimal-number>formato.

Este termo não foi mencionado em nenhum outro lugar no ARM, e é a única menção de qualquer identificador de objeto .

• Parece não estar relacionado ao cliente que estava enviando a consulta:

  • pode ser o mesmo para consultas de muitos endereços IP não relacionados, mas
  • pode ser diferente para duas consultas do mesmo endereço IP.

• Por exemplo@0x123456789abc

  • a primeira metade 123456parece sempre ser a mesma
  • a segunda metade 789abcmuda de tempos em tempos.

• Nos exemplos de log de consulta, pode ser de 32 bits @0xffffffffou 48 bits @0xffffffffffff.

• Alan Clegg, nesta apresentação do BIND Logging de outubro de 2019, apenas o descreve através do que não é:

  A @0xseguido pelo identificador de objeto do cliente (nada a ver com o endereço do cliente)

O que é e como é calculado?
Que informações podemos extrair dele? Por que é registrado de qualquer maneira?

Os HP EliteBooks (com Windows 10) continuam desligando o WiFi quando a conexão VPN é estabelecida, porque o adaptador de rede virtual é reconhecido como uma conexão com fio, fazendo com que ambos falhem.

Isso acontece apesar de a comutação LAN/WLAN estar desabilitada nas configurações do BIOS e o gerenciamento de energia do adaptador estar desligado.

Existem muitos tutoriais sobre como configurar o OpenDMARC em sua versão favorita do Linux, mas todos eles se concentram em configurações de servidor único. Meu objetivo era manter os servidores MX secundários de backup, mas fazer RejectFailures truecom que o DMARC p=rejectfosse realmente satisfeito.

Isso levou a um problema: a configuração de exemplo tem TrustedAuthservIDs HOSTNAMEfontes SPF e DKIM de upstream. Se isso fosse usado para listar servidores MX secundários, permitiria ignorar completamente as verificações do OpenDMARC no MX primário com um único cabeçalho forjado.

Authentication-Results: <HOSTNAME>;
        dkim=pass (1024-bit key; unprotected) header.d=example.com [email protected];

Como configurar a confiança entre o MX primário e o secundário sem essa falha?

Esta é uma reescrita de outra pergunta no Security Stack Exchange para o escopo de falha do servidor.

Ambiente: A rede de uma empresa tem um dispositivo Firebox M-series com Total Security Suite na sede. Cada filial tem um Firebox da série T menor sem serviços de assinatura. Por esse motivo, todo o tráfego das filiais é roteado pelo dispositivo M-series na matriz. Alguns Fireboxes de filiais possuem um IP estático, outros o obtêm via DHCP.

Ocasionalmente, pode haver alguns problemas com o túnel (por exemplo, se a rede HQ estiver inativa). Portanto, os Fireboxes da filial precisam ser capazes de abandonar a 0.0.0.0/0rota pelo túnel e trabalhar de forma autônoma por um tempo, já que a conectividade com a Internet do BO é crucial para o negócio. Isso funciona com BO Virtual Interface, mas não com 0.0.0.0/0BO GW & Tunnel.

Configuração relacionada simplificada (apenas uma Externa e Confiável if), uma filial com DHCP.

• Firebox-HQ ( 10.9.0.1) - M670 [Fireware OS v12.2.1.B572649]
  • Interfaces (Modo Roteado)
    • eth0: ISP1 [Externo] - 198.51.100.123/24(Estático)
    • eth1: Confiável [Confiável] -10.9.0.1/24
  • Interface VPN ( bvpn20): BovpnVif.BO20 [IKEv1]
    • Rota para10.9.20.0/24
• Firebox-BO20 ( 10.9.20.1) - T55 [Fireware OS v12.2.1.B572649]
  • Interfaces (Modo Roteado)
    • Servidores DNS: 192.0.2.10& 192.0.2.20(servidores DNS do ISP2)
    • eth0: ISP2 [Externo] - 203.0.113.33/24(DHCP)
    • eth1: Confiável [Confiável] -10.9.20.1/24
  • Interface VPN ( bvpn1): BovpnVif.HQ [IKEv1]
    • Rota para0.0.0.0/0
    • Configurações VPN: [x] Remova as rotas VPN quando o túnel para um BOVPN vif estiver inativo.

Tudo funciona exatamente como esperado quando o túnel está inativo. O Firebox-BO20 pode funcionar como um resolvedor de DNS para sua eth1rede. Tanto 10.9.20.0/24o Firebox quanto o próprio podem acessar a Internet.

Problema: Quando o túnel está ativo e a 0.0.0.0/0rota bvpn1é adicionada, os clientes eth1podem acessar a Internet através da VPN e todos os recursos (incluindo servidores DNS) no HQ.

IPv4 Routes
------------
Destination     Gateway         Genmask         Flags   Metric    Interface   
0.0.0.0         0.0.0.0         0.0.0.0         U       1         bvpn1       
0.0.0.0         203.0.113.1     0.0.0.0         UG      5         eth0        
10.9.20.0       0.0.0.0         255.255.255.0   U       0         eth1        
203.0.113.0     0.0.0.0         255.255.255.0   U       0         eth0        
127.0.0.0       0.0.0.0         255.0.0.0       U       0         lo           

No entanto, o Firebox para de funcionar como um resolvedor de DNS e perde sua própria conectividade com a Internet . Isso se deve ao fato de as próprias conexões do Firebox começarem a usar a rota também.

• Os servidores DNS do ISP2 192.0.2.10não 192.0.2.20podem ser acessados ​​pelo ISP1.
• Os dispositivos na rede 10.9.20.0/24podem acessar a Internet através do bvpn1.
• O Firebox não usa seu IP interno 10.9.20.1pelo túnel, mas o 203.0.113.33.
• A regra de firewall Any From Firebox-00é codificada e não aparece no Policy Manager. Caso contrário, teria sido fácil forçá-lo a usar eth0com <policy-routing>.

Existem políticas de firewall para permitir todo o tráfego necessário em ambos os appliances; o problema fica, portanto, delimitado apenas ao roteamento.

Esta é uma pergunta canônica sobre como interpretar o GDPR conforme discutido no meta.

Embora a falha do servidor possa ajudá-lo quando você tiver um problema específico na implementação de algo relacionado ao regulamento, as perguntas gerais sobre a conformidade com o GDPR são muito amplas, não somos advogados que possam interpretar as questões legais e o estilo de perguntas e respostas não permite que o discussão aprofundada necessária para conhecer todos os detalhes em sua organização para ter certeza de que você realmente cumpre.

Tenho uma pergunta sobre o Regulamento Geral de Proteção de Dados (GDPR), regulamento da UE 2016/679.

• Como cumprir o GDPR?
• Minha organização está pronta para o GDPR?
• Devo fazer X para cumprir o GDPR?
• O GDPR me proíbe de fazer Y?
• Z ainda é permitido sob o GDPR?

Estou usando o Debian 9 com PHP-FPM 7.0.26-2e 5.6.32-1do repositório deb.sury.org. A mesma configuração está funcionando bem em um servidor Debian 8 com PHP-FPM5.6.30

• Eu copiei o pool.d/user.confdesse servidor.
• Ambos os php.iniarquivos estão tendo cgi.fix_pathinfo=1.
• O parâmetro também é forçado usando php_admin_value[cgi.fix_pathinfo] = 1.

• Ambos os servidores usam esse pool de maneira semelhante no <VirtualHost>contexto com:

  ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/public_html
  

Agora, há uma página AJAX que precisa ler o caminho de PATH_INFO(possivelmente PATH_TRANSLATED). No entanto, embora essas variáveis ​​tenham conteúdo correto no servidor Debian 8:

["SCRIPT_NAME"]=>
string(14) "/path/ajax.php"
["ORIG_SCRIPT_NAME"]=>
string(25) "/path/ajax.php/para/meters"
["PATH_INFO"]=>
string(12) "/para/meters"
["PATH_TRANSLATED"]=>
string(34) "/home/user/public_html/para/meters"

Eles parecem funcionar de maneira diferente no novo Debian 9 + dub.sury.org:

["SCRIPT_NAME"]=>
string(25) "/path/ajax.php/para/meters"
["PATH_TRANSLATED"]=>
string(22) "/home/user/public_html"

E os prameters ORIG_SCRIPT_NAMEe PATH_INFOestão completamente ausentes.

Por algum motivo, o Firewall do Windows foi desabilitado em um domínio AD do meu cliente. O relatório RSoP mostra que a configuração é originada das Configurações Extras do Registro na Diretiva de Domínio Padrão .

Se isso estivesse em qualquer outro GPO, eu poderia simplesmente removê-lo, mas é a Diretiva de Domínio Padrão . No Controlador de Domínio, não há um modelo ADM/ADMX configurado que controle essas chaves do Registro, portanto, não posso editá-las usando o Editor de Gerenciamento de Diretiva de Grupo. (Provavelmente algum administrador em algum momento teve um em um computador externo com as Ferramentas de Administração de Servidor Remoto instaladas.)

Qual seria a maneira correta de excluir essas configurações? Devo encontrar e instalar o modelo ADM(X) correto ou existe algum atalho? (Todas as configurações que eu realmente preciso já podem ser encontradas Network\Network Connections\Windows Firewall\, mas isso mantém o Firewall do Windows desabilitado para redes públicas e domésticas.)