Среда размещения ASP.NET Core в операционной системе Linux с Nginx

В этом руководстве объясняется, как настроить рабочую среду ASP.NET Core для Ubuntu, Red Hat Enterprise (RHEL) и SUSE Linux Enterprise Server.

Сведения о других дистрибутивах Linux, поддерживаемых платформой ASP.NET Core, см. в разделе о необходимых компонентах для .NET Core в Linux.

В этом руководстве рассматривается

• размещение существующего приложения ASP.NET Core за обратным прокси-сервером;
• настройка обратного прокси-сервера для переадресации запросов на веб-сервер Kestrel;
• проверка выполнения веб-приложения как управляющей программы при запуске системы;
• настройка средства управления процессами, с помощью которого можно перезапустить веб-приложение.

Необходимые компоненты

Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.

Публикация и копирование приложения

Настройте приложение, чтобы его развертывание зависело от платформы.

Если приложение запускается локально в рабочей среде и не настроено на сервере для безопасного подключения (HTTPS), следует применять один из следующих подходов:

• Настройка приложения для обработки безопасных локальных подключений. Дополнительные сведения см. в разделе Конфигурация HTTPS.

• Настройте приложение для запуска в небезопасной конечной точке:

  • Отключите ПО промежуточного слоя перенаправления HTTPS в среде разработки (Program.cs):

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

    Дополнительные сведения см. в статье Использование нескольких сред в ASP.NET Core.

  • Удалите https://localhost:5001 (при наличии) из applicationUrl свойства в Properties/launchSettings.json файле.

Дополнительные сведения о настройке разных сред см. в статье Использование нескольких сред в ASP.NET Core.

Выполните команду dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, где заполнитель {TARGET FRAMEWORK MONIKER} является моникером целевой платформы или TFM), который может выполняться на сервере:

dotnet publish --configuration Release

Приложение может быть опубликовано как автономное развертывание, если вы предпочитаете не сохранять среду выполнения .NET Core на сервере.

Скопируйте приложение ASP.NET Core на сервер с помощью инструмента, интегрированного в ваш рабочий процесс (например, SCP, SFTP). Обычно веб-приложения находятся в каталоге var (например, var/www/helloapp).

Проверьте работу приложения:

1. Запустите приложение в командной строке: dotnet <app_assembly>.dll.
2. В браузере откройте страницу http://<serveraddress>:<port>, чтобы убедиться, что приложение локально работает на платформе Linux.

Настройка обратного прокси-сервера

Обратный прокси-сервер — это общая настройка для обслуживания динамических веб-приложений. Обратный прокси-сервер завершает HTTP-запрос и перенаправляет его в приложение ASP.NET Core.

Использование обратного прокси-сервера

Kestrel отлично подходит для предоставления динамического содержимого из ASP.NET Core. При этом компоненты для работы с веб-службами не настолько функциональны, как серверы типа IIS, Apache или Nginx. Обратный прокси-сервер может облегчить такую работу, как обслуживание статического содержимого, кэширование и сжатие запросов, а также терминирование HTTPS с HTTP-сервера. Обратный прокси-сервер можно разместить на отдельном компьютере или развернуть параллельно с HTTP-сервером.

В контексте данного руководства используется отдельный экземпляр Nginx. Он выполняется на том же сервере, что и HTTP-сервер. Настройки можно выбирать в зависимости от требований.

Так как запросы пересылаются обратным прокси-сервером, используйте ПО промежуточного слоя перенаправленных заголовков из Microsoft.AspNetCore.HttpOverrides пакета, которое автоматически включается в приложения ASP.NET Core через метапакет общей платформыMicrosoft.AspNetCore.App. Это ПО обновляет Request.Scheme, используя заголовок X-Forwarded-Proto, что обеспечивает правильную работу URI перенаправления и других политик безопасности.

ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.

Вызов метода перед вызовом UseForwardedHeaders другого ПО промежуточного слоя. В ПО промежуточного слоя настройте перенаправление заголовков X-Forwarded-For и 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();

Если параметр ForwardedHeadersOptions не задан для ПО промежуточного слоя, по умолчанию перенаправляются заголовки None.

Прокси-серверы под управлением адресов замыкания на себя (127.0.0.0/8, [::1]), включая стандартные адреса localhost (127.0.0.1), считаются доверенными по умолчанию. Если другие доверенные прокси-серверы или сети в организации обрабатывают запросы между Интернетом и веб-сервером, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. В следующем примере добавляется доверенный прокси-сервер по IP-адресу 10.0.0.100 в ПО 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();

Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Установка Nginx

Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.

sudo service nginx start

В браузере должна открыться стартовая страница Nginx по умолчанию. Целевая страница доступна по адресу http://<server_IP_address>/index.nginx-debian.html.

Настройка Nginx

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

http {
  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;
    }
  }
}

Если приложение является приложением SignalR или Blazor Server приложением, ознакомьтесь с ASP.NET производственным размещением и масштабированием и SignalR развертыванием ASP.NET серверных приложений на стороне Blazor сервера соответственно.

