Hospedar o ASP.NET Core no Linux com o Apache
Por Shayne Boyer
Usando este guia, aprenda como configurar o Apache como um servidor proxy reverso no CentOS 7 para redirecionar o tráfego HTTP para um aplicativo Web ASP.NET Core em execução no servidor Kestrel. A extensão mod_proxy e os módulos relacionados criam o proxy reverso do servidor.
Cuidado
Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (Fim da Vida Útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.
Pré-requisitos
- Servidor que executa o CentOS 7 com uma conta de usuário padrão com privilégio sudo.
- Instale o runtime do .NET Core no servidor.
- Acesse a página Baixar o .NET Core.
- Selecione a versão mais recente não prévia do .NET Core.
- Baixe o runtime não visualizado mais recente na tabela em Executar aplicativos – Runtime.
- Selecione o link Instruções do gerenciador de pacotes do Linux e siga as instruções do CentOS.
- Um aplicativo ASP.NET Core existente.
A qualquer momento no futuro, depois de atualizar a estrutura compartilhada, reinicie os aplicativos ASP.NET Core hospedados pelo servidor.
Publicar e copiar o aplicativo
Configurar o aplicativo para um implantação dependente de estrutura.
Se o aplicativo for executado localmente no Ambiente de desenvolvimento e não estiver configurado pelo servidor para fazer conexões HTTPS seguras, adote uma das seguintes abordagens:
Configure o aplicativo para lidar com conexões seguras locais. Para obter mais informações, veja a seção Configuração de HTTPS.
Configure o aplicativo para ser executado no ponto de extremidade inseguro:
Desativar o middleware de redirecionamento HTTPS no ambiente de desenvolvimento (
Program.cs
):if (!app.Environment.IsDevelopment()) { app.UseHttpsRedirection(); }
Para obter mais informações, confira Usar vários ambientes no ASP.NET Core.
Remova
https://localhost:5001
(se houver) da propriedadeapplicationUrl
no arquivoProperties/launchSettings.json
.
Para obter mais informações sobre a configuração por ambiente, consulte Use vários ambientes no ASP.NET Core.
Execute dotnet publish do ambiente de desenvolvimento para empacotar um aplicativo em um diretório (por exemplo, bin/Release/{TARGET FRAMEWORK MONIKER}/publish
, onde o espaço reservado {TARGET FRAMEWORK MONIKER}
é o TFM (Moniker da Estrutura de Destino)) que pode ser executado no servidor:
dotnet publish --configuration Release
O aplicativo também poderá ser publicado como uma implantação autossuficiente se você preferir não manter o runtime do .NET Core no servidor.
Copie o aplicativo ASP.NET Core para o servidor usando uma ferramenta que se integre ao fluxo de trabalho da organização (por exemplo, SCP, SFTP). É comum para localizar os aplicativos Web no diretório var (por exemplo, var/www/helloapp).
Observação
Em um cenário de implantação de produção, um fluxo de trabalho de integração contínua faz o trabalho de publicar o aplicativo e copiar os ativos para o servidor.
Configurar um servidor proxy
Um proxy reverso é uma configuração comum para atender a aplicativos Web dinâmicos. O proxy reverso encerra a solicitação HTTP e a encaminha para o aplicativo ASP.NET.
Um servidor proxy encaminha as solicitações de cliente para outro servidor, em vez de atendê-las por conta própria. Um proxy reverso encaminha para um destino fixo, normalmente, em nome de clientes arbitrários. Neste guia, o Apache é configurado como o proxy reverso em execução no mesmo servidor em que o Kestrel está servindo o aplicativo ASP.NET Core.
Uma vez que as solicitações são encaminhadas pelo proxy reverso, use o Middleware de Cabeçalhos Encaminhados do pacote Microsoft.AspNetCore.HttpOverrides. O middleware atualiza o Request.Scheme
usando o cabeçalho X-Forwarded-Proto
, de forma que URIs de redirecionamento e outras políticas de segurança funcionam corretamente.
Qualquer componente que dependa do esquema, como autenticação, geração de link, redirecionamentos e localização geográfica, deverá ser colocado depois de invocar o Middleware de Cabeçalhos Encaminhados.
Middlewares de Cabeçalhos Encaminhados devem ser executados antes de outros middlewares. Essa ordenação garantirá que o middleware conte com informações de cabeçalhos encaminhadas que podem consumir os valores de cabeçalho para processamento. Para executar o Middleware de Cabeçalhos Encaminhados após o diagnóstico e o middleware de tratamento de erros, consulte Ordem do Middleware de Cabeçalhos Encaminhados.
Invocar o método UseForwardedHeaders na parte superior de Startup.Configure
antes de chamar outro middleware. Configure o middleware para encaminhar os cabeçalhos X-Forwarded-For
e X-Forwarded-Proto
.
Adicione o namespace Microsoft.AspNetCore.HttpOverrides à parte superior do arquivo:
using Microsoft.AspNetCore.HttpOverrides;
No pipeline de processamento do aplicativo:
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});
app.UseAuthentication();
Se nenhum ForwardedHeadersOptions for especificado para o middleware, os cabeçalhos padrão para encaminhar serão None
.
Os proxies em execução em endereços de loopback (127.0.0.0/8, [::1]
), incluindo o endereço de host local padrão (127.0.0.1), são confiáveis por padrão. Se outros proxies ou redes confiáveis em que a organização trata solicitações entre a Internet e o servidor Web, adicione-os à lista de KnownProxies ou KnownNetworks com ForwardedHeadersOptions. O exemplo a seguir adiciona um servidor proxy confiável no endereço IP 10.0.0.100 ao Middleware de cabeçalhos encaminhados KnownProxies
em Startup.ConfigureServices
:
Adicione o namespace System.Net à parte superior do arquivo:
using System.Net;
Use o seguinte registro de serviço:
services.Configure<ForwardedHeadersOptions>(options =>
{
options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});
Para obter mais informações, veja Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.
Instalar o Apache
Atualize os pacotes CentOS para as respectivas versões estáveis mais recentes:
sudo yum update -y
Instale o servidor Web do Apache no CentOS com um único comando yum
:
sudo yum -y install httpd mod_ssl
Saída de exemplo depois de executar o comando:
Downloading packages:
httpd-2.4.6-40.el7.centos.4.x86_64.rpm | 2.7 MB 00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : httpd-2.4.6-40.el7.centos.4.x86_64 1/1
Verifying : httpd-2.4.6-40.el7.centos.4.x86_64 1/1
Installed:
httpd.x86_64 0:2.4.6-40.el7.centos.4
Complete!
Observação
Neste exemplo, o resultado reflete httpd.86_64, pois a versão do CentOS 7 é de 64 bits. Para verificar o local em que o Apache está instalado, execute whereis httpd
em um prompt de comando.
Configurar o Apache
Os arquivos de configuração do Apache estão localizados no diretório /etc/httpd/conf.d/
. No Apache no Ubuntu, todos os arquivos de configuração de host virtual são armazenados no /etc/apache2/sites-available
. Qualquer arquivo com a extensão .conf é processado em ordem alfabética, além dos arquivos de configuração do módulo em /etc/httpd/conf.modules.d/
, que contém todos os arquivos de configuração necessários para carregar os módulos.
Crie um arquivo de configuração chamado helloapp.conf para o aplicativo:
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}s
</VirtualHost>
<VirtualHost *:80>
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
ServerName www.example.com
ServerAlias *.example.com
ErrorLog ${APACHE_LOG_DIR}/helloapp-error.log
CustomLog ${APACHE_LOG_DIR}/helloapp-access.log common
</VirtualHost>
Nota: as versões do Apache anteriores a 2.4.6 não exigem o RequestHeader set
contêm o final s
:
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>
Para obter mais informações, veja %{VARNAME}s
in Módulo Apache mod_headers.
O bloco VirtualHost
pode aparecer várias vezes, em um ou mais arquivos em um servidor. No arquivo de configuração anterior, o Apache aceita tráfego público na porta 80. O domínio www.example.com
está sendo atendido e o alias *.example.com
é resolvido para o mesmo site. Para obter mais informações, confira Suporte a host virtual baseado em nome. As solicitações passadas por proxy na raiz para a porta 5000 do servidor em 127.0.0.1. Para a comunicação bidirecional, ProxyPass
e ProxyPassReverse
são necessários. Para alterar o IP/porta do Kestrel, veja Kestrel: configuração de ponto de extremidade.
O bloco VirtualHost
pode aparecer várias vezes, em um ou mais arquivos em um servidor. No arquivo de configuração anterior, o Apache aceita tráfego público na porta 80. O domínio www.example.com
está sendo atendido e o alias *.example.com
é resolvido para o mesmo site. Para obter mais informações, confira Suporte a host virtual baseado em nome. As solicitações passadas por proxy na raiz para a porta 5000 do servidor em 127.0.0.1. Para a comunicação bidirecional, ProxyPass
e ProxyPassReverse
são necessários. Para alterar o IP/porta do Kestrel, veja Kestrel: configuração de ponto de extremidade.
Crie um link simbólico para o diretório /etc/apache2/sites-enabled
para ser lido pelo Apache durante a inicialização:
sudo ln -s /etc/apache2/sites-available/helloapp.conf /etc/apache2/sites-enabled/
Aviso
Falha ao especificar uma diretiva ServerName no bloco VirtualHost expõe seu aplicativo para vulnerabilidades de segurança. Associações de curinga de subdomínio (por exemplo, *.example.com
) não oferecerão esse risco de segurança se você controlar o domínio pai completo (em vez de *.com
, o qual é vulnerável). Para obter mais informações, consulte RFC 9110: Semântica HTTP (Seção 7.2: Host e :authority).
O registro em log pode ser configurado por VirtualHost
usando diretivas ErrorLog
e CustomLog
. ErrorLog
é o local em que o servidor registrará em log os erros, enquanto CustomLog
define o nome de arquivo e o formato do arquivo de log. Nesse caso, esse é o local em que as informações de solicitação são registradas em log. Há uma linha para cada solicitação.
Salve o arquivo e teste a configuração. Se tudo passar, a resposta deverá ser Syntax [OK]
.
sudo apachectl configtest
Reinicie o Apache:
sudo systemctl restart httpd
sudo systemctl enable httpd
Para obter mais informações sobre valores de diretiva de cabeçalho, veja Mod_headers do módulo Apache.
Monitorar o aplicativo
O Apache agora está configurado para encaminhar solicitações feitas a http://localhost:80
para o aplicativo ASP.NET Core em execução no Kestrel em http://127.0.0.1:5000
. No entanto, o Apache não está configurado para gerenciar o processo Kestrel. Use systemd e crie um arquivo de serviço para iniciar e monitorar o aplicativo Web subjacente. systemd é um sistema de inicialização que fornece muitos recursos poderosos para iniciar, parar e gerenciar processos.
Criar o arquivo de serviço
Crie o arquivo de definição de serviço:
sudo nano /etc/systemd/system/kestrel-helloapp.service
Eis um exemplo de arquivo de serviço para o aplicativo:
[Unit]
Description=Example .NET Web API App running on CentOS 7
[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Restart=always
# Restart service after 10 seconds if the dotnet service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=dotnet-example
User=apache
Environment=ASPNETCORE_ENVIRONMENT=Production
[Install]
WantedBy=multi-user.target
Observação: defina a pasta local/bin
para sua distribuição. Algumas versões do Ubuntu exigem ExecStart=/usr/bin/dotnet
No exemplo anterior, o usuário que gerencia o serviço é especificado pela opção User
. O usuário (apache
) deve existir e ter a propriedade adequada dos arquivos do aplicativo.
Use TimeoutStopSec
para configurar a duração do tempo de espera para o aplicativo desligar depois de receber o sinal de interrupção inicial. Se o aplicativo não desligar nesse período, o SIGKILL será emitido para encerrá-lo. Forneça o valor como segundos sem unidade (por exemplo, 150
), um valor de duração (por exemplo, 2min 30s
) ou infinity
para desabilitar o tempo limite. TimeoutStopSec
é revertido para o valor padrão de DefaultTimeoutStopSec
no arquivo de configuração do gerenciador (systemd-system.conf, system.conf.d, systemd-user.conf e user.conf.d). O tempo limite padrão para a maioria das distribuições é de 90 segundos.
# The default value is 90 seconds for most distributions.
TimeoutStopSec=90
Alguns valores (por exemplo, cadeias de conexão de SQL) devem ser escapadas para que os provedores de configuração leiam as variáveis de ambiente. Use o seguinte comando para gerar um valor corretamente com caracteres de escape para uso no arquivo de configuração:
systemd-escape "<value-to-escape>"
Separadores do tipo dois-pontos (:
) não são compatíveis com nomes de variáveis de ambiente. Use um sublinhado duplo (__
) no lugar de dois-pontos. O provedor de configuração de Variáveis de Ambiente converte caracteres de sublinhado duplo em dois-pontos quando as variáveis de ambiente são lidas na configuração. No exemplo a seguir, a chave de cadeia de conexão ConnectionStrings:DefaultConnection
está definida no arquivo de definição de serviço como ConnectionStrings__DefaultConnection
:
Separadores do tipo dois-pontos (:
) não são compatíveis com nomes de variáveis de ambiente. Use um sublinhado duplo (__
) no lugar de dois-pontos. O provedor de configuração de Variáveis de Ambiente converte caracteres de sublinhado duplo em dois-pontos quando as variáveis de ambiente são lidas na configuração. No exemplo a seguir, a chave de cadeia de conexão ConnectionStrings:DefaultConnection
está definida no arquivo de definição de serviço como ConnectionStrings__DefaultConnection
:
Environment=ConnectionStrings__DefaultConnection={Connection String}
Salve o arquivo e habilite o serviço:
sudo systemctl enable kestrel-helloapp.service
Inicie o serviço e verifique se ele está em execução:
sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service
◝ kestrel-helloapp.service - Example .NET Web API App running on CentOS 7
Loaded: loaded (/etc/systemd/system/kestrel-helloapp.service; enabled)
Active: active (running) since Thu 2016-10-18 04:09:35 NZDT; 35s ago
Main PID: 9021 (dotnet)
CGroup: /system.slice/kestrel-helloapp.service
└─9021 /usr/local/bin/dotnet /var/www/helloapp/helloapp.dll
Com o proxy reverso configurado e o Kestrel gerenciado por meio de systemd, o aplicativo Web está totalmente configurado e pode ser acessado em um navegador no computador local em http://localhost
. Inspecionando os cabeçalhos de resposta, o cabeçalho Server indica que o aplicativo ASP.NET Core é servido pelo Kestrel:
HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 16:22:23 GMT
Server: Kestrel
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Exibir logs
Já que o aplicativo Web usando Kestrel é gerenciado usando systemd, os eventos e os processos são registrados em um diário centralizado. No entanto, esse diário contém todas as entradas para todos os serviços e processos gerenciados por systemd. Para exibir os itens específicos de kestrel-helloapp.service
, use o seguinte comando:
sudo journalctl -fu kestrel-helloapp.service
Para filtragem de hora, especifique opções de tempo com o comando. Por exemplo, use --since today
para filtrar o dia atual ou --until 1 hour ago
para ver as entradas da hora anterior. Para obter mais informações, confira a página de manual para journalctl.
sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"
Proteção de dados
A pilha de proteção de dados do ASP.NET Core é usada por vários middlewares do ASP.NET Core, incluindo o middleware de autenticação (por exemplo, o middleware de cookie) e as proteções de CSRF (solicitação intersite forjada). Mesmo se as APIs de Proteção de Dados não forem chamadas pelo código do usuário, a proteção de dados deverá ser configurada para criar um repositório de chaves criptográfico persistente. Se a proteção de dados não estiver configurada, as chaves serão mantidas na memória e descartadas quando o aplicativo for reiniciado.
Se o token de autenticação for armazenado na memória quando o aplicativo for reiniciado:
- Todos os tokens de autenticação baseados em cookie serão invalidados.
- Os usuários precisam entrar novamente na próxima solicitação deles.
- Todos os dados protegidos com o token de autenticação não poderão mais ser descriptografados. Isso pode incluir os tokens CSRF e cookies TempData do MVC do ASP.NET Core.
Para configurar a proteção de dados de modo que ela mantenha e criptografe o token de autenticação, consulte:
- Provedores de armazenamento de chaves no ASP.NET Core
- Criptografia de chave em repouso no Windows e no Azure usando o ASP.NET Core
Proteger o aplicativo
Configurar o firewall
Firewalld é um daemon dinâmico para gerenciar o firewall com suporte para zonas de rede. Portas e filtragem de pacote ainda podem ser gerenciados pelo iptables. Firewalld deve ser instalado por padrão. yum
pode ser usado para instalar o pacote ou verificar se ele está instalado.
sudo yum install firewalld -y
Use firewalld
para abrir somente as portas necessárias para o aplicativo. Nesse caso, as portas 80 e 443 são usadas. Os comandos a seguir definem permanentemente as portas 80 e 443 para estarem abertas:
sudo firewall-cmd --add-port=80/tcp --permanent
sudo firewall-cmd --add-port=443/tcp --permanent
Recarregue as configurações de firewall. Verifique os serviços e as portas disponíveis na zona padrão. As opções estão disponíveis por meio da inspeção de firewall-cmd -h
.
sudo firewall-cmd --reload
sudo firewall-cmd --list-all
public (default, active)
interfaces: eth0
sources:
services: dhcpv6-client
ports: 443/tcp 80/tcp
masquerade: no
forward-ports:
icmp-blocks:
rich rules:
Configuração de HTTPS
Configurar o aplicativo para conexões seguras (HTTPS) locais
O comando dotnet run usa o arquivo Properties/launchSettings.json
do aplicativo, que configura o aplicativo para escutar nas URLs fornecidas pela propriedade applicationUrl
(por exemplo, https://localhost:5001;http://localhost:5000
).
Configure o aplicativo para usar um certificado no desenvolvimento para o comando dotnet run
ou no ambiente de desenvolvimento (F5 ou Ctrl + F5 no Visual Studio Code) usando uma das seguintes abordagens:
Configurar o proxy reverso para conexões de cliente seguras (HTTPS)
Aviso
A configuração de segurança nesta seção é uma configuração geral a ser usada como ponto de partida para personalização adicional. Não é possível fornecer suporte para ferramentas, servidores e sistemas operacionais de terceiros. Use a configuração nesta seção por sua conta e risco. Para obter mais informações, acesse os seguintes recursos:
- Criptografia SSL/TLS do Apache (documentação do Apache)
- Gerador de configuração SSL mozilla.org
Para configurar o Apache para HTTPS, o módulo mod_ssl é usado. Quando o módulo httpd foi instalado, o módulo mod_ssl também foi instalado. Se ele não foi instalado, use yum
para adicioná-lo à configuração.
sudo yum install mod_ssl
Para impor o HTTPS, instale o módulo mod_rewrite
para habilitar a regravação de URL:
sudo yum install mod_rewrite
Modifique o arquivo helloapp.conf para habilitar a comunicação segura na porta 443.
O exemplo a seguir não configura o servidor para redirecionar solicitações inseguras. É recomendável usar o Middleware de Redirecionamento HTTPS. Para obter mais informações, confira Impor HTTPS no ASP.NET Core.
Observação
Para ambientes de desenvolvimento em que a configuração do servidor manipula o redirecionamento seguro em vez do Middleware de Redirecionamento HTTPS, recomendamos usar redirecionamentos temporários (302) em vez de permanentes (301). O cache de link pode causar um comportamento instável em ambientes de desenvolvimento.
A adição de um cabeçalho Strict-Transport-Security
(HSTS) garante que todas as próximas solicitações feitas pelo cliente sejam por HTTPS. Para obter diretrizes sobre como definir o Strict-Transport-Security
cabeçalho, confira Impor HTTPS em ASP.NET Core.
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>
<VirtualHost *:443>
Protocols h2 http/1.1
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5000/
ErrorLog /var/log/httpd/helloapp-error.log
CustomLog /var/log/httpd/helloapp-access.log common
SSLEngine on
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder off
SSLCompression off
SSLSessionTickets on
SSLUseStapling off
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
</VirtualHost>
Observação
Este exemplo usa um certificado gerado localmente. SSLCertificateFile deve ser o arquivo de certificado primário para o nome de domínio. SSLCertificateKeyFile deve ser o arquivo de chave gerado quando o CSR é criado. SSLCertificateChainFile deve ser o arquivo de certificado intermediário (se houver) fornecido pela autoridade de certificação.
O Apache HTTP Server versão 2.4.43 ou mais recente é necessário para operar um servidor Web TLS 1.3 com OpenSSL 1.1.1.
Observação
O exemplo anterior desabilita a associação do protocolo OCSP. Para obter mais informações e diretrizes sobre como habilitar o OCSP, consulte Associação do OCSP (documentação do Apache).
Salve o arquivo e teste a configuração:
sudo service httpd configtest
Reinicie o Apache:
sudo systemctl restart httpd
Sugestões adicionais do Apache
Reiniciar aplicativos com atualizações de estrutura compartilhada
Depois de atualizar a estrutura compartilhada no servidor, reinicie os aplicativos ASP.NET Core hospedados pelo servidor.
Cabeçalhos adicionais
Para proteção contra ataques mal-intencionados, há alguns cabeçalhos que devem ser modificados ou adicionados. Verifique se o módulo mod_headers
está instalado:
sudo yum install mod_headers
Proteger o Apache contra ataques de clickjacking
Clickjacking, também conhecido como um ataque por inferência na interface do usuário, é um ataque mal-intencionado em que o visitante do site é levado a clicar em um link ou botão em uma página diferente daquela que está visitando atualmente. Use X-FRAME-OPTIONS
para proteger o site.
Para atenuar ataques de clickjacking:
Edite o arquivo httpd.conf:
sudo nano /etc/httpd/conf/httpd.conf
Adicione a linha
Header append X-FRAME-OPTIONS "SAMEORIGIN"
.Salve o arquivo.
Reinicie o Apache.
Detecção de tipo MIME
O cabeçalho X-Content-Type-Options
impedirá o Internet Explorer de farejar por MIME (determinar o Content-Type
de um arquivo com base no conteúdo do arquivo). Se o servidor define o cabeçalho Content-Type
para text/html
com a opção nosniff
definida, o Internet Explorer renderiza o conteúdo como text/html
, independentemente do conteúdo do arquivo.
Edite o arquivo httpd.conf:
sudo nano /etc/httpd/conf/httpd.conf
Adicione a linha Header set X-Content-Type-Options "nosniff"
. Salve o arquivo. Reinicie o Apache.
Balanceamento de carga
Este exemplo mostra como instalar e configurar o Apache no CentOS 7 e Kestrel no mesmo computador da instância. Para não ter um ponto único de falha, o uso de mod_proxy_balancer e a modificação do VirtualHost permitiriam o gerenciamento de várias instâncias dos aplicativos Web protegidos pelo servidor proxy do Apache.
sudo yum install mod_proxy_balancer
No arquivo de configuração mostrado abaixo, uma instância adicional do helloapp
é configurada para ser executada na porta 5001. A seção Proxy é definida com uma configuração de balanceador com dois membros para balancear carga de byrequests.
<VirtualHost *:*>
RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
</VirtualHost>
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>
<VirtualHost *:443>
ProxyPass / balancer://mycluster/
ProxyPassReverse / http://127.0.0.1:5000/
ProxyPassReverse / http://127.0.0.1:5001/
<Proxy balancer://mycluster>
BalancerMember http://127.0.0.1:5000
BalancerMember http://127.0.0.1:5001
ProxySet lbmethod=byrequests
</Proxy>
<Location />
SetHandler balancer
</Location>
ErrorLog /var/log/httpd/helloapp-error.log
CustomLog /var/log/httpd/helloapp-access.log common
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:!RC4+RSA:+HIGH:+MEDIUM:!LOW:!RC4
SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
</VirtualHost>
Limites de taxa
Usando mod_ratelimit, que está incluído no módulo httpd, a largura de banda de clientes pode ser limitada:
sudo nano /etc/httpd/conf.d/ratelimit.conf
O arquivo de exemplo limita a largura de banda a 600 KB/s no local raiz:
<IfModule mod_ratelimit.c>
<Location />
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 600
</Location>
</IfModule>
Campos de cabeçalho da solicitação muito grandes
As configurações padrão do servidor proxy normalmente limitam os campos de cabeçalho de solicitação a 8.190 bytes. Um aplicativo pode exigir campos maiores que o padrão (por exemplo, aplicativos que utilizam o Microsoft Entra ID). Se forem necessários campos mais longos, a diretiva LimitRequestFieldSize do servidor proxy exigirá ajuste. O valor a ser aplicado depende do cenário. Para obter mais informações, confira a documentação do servidor.
Aviso
Não aumente o valor padrão de LimitRequestFieldSize
a menos que necessário. Aumentar esse valor aumenta o risco de estouro de buffer (estouro) e ataques de DoS (negação de serviço) por usuários mal-intencionados.
Recursos adicionais
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários