Linux and asp net

ASP.NET Core: ваше первое приложение на Linux c использованием Visual Studio Code

Решил недавно написать небольшое ASP.Net MVC приложение после многолетнего перерыва и знающие люди на Хабре подсказали попробовать новый ASP.Net Core, тем более, что он работает в Линуксе из коробки без необходимости задействовать mono, и, судя по последним тестам, даже показывает неплохую производительность. За основу взял аналогичную статью для Mac, однако здесь в отличии от вдохновившей меня статьи хочу описать процесс пошагово в одном месте, для того, чтобы не пришлось лазить по перекрёстным ссылкам, пытаясь разобраться как установить непонятно для чего предназначенные приложения и пакеты. Такое подробное описание процесса возможно поможет многим избежать граблей, с которыми пришлось столкнуться мне. Несколько фраз и рисунков, в части одинаковой для любой платформы, с правками и корректировками взяты из статьи для Mac.

Установка .Net Core и Visual Studio Code

Приводимые здесь команды установки подходят для дистрибутивов Ubuntu 16.04/Mint 18.x, для остальных можно найти здесь.

Установка .Net Core:

Устанавливаем новейший на данный момент RC4 для совместимости с новейшим генератором проектов aspnet:

Установка Visual Studio Code

Устанавливается легко в пару кликов по этой ссылке.

Установка расширения C#

Запускаем Visual Studio Code, нажимаем Ctrl-P, вводим команду:
ext install csharp

В появившейся слева панели нажимаем «Установить» напротив соответствующего расширения, если это не произошло автоматически. Visual Studio Code можно пока закрыть.

Подготовка среды разработки и формирование шаблонов приложений

Устанавливаем новейший node.js с оригинального сайта (тот, что идёт с дистрибутивом не подходит), он нам нужен из-за менеджера пакетов npm, который идёт вместе с ним:
Для других дистрибутивов инструкция здесь.

Инициализация проекта

Для инициализации используется скаффолдер Yeoman — инициализатор проекта, включающий в себя развёртывание файловой структуры и генерацию шаблона проекта, т.е. исходного кода приложения. Включает в себя скаффолдер Yo, менеджер пакетов Bower и менеджер задач Grunt. При установке Yo вам будут установлены также Bower и Grunt. Здесь устанавливаем в любом терминале также новейший генератор aspnet, в котором возвращена система сборки msbuild вместо project.json:

Запуск генератора проекта

Примечание: При выборе пункта WebApplication будет создан шаблон приложения с авторизацией клиентов, где в качестве БД может использоваться SQLite (генератор выдаст соответствующие инструкции как это сделать). Если же вы захотите в качестве базы использовать что-нибудь покруче, то можно добавить поддержку PostgreSQL:

• Установка: npm install -g generator-aspnetpostgresql
• Генерация шаблона: yo aspnetpostgresql

Данный генератор основан на том же самом OmniSharp/generator-aspnet. Версия несколько устарела, поэтому для запуска нужно сначала выполнить dotnet migrate & dotnet restore — именно в таком порядке.

Your project is now created, you can use the following commands to get going
cd «WebApplicationBasic»
dotnet restore
dotnet build (optional, build will also happen with it’s run)
dotnet run

Восстановить и собрать можно, а вот запускать пока рано: нужно ещё кое что сделать.

Разработка приложений ASP.NET Core MVC на Linux с помощью Visual Studio Code

Теперь запустите Visual Studio Code.

Выберите пункт Файл → Отрыть папку и выберите папку, в которой Вы создали шаблон приложения ASP.NET Core MVC с помощью yo.

При первом запуске Visual Studio Code выдаст предупреждение об отсутствии необходимых инструментов для сборки и отладки. Нажимаем Yes , чтобы добавить их. Без этого автоматическая отладка и сборка средствами Visual Studio Code будет недоступна, а только через терминал командами dotnet build и dotnet run .