Если отсутствуют совпадения для server_name, Nginx использует сервер по умолчанию. Если сервер по умолчанию не определен, первый сервер в файле конфигурации является сервером по умолчанию. Рекомендуется добавить в качестве сервера по умолчанию определенный сервер, который возвращает код состояния 444 в файле конфигурации. Ниже приведен пример конфигурации сервера по умолчанию:

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

С представленным выше файлом конфигурации и сервером по умолчанию Nginx принимает трафик от любого источника через порт 80 с заголовком узла example.com или *.example.com. Запросы, не соответствующие этим узлам, не переадресуются в Kestrel. Запросы, которые им соответствуют, переадресуются Nginx в Kestrel по адресу http://127.0.0.1:5000/. Дополнительные сведения см. в статье Как nginx обрабатывает запросы. Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.

Установив конфигурацию Nginx, выполните команду sudo nginx -t, чтобы проверить синтаксис файлов конфигурации. Если проверка файла конфигурации прошла успешно, заставьте Nginx принять изменения, выполнив команду sudo nginx -s reload.

Для непосредственного запуска приложений на сервере:

1. Перейдите в каталог приложения.
2. Запустите приложение: dotnet <app_assembly.dll>, где app_assembly.dll — имя файла сборки приложения.

Когда закончите проверять приложение, завершите его работу с помощью клавиш CTRL+C (Windows) или ⌘+C (macOS) в командной строке.

Увеличение keepalive_requests

keepalive_requests Можно увеличить производительность для повышения производительности. Дополнительные сведения см . в этой проблеме GitHub.

Мониторинг приложения

Сервер настроен на переадресацию запросов к http://<serveraddress>:80 в приложение ASP.NET Core, работающее на базе Kestrel по адресу http://127.0.0.1:5000. При этом в Nginx не настроено управление процессом Kestrel. systemd можно использовать для создания файла службы для запуска и мониторинга базового веб-приложения. systemd — это система инициализации, которая предоставляет множество мощных функций для запуска, остановки и управления процессами.

Создание файла службы

Создайте файл определения службы.

sudo nano /etc/systemd/system/kestrel-helloapp.service

Далее представлен пример файла службы .ini для нашего приложения:

[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

В предыдущем примере управляющий службой пользователь задается с помощью параметра User. Этот пользователь (www-data) должен существовать и иметь права владельца в отношении файлов приложения.

Используйте TimeoutStopSec, чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, 150), значение интервала (например, 2min 30s) или значение infinity, которое отключает время ожидания. TimeoutStopSec по умолчанию использует значение DefaultTimeoutStopSec в файле конфигурации диспетчера (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux имеет файловую систему, в которой учитывается регистр символов. Задание ASPNETCORE_ENVIRONMENT для Production приведет к поиску файла конфигурации appsettings.Production.json, а не appsettings.production.json.

Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли считать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:

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

Разделители-двоеточия (:) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания (__) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection.

Environment=ConnectionStrings__DefaultConnection={Connection String}

Сохраните файл и включите службу.

sudo systemctl enable kestrel-helloapp.service

Запустите службу и убедитесь, что она работает.

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

Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через systemd, веб-приложение можно считать полностью настроенным и оно доступно через http://localhost в браузере на локальном компьютере. Оно также доступно для удаленных компьютеров, несмотря на наличие блокирующих трафик межсетевых экранов. Заголовок ответа Server подтверждает, что приложение ASP.NET Core обслуживается 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

Просмотреть журналы

Так как веб-приложение, использующее Kestrel, управляется через systemd, все события и процессы регистрируются в централизованном журнале. При этом журнал содержит все записи обо всех службах и процессах, управляемых systemd. Чтобы просмотреть элементы, связанные с kestrel-helloapp.service, используйте следующую команду.

sudo journalctl -fu kestrel-helloapp.service

Кроме того, количество возвращаемых записей можно уменьшить, указав параметры времени, например --since today, --until 1 hour ago или их комбинацию.

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

Защита данных

Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

• Все токены аутентификации, использующие файлы cookie, становятся недействительными.
• При выполнении следующего запроса пользователю требуется выполнить вход снова.
• Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.

• Поставщики хранилищ ключей в ASP.NET Core
• Шифрование rest ключей в Windows и Azure с помощью ASP.NET Core

Длинные поля заголовка запроса

Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Для приложения может потребоваться больше полей по умолчанию (например, приложения, использующие идентификатор Microsoft Entra). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Защита приложения

Включение AppArmor

Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.

Настройка брандмауэра

Закройте все внешние порты, которые не используются. Простой брандмауэр (ufw) позволяет взаимодействовать с iptables. Для настройки брандмауэра предоставляется CLI.

sudo apt-get install ufw

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

sudo ufw enable

sudo yum -y install ufw

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

sudo ufw enable

sudo yum -y install ufw

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

sudo ufw enable

Защита Nginx

Изменение имени ответа Nginx

Отредактируйте файл 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;

Настройка параметров

Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.

Конфигурация HTTPS

Настройка приложения для безопасных (HTTPS) локальных подключений

Команда dotnet run использует файл приложения Properties/launchSettings.json, который настраивает приложение для прослушивания URL-адресов, заданных свойством applicationUrl. Например, https://localhost:5001;http://localhost:5000.

Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки (F5 или CTRL+F5 в Visual Studio Code), используя один из следующих подходов:

• Замена сертификата по умолчанию из конфигурации (рекомендуется)
• KestrelServerOptions.ConfigureHttpsDefaults

Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)

• Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).

• Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.

• В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Дополнительные сведения см. в статье Принудительное использование HTTPS.

  Примечание.

  Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.

• При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в статье Принудительное применение HTTPS в ASP.NET Core.

• Если протокол HTTPS будет отключен в будущем, используйте один из следующих подходов.

  • Не добавляйте заголовок HSTS.
  • Выберите короткое значение max-age.

Добавьте файл конфигурации /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;

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;
        }
    }
}

Защита Nginx от кликджекинга

Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.

Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   http{} В блоке кода добавьте строку:add_header X-Frame-Options "SAMEORIGIN";

2. Сохраните файл.

3. Перезапустите Nginx.

Сканирование типа MIME

Этот заголовок предотвращает MIME-сканирование ответов с указанным типом содержимого в большинстве браузеров, запрещая браузеру переопределять тип содержимого ответа. Параметр nosniff означает, что если сервер определяет содержимое как text/html, то браузер будет обрабатывать его как text/html.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   http{} В блоке кода добавьте строку:add_header X-Content-Type-Options "nosniff";

2. Сохраните файл.

3. Перезапустите Nginx.

Дополнительные предложения Nginx

После обновления общей платформы на сервере перезапустите размещенные на нем приложения ASP.NET Core.

Дополнительные ресурсы

• Необходимые компоненты для .NET Core в Linux
• Nginx: двоичные выпуски. Официальные пакеты Debian и Ubuntu
• Устранение неполадок и отладка проектов ASP.NET Core
• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• NGINX. Использование перенаправленного заголовка

В этом руководстве описывается настройка готовой к работе среды ASP.NET Core на сервере Ubuntu 16.04. Эти инструкции могут подходить для более поздних версий Ubuntu, но они еще не были протестированы в этих версиях.

Сведения о других дистрибутивах Linux, поддерживаемых платформой ASP.NET Core, см. в разделе о необходимых компонентах для .NET Core в Linux.

В этом руководстве рассматривается

• размещение существующего приложения ASP.NET Core за обратным прокси-сервером;
• настройка обратного прокси-сервера для переадресации запросов на веб-сервер Kestrel;
• проверка выполнения веб-приложения как управляющей программы при запуске системы;
• настройка средства управления процессами, с помощью которого можно перезапустить веб-приложение.

Необходимые компоненты

• Доступ к серверу Ubuntu 16.04 под учетной записью обычного пользователя с правами sudo.
• Последняя не предварительная версия среды выполнения .NET, установленная на сервере.
• Существующее приложение ASP.NET Core.

Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.

Публикация и копирование приложения

Настройте приложение, чтобы его развертывание зависело от платформы.

Если приложение запускается локально в рабочей среде и не настроено на сервере для безопасного подключения (HTTPS), следует применять один из следующих подходов:

• Настройка приложения для обработки безопасных локальных подключений. Дополнительные сведения см. в разделе Конфигурация HTTPS.

• Настройте приложение для запуска в небезопасной конечной точке:

  • Отключите ПО промежуточного слоя перенаправления HTTPS в среде разработки (Program.cs):

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

    Дополнительные сведения см. в статье Использование нескольких сред в ASP.NET Core.

  • Удалите https://localhost:5001 (при наличии) из applicationUrl свойства в Properties/launchSettings.json файле.

Дополнительные сведения о настройке разных сред см. в статье Использование нескольких сред в ASP.NET Core.

Выполните команду dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, где заполнитель {TARGET FRAMEWORK MONIKER} является моникером целевой платформы или TFM), который может выполняться на сервере:

dotnet publish --configuration Release

Приложение может быть опубликовано как автономное развертывание, если вы предпочитаете не сохранять среду выполнения .NET Core на сервере.

Скопируйте приложение ASP.NET Core на сервер с помощью инструмента, интегрированного в ваш рабочий процесс (например, SCP, SFTP). Обычно веб-приложения находятся в каталоге var (например, var/www/helloapp).

Проверьте работу приложения:

1. Запустите приложение в командной строке: dotnet <app_assembly>.dll.
2. В браузере откройте страницу http://<serveraddress>:<port>, чтобы убедиться, что приложение локально работает на платформе Linux.

Настройка обратного прокси-сервера

Обратный прокси-сервер — это общая настройка для обслуживания динамических веб-приложений. Обратный прокси-сервер завершает HTTP-запрос и перенаправляет его в приложение ASP.NET Core.

