Jeff's questions

Como você faz o Apache (2.4.52) parar de registrar o AH10244 [core:error]?

[Sun Mar 13 05:23:47.884213 2022] [core:error] [pid 558:tid 140262206592768] [client 45.146.165.37:51872] AH10244: invalid URI path (/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh)
[Tue Mar 15 10:19:35.439128 2022] [core:error] [pid 14291:tid 140557854676736] [client 45.77.75.45:37640] AH10244: invalid URI path (/%)

Essas mensagens de log são causadas por utilitários de linha de comando (wget, curl, lynx) solicitando endereço IP ou vhost, por exemplo

http://10.0.0.100/%
http://example.org/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh // note: a common attack vector

A única coisa que encontrei para funcionar até agora é LogLevel notice core:crit, mas ainda quero que outras core:noticemensagens apareçam no meu log, para que essa solução não seja inicial.

A resposta muito bem pode ser, não é possível . Se sim, por favor, deixe uma resposta me informando.

Normalmente nos meus blocos vhost eu faço:

Define SITE example.com

SSLCertificateFile /path/to/${SITE}.crt
SSLCertificateKeyFile /path/to/${SITE}.key

Eu estou querendo saber se é possível criar uma variável no Apache que corresponda aos meus nomes de arquivos para example.com.crte example.com.key?

Suponho que não, mas vale a pena pedir para consolidar meus blocos vhost.

Editar eu acho que o que eu preciso aqui éSetEnvIf

Estou tentando consolidar todos os meus VirtualHosts de porta 80 em um bloco por conveniência, mas estou lutando com a peça final do quebra-cabeça.

Todos os vhosts da porta 80 aceitam uma conexão wwwe a . Todas as outras solicitações 301 para https://example.com/ - não www.non-www/.well-known/acme-challenge/

Acho que preciso transformar %{HTTP_HOST}em uma variável Defineable menos o possível "www" , por exemplo ${SITE}.

Ou talvez haja uma maneira melhor?

É aqui que estou até agora:

<VirtualHost ${IP1}:80>
    Define SITE hmmm
    ServerName example-1.com
    ServerAlias www.example-1.com
    ServerAlias example-2.com
    ServerAlias www.example-2.com
    # And so on... 25 vhosts
    DocumentRoot /home/user/htdocs/${SITE}

    RewriteEngine on
    RewriteCond %{REQUEST_URI} !^/\.well\-known/acme\-challenge/
    RewriteRule ^ https://${SITE}%{REQUEST_URI} [NE,R=301,L]

    <Directory /home/user/htdocs/${SITE}>
        Options FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>
</VirtualHost>

Isso tem me atormentado por um tempo, então é hora de perguntar.

O MySQL error_logé preenchido com "Informações de status" quando o servidor é reinicializado devido a SIGHUP. Aqui está um link que descreve o comportamento: Resposta do MySQL Server aos sinais SIGHUP

Entendo o que está acontecendo, mas não sei como resolver.

Eu tenho um script que controla o início/parada do mysqld: /etc/init.d/mysql

E aqui está o arquivo mysql-helpers de origem referenciado pelo script init.d.

Não consigo encontrar de onde vem o SIGHUP? Ou talvez esteja vindo do sistema operacional? Debian 10.

Editar

Fazer service mysql restartou stopnunca produzir a entrada de log extra, então talvez tenha algo a ver com o processo de desligamento durante a reinicialização do servidor | parada? Não entendo o SIGHUP o suficiente para determinar se estou no caminho certo ou não.

Em vez de adicionar protocols h2 http/1.1todos os 45 dos meus VirtualHost *:443blocos, eu queria saber se existe uma maneira de verificar a condição apropriada e, em seguida, definir protocolscom base nisso? Acho, mas não com 100% de certeza, que o teste apropriado deveria ser ver se a requisição era para https. Talvez eu deva testar a porta em vez disso?

Isso é o que eu tenho até agora e não está funcionando.

Define PROTOCOLS "http/1.1"

<If "%{HTTPS} == 'on'">
    Define PROTOCOLS "h2 http/1.1"
</If>

Protocols ${PROTOCOLS}

Editar

