Hospedar o ASP.NET Core no Linux com Nginx

Por Sourabh Shirhatti

Este guia explica a configuração de um ambiente ASP.NET Core pronto para produção para Ubuntu, Red Hat Enterprise (RHEL) e SUSE Linux Enterprise Server.

Para obter informações sobre outras distribuições Linux suportadas pelo ASP.NET Core, consulte Pré-requisitos para .NET Core no Linux.

Este guia:

• Coloca um aplicativo ASP.NET Core existente atrás de um servidor proxy reverso.
• Configura o servidor proxy reverso para encaminhar solicitações para o servidor Web Kestrel.
• Garante que o aplicativo Web seja executado na inicialização como um daemon.
• Configura uma ferramenta de gerenciamento de processos para ajudar a reiniciar o aplicativo Web.

Pré-requisitos

Ubuntu

• Acesso ao Ubuntu 20.04 com uma conta de utilizador padrão com privilégio sudo.
• O mais recente ambiente de execução estável do .NET instalado no servidor.
• Um aplicativo ASP.NET Core existente.

Red Hat Enterprise Linux

• Acesso ao Red Hat Enterprise (RHEL) 8.0 ou posterior com uma conta de utilizador padrão com privilégios de sudo.
• O runtime mais recente e estável do .NET está instalado no servidor.
• Um aplicativo ASP.NET Core existente.

SUSE Linux Enterprise Server

• Acesso ao SLES 12 ou 15 com uma conta de usuário padrão com privilégio sudo.
• O ambiente de execução mais recente e estável do .NET está instalado no servidor.
• 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 através da aplicação

Configure a aplicação para uma implementação dependente da 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 locais seguras. Para obter mais informações, consulte a seção de configuração HTTPS.

• Configure o aplicativo para ser executado no ponto de extremidade inseguro:

  • Desative o middleware de redirecionamento HTTPS no ambiente de desenvolvimento (Program.cs):

    if (!app.Environment.IsDevelopment())
    {
        app.UseHttpsRedirection();
    }
    

    Para obter mais informações, consulte Usar vários ambientes no ASP.NET Core.

  • Remova https://localhost:5001 (se houver) da propriedade applicationUrl no arquivo Properties/launchSettings.json.

Para obter mais informações sobre a configuração por ambiente, consulte Usar vários ambientes no ASP.NET Core.

Execute o comando dotnet publish a partir do ambiente de desenvolvimento para empacotar uma aplicação num diretório (por exemplo, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, onde o espaço reservado {TARGET FRAMEWORK MONIKER} é o "Target Framework Moniker (TFM)" ) que possa ser executado no servidor:

dotnet publish --configuration Release

A aplicação também pode ser publicada como uma implantação independente se preferir não manter o runtime .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 localizar 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.

Teste o aplicativo:

1. Na linha de comando, execute o aplicativo: dotnet <app_assembly>.dll.
2. Em um navegador, navegue até http://<serveraddress>:<port> para verificar se o aplicativo funciona no Linux localmente.

Configurar um servidor proxy reverso

Um proxy reverso é uma configuração comum para servir aplicativos Web dinâmicos. Um proxy reverso encerra a solicitação HTTP e a encaminha para o aplicativo ASP.NET Core.

Usar um servidor proxy reverso

Kestrel é ótimo para veicular conteúdo dinâmico do ASP.NET Core. No entanto, os recursos de serviço da Web não são tão ricos em recursos quanto servidores como IIS, Apache ou Nginx. Um servidor proxy reverso pode descarregar trabalho, como servir conteúdo estático, armazenar em cache as solicitações, compactar solicitações e realizar o término do HTTPS do servidor HTTP. Um servidor proxy reverso pode residir em uma máquina dedicada ou pode ser implantado ao lado de um servidor HTTP.

Para os fins deste guia, uma única instância de Nginx é usada. Ele é executado no mesmo servidor, ao lado do servidor HTTP. Com base nos requisitos, uma configuração diferente pode ser escolhida.

Como as solicitações são encaminhadas por proxy reverso, use o Middleware de cabeçalhos encaminhados do pacote Microsoft.AspNetCore.HttpOverrides, que é incluído automaticamente nos aplicativos ASP.NET Core por meio do de metapacote Microsoft.AspNetCore.App da estrutura compartilhada. O middleware atualiza o Request.Scheme, usando o cabeçalho X-Forwarded-Proto, para que os URIs de redirecionamento e outras políticas de segurança funcionem corretamente.