Использование обратного прокси-сервера

Kestrel отлично подходит для предоставления динамического содержимого из ASP.NET Core. При этом компоненты для работы с веб-службами не настолько функциональны, как серверы типа IIS, Apache или Nginx. Обратный прокси-сервер может облегчить такую работу, как обслуживание статического содержимого, кэширование и сжатие запросов, а также терминирование HTTPS с HTTP-сервера. Обратный прокси-сервер можно разместить на отдельном компьютере или развернуть параллельно с HTTP-сервером.

В контексте данного руководства используется отдельный экземпляр Nginx. Он выполняется на том же сервере, что и HTTP-сервер. Настройки можно выбирать в зависимости от требований.

Так как запросы перенаправляются обратным прокси-сервером, используйте ПО промежуточного слоя перенаправленных заголовков из пакета Microsoft.AspNetCore.HttpOverrides. Это ПО обновляет Request.Scheme, используя заголовок X-Forwarded-Proto, что обеспечивает правильную работу URI перенаправления и других политик безопасности.

ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.

Вызовите UseForwardedHeaders метод наверху Program.cs, прежде чем вызывать другое ПО промежуточного слоя. В ПО промежуточного слоя настройте перенаправление заголовков X-Forwarded-For и X-Forwarded-Proto:

// requires using Microsoft.AspNetCore.HttpOverrides;
app.UseForwardedHeaders(new ForwardedHeadersOptions
{
    ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
});

app.UseAuthentication();

Если параметр ForwardedHeadersOptions не задан для ПО промежуточного слоя, по умолчанию перенаправляются заголовки None.

Прокси-серверы под управлением адресов замыкания на себя (127.0.0.0/8, [::1]), включая стандартные адреса localhost (127.0.0.1), считаются доверенными по умолчанию. Если запросы между Интернетом и веб-сервером обрабатывают другие прокси-серверы или сети организации, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. Следующий пример добавляет доверенный прокси-сервер с IP-адресом 10.0.0.100 в ПО промежуточного слоя для перенаправления заголовков KnownProxies в Program.cs:

using System.Net;

var builder = WebApplication.CreateBuilder(args);

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

Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Установка Nginx

Установите Nginx с помощью команды apt-get. Установщик создает systemd скрипт инициализации, который запускает Nginx в качестве управляющей программы при запуске системы. Следуйте инструкциям по установке для Ubuntu, которые представлены в описании официальных пакетов Nginx для Debian и Ubuntu.

Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.

sudo service nginx start

В браузере должна открыться стартовая страница Nginx по умолчанию. Целевая страница доступна по адресу http://<server_IP_address>/index.nginx-debian.html.

Настройка Nginx

Чтобы настроить Nginx как обратный прокси-сервер для перенаправления HTTP-запросов в ваше приложение ASP.NET Core, измените файл /etc/nginx/sites-available/default. Откройте этот файл в текстовом редакторе и замените его содержимое на следующий фрагмент кода:

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 keep-alive;
        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;
    }
}

Если приложение является приложением SignalR или Blazor Server приложением, ознакомьтесь с ASP.NET производственным размещением и масштабированием и SignalR развертыванием ASP.NET серверных приложений на стороне Blazor сервера соответственно.

Если отсутствуют совпадения для server_name, Nginx использует сервер по умолчанию. Если сервер по умолчанию не определен, первый сервер в файле конфигурации является сервером по умолчанию. Рекомендуется добавить в качестве сервера по умолчанию определенный сервер, который возвращает код состояния 444 в файле конфигурации. Ниже приведен пример конфигурации сервера по умолчанию:

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

С представленным выше файлом конфигурации и сервером по умолчанию Nginx принимает трафик от любого источника через порт 80 с заголовком узла example.com или *.example.com. Запросы, не соответствующие этим узлам, не переадресуются в Kestrel. Запросы, которые им соответствуют, переадресуются Nginx в Kestrel по адресу http://127.0.0.1:5000. Дополнительные сведения см. в статье Как nginx обрабатывает запросы. Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.

Установив конфигурацию Nginx, выполните команду sudo nginx -t, чтобы проверить синтаксис файлов конфигурации. Если проверка файла конфигурации прошла успешно, заставьте Nginx принять изменения, выполнив команду sudo nginx -s reload.

Для непосредственного запуска приложений на сервере:

1. Перейдите в каталог приложения.
2. Запустите приложение: dotnet <app_assembly.dll>, где app_assembly.dll — имя файла сборки приложения.

Если приложение выполняется на сервере, но не отвечает по Интернету, проверьте брандмауэр сервера и убедитесь, что порт 80 открыт. При использовании виртуальной машины Ubuntu Azure добавьте правило группы безопасности сети (NSG), которое разрешает входящий трафик через порт 80. Не нужно включать правило исходящего трафика на порте 80, так как исходящий трафик предоставляется автоматически при включении правила для входящего трафика.