Protocolsnão funciona em um contexto de diretório.

Editar 2

Eu simplesmente não acho que seja possível, dado que a Protocolsdiretiva, se definida globalmente, não pode ser modificada dinamicamente assim. O servidor já analisou a diretiva. Está definido. Corrija-me se eu estiver errado.

Estou atualizando meu servidor web Apache e me perguntando se preciso declarar um arquivo CA na configuração do vhost?

Minha configuração do vhost é

SSLEngine on
SSLCertificateFile /home/user/ssl/${SITE}-cert.pem
SSLCertificateKeyFile /home/user/ssl/${SITE}-key.pem
SSLCertificateChainFile /home/user/ssl/${SITE}-ca.pem
#SSLCACertificateFile /home/user/ssl/${SITE}-ca.pem

Por padrão, o Apache é fornecido apenas com o SSLCertificateFilee SSLCertificateKeyFileativo. O mesmo com o pacote do Debian. Eu entendo os dois.

Por padrão, ambos SSLCertificateChainFilee SSLCACertificateFileestão desabilitados na fonte do Apache e no pacote do Debian. Eu pensei que tinha entendido isso, mas não tenho tanta certeza agora.

Todos os meus sites funcionam bem com as duas CAdiretivas desabilitadas.

Mas estou perdendo alguma coisa? A desativação de ambos está fazendo com que meu servidor forneça uma CA nos bastidores, como no /etc/ssl/certs do sistema?

Let's Encrypt fornece seu arquivo CA durante a renovação, então achei que não faria mal especificar o SSLCertificateChainFile, mas quero entender por que meus sites funcionam sem ele?

Essas duas diretivas CA não servem a um propósito semelhante ao arquivo de pacote CA do cURL obtido do Mozilla ? Posso apenas apontar SSLCACertificateFile para isso no meu servidor e encerrar o dia?

Foi meu entendimento que o cliente se encarrega de verificar o certificado do site usando sua própria CA autorizada. Estou errado?

Os documentos não parecem oferecer nenhum insight:

SSLCertificateChainFile e SSLCACertificateFile

Eu sou novo na cena de hospedagem VPS e já faz um tempo desde que instalei o Debian, 7-Wheezy foi o meu último.

Estou vendo uma pesquisa de uma unidade de CD rom após o GRUB do SeaBIOS (veja a primeira captura de tela).

Por "depois do GRUB", quero dizer, após a tela pedindo para você selecionar qual sistema operacional inicializar (veja a segunda captura de tela).

Isso está sendo feito pelo Debian (10) ou pela empresa de hospedagem VPS (Vultr)?

O que mais me confunde é que ele pesquisa o CD após o GRUB. Eu pensei que o GRUB veio depois do BIOS. Talvez seja uma coisa de VPS que eu não saiba.

Eu gostaria de desabilitar a pesquisa de CD na inicialização, mas não tenho certeza de como proceder.

É possível?

Tentando mover minha segurança de script para o nível do servidor.

Com PHP, basta verificar se $_SERVER['HTTP_X_REQUESTED_WITH']está definido para XMLHttpRequest(jQuery adicionado).

Acho que talvez uma pergunta melhor seja, como posso adicionar o X-Requested-Withcabeçalho da solicitação a uma variável que posso verificar com um mod_rewrite RewriteCond?

O %{REQUEST_FILENAME}contém uma string como esta:

/web/webroot/index.php

Vejo que muitas pessoas recomendam testar se um arquivo existe e tem uma extensão .php como esta:

RewriteCond %{REQUEST_FILENAME}.php -f

O .phpdepois não é %{REQUEST_FILENAME}redundante? A variável já deve conter o .php, certo?

Parece que adicionar .phpdepois %{REQUEST_FILENAME}faria a verificação de TestString adicionar um .php extra, assim:

/web/webroot/index.php.php

Estou sentindo falta de algo simples, tenho certeza, mas não sei o que é.

O contexto é este:

RewriteCond %{THE_REQUEST} ^.*?\.php [NC]
RewriteRule ^ - [R=404,NE,L]

RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule ^ %{REQUEST_FILENAME}.php [L]