В Терминале Visual Studio Code (Ctrl-`) выполните команду dotnet restore , чтобы восстановить зависимости проекта (если не сделали этого раньше). Другой способ — выполнить команду Ctrl-Shift-P в Visual Studio Code и затем ввести dot, как показано ниже (у меня почему-то не заработало):

Для тех, кто только приступает к использованию Visual Studio Code (или Code, для краткости), следует заметить, что данный продукт не только имеет удобный, простой и отзывчивый интерфейс, обеспечивающий быструю работу с файлами, но он также предоставляет инструменты для наиболее эффективного написания кода.

В левой панели навигации находятся пять значков, представляющие четыре viewlet:

• Explore
• Search
• Git
• Debug
• Extensions

Explore viewlet позволяет быстро перемещаться по системе каталогов, а также облегчает обзор файлов, с которыми вы работаете. При наличии несохраненных изменений в файлах специальный значок на экране будет уведомлять об этом; упрощается процесс создания новых файлов и папок (для этого не надо открывать новое окно). Также удобно пользоваться командой Save All (Сохранить все), доступной в меню, которое появляется при наведении курсора мыши.

Code интегрируется с Git, если он установлен на вашем компьютере. При помощи Git viewlet можно создавать новые репозитории, подтверждать изменение кода, отправлять изменения.

Debug viewlet поддерживает интерактивную отладку приложений.

Кроме того, в редакторе Code есть множество замечательных функций. Вы увидите, что неиспользованные операторы using будут подчеркнуты и могут быть удалены автоматически при помощи Сtrl-. , если значок лампочки отображается на экране. Также можно видеть, сколько ссылок на классы и методы есть в проекте. Если вы переходить с Visual Studio, то вы можете использовать многие знакомые сочетания клавиш, например, Сtrl-K+C , чтобы закомментировать блок кода или Ctrl-K-U , чтобы раскомментировать его.

Запуск приложения при помощи Kestrel

Kestrel — это кросс-платформенный HTTP сервер, основанный на libuv — библиотеке асинхронного ввода-вывода. Для его установки нужно установить соответствующий пакет NuGet: Microsoft.AspNetCore.Server.Kestrel. Сделать это можно двумя способами:

• Установив .Net Core Project Manager (Nuget) через viewlet Extensions (Расширения): Ctrl-Shift-P , набираем Nuget , ↵, затем Kestrel ↵ выбираем Microsoft.AspNetCore.Server.Kestrel
• Через командную строку в терминале редактора vs code editor:

Всё, теперь можно запускать: нажимаем F5 или в терминале dotnet run , при этом автоматически запускается браузер с приложением по адресу: localhost:5000 . Чтобы остановить веб-сервер, нажмите Ctrl+C. Вот и всё, можете наслаждаться вашим первым приложением ASP.Net Core:

Источник

Разворачиваем и демонизируем ASP.NET Core приложение под Linux в виде фонового сервиса

Подготовка окружения

Для начала, добавим dotnet-репозиторий:

На выходе получаем примерно следующее:

Теперь обновим индекс наших пакетов:

Далее, мы можем просто установить dotnet-пакет при помощи apt-get:

Теперь можем смело приступать к созданию приложения

Создание приложения

При помощи команды dotnet new мы можем создать шаблон для нашего приложения, подобно шаблонам из Visual Studio. Подробная документация к команде.

На текущий момент (07.2017), команда dotnet new поддерживает следующие шаблоны:

Мы создадим веб-приложение ASP.NET Core:

На выходе консоль выдаст нам следующее сообщение:

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

Все необходимые папки для сборки приложения на месте, приступим! Для начала, восстановим все пакеты при помощи dotnet restore .

Теперь можем собрать приложение:

Запустим приложение с помощью:

Консоль говорит нам, что приложение запустилось по адресу localhost:5000/. Проверим:

Желающих подробнее узнать, как работает web-сервер отсылаю к официальному источнику.

Теперь убьём процесс нажав Ctrl + C и опубликуем приложение командой dotnet publish. Эта команда упаковывает приложение и все его зависимости для дальнейшего развёртывания (желающим интимных подробностей сюда).

В случае проблем с правами доступа Вам поможет команда sudo chmod и эта страница документации.

Развертывание на сервере.

Если мы хотим развернуть наше приложение под linux-сервером, необходимо настроить прокси и демонизировать процесс запуска приложения. Для проксирования мы будем использовать nginx, для демонизации процесса systemd. Краткое описание утилиты

Как следует из документации выше, с asp.net core в коробке идет kestrel — веб-сервер для asp.net приложений. Зачем нам тогда нужен прокси-сервер? Ответ даётся на официальной странице Microsoft:

Если вы выставляете ваше приложение в интернет, Вы должны использовать IIS, Nginx или Apache как обратный прокси-сервер.

Обратный прокси-сервер получает HTTP запросы из сети и направляет их в Kestrel после первоначальной обработки, как показано на след диаграмме:

Главная причина, по которой следует использовать обратный прокси сервер — безопасность. Kestrel относительно нов и ещё не имеет полного комплекта защиты от атак.

Ещё одна причина, по которой следует использовать обратный прокси-сервер — наличие на сервере нескольких приложений, использующих один порт. Kestrel не поддерживает разделение одного порта между несколькими приложениями.

Так же, использование обратного прокси-сервера может облегчить распределение нагрузки и поддержку SSL.

Как говорилось выше, в качестве прокси-сервера мы будем использовать nginx.

Т.к. в качестве прокси-сервера у нас используется не IIS, следует добавить следующие строки в метод Configure файла Startap.cs.

Здесь мы включаем поддержку ForwardedHeaders мидлвера из пакета. Microsoft.AspNetCore.HttpOverrides, который будет вставлять в Http-запрос заголовки X-Forwarded-For и X-Forwarded-Proto, использующиеся для определения исходного IP адреса клиента и передачи его прокси-серверу. Определение мидлверов и практическое использование так же будет рассмотрено в дальнейших частях этого гайда.

Если у Вас nginx не установлен, выполните следующую команду.

и запустите его командой:

Далее, нам необходимо сконфигурировать nginx для проксирования http-запросов.

Создадим файл /etc/nginx/sites-available/aspnetcore.conf. Папка sites-avalible укахывает nginx-у, какие веб-сайты доступны на текущем сервере для обработки. Добавим в него следующие строки:

Создадим символическую ссылку на aspnetcore.conf в папку sites-enabled, в которой отражаются запущенные nginx-ом сайты.

Nginx настроен на то, чтобы принимать запросы с localhost:8888. Перезапускаем nginx командой sudo service nginx restart , чтобы созданные нами конфигурационные файлы вступили в силу. Проверяем:

502-я ошибка говорит, что сервер перенаправляет нас в другое место и в этом месте что-то пошло не так. В нашем случае — я убил процесс с нашим веб-приложением, которое было ранее запущено командой dotnet run. Потому что могу 🙂

На самом деле, потому что запускать dotnet run в консоли и вечно держать эту вкладку открытой грустно. Именно поэтому процесс будем демонизировать, то есть настроем автозапуск после перезагрузки и автоматическую работу в фоне с помощью systemd.

Для этого создадим файл в директории /etc/systemd/system/ с расширением .service

Назовём его kestrel-test:

И положим в него следующее содержимое:

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

[Service]
WorkingDirectory=/home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish #путь к publish папке вашего приложения
ExecStart=/usr/bin/dotnet /home/robounicorn/projects/asp.net/core/test-lesson/bin/Debug/netcoreapp1.1/publish/test-lesson.dll # путь к опубликованной dll
Restart=always
RestartSec=10 # Перезапускать сервис через 10 секунд при краше приложения
SyslogIdentifier=dotnet-example
User=root # пользователь, под которым следует запускать ваш сервис
Environment=ASPNETCORE_ENVIRONMENT=Production

Теперь включим и запустим сервис при помощи следующих команд:

Проверим статус сервиса:

Если всё было сделано правильно, на эта команда выдаст нам следующее:

Источник

Среда размещения 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//publish , где заполнитель является моникером целевой платформы или TFM), который может выполняться на сервере:

Приложение может быть опубликовано как автономное развертывание, если вы предпочитаете не сохранять среду выполнения .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»;

Источник