Когда закончите проверять приложение, завершите его работу с помощью клавиш CTRL+C (Windows) или ⌘+C (macOS) в командной строке.

Мониторинг приложения

Сервер настроен на переадресацию запросов к http://<serveraddress>:80 в приложение ASP.NET Core, работающее на базе Kestrel по адресу http://127.0.0.1:5000. При этом в Nginx не настроено управление процессом Kestrel. systemd можно использовать для создания файла службы для запуска и мониторинга базового веб-приложения. systemd — это система инициализации, которая предоставляет множество мощных функций для запуска, остановки и управления процессами.

Создание файла службы

Создайте файл определения службы.

sudo nano /etc/systemd/system/kestrel-helloapp.service

Далее представлен пример файла службы для нашего приложения:

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

[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

В предыдущем примере управляющий службой пользователь задается с помощью параметра User. Этот пользователь (www-data) должен существовать и иметь права владельца в отношении файлов приложения.

Используйте TimeoutStopSec, чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, 150), значение интервала (например, 2min 30s) или значение infinity, которое отключает время ожидания. TimeoutStopSec по умолчанию использует значение DefaultTimeoutStopSec в файле конфигурации диспетчера (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux имеет файловую систему, в которой учитывается регистр символов. Задание ASPNETCORE_ENVIRONMENT для Production приведет к поиску файла конфигурации appsettings.Production.json, а не appsettings.production.json.

Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли считать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:

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

Разделители-двоеточия (:) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания (__) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection.

Environment=ConnectionStrings__DefaultConnection={Connection String}

Сохраните файл и включите службу.

sudo systemctl enable kestrel-helloapp.service

Запустите службу и убедитесь, что она работает.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    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

Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через systemd, веб-приложение можно считать полностью настроенным и оно доступно через http://localhost в браузере на локальном компьютере. Оно также доступно для удаленных компьютеров, несмотря на наличие блокирующих трафик межсетевых экранов. Заголовок ответа Server подтверждает, что приложение ASP.NET Core обслуживается 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

Просмотреть журналы

Так как веб-приложение, использующее Kestrel, управляется через systemd, все события и процессы регистрируются в централизованном журнале. При этом журнал содержит все записи обо всех службах и процессах, управляемых systemd. Чтобы просмотреть элементы, связанные с kestrel-helloapp.service, используйте следующую команду.

sudo journalctl -fu kestrel-helloapp.service

Кроме того, количество возвращаемых записей можно уменьшить, указав параметры времени, например --since today, --until 1 hour ago или их комбинацию.

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

Защита данных

Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

• Все токены аутентификации, использующие файлы cookie, становятся недействительными.
• При выполнении следующего запроса пользователю требуется выполнить вход снова.
• Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.

• Поставщики хранилищ ключей в ASP.NET Core
• Шифрование rest ключей в Windows и Azure с помощью ASP.NET Core

Длинные поля заголовка запроса

Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Защита приложения

Включение AppArmor

Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.

Настройка брандмауэра

Закройте все внешние порты, которые не используются. Простой брандмауэр (ufw) позволяет взаимодействовать с iptables. Для настройки брандмауэра предоставляется CLI.

Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.

sudo apt-get install ufw

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

sudo ufw enable

Защита Nginx

Изменение имени ответа Nginx

Отредактируйте файл 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;

Настройка параметров

Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.

Конфигурация HTTPS

Настройка приложения для безопасных (HTTPS) локальных подключений

Команда dotnet run использует файл приложения Properties/launchSettings.json, который настраивает приложение для прослушивания URL-адресов, заданных свойством applicationUrl. Например, https://localhost:5001;http://localhost:5000.

Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки (F5 или CTRL+F5 в Visual Studio Code), используя один из следующих подходов:

• Замена сертификата по умолчанию из конфигурации (рекомендуется)
• KestrelServerOptions.ConfigureHttpsDefaults

Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)

• Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).

• Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.

• В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Дополнительные сведения см. в статье Принудительное использование HTTPS.

  Примечание.

  Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.

• При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в статье Принудительное применение HTTPS в ASP.NET Core.

• Если протокол HTTPS будет отключен в будущем, используйте один из следующих подходов.

  • Не добавляйте заголовок HSTS.
  • Выберите короткое значение max-age.

Добавьте файл конфигурации /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;

Замените содержимое файла конфигурации /etc/nginx/nginx.conf следующим файлом. В этом примере показаны разделы http и server одного и того же файла конфигурации.

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;
        }
    }
}

Защита Nginx от кликджекинга

Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.

Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   Добавьте строку: add_header X-Frame-Options "SAMEORIGIN";

2. Сохраните файл.

3. Перезапустите Nginx.

Сканирование типа MIME

Этот заголовок предотвращает MIME-сканирование ответов с указанным типом содержимого в большинстве браузеров, запрещая браузеру переопределять тип содержимого ответа. Параметр nosniff означает, что если сервер определяет содержимое как text/html, то браузер будет обрабатывать его как text/html.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   Добавьте строку: add_header X-Content-Type-Options "nosniff";