Executando o Apache 2.4.6 com vhosts e PHP 7.2.34 e acabei de descobrir um problema estranho.

Um URL válido em meus vhosts, como http://example.com/exists.phptambém pode ser servido com uma barra final; por exemplo http://example.com/exists.php/.

Este é apenas o caso se o arquivo que está sendo veiculado terminar com .php, não com .html, .txt etc.

Não há regras mod_rewrite que afetem os vhosts. Meu php.ini parece bom.

Alguma ideia? Comportamento normal?

Chegou ao meu conhecimento que talvez eu precise ajustar minha configuração do Postfix da seguinte maneira para corrigir um problema de entrega de e-mail de um remetente em particular:

# vim /etc/postfix/main.cf

+ header_checks = regexp:/etc/postfix/header_checks

# vim /etc/postfix/header_checks // NEW FILE

+ /^Delivered-To: .*/ IGNORE

# postmap /etc/postfix/header_checks
# service postfix restart

A parte que me sinto desconfortável em reverter é o postmapcomando.

O plano atual para reverter isso se não resolver meu problema é apenas remover a header_checkslinha do main.cf e reiniciar o Postfix. Isso soa certo?

Meu servidor está funcionando como um campeão há mais de 4 anos e eu odeio mexer com ele quando não é necessário. Infelizmente é necessário agora.

Você acha necessário gerar novamente suas chaves DKIM a cada 1-6 meses para evitar que seus e-mails entrem na pasta de lixo eletrônico dos servidores de recebimento?

Alguns guias recomendam isso, alguns até dizem que é "Melhor prática" fazê-lo, mas a maioria dos outros guias não menciona isso. Evidentemente, é a melhor prática fazer isso , mas qual é a sua experiência no mundo real?

Acabei de modernizar meu antigo servidor Debian 7 Postfix para incluir DKIM + DMARC (+ SPF) e quero saber se devo fazer manutenção contínua para regenerar as chaves.

O que a maioria das pessoas está fazendo? Quais são suas experiências no mundo real? Você notou que as chaves antigas são a causa do seu e-mail ser enviado para a pasta de lixo eletrônico?

Sou um remetente de baixo volume, talvez 5-10 e-mails/dia sejam enviados pelo meu servidor.

Eu tenho vários hosts virtuais baseados em IP aos quais desejo adicionar o Strict-Transport-Securitycabeçalho. Estou usando o Apache 2.4 personalizado compilado.

Atualmente tenho dois <VirtualHost>containers para cada domínio, assim:

<VirtualHost ${IP3}:80>
    ...
    <IfModule rewrite_module>
        RewriteEngine On
        RewriteCond %{HTTPS} off [OR]
        RewriteCond %{HTTP_HOST} !^www\. [NC]
        RewriteRule .* https://www.${SITE}%{REQUEST_URI} [NE,R=301,L]
    </IfModule>
    ...
</VirtualHost>

<VirtualHost ${IP3}:443>
    ...
</VirtualHost>

O primeiro VirtualHost faz um mod_rewrite simples para solicitações não-ssl e não-www redirecionando todas as solicitações para o segundo VirtualHost. Fácil.

Questão 1

Devo configurar minhas coisas mod_headers no primeiro contêiner VirtualHost (:80), no segundo (:443) ou em ambos?

Questão 2

Meu material mod_headers deve vir antes ou depois do material mod_rewrite?

Questão 3

Devo aplicar os Strict-Transport-Securitycabeçalhos a todos os arquivos ou apenas aos arquivos .htm, .html e .php? (Eu tenho uma diretiva FilesMatch configurada como um qualificador para certos cabeçalhos)

Minhas melhores respostas

Antes de qualquer teste, minhas melhores respostas seriam:

Q1. Adicione o material mod_headers a ambos os contêineres VirtualHost.

Q2. O material mod_headers deve vir antes do material mod_rewrite.

Q3. Sim, apenas os tipos de arquivo da Web que você atende precisam do Strict-Transport-Security. Não é necessário adicioná-lo a .gifs, .pngs, .svgs, .css, .js etc.

EDIT: Vejo que o stackexchange também os adiciona ao arquivo robots.txt.

Obrigado.