- Отладка .NET Core в Linux с помощью SSH путем присоединения к процессу
- Предварительные требования
- Подготовка приложения к отладке
- Создание и развертывание приложения.
- Подключение отладчика
- How to run a .NET Core console app as a service using Systemd on Linux (RHEL)
- .NET Core console application #
- .NET Core worker template #
- Adding .NET Core Systemd integration #
- Summary #
- Среда размещения ASP.NET Core в операционной системе Linux с Nginx
- Предварительные требования
- Публикация и копирование приложения
- Настройка обратного прокси-сервера
- Использование обратного прокси-сервера
- Установка Nginx
- Настройка Nginx
- Мониторинг приложения
- Создание файла службы
- Просмотр журналов
- Защита данных
- Длинные поля заголовка запроса
- Защита приложения
- Включение AppArmor
- Настройка брандмауэра
- Защита Nginx
- Изменение имени ответа Nginx
- Настройка параметров
- Конфигурация HTTPS
- Защита Nginx от кликджекинга
- Сканирование типа MIME
Отладка .NET Core в Linux с помощью SSH путем присоединения к процессу
Начиная с Visual Studio 2017 можно присоединяться к процессам .NET Core, запущенным в локальном или удаленном развертывании Linux, по протоколу SSH. В этой статье описывается настройка и выполнение процесса отладки. Сценарии отладки с использованием контейнеров Docker см. в статьях Присоединение к процессу, выполняющемуся в контейнере Docker и об инструментах для работы с контейнерами. Сведения об отладке Linux в WSL 2 из Visual Studio (без присоединения к процессу) см. в этой статье.
Предварительные требования
На компьютере Visual Studio необходимо установить рабочую нагрузку ASP.NET и разработка веб-приложений или Кроссплатформенная разработка .NET Core.
На сервере Linux необходимо установить SSH-сервер (распакуйте и установите его с помощью curl или wget). Например, в Ubuntu это можно сделать, запустив:
Протокол SFTP должен быть включен так же, как и SSH. Большинство дистрибутивов SSH устанавливают и включают SFTP по умолчанию, но это не всегда так.
На сервере Linux установите среду выполнения .NET для Linux и найдите страницу, соответствующую вашему дистрибутиву Linux (например, Ubuntu). Пакет SDK для .NET не требуется.
Подготовка приложения к отладке
Подготовка приложения для отладки
При сборке приложения рассмотрите возможность использования конфигурации «Отладка». Отладка кода, скомпилированного для розничного выпуска (конфигурация «Выпуск»), намного сложнее, чем отладка кода, скомпилированного для отладочного выпуска. Если необходимо использовать конфигурацию «Выпуск», сначала отключите режим «Только мой код». Чтобы отключить этот параметр, последовательно выберите Сервис > Параметры > Отладка, а затем снимите флажок Включить только мой код.
Убедитесь, что проект настроен на создание переносимых PDB-файлов (параметр по умолчанию) и что PDB-файлы находятся в том же расположении, что и библиотека DLL. Чтобы выполнить эту настройку в Visual Studio, щелкните проект правой кнопкой мыши, затем выберите Свойства > Сборка > Дополнительно > Отладочная информация.
Создание и развертывание приложения.
Для развертывания приложения перед отладкой можно использовать несколько методов. Например, с их помощью можно выполнять следующее.
Скопируйте источники на целевой компьютер и выполните сборку с помощью dotnet build на компьютере Linux.
Выполните сборку приложения в Windows, а затем перенесите артефакты сборки на компьютер Linux. (Артефакты сборки включают само приложение, переносимые PDB-файлы, любые библиотеки среды выполнения, от которых может зависеть приложение, и файл .deps.json.)
При развертывании приложения запустите приложение.
Подключение отладчика
После запуска приложения на компьютере с Linux можно подключить отладчик.
В Visual Studio последовательно выберите пункты Отладка > Присоединиться к процессу. .
В списке Тип подключения выберите SSH.
В поле Цель подключения укажите IP-адрес или имя узла целевого компьютера.
Если вы еще не указали учетные данные, вам будет предложено ввести пароль и (или) указать файл закрытого ключа.
Настраивать порты не требуется, за исключением порта, на котором выполняется сервер SSH.
Найдите процесс, который нужно отладить.
Код выполняется в процессе с уникальным именем или в процессе с именем dotnet. Чтобы найти требуемый процесс, просмотрите столбец Заголовок, в котором отображаются аргументы командной строки для процесса.
В следующем примере показан список процессов на удаленном компьютере Linux, подключенных по протоколу SSH, отображаемых в диалоговом окне Присоединение к процессу.
Выберите Присоединиться.
В появившемся диалоговом окне выберите тип кода для отладки. Выберите Управляемый (.NET Core для Unix) .
Используйте функции отладки Visual Studio для отладки приложения.
В следующем примере отладчик Visual Studio остановлен в точке останова в коде, выполняющемся на удаленном компьютере Linux.
Источник
How to run a .NET Core console app as a service using Systemd on Linux (RHEL)
Niels Swimberghe — 1/31/2020 — .NET
This article walks us through running a .NET Core console application on systemd. After running a simple console app as a service, we’ll upgrade to the worker template which is designed for long running services/ daemons . Lastly, we’ll add the systemd package for increased integration with systemd.
To learn how to run ASP.NET Core services (web stuff) on Linux, check out «How to run ASP.NET Core as a service on Linux without reverse proxy, no NGINX or Apache».
- Red Hat Enterprise Linux (or a compatible Unix based OS)
- .NET Core 3.1 installed (Get started instructions from Red Hat)
- Sudo privileges
This walkthrough should work for most .NET Core supported Linux distributions, not just RHEL.
.NET Core console application #
Let’s start by making a new console application using the dotnet CLI:
Verify that the console app works by running ` dotnet run `. The output should be «Hello World!».
If the application works, we can publish it somewhere logical such as ‘/srv/HelloWorld’:
The published result contains an executable called ‘HelloWorld’ which will run the application. Let’s verify we can also run the published application:
To run services on Linux, Systemd uses ‘ service unit configuration ‘ files to configure services.
Let’s create the file ‘HelloWorld.service’ inside our project so we can store it in source control along with our code. Add the following content to the file:
Make sure to update the ‘User’ to your username. Refer to the comments in the file for a basic explanation. For more in depth information, read the freedesktop manual page or the Red Hat documentation.
Systemd expects all configuration files to be put under ‘/etc/systemd/system/’. Copy the service configuration file to ‘/etc/systemd/system/HelloWorld.service‘. Then tell systemd to reload the configuration files, and start the service.
Using the ` systemctl status ` command we can view the status of the service:
In addition to the status command, we can use the ‘journalctl’ command to read everything our service is printing to the console. Using the unit-flag (-u), we can filter down to our HelloWorld service.
The console app only logs «Hello world!» to the console and then exits. When querying the status, systemd reports the service is inactive (dead). That’s because the console app starts, runs, and immediately exits. That’s not very useful, so let’s add some code that will let the app run until told to stop. Update Program.cs with the following content:
Let’s publish the app again:
Now we have a minimal application that is continuously running until told to stop.
If the application stops due to a crash, systemd will not automatically restart the service unless we configure that. Add the ‘Restart’ & ‘RestartSec’ options to HelloWorld.service:
Copy the service file, reload, and restart the service:
Now the service will automatically restart in case of a crash. But when the OS reboots, the application will not automatically start. To enable automatic startup of the service on boot, run the following command:
This console app works fine, but Microsoft has provided the worker template which is a more robust solution for long running services/daemons. Let’s upgrade to using the worker template next.
.NET Core worker template #
Let’s create a new empty directory and create the worker using the dotnet CLI:
Verify the worker is functional using the command ` dotnet run `.
If the application works, publish it somewhere logical such as ‘/srv/Worker’:
Let’s verify we can also run the published application:
Create a s ervice unit configuration file called «Worker.service» inside our project:
Copy the service configuration file to ‘ /etc/systemd/system/Worker.service ‘ and tell systemd to reload the configuration files:
Using ‘journalctl’, we can verify that the application is contentiously running successfully. The following ‘journalctl’ command will follow the output of the application. Use Ctrl-C to exit the command.
The .NET Core worker now runs as a systemd service, but the integration between .NET Core and systemd can bi improved on by installing the systemd-integration.
Adding .NET Core Systemd integration #
Microsoft recently added a package to better integrate with systemd. The .NET Core application will notify systemd when it’s ready and when it’s stopping. Additionally, systemd will now understand the different log levels when the .NET Core application logs to output.
Using the dotnet CLI, add the ‘Microsoft.Extensions.Hosting.Systemd’ ( nuget ) package:
Next, we’ll need to add one line to the ‘Program.cs’, ` .UseSystemd() `:
Lastly, we need to update our service unit configuration file to specify ‘type=Notify’:
Let’s publish, reload, and restart the service:
With the Systemd integration in place, we can now use the priority-flag (-p) on ‘journalctl’ to filter the output according to the log levels below:
LogLevel | Syslog level | systemd name |
Trace/Debug | 7 | debug |
Information | 6 | info |
Warning | 4 | warning |
Error | 3 | err |
Critical | 2 | crit |
For example, the following command will only print output with log level 4 and below:
We won’t see much because there’s nothing being logged as a warning, error, or critical.
Update the ‘Worker.cs’ file to include ‘LogWarning’, ‘LogError’, ‘LogCritical’ and republish:
Republish and restart the service:
When we run the same ‘journalctl’ command, we can now see the warning output as bold white text, the error and critical output as red bold text.
The ‘UseSystemd’ function will not do anything when run outside of a systemd service.
The implementation checks if the OS is a Unix system and whether the parent process is systemd.
If not, the systemd integration is skipped.
Summary #
.NET Core has good support for running services on Linux. Using the worker template, we can create a long running service/daemon that integrates well with systemd. Using the systemd hosting integration, systemd is notified when the .NET Core application is ready & also understand the different log levels in .NET.
Источник
Среда размещения ASP.NET Core в операционной системе Linux с Nginx
В этом руководстве описывается настройка готовой к работе среды ASP.NET Core на сервере Ubuntu 16.04. Эти инструкции могут подходить для более поздних версий Ubuntu, но они еще не были протестированы в этих версиях.
Сведения о других дистрибутивах Linux, поддерживаемых платформой ASP.NET Core, см. в разделе о необходимых компонентах для .NET Core в Linux.
Для Ubuntu 14.04 в качестве решения для мониторинга процесса Kestrel рекомендуется использовать supervisord . Решение systemd в Ubuntu 14.04 недоступно. Инструкции для Ubuntu 14.04 см. в предыдущей версии этого раздела.
В этом руководстве рассматривается
- размещение существующего приложения ASP.NET Core за обратным прокси-сервером;
- настройка обратного прокси-сервера для переадресации запросов на веб-сервер Kestrel;
- проверка выполнения веб-приложения как управляющей программы при запуске системы;
- настройка средства управления процессами, с помощью которого можно перезапустить веб-приложение.
Предварительные требования
- Доступ к серверу Ubuntu 16.04 под учетной записью обычного пользователя с правами sudo.
- Последняя не предварительная версия среды выполнения .NET, установленная на сервере.
- Существующее приложение ASP.NET Core.
Перезапустить приложения ASP.NET Core, размещенные на сервере, можно в любой момент после обновления общей платформы.
Публикация и копирование приложения
Если приложение запускается локально и не настроено для безопасного подключения (HTTPS), следует применять один из следующих подходов.
- Настройка приложения для обработки безопасных локальных подключений. Дополнительные сведения см. в разделе Конфигурация HTTPS.
- Удалите https://localhost:5001 (при его наличии) из свойства applicationUrl в файле Properties/launchSettings.json .
Выполните команду dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/
Приложение может быть опубликовано как автономное развертывание, если вы предпочитаете не сохранять среду выполнения .NET Core на сервере.
Скопируйте приложение ASP.NET Core на сервер с помощью инструмента, интегрированного в ваш рабочий процесс (например, SCP , SFTP ). Обычно веб-приложения находятся в каталоге var (например, var/www/helloapp ).
Если развертывание выполняется в рабочей среде, рабочий процесс непрерывной интеграции автоматически опубликует приложение и скопирует его ресурсы на сервер.
Проверьте работу приложения:
, чтобы убедиться, что приложение локально работает на платформе 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 :
Если параметр ForwardedHeadersOptions не задан для ПО промежуточного слоя, по умолчанию перенаправляются заголовки None .
Прокси-серверы под управлением адресов замыкания на себя ( 127.0.0.0/8 , [::1] ), включая стандартные адреса localhost ( 127.0.0.1 ), считаются доверенными по умолчанию. Если запросы между Интернетом и веб-сервером обрабатывают другие прокси-серверы или сети организации, добавьте их в список KnownProxies или KnownNetworks с помощью ForwardedHeadersOptions. Следующий пример добавляет доверенный прокси-сервер с IP-адресом 10.0.0.100 в ПО промежуточного слоя для перенаправления заголовков KnownProxies в Startup.ConfigureServices :
Установка Nginx
Установите Nginx с помощью команды apt-get . Программа установки создает сценарий инициализации systemd , который запускает Nginx как управляющую программу при запуске системы. Следуйте инструкциям по установке для Ubuntu в разделе Nginx: официальные пакеты Debian и Ubuntu.
Если необходимы дополнительные модули Nginx, может потребоваться создание Nginx из источника.
Так как Nginx устанавливается впервые, запустите его напрямую, выполнив следующую команду.
В браузере должна открыться стартовая страница Nginx по умолчанию. Целевая страница доступна по адресу http:// /index.nginx-debian.html .
Настройка Nginx
Чтобы настроить Nginx как обратный прокси-сервер для перенаправления HTTP-запросов в ваше приложение ASP.NET Core, измените файл /etc/nginx/sites-available/default . Откройте этот файл в текстовом редакторе и замените его содержимое на следующий фрагмент кода:
Если вы работаете с приложением SignalR или Blazor Server, дополнительные сведения см. в разделах о ASP.NET Core SignalR рабочее размещение и масштабирование и Размещение и развертывание ASP.NET Core Blazor Server соответственно.
Если отсутствуют совпадения для server_name , Nginx использует сервер по умолчанию. Если сервер по умолчанию не определен, первый сервер в файле конфигурации является сервером по умолчанию. Рекомендуется добавить в качестве сервера по умолчанию определенный сервер, который возвращает код состояния 444 в файле конфигурации. Ниже приведен пример конфигурации сервера по умолчанию:
С представленным выше файлом конфигурации и сервером по умолчанию Nginx принимает трафик от любого источника через порт 80 с заголовком узла example.com или *.example.com . Запросы, не соответствующие этим узлам, не переадресуются в Kestrel. Запросы, которые им соответствуют, переадресуются Nginx в Kestrel по адресу http://127.0.0.1:5000 . Дополнительные сведения см. в статье Как nginx обрабатывает запросы. Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.
С представленным выше файлом конфигурации и сервером по умолчанию Nginx принимает трафик от любого источника через порт 80 с заголовком узла example.com или *.example.com . Запросы, не соответствующие этим узлам, не переадресуются в Kestrel. Запросы, которые им соответствуют, переадресуются Nginx в Kestrel по адресу http://127.0.0.1:5000 . Дополнительные сведения см. в статье Как nginx обрабатывает запросы. Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.
Если не будет указана правильная директива server_name, приложение будет подвержено значительным уязвимостям. Привязки с подстановочными знаками на уровне дочерних доменов (например, *.example.com ) не создают таких угроз безопасности, если вы полностью контролируете родительский домен (в отличие от варианта *.com , создающего уязвимость). Дополнительные сведения см. в документе rfc7230, раздел 5.4.
Установив конфигурацию Nginx, выполните команду sudo nginx -t , чтобы проверить синтаксис файлов конфигурации. Если проверка файла конфигурации прошла успешно, заставьте Nginx принять изменения, выполнив команду sudo nginx -s reload .
Для непосредственного запуска приложений на сервере:
Если приложение выполняется на сервере, но не отвечает по Интернету, проверьте брандмауэр сервера и убедитесь, что порт 80 открыт. При использовании виртуальной машины Ubuntu Azure добавьте правило группы безопасности сети (NSG), которое разрешает входящий трафик через порт 80. Не нужно включать правило исходящего трафика на порте 80, так как исходящий трафик предоставляется автоматически при включении правила для входящего трафика.
Когда закончите тестировать приложение, завершите его работу с помощью клавиш CTRL + C в командной строке.
Мониторинг приложения
Сервер настроен на переадресацию запросов к http:// :80 в приложение ASP.NET Core, работающее на базе Kestrel по адресу http://127.0.0.1:5000 . При этом в Nginx не настроено управление процессом Kestrel. Для запуска и мониторинга соответствующего веб-приложения можно использовать systemd и создать файл службы. systemd — это система инициализации, предоставляющая различные функции для запуска и остановки процессов, а также управления ими.
Создание файла службы
Создайте файл определения службы.
Далее представлен пример файла службы для нашего приложения:
В предыдущем примере управляющий службой пользователь задается с помощью параметра User . Этот пользователь ( www-data ) должен существовать и иметь права владельца в отношении файлов приложения.
Используйте TimeoutStopSec , чтобы настроить время ожидания до завершения работы приложения после начального сигнала прерывания. Если приложение не завершит работу в течение этого периода, оно прерывается сигналом SIGKILL. Укажите значение в секундах без единиц измерения (например, 150 ), значение интервала (например, 2min 30s ) или значение infinity , которое отключает время ожидания. TimeoutStopSec по умолчанию использует значение DefaultTimeoutStopSec в файле конфигурации диспетчера ( systemd-system.conf , system.conf.d , systemd-user.conf , user.conf.d ). В большинстве дистрибутивов по умолчанию устанавливается время ожидания 90 секунд.
Linux имеет файловую систему, в которой учитывается регистр символов. Задание ASPNETCORE_ENVIRONMENT для Production приведет к поиску файла конфигурации appsettings.Production.json , а не appsettings.production.json .
Некоторые значения (например, строки подключения SQL) необходимо экранировать, чтобы поставщики конфигурации могли читать переменные среды. Используйте следующую команду, чтобы создать правильно экранированное значение для файла конфигурации:
Разделители-двоеточия ( : ) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания ( __ ) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection .
Разделители-двоеточия ( : ) не поддерживаются в именах переменных среды. Следует использовать двойной знак подчеркивания ( __ ) вместо двоеточия. Поставщик конфигурации переменных среды преобразует двойные символы подчеркивания в двоеточия, когда переменные среды считываются в конфигурации. В следующем примере ключ строки подключения ConnectionStrings:DefaultConnection задается в файле определения службы как ConnectionStrings__DefaultConnection .
Сохраните файл и включите службу.
Запустите службу и убедитесь, что она работает.
Теперь, когда обратный прокси-сервер настроен и Kestrel управляется через systemd , веб-приложение можно считать полностью настроенным и оно доступно через http://localhost в браузере на локальном компьютере. Оно также доступно для удаленных компьютеров, несмотря на наличие блокирующих трафик межсетевых экранов. Заголовок ответа Server подтверждает, что приложение ASP.NET Core обслуживается Kestrel.
Просмотр журналов
Так как веб-приложение, использующее Kestrel, управляется через systemd , все события и процессы регистрируются в централизованном журнале. При этом журнал содержит все записи обо всех службах и процессах, управляемых systemd . Чтобы просмотреть элементы, связанные с kestrel-helloapp.service , используйте следующую команду.
Кроме того, количество возвращаемых записей можно уменьшить, указав параметры времени, например —since today , —until 1 hour ago или их комбинацию.
Защита данных
Стек защиты данных в ASP.NET Core используется определенным ПО промежуточного слоя ASP.NET Core, включая промежуточное ПО для проверки подлинности (например, промежуточное ПО файлов cookie) и средствами защиты от подделки межсайтовых запросов. Даже если API-интерфейсы защиты данных не вызываются из пользовательского кода, необходимо настроить защиту данных для создания постоянного хранилища криптографических ключей. Если защита данных не настроена, ключи хранятся в памяти и удаляются при перезапуске приложения.
Если набор ключей хранится в памяти, при перезапуске приложения происходит следующее:
- Все токены аутентификации, использующие файлы cookie, становятся недействительными.
- При выполнении следующего запроса пользователю требуется выполнить вход снова.
- Все данные, защищенные с помощью набора ключей, больше не могут быть расшифрованы. Это могут быть токены CSRF и файлы cookie временных данных ASP.NET Core MVC.
Сведения о настройке защиты данных для хранения и шифрования набора ключей см. в приведенных ниже статьях.
Длинные поля заголовка запроса
Параметры прокси-сервера по умолчанию обычно ограничивают длину полей заголовка запроса значением 4 КБ или 8 КБ (в зависимости от платформы). Приложению могут потребоваться более длинные поля (например, приложениям, использующим Azure Active Directory). В этом случае требуется скорректировать параметры по умолчанию для прокси-сервера. Применяемые значения зависят от конкретного сценария. Дополнительные сведения см. в документации сервера.
Не увеличивайте значение буферов прокси-сервера по умолчанию, если это не требуется. Увеличение этих значений повышает риск переполнения буфера и атак типа «отказ в обслуживании» (DoS) со стороны злоумышленников.
Защита приложения
Включение AppArmor
Начиная с версии 2.6 ядро Linux включает платформу модулей безопасности Linux (LSM). LSM поддерживают различные реализации модулей безопасности. AppArmor — это LSM, который реализует систему обязательного контроля доступа, позволяющую ограничивать программу определенным набором ресурсов. Убедитесь, что AppArmor включен и правильно настроен.
Настройка брандмауэра
Закройте все внешние порты, которые не используются. Простой брандмауэр (ufw) позволяет взаимодействовать с iptables . Для настройки брандмауэра предоставляется CLI.
Неправильно настроенный брандмауэр предотвратит доступ ко всей системе. Если задать неправильный порт SSH, то при использовании SSH для подключения к системе произойдет ее блокировка. Порт по умолчанию — 22. Дополнительные сведения см. в вводной статье по ufw и в этом руководстве.
Установите ufw и настройте его для разрешения прохождения трафика через все необходимые порты.
Защита Nginx
Изменение имени ответа Nginx
Отредактируйте файл src/http/ngx_http_header_filter_module.c :
Настройка параметров
Настройте дополнительные обязательные модули на сервере. Для дополнительной защиты приложения можно использовать межсетевой экран для веб-приложений, например ModSecurity.
Конфигурация HTTPS
Настройка приложения для безопасных (HTTPS) локальных подключений
Команда dotnet run использует файл приложения Properties/launchSettings.json, который настраивает приложение для прослушивания URL-адресов, заданных свойством applicationUrl . Например, https://localhost:5001;http://localhost:5000 .
Настройте приложение, чтобы оно использовало при разработке сертификат для команды dotnet run или среды разработки ( F5 или CTRL + F5 в Visual Studio Code), используя один из следующих подходов:
Настройка обратного прокси-сервера для безопасного подключения клиентов (HTTPS)
Конфигурация безопасности в этом разделе представляет собой общую конфигурацию, которая будет использоваться в качестве отправной точки для дальнейшей настройки. Мы не можем обеспечить поддержку инструментов, серверов и операционных систем сторонних производителей. Ответственность за использование конфигурации в этом разделе лежит на пользователе. Дополнительные сведения см. в следующих ресурсах:
Настройте сервер для прослушивания трафика HTTPS через порт 443, указав действительный сертификат, выпущенный доверенным центром сертификации (ЦС).
Обеспечьте дополнительную защиту, применив некоторые методы, показанные в представленном ниже файле /etc/nginx/nginx.conf.
В следующем примере не выполняется настройка сервера для перенаправления небезопасных запросов. Рекомендуется использовать ПО промежуточного слоя перенаправления HTTPS. Для получения дополнительной информации см. Принудительное применение HTTPS в ASP.NET Core.
Для сред разработки, в которых безопасное перенаправление обрабатывается конфигурацией сервера, а не ПО промежуточного слоя перенаправления HTTPS, рекомендуется использовать временные перенаправления (302), а не постоянные перенаправления (301). Кэширование ссылок может привести к нестабильной работе в средах разработки.
При добавлении заголовка Strict-Transport-Security (HSTS) все последующие запросы клиента будут проходить по протоколу HTTPS. Рекомендации по настройке заголовка Strict-Transport-Security см. в разделе Принудительное применение HTTPS в ASP.NET Core.
Если протокол HTTPS будет отключен в будущем, используйте один из следующих подходов.
- Не добавляйте заголовок HSTS.
- Выберите короткое значение max-age .
Добавьте файл конфигурации /etc/nginx/proxy.conf:
Замените содержимое файла конфигурации /etc/nginx/nginx.conf следующим файлом. В этом примере показаны разделы http и server одного и того же файла конфигурации.
Приложениям Blazor WebAssembly требуется большее значение параметра burst с учетом большего количества запросов, выполняемых приложением. Для получения дополнительной информации см. Размещение и развертывание ASP.NET Core Blazor WebAssembly.
В предыдущем примере ассоциация протокола OCSP отключена. Если он включен, убедитесь, что сертификат поддерживает эту возможность. Дополнительные сведения и рекомендации по включению протокола OCSP см. в описании следующих свойств в статье Модуль Ngx_http_ssl_module (документация по Nginx):
- ssl_stapling
- ssl_stapling_file
- ssl_stapling_responder
- ssl_stapling_verify
Защита Nginx от кликджекинга
Кликджекинг (или атака с подменой пользовательского интерфейса) является вредоносной атакой, при которой посетителя сайта обманным путем вынуждают щелкнуть ссылку или нажать кнопку не той страницы, на которой он находится. Используйте X-FRAME-OPTIONS для защиты сайта.
Чтобы уменьшить риск атак кликджекинга, выполните указанные ниже действия.
Измените файл nginx.conf.
Добавьте строку: add_header X-Frame-Options «SAMEORIGIN»;
Сканирование типа MIME
Этот заголовок предотвращает MIME-сканирование ответов с указанным типом содержимого в большинстве браузеров, запрещая браузеру переопределять тип содержимого ответа. Параметр nosniff означает, что если сервер определяет содержимое как text/html , то браузер будет обрабатывать его как text/html .
Измените файл nginx.conf.
Добавьте строку: add_header X-Content-Type-Options «nosniff»;
Источник