O middleware de cabeçalhos encaminhados deve ser executado antes de outro middleware. Essa ordenação garante que o middleware que depende das informações de cabeçalhos encaminhados possa consumir os valores de cabeçalho para processamento. Para executar o Middleware de Cabeçalhos Encaminhados após o middleware de diagnóstico e tratamento de erros, consulte a ordem do Middleware de Cabeçalhos Encaminhados em .

Invoque o método UseForwardedHeaders antes de chamar outro middleware. Configure o middleware para encaminhar os cabeçalhos X-Forwarded-For e X-Forwarded-Proto:

using Microsoft.AspNetCore.HttpOverrides;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "Hello ForwardedHeadersOptions!");

app.Run();

Se nenhum ForwardedHeadersOptions for especificado para o middleware, os cabeçalhos padrão a serem encaminhados serão None.

Os proxies executados 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 dentro da organização lidarem com 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:

using Microsoft.AspNetCore.HttpOverrides;
using System.Net;

var builder = WebApplication.CreateBuilder(args);

// Configure forwarded headers
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

builder.Services.AddAuthentication();

var app = builder.Build();

app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

app.MapGet("/", () => "10.0.0.100");

app.Run();

Para obter mais informações, consulte Configurar ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

Instalar Nginx

Ubuntu

Use apt-get para instalar Nginx. O instalador cria um script systemd init que executa o Nginx como daemon na inicialização do sistema. Siga as instruções de instalação para o Ubuntu em Nginx: Pacotes oficiais Debian / Ubuntu.

Red Hat Enterprise Linux

Use yum-utils para selecionar e instalar um fluxo de módulo Nginx. Siga as instruções de instalação do RHEL em Nginx: Linux packages - RHEL.

SUSE Linux Enterprise Server

Use yum-utils para selecionar e instalar um fluxo de módulo Nginx. Siga as instruções de instalação para SLES em Nginx: Linux packages - SLES.

Observação

Se módulos Nginx opcionais são necessários, a construção de Nginx a partir do código-fonte pode ser necessária.

Desde que o Nginx foi instalado pela primeira vez, inicie-o explicitamente executando:

sudo service nginx start

Verifique se um navegador exibe a página de destino padrão do Nginx. A página de destino pode ser acessada em http://<server_IP_address>/index.nginx-debian.html.

Configurar o Nginx

Ubuntu

Para configurar o Nginx como um proxy reverso para encaminhar solicitações HTTP para o aplicativo ASP.NET Core, modifique /etc/nginx/sites-available/default e recrie o link simbólico. Depois de criar o arquivo /etc/nginx/sites-available/default, use o seguinte comando para criar o link simbólico:

sudo ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default

Abra /etc/nginx/sites-available/default em um editor de texto e substitua o conteúdo pelo seguinte trecho:

Red Hat Enterprise Linux

Para configurar o Nginx como um proxy reverso para encaminhar solicitações HTTP para um aplicativo ASP.NET Core, modifique /etc/nginx.conf. Atualize o bloco de código http{} com o seguinte trecho:

SUSE Linux Enterprise Server

Para configurar o Nginx como um proxy reverso para encaminhar solicitações HTTP para um aplicativo ASP.NET Core, modifique /etc/nginx.conf. Atualize o bloco de código http{} com o seguinte trecho:

map $http_connection $connection_upgrade {
  "~*Upgrade" $http_connection;
  default keep-alive;
}

server {
  listen        80;
  server_name   example.com *.example.com;
  location / {
      proxy_pass         http://127.0.0.1:5000/;
      proxy_http_version 1.1;
      proxy_set_header   Upgrade $http_upgrade;
      proxy_set_header   Connection $connection_upgrade;
      proxy_set_header   Host $host;
      proxy_cache_bypass $http_upgrade;
      proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header   X-Forwarded-Proto $scheme;
  }
}

Se o aplicativo for um aplicativo SignalR ou Blazor Server, consulte ASP.NET Core SignalR production hosting and scaling e Host e deploy ASP.NET Core server-side Blazor apps respectivamente para obter mais informações.

