janeden's questions

Gostaria de usar o mesmo limit_req_zone(ou seja, a mesma taxa de solicitação) em vários locais, mas com burstvalores diferentes para limit_req. A configuração a seguir deve ser capaz de servir 2 páginas e até 10 ativos de suporte para uma página em um único burst. Ele testa bem, mas essa é a maneira certa de fazer isso ou eu precisaria de duas limit_req_zonediretivas diferentes?

http {
    limit_req_zone $binary_remote_addr zone=lr_zone:10m rate=1r/s;
    #...
    server {
        #...
        location / {
            limit_req zone=lr_zone burst=2 nodelay;
            #...
        }
        location ~ ^/(css|fonts|images|pdf)/ {
            limit_req zone=lr_zone burst=10 nodelay;
            #...
        }
    }
}

Eu uso um script wrapper rsync para sincronizar ou fazer backup de/para vários diretórios em diferentes servidores. O script invoca rsync(obviamente), e em algumas configurações lnno servidor.

Restringir o acesso SSH usando o commandparâmetro in authorized_keyspara uma única chave with rrsync(conforme recomendado aqui ) ou chrooting o usuário nos servidores não é viável, pois preciso acessar (ler ou escrever) diretórios em muitos lugares diferentes. Usar um script wrapper para avaliar $SSH_ORIGINAL_COMMAND(conforme sugerido aqui ) permitiria chamadas estáticas para rsyncand ln, mas não para todos os parâmetros diferentes rsynccriados pelo meu script local.

Existe outra maneira de bloquear o acesso nessas circunstâncias?

Na minha LAN de pilha dupla, um servidor de vinculação resolve domínios locais ( *.something.internal) para registros A e AAAA:

# bind zone file db.internal
webserver1.something      IN      AAAA    2001:908:532:bca0:211:32ff:fee5:8627 
webserver1.something      IN      A       192.168.78.93

e todos os servidores web LAN escutam em IPv4 e IPv6. Ao acessar os servidores, o IPv6 é priorizado (como esperado), exceto para meu cliente local (que também atua como um servidor web) no Firefox e Safari. O Chrome usa endereços IPv6 para todos os servidores. Usei a aba Network das ferramentas do desenvolvedor em todos os três navegadores para comparar e verificar o comportamento.

Também usei o about:networking#dnslookuptoolrecurso no Firefox, e o Firefox inverte consistentemente a ordem dos IPs IPv4/IPv6 somente para meu cliente.

Como próximo passo, verifiquei com curl e vi (quase) a mesma coisa. O curl resolve o IPv6 primeiro, mas depois passa a usar o endereço IPv4 para a máquina local:

# This is my local client and webserver
curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:10e0:6db1:72f1:9c2f
* IPv4: 192.168.78.55
*   Trying 192.168.78.55:443...
* Connected to static.something.internal (192.168.78.55) port 443

# This is another webserver on the LAN
curl -Iv https://nuc.something.internal/
* Host nuc.something.internal:443 was resolved.
* IPv6: 2001:908:532:bca0:1e69:7aff:feaf:7455
* IPv4: 192.168.78.42
*   Trying [2001:908:532:bca0:1e69:7aff:feaf:7455]:443...
* Connected to nuc.something.internal (2001:908:532:bca0:1e69:7aff:feaf:7455) port 443