2. Сохраните файл.

3. Перезапустите Nginx.

Дополнительные предложения Nginx

После обновления общей платформы на сервере перезапустите размещенные на нем приложения ASP.NET Core.

Дополнительные ресурсы

• Необходимые компоненты для .NET Core в Linux
• Nginx: двоичные выпуски. Официальные пакеты Debian и Ubuntu
• Устранение неполадок и отладка проектов ASP.NET Core
• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• NGINX. Использование перенаправленного заголовка

В этом руководстве описывается настройка готовой к работе среды ASP.NET Core на сервере Ubuntu 16.04. Эти инструкции могут подходить для более поздних версий Ubuntu, но они еще не были протестированы в этих версиях.

Сведения о других дистрибутивах Linux, поддерживаемых платформой ASP.NET Core, см. в разделе о необходимых компонентах для .NET Core в Linux.

В этом руководстве рассматривается

• размещение существующего приложения ASP.NET Core за обратным прокси-сервером;
• настройка обратного прокси-сервера для переадресации запросов на веб-сервер Kestrel;
• проверка выполнения веб-приложения как управляющей программы при запуске системы;
• настройка средства управления процессами, с помощью которого можно перезапустить веб-приложение.

Необходимые компоненты

• Доступ к серверу Ubuntu 16.04 под учетной записью обычного пользователя с правами sudo.
• Последняя не предварительная версия среды выполнения .NET, установленная на сервере.
• Существующее приложение ASP.NET Core.

Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.

Публикация и копирование приложения

Настройте приложение, чтобы его развертывание зависело от платформы.

Если приложение запускается локально в рабочей среде и не настроено на сервере для безопасного подключения (HTTPS), следует применять один из следующих подходов:

• Настройка приложения для обработки безопасных локальных подключений. Дополнительные сведения см. в разделе Конфигурация HTTPS.

• Настройте приложение для запуска в небезопасной конечной точке:

  • Отключите ПО промежуточного слоя перенаправления HTTPS в среде разработки (Program.cs):

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

    Дополнительные сведения см. в статье Использование нескольких сред в ASP.NET Core.

  • Удалите https://localhost:5001 (при наличии) из applicationUrl свойства в Properties/launchSettings.json файле.

Дополнительные сведения о настройке разных сред см. в статье Использование нескольких сред в ASP.NET Core.

Выполните команду dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/{TARGET FRAMEWORK MONIKER}/publish, где заполнитель {TARGET FRAMEWORK MONIKER} является моникером целевой платформы или TFM), который может выполняться на сервере:

dotnet publish --configuration Release

Приложение может быть опубликовано как автономное развертывание, если вы предпочитаете не сохранять среду выполнения .NET Core на сервере.

Скопируйте приложение ASP.NET Core на сервер с помощью инструмента, интегрированного в ваш рабочий процесс (например, SCP, SFTP). Обычно веб-приложения находятся в каталоге var (например, var/www/helloapp).

Проверьте работу приложения:

1. Запустите приложение в командной строке: dotnet <app_assembly>.dll.
2. В браузере откройте страницу http://<serveraddress>:<port>, чтобы убедиться, что приложение локально работает на платформе Linux.

Настройка обратного прокси-сервера

Обратный прокси-сервер — это общая настройка для обслуживания динамических веб-приложений. Обратный прокси-сервер завершает HTTP-запрос и перенаправляет его в приложение ASP.NET Core.

Использование обратного прокси-сервера

Kestrel отлично подходит для предоставления динамического содержимого из ASP.NET Core. При этом компоненты для работы с веб-службами не настолько функциональны, как серверы типа IIS, Apache или Nginx. Обратный прокси-сервер может облегчить такую работу, как обслуживание статического содержимого, кэширование и сжатие запросов, а также терминирование HTTPS с HTTP-сервера. Обратный прокси-сервер можно разместить на отдельном компьютере или развернуть параллельно с HTTP-сервером.

В контексте данного руководства используется отдельный экземпляр Nginx. Он выполняется на том же сервере, что и HTTP-сервер. Настройки можно выбирать в зависимости от требований.

Так как запросы перенаправляются обратным прокси-сервером, используйте ПО промежуточного слоя перенаправленных заголовков из пакета Microsoft.AspNetCore.HttpOverrides. Это ПО обновляет Request.Scheme, используя заголовок X-Forwarded-Proto, что обеспечивает правильную работу URI перенаправления и других политик безопасности.

ПО промежуточного слоя перенаправления заголовков должно выполняться до другого ПО промежуточного слоя. Такой порядок гарантирует, что ПО промежуточного слоя, полагающееся на сведения о перенаправленных заголовках, может использовать значения заголовков для обработки. Сведения о запуске ПО промежуточного слоя перенаправления заголовков после ПО промежуточного слоя диагностики и обработки ошибок см. в разделе Порядок ПО промежуточного слоя перенаправления заголовков.