Quando server_name não corresponde a nada, o Nginx usa o servidor padrão. Se nenhum servidor padrão for definido, o primeiro servidor no arquivo de configuração será o servidor padrão. Como prática recomendada, adicione um servidor padrão específico que retorne um código de status de 444 no arquivo de configuração. Um exemplo de configuração de servidor padrão é:

server {
    listen   80 default_server;
    # listen [::]:80 default_server deferred;
    return   444;
}

Com o ficheiro de configuração anterior e o servidor padrão, o Nginx aceita tráfego público à porta 80 com cabeçalho do host example.com ou *.example.com. As solicitações que não corresponderem a esses hosts não serão encaminhadas para Kestrel. Nginx encaminha as solicitações correspondentes para Kestrel em http://127.0.0.1:5000/. Para obter mais informações, consulte Como o nginx processa uma solicitação. Para alterar o IP/porta do Kestrel, consulte Kestrel: Endpoint configuration.

Advertência

A falha em especificar uma diretiva de server_name adequada expõe seu aplicativo a vulnerabilidades de segurança. A vinculação de curinga de subdomínio (por exemplo, *.example.com) não representa esse risco de segurança se você controlar todo o domínio pai (ao contrário de *.com, que é vulnerável). Para obter mais informações, consulte RFC 9110: Semântica HTTP (Seção 7.2: Host e :authority).

Uma vez que a configuração do Nginx é estabelecida, execute sudo nginx -t para verificar a sintaxe dos arquivos de configuração. Se o teste do arquivo de configuração for bem-sucedido, force o Nginx a pegar as alterações executando sudo nginx -s reload.

Para executar diretamente o aplicativo no servidor:

1. Navegue até o diretório do aplicativo.
2. Execute o aplicativo: dotnet <app_assembly.dll>, onde app_assembly.dll é o nome do arquivo assembly do aplicativo.

Ubuntu

Se o aplicativo for executado no servidor, mas não responder pela Internet, verifique o firewall do servidor e confirme se a porta 80 está aberta. Se estiver usando uma VM do Azure Ubuntu, adicione uma regra NSG (Network Security Group) que habilite o tráfego da porta 80 de entrada. Não há necessidade de habilitar uma regra de porta de saída 80, pois o tráfego de saída é concedido automaticamente quando a regra de entrada está habilitada.

Red Hat Enterprise Linux

Se o aplicativo for executado no servidor, mas não responder pela Internet, verifique o firewall do servidor e confirme se a porta 80 está aberta.

SUSE Linux Enterprise Server

Se o aplicativo for executado no servidor, mas não responder pela Internet, verifique o firewall do servidor e confirme se a porta 80 está aberta.

Quando terminar de testar o aplicativo, desligue-o com Ctrl+C no shell de comando.

Aumentar pedidos de keepalive

keepalive_requests pode ser aumentado para um desempenho superior de . Para mais informações, consulte este problema no GitHub.

Monitorar o aplicativo

O servidor está configurado para encaminhar solicitações feitas ao http://<serveraddress>:80 para o aplicativo ASP.NET Core em execução no Kestrel em http://127.0.0.1:5000. No entanto, o Nginx não está configurado para gerenciar o processo de Kestrel. systemd pode ser usado para criar um arquivo de serviço para iniciar e monitorar o aplicativo Web subjacente. systemd é um sistema init 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

O exemplo a seguir é um arquivo de serviço .ini para o aplicativo:

[Unit]
Description=Example .NET Web API App running on Linux

[Service]
WorkingDirectory=/var/www/helloapp
ExecStart=/usr/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=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_NOLOGO=true

[Install]
WantedBy=multi-user.target

No exemplo anterior, o usuário que gerencia o serviço é especificado pela opção User. O usuário (www-data) deve existir e ter a propriedade adequada dos arquivos do aplicativo.