Por que o Firefox, Safari e curl priorizam IPv4 para a máquina local (ao contrário do Chrome)? Poderia ter algo a ver com o fato de que a solicitação é enviada do mesmo endereço IPv6 que o domínio resolve (mesmo que o curl use esse endereço sem problemas quando forçado a usar com curl -Iv -6 https://static.something.internal)?

Observação: se eu preencher /etc/hostsa máquina local (usando 127.0.0.1e ::1para seus domínios) em vez de usar meu servidor DNS, todos os aplicativos priorizarão o IPv6 (o seguinte teste curl foi repetido com o Firefox e o Safari):

curl -Iv https://static.something.internal/
* Host static.something.internal:443 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:443...
* Connected to static.something.internal (::1) port 443

Minha configuração usa um mapa para definir Expirescabeçalhos diferentes para vários arquivos estáticos (com base no tipo MIME). Para conteúdo com proxy ( ), eu uso um cabeçalho uwsgi_passestático :Expires

map $sent_http_content_type $expires {
    default                    off;
    text/html                  7d;
    text/css                   180d;
    application/font-woff2      1y;
    application/pdf             1y;
    ~image/                     1y;
}

server {
    listen       443 ssl http2;
    server_name  example.com;
    
    location / {
            uwsgi_pass django;
            expires 7d;
    }
    
    location ~ ^/(css|fonts|images|pdf|html)/ {
            root /var/www/django/static/;
            expires $expires;
    }
}

Usar o mapa (por meio da $expiresvariável) para conteúdo com proxy não funciona. Existe alguma maneira do nginx identificar o tipo mime de conteúdo com proxy para fazer isso funcionar?

location / {
        uwsgi_pass django;
        expires $expires;
}

(Editar) Como Alexey sugeriu, eu fiz isso:

map $upstream_http_content_type $expires2 {
         default                    off;
         text/html                  2d;
         text/plain                  20d;
         text/css                   180d;
}

location / {
        uwsgi_pass      django;
        expires $expires2;
}

Infelizmente, ainda não há nenhum Expirescabeçalho adicionado ao conteúdo entregue via uwsgi.

Coloquei a configuração de exemplo para autolearn /etc/rspamd/statistic.confem /etc/rspamd/local.d/classifier-bayes.conf:

autolearn {
  spam_threshold = 6.0;
  junk_threshold = 4.0;
  ham_threshold = -0.5;
  check_balance = true;
  min_balance = 0.9;
}

e reiniciei o rspamd, mas nenhum SPAM/HAM parece ser aprendido. o que estou perdendo?

Obrigado, Jan

Eu quero usar a seguinte configuração para o Postfix:

smtpd_relay_restrictions = permit_mynetworks reject_sender_login_mismatch permit_sasl_authenticated defer_unauth_destination, check_policy_service unix:private/policyd-spf
smtpd_sender_login_maps = hash:/etc/postfix/controlled_envelope_senders

controlled_envelope_senderscontém uma única entrada para meu usuário SASL:

[email protected] [email protected]

Essa configuração geralmente funciona bem, mas há dois problemas.

1. O Postfix aceita mensagens de outros endereços (por exemplo, [email protected] ou [email protected]) para [email protected]:

Feb  6 08:28:21 eden postfix/submission/smtpd[568746]: connect from cable-87-79-207-4.nc.de[87.79.207.4]
Feb  6 08:28:21 eden postfix/submission/smtpd[568746]: F0F207F941: client=cable-87-79-207-4.nc.de[87.79.207.4], sasl_method=PLAIN, [email protected]
Feb  6 08:28:22 eden postfix/cleanup[568753]: F0F207F941: message-id=<[email protected]>
Feb  6 08:28:22 eden postfix/qmgr[568743]: F0F207F941: from=<[email protected]>, size=770, nrcpt=2 (queue active)

2. Para mensagens externas enviadas para um dos meus virtual_alias_domains, há um aviso em mail.log:

Feb  6 08:45:35 eden postfix/smtpd[568806]: warning: restriction `reject_authenticated_sender_login_mismatch' ignored: no SASL support

Eu não especifiquei reject_authenticated_sender_login_mismatch, e essas mensagens não são enviadas por remetentes autenticados - então a que se refere este aviso?

Obrigado, Jan

meu provedor de correio (posteo.de) oferece um FQDN durante a troca HELO/EHLO (por exemplo, mout2.posteo.de) – que é visto pelo policyd-spf (s. abaixo) – mas o SpamAssassin em um servidor de recebimento marca o relé como oferta nenhum FQDN ou domínio:

Feb  2 06:17:10 eden policyd-spf[478301]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=185.67.36.66; helo=mout02.posteo.de; [email protected]; receiver=<UNKNOWN> 
Feb  2 06:17:10 eden postfix/smtpd[478286]: 502C97F91B: client=mout02.posteo.de[185.67.36.66]
Feb  2 06:17:10 eden postfix/cleanup[478303]: 502C97F91B: message-id=<[email protected]>
Feb  2 06:17:10 eden spamd[423260]: spamd: connection from 127.0.0.1 [127.0.0.1]:60310 to port 783, fd 6
Feb  2 06:17:10 eden spamd[423260]: spamd: processing message <xxxxx> for xxx:111
Feb  2 06:17:13 eden spamd[423260]: spamd: clean message (0.8/6.0) for xxx:111 in 3.6 seconds, 1910 bytes.
Feb  2 06:17:13 eden spamd[423260]: spamd: result: . 0 - DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED scantime=3.6,size=1910,required_score=6.0,rhost=127.0.0.1,raddr=127.0.0.1,autolearn=no autolearn_force=no

Por que o SpamAssassin não vê o FQDN que está obviamente presente?

Obrigado, Jan

O tópico de tratamento de mensagens de rejeição para rejeições remotas foi trazido à tona pelo menos três vezes ( 1 , 2 , 3 ), e parece que não há uma solução real. Gostaria de saber, no entanto, se o modelo de rejeição pode ser modificado para não incluir a mensagem de rejeição do servidor remoto (que contém informações sobre o endereço do destinatário final que prefiro não enviar a um spammer).

Desde já agradeço qualquer dica, Jan

PS. Não consigo encontrar o modelo de rejeição padrão no Ubuntu 20.04 (não está em /etc/postfix nem em nenhum outro lugar). Como o DSN é criado sem um arquivo de modelo (padrão)?

Eu tenho uma configuração bastante padrão do Postfix para encaminhar e-mails para vários domínios (a configuração inclui postsrsd e spamassassin/spamass-milter, que funciona bem):

myhostname = mail.mydomain.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

virtual_alias_domains = mydomain.com, otherdomain.com, thirddomain.com
virtual_alias_maps = hash:/etc/postfix/virtual

Mas em vez de receber (e encaminhar) e-mails apenas para os endereços definidos em virtual_alias_maps, o Postfix tenta enviar mensagens fraudulentas para vários servidores de e-mail da seguinte forma:

Jan 29 15:52:41 localhost postfix/qmgr[354872]: D07D97F95E: from=<>, size=12267, nrcpt=1 (queue active)
Jan 29 15:52:41 localhost postfix/qmgr[354872]: 9C1C77F952: from=<>, size=11583, nrcpt=1 (queue active)
Jan 29 15:52:41 localhost postfix/smtp[362942]: connect to mail.visceration.co[2606:4700:3032::ac43:8c58]:25: No route to host
Jan 29 15:52:41 localhost postfix/smtp[362942]: connect to mail.visceration.co[2606:4700:3033::6815:369f]:25: No route to host
Jan 29 15:52:41 localhost postfix/smtp[362943]: connect to mail.smartsnakepro.us[2606:4700:3031::6815:efe]:25: No route to host
Jan 29 15:52:42 localhost postfix/smtp[362944]: 9C1C77F952: to=<[email protected]>, relay=mail.gethoys.me[137.184.49.234]:25, delay=139007, delays=139006/0.03/0.76/0.1, dsn=4.7.1, status=deferred (host mail.gethoys.me[137.184.49.234] said: 454 4.7.1 <[email protected]>: Relay access denied (in reply to RCPT TO command))
Jan 29 15:53:11 localhost postfix/smtp[362942]: connect to mail.visceration.co[172.67.140.88]:25: Connection timed out
Jan 29 15:53:11 localhost postfix/smtp[362943]: connect to mail.smartsnakepro.us[104.21.14.254]:25: Connection timed out
Jan 29 15:53:11 localhost postfix/smtp[362943]: connect to mail.smartsnakepro.us[2606:4700:3033::ac43:a0d9]:25: No route to host
Jan 29 15:53:41 localhost postfix/smtp[362942]: connect to mail.visceration.co[104.21.54.159]:25: Connection timed out

Como posso evitar que meu servidor de e-mail reaja a essas conexões? E por que o smtpd não está envolvido (como está no encaminhamento de e-mail legítimo)?

Obrigado, Jan