Вызовите UseForwardedHeaders метод наверху Startup.Configure, прежде чем вызывать другое ПО промежуточного слоя. В ПО промежуточного слоя настройте перенаправление заголовков X-Forwarded-For и X-Forwarded-Proto:

using Microsoft.AspNetCore.HttpOverrides;

...

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

app.UseAuthentication();

Если параметр ForwardedHeadersOptions не задан для ПО промежуточного слоя, по умолчанию перенаправляются заголовки None.

Прокси-серверы под управлением адресов замыкания на себя (127.0.0.0/8, [::1]), включая стандартные адреса localhost (127.0.0.1), считаются доверенными по умолчанию. Если запросы между Интернетом и веб-сервером обрабатывают другие прокси-серверы или сети организации, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. Следующий пример добавляет доверенный прокси-сервер с IP-адресом 10.0.0.100 в ПО промежуточного слоя для перенаправления заголовков KnownProxies в Startup.ConfigureServices:

using System.Net;

...

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.KnownProxies.Add(IPAddress.Parse("10.0.0.100"));
});

Дополнительные сведения см. в разделе Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки.

Установка Nginx

Установите Nginx с помощью команды apt-get. Установщик создает systemd скрипт инициализации, который запускает Nginx в качестве управляющей программы при запуске системы. Следуйте инструкциям по установке для Ubuntu, которые представлены в описании официальных пакетов Nginx для Debian и Ubuntu.

Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.

sudo service nginx start

В браузере должна открыться стартовая страница Nginx по умолчанию. Целевая страница доступна по адресу http://<server_IP_address>/index.nginx-debian.html.

Настройка Nginx

Чтобы настроить Nginx как обратный прокси-сервер для перенаправления HTTP-запросов в ваше приложение ASP.NET Core, измените файл /etc/nginx/sites-available/default. Откройте этот файл в текстовом редакторе и замените его содержимое на следующий фрагмент кода:

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 keep-alive;
        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;
    }
}

Если приложение является приложением SignalR или Blazor Server приложением, ознакомьтесь с ASP.NET производственным размещением и масштабированием и SignalR развертыванием ASP.NET серверных приложений на стороне Blazor сервера соответственно.

Если отсутствуют совпадения для server_name, Nginx использует сервер по умолчанию. Если сервер по умолчанию не определен, первый сервер в файле конфигурации является сервером по умолчанию. Рекомендуется добавить в качестве сервера по умолчанию определенный сервер, который возвращает код состояния 444 в файле конфигурации. Ниже приведен пример конфигурации сервера по умолчанию:

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

С представленным выше файлом конфигурации и сервером по умолчанию Nginx принимает трафик от любого источника через порт 80 с заголовком узла example.com или *.example.com. Запросы, не соответствующие этим узлам, не переадресуются в Kestrel. Запросы, которые им соответствуют, переадресуются Nginx в Kestrel по адресу http://127.0.0.1:5000. Дополнительные сведения см. в статье Как nginx обрабатывает запросы. Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.

Установив конфигурацию Nginx, выполните команду sudo nginx -t, чтобы проверить синтаксис файлов конфигурации. Если проверка файла конфигурации прошла успешно, заставьте Nginx принять изменения, выполнив команду sudo nginx -s reload.

Для непосредственного запуска приложений на сервере:

1. Перейдите в каталог приложения.
2. Запустите приложение: dotnet <app_assembly.dll>, где app_assembly.dll — имя файла сборки приложения.

Если приложение выполняется на сервере, но не отвечает по Интернету, проверьте брандмауэр сервера и убедитесь, что порт 80 открыт. При использовании виртуальной машины Ubuntu Azure добавьте правило группы безопасности сети (NSG), которое разрешает входящий трафик через порт 80. Не нужно включать правило исходящего трафика на порте 80, так как исходящий трафик предоставляется автоматически при включении правила для входящего трафика.

Когда закончите проверять приложение, завершите его работу с помощью клавиш CTRL+C (Windows) или ⌘+C (macOS) в командной строке.

Мониторинг приложения

Сервер настроен на переадресацию запросов к http://<serveraddress>:80 в приложение ASP.NET Core, работающее на базе Kestrel по адресу http://127.0.0.1:5000. При этом в Nginx не настроено управление процессом Kestrel. systemd можно использовать для создания файла службы для запуска и мониторинга базового веб-приложения. systemd — это система инициализации, которая предоставляет множество мощных функций для запуска, остановки и управления процессами.

Создание файла службы

Создайте файл определения службы.

sudo nano /etc/systemd/system/kestrel-helloapp.service

Далее представлен пример файла службы для нашего приложения:

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

[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_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

В предыдущем примере управляющий службой пользователь задается с помощью параметра User. Этот пользователь (www-data) должен существовать и иметь права владельца в отношении файлов приложения.

Используйте TimeoutStopSec, чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, 150), значение интервала (например, 2min 30s) или значение infinity, которое отключает время ожидания. TimeoutStopSec по умолчанию использует значение DefaultTimeoutStopSec в файле конфигурации диспетчера (systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.

# The default value is 90 seconds for most distributions.
TimeoutStopSec=90

Linux имеет файловую систему, в которой учитывается регистр символов. Задание ASPNETCORE_ENVIRONMENT для Production приведет к поиску файла конфигурации appsettings.Production.json, а не appsettings.production.json.

Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли считать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:

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

Разделители-двоеточия (:) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания (__) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection.

Environment=ConnectionStrings__DefaultConnection={Connection String}

Сохраните файл и включите службу.

sudo systemctl enable kestrel-helloapp.service

Запустите службу и убедитесь, что она работает.

sudo systemctl start kestrel-helloapp.service
sudo systemctl status kestrel-helloapp.service

◝ kestrel-helloapp.service - Example .NET Web API App running on Ubuntu
    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

Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через systemd, веб-приложение можно считать полностью настроенным и оно доступно через http://localhost в браузере на локальном компьютере. Оно также доступно для удаленных компьютеров, несмотря на наличие блокирующих трафик межсетевых экранов. Заголовок ответа Server подтверждает, что приложение ASP.NET Core обслуживается 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

Просмотреть журналы

Так как веб-приложение, использующее Kestrel, управляется через systemd, все события и процессы регистрируются в централизованном журнале. При этом журнал содержит все записи обо всех службах и процессах, управляемых systemd. Чтобы просмотреть элементы, связанные с kestrel-helloapp.service, используйте следующую команду.

sudo journalctl -fu kestrel-helloapp.service

Кроме того, количество возвращаемых записей можно уменьшить, указав параметры времени, например --since today, --until 1 hour ago или их комбинацию.

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

Защита данных

Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.

Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:

• Все токены аутентификации, использующие файлы cookie, становятся недействительными.
• При выполнении следующего запроса пользователю требуется выполнить вход снова.
• Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.

Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.

• Поставщики хранилищ ключей в ASP.NET Core
• Шифрование rest ключей в Windows и Azure с помощью ASP.NET Core

Длинные поля заголовка запроса

Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.

• proxy_buffer_size
• proxy_buffers
• proxy_busy_buffers_size
• large_client_header_buffers

Защита приложения

Включение AppArmor

Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.

Настройка брандмауэра

Закройте все внешние порты, которые не используются. Простой брандмауэр (ufw) позволяет взаимодействовать с iptables. Для настройки брандмауэра предоставляется CLI.

Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.

sudo apt-get install ufw

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

sudo ufw enable

Защита Nginx

Изменение имени ответа Nginx

Отредактируйте файл 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;

Настройка параметров

Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.

Конфигурация HTTPS

Настройка приложения для безопасных (HTTPS) локальных подключений

Команда dotnet run использует файл приложения Properties/launchSettings.json, который настраивает приложение для прослушивания URL-адресов, заданных свойством applicationUrl. Например, https://localhost:5001;http://localhost:5000.

Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки (F5 или CTRL+F5 в Visual Studio Code), используя один из следующих подходов:

• Замена сертификата по умолчанию из конфигурации (рекомендуется)
• KestrelServerOptions.ConfigureHttpsDefaults

Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)

• Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).

• Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.

• В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Дополнительные сведения см. в статье Принудительное использование HTTPS.

  Примечание.

  Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.

• При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в статье Принудительное применение HTTPS в ASP.NET Core.

• Если протокол HTTPS будет отключен в будущем, используйте один из следующих подходов.

  • Не добавляйте заголовок HSTS.
  • Выберите короткое значение max-age.

Добавьте файл конфигурации /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;

Замените содержимое файла конфигурации /etc/nginx/nginx.conf следующим файлом. В этом примере показаны разделы http и server одного и того же файла конфигурации.

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;
        }
    }
}

Защита Nginx от кликджекинга

Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.

Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   Добавьте строку: add_header X-Frame-Options "SAMEORIGIN";

2. Сохраните файл.

3. Перезапустите Nginx.

Сканирование типа MIME

Этот заголовок предотвращает MIME-сканирование ответов с указанным типом содержимого в большинстве браузеров, запрещая браузеру переопределять тип содержимого ответа. Параметр nosniff означает, что если сервер определяет содержимое как text/html, то браузер будет обрабатывать его как text/html.

1. Измените файл nginx.conf.

   sudo nano /etc/nginx/nginx.conf
   

   Добавьте строку: add_header X-Content-Type-Options "nosniff";

2. Сохраните файл.

3. Перезапустите Nginx.

Дополнительные предложения Nginx

После обновления общей платформы на сервере перезапустите размещенные на нем приложения ASP.NET Core.

Дополнительные ресурсы

• Необходимые компоненты для .NET Core в Linux
• Nginx: двоичные выпуски. Официальные пакеты Debian и Ubuntu
• Устранение неполадок и отладка проектов ASP.NET Core
• Настройка ASP.NET Core для работы с прокси-серверами и подсистемами балансировки нагрузки
• NGINX. Использование перенаправленного заголовка