Use TimeoutStopSec para configurar a duração do tempo para aguardar o desligamento do aplicativo depois de receber o sinal de interrupção inicial. Se a aplicação não for desligada nesse período, o SIGKILL será emitido para encerrar a aplicação. Forneça o valor como segundos sem unidade (por exemplo, 150), um valor de intervalo de tempo (por exemplo, 2min 30s) ou infinity para desativar o tempo limite. TimeoutStopSec assume como padrão o valor de DefaultTimeoutStopSec no arquivo de configuração do gerenciador (systemd-system.conf, system.conf.d, systemd-user.conf, 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

O Linux tem um sistema de arquivos que diferencia maiúsculas de minúsculas. Definir ASPNETCORE_ENVIRONMENT para Production resulta na pesquisa do arquivo de configuração appsettings.Production.json, não appsettings.production.json.

Alguns valores (por exemplo, cadeias de conexão SQL) devem ser mascarados para que os provedores de configuração leiam as variáveis de ambiente. Use o seguinte comando para gerar um valor com escape adequado para uso no arquivo de configuração:

systemd-escape "<value-to-escape>"

Os separadores de cólon (:) não são suportados em nomes de variáveis de ambiente. Use um sublinhado duplo (__) no lugar de dois pontos. O provedor de configuração Variáveis de Ambiente converte sublinhados duplos para dois pontos quando as variáveis de ambiente são lidas para a configuração. No exemplo a seguir, a chave da cadeia de conexão ConnectionStrings:DefaultConnection é 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 Linux
    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 Kestrel gerenciado por meio de systemd, o aplicativo Web é totalmente configurado e pode ser acessado a partir de um navegador na máquina local em http://localhost. Também é acessível a partir de uma máquina remota, excluindo qualquer firewall que possa estar a bloquear. Inspecionando os cabeçalhos de resposta, o cabeçalho Server mostra o aplicativo ASP.NET Core que está sendo servido por 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

Ver registos

Como o aplicativo Web que usa o Kestrel é gerenciado usando systemd, todos os eventos e processos são registrados em um diário centralizado. No entanto, este diário inclui todas as entradas para todos os serviços e processos gerenciados por systemd. Para exibir os itens específicos do kestrel-helloapp.service, use o seguinte comando:

sudo journalctl -fu kestrel-helloapp.service

Para filtragem adicional, opções de tempo como --since today, --until 1 hour agoou uma combinação delas podem reduzir o número de entradas retornadas.

sudo journalctl -fu kestrel-helloapp.service --since "2016-10-18" --until "2016-10-18 04:00"

Proteção de dados

O de pilha do ASP.NET Core Data Protection é usado por vários middlewares ASP.NET Core , incluindo middleware de autenticação (por exemplo, middleware cookie) e proteções de falsificação de solicitação entre sites (CSRF). Mesmo que as APIs de proteção de dados não sejam chamadas pelo código do usuário, a proteção de dados deve ser configurada para criar um armazenamento 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 porta-chaves estiver armazenado na memória quando a aplicação for reiniciada:

• Todos os tokens de autenticação baseados em cookiesão invalidados.
• Os usuários são obrigados a entrar novamente em sua próxima solicitação.
• Quaisquer dados protegidos com o porta-chaves já não podem ser desencriptados. Isso pode incluir tokens CSRF e ASP.NET cookies Core MVC TempData.

Para configurar a proteção de dados para persistir e criptografar o porta-chaves, consulte:

• Principais provedores de armazenamento no ASP.NET Core
• Criptografia de chave em repouso no Windows e no Azure usando ASP.NET Core

Campos de cabeçalho de solicitação longos

As configurações padrão do servidor proxy normalmente limitam os campos de cabeçalho de solicitação a 4 K ou 8 K, dependendo da plataforma. Uma aplicação pode exigir campos maiores do que o padrão (por exemplo, aplicações que usam ID do Microsoft Entra). Se forem necessários campos mais longos, as configurações padrão do servidor proxy exigirão ajustes. Os valores a aplicar dependem do cenário. Para obter mais informações, consulte a documentação do servidor.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Advertência

Não aumente os valores padrão dos buffers de proxy, a menos que seja necessário. O aumento desses valores aumenta o risco de saturação de buffer (estouro) e ataques de negação de serviço (DoS) por usuários mal-intencionados.

Proteja o aplicativo

Ativar AppArmor

Linux Security Modules (LSM) é uma estrutura que faz parte do kernel Linux desde o Linux 2.6. O LSM suporta diferentes implementações de módulos de segurança. AppArmor é um LSM que implementa um sistema de Controle de Acesso Obrigatório, que permite confinar o programa a um conjunto limitado de recursos. Verifique se o AppArmor está habilitado e configurado corretamente.

Configurar o firewall

Feche todas as portas externas que não estão em uso. O firewall descomplicado (ufw) fornece um front-end para iptables fornecendo uma CLI para configurar o firewall.

Ubuntu

Advertência

Um firewall impede o acesso a todo o sistema se não estiver configurado corretamente. A falha em especificar a porta SSH correta efetivamente bloqueia você fora do sistema se você estiver usando SSH para se conectar a ele. A porta padrão é 22. Para obter mais informações, consulte a introdução ao ufw e o manual.

Instale ufw e configure-o para permitir o tráfego em todas as portas necessárias.

sudo apt-get install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Red Hat Enterprise Linux

Advertência

Um firewall impede o acesso a todo o sistema se não estiver configurado corretamente. A falha em especificar a porta SSH correta efetivamente bloqueia você fora do sistema se você estiver usando SSH para se conectar a ele. A porta padrão é 22. Para saber mais, consulte a introdução ao ufw.

Instale ufw e configure-o para permitir o tráfego em todas as portas necessárias.

sudo yum -y install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

SUSE Linux Enterprise Server

Advertência

Um firewall impede o acesso a todo o sistema se não estiver configurado corretamente. A falha em especificar a porta SSH correta efetivamente bloqueia você fora do sistema se você estiver usando SSH para se conectar a ele. A porta padrão é 22. Para obter mais informações, consulte a introdução ao ufw.

Instale ufw e configure-o para permitir o tráfego em todas as portas necessárias.

sudo yum -y install ufw

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable

Nginx Seguro

Alterar o nome da resposta Nginx

Editar src/http/ngx_http_header_filter_module.c:

static char ngx_http_server_string[] = "Server: Web Server" CRLF;
static char ngx_http_server_full_string[] = "Server: Web Server" CRLF;

Configurar opções

Configure o servidor com módulos adicionais necessários. Considere usar um firewall de aplicativo Web, como ModSecurity, para proteger o aplicativo.

Configuração HTTPS

Configurar o aplicativo para conexões locais seguras (HTTPS)

O comando dotnet run usa o arquivo Properties/launchSettings.json do aplicativo, que configura o aplicativo para ouvir as URLs fornecidas pela propriedade applicationUrl. Por exemplo, https://localhost:5001;http://localhost:5000.

Configure o aplicativo para usar um certificado em desenvolvimento para o comando dotnet run ou ambiente de desenvolvimento (F5 ou Ctrl+F5 no Visual Studio Code) usando uma das seguintes abordagens:

• Substitua o certificado padrão do de configuração (recomendado )
• KestrelServerOptions.ConfigureHttpsDefaults

Configurar o proxy reverso para conexões de cliente seguras (HTTPS)

Advertência

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 podemos 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:

• Configurando servidores HTTPS (documentação Nginx)
• Gerador de Configuração SSL do mozilla.org

• Configure o servidor para escutar o tráfego HTTPS na porta 443 especificando um certificado válido emitido por uma Autoridade de Certificação (CA) confiável.

• Proteja a segurança empregando algumas das práticas descritas no seguinte arquivo de /etc/nginx/nginx.conf.

• O exemplo a seguir não configura o servidor para redirecionar solicitações inseguras. Recomendamos o uso do HTTPS Redirection Middleware. Para obter mais informações, consulte Impor HTTPS no ASP.NET Core.

  Observação

  Para ambientes de desenvolvimento em que a configuração do servidor lida com redirecionamento seguro em vez de middleware de redirecionamento HTTPS, recomendamos o uso de redirecionamentos temporários (302) em vez de permanentes (301). O cache de link pode causar um comportamento instável em ambientes de desenvolvimento.

• Adicionar um cabeçalho Strict-Transport-Security (HSTS) garante que todas as solicitações subsequentes feitas pelo cliente sejam feitas por HTTPS. Para obter orientação sobre como definir o cabeçalho Strict-Transport-Security, consulte Enforce HTTPS in ASP.NET Core.

• Se o HTTPS for desativado no futuro, use uma das seguintes abordagens:

  • Não adicione o cabeçalho HSTS.
  • Escolha um valor de max-age curto.

Adicione o arquivo de configuração /etc/nginx/proxy.conf:

proxy_redirect          off;
proxy_set_header        Host $host;
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        X-Forwarded-Proto $scheme;
client_max_body_size    10m;
client_body_buffer_size 128k;
proxy_connect_timeout   90;
proxy_send_timeout      90;
proxy_read_timeout      90;
proxy_buffers           32 4k;

Ubuntu

Substitua o conteúdo do arquivo de configuração /etc/nginx/nginx.conf pelo seguinte arquivo. O exemplo contém as seções http e server em um arquivo de configuração.

Red Hat Enterprise Linux

Modificar /etc/nginx/nginx.conf. Abra-o em um editor de texto e substitua os blocos de código http{} e server{} pelo conteúdo com o seguinte trecho:

SUSE Linux Enterprise Server

Modificar /etc/nginx/nginx.conf. Abra-o em um editor de texto e substitua os blocos de código http{} e server{} pelo conteúdo com o seguinte trecho:

http {
    include        /etc/nginx/proxy.conf;
    limit_req_zone $binary_remote_addr zone=one:10m rate=5r/s;
    server_tokens  off;

    sendfile on;
    # Adjust keepalive_timeout to the lowest possible value that makes sense 
    # for your use case.
    keepalive_timeout   29;
    client_body_timeout 10; client_header_timeout 10; send_timeout 10;

    upstream helloapp{
        server 127.0.0.1:5000;
    }

    server {
        listen                    443 ssl http2;
        listen                    [::]:443 ssl http2;
        server_name               example.com *.example.com;
        ssl_certificate           /etc/ssl/certs/testCert.crt;
        ssl_certificate_key       /etc/ssl/certs/testCert.key;
        ssl_session_timeout       1d;
        ssl_protocols             TLSv1.2 TLSv1.3;
        ssl_prefer_server_ciphers off;
        ssl_ciphers               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;
        ssl_session_cache         shared:SSL:10m;
        ssl_session_tickets       off;
        ssl_stapling              off;

        add_header X-Frame-Options DENY;
        add_header X-Content-Type-Options nosniff;

        #Redirects all traffic
        location / {
            proxy_pass http://helloapp;
            limit_req  zone=one burst=10 nodelay;
        }
    }
}

Observação

Blazor WebAssembly aplicações exigem um valor maior para o parâmetro burst para acomodar o número elevado de solicitações feitas por uma aplicação. Para obter mais informações, consulte Host e implantar ASP.NET Core Blazor WebAssembly.

Observação

O exemplo anterior desativa o OCSP Stapling (Online Certificate Status Protocol). Se habilitado, confirme se o certificado suporta o recurso. Para obter mais informações e orientações sobre como habilitar o OCSP, consulte as seguintes propriedades no artigo ngx_http_ssl_module Module (documentação do Nginx):

• ssl_stapling
• ssl_stapling_file
• ssl_stapling_responder
• ssl_stapling_verify

Proteja o Nginx contra o clickjacking

Clickjacking, também conhecido como UI redress attack, é um ataque malicioso em que um visitante do site é induzido a clicar em um link ou botão em uma página diferente da que está visitando atualmente. Use X-FRAME-OPTIONS para proteger o site.

Para mitigar ataques de "clickjacking":

1. Edite o arquivo nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Dentro do bloco de código http{}, adicione a linha: add_header X-Frame-Options "SAMEORIGIN";

2. Salve o arquivo.

3. Reinicie o Nginx.

Deteção do tipo MIME

Esse cabeçalho impede que a maioria dos navegadores analise o MIME de uma resposta diferente do tipo de conteúdo declarado, pois instrui o navegador a não alterar o tipo de conteúdo da resposta. Com a opção nosniff, se o servidor disser que o conteúdo é text/html, o navegador o renderizará como text/html.

1. Edite o arquivo nginx.conf:

   sudo nano /etc/nginx/nginx.conf
   

   Dentro do bloco de código http{}, adicione a linha: add_header X-Content-Type-Options "nosniff";

2. Salve o arquivo.

3. Reinicie Nginx.

Sugestões adicionais de Nginx

Depois de atualizar a estrutura compartilhada no servidor, reinicie os aplicativos ASP.NET Core hospedados pelo servidor.

Recursos adicionais

• Pré-requisitos para o .NET Core no Linux
• Nginx: Lançamentos binários: Pacotes oficiais Debian/Ubuntu
• Solucionar problemas e depurar projetos ASP.NET Core
• Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga
• NGINX: Usando o cabeçalho Encaminhado