Asp web server для linux

Установка и настройка mono на Linux Ubuntu

Проект mono позволяет реализовать платформу .NET Framework на системах Linux. В данной инструкции мы разберем процесс его установки на Ubuntu.

Установка и запуск mono

Установку выполняем командой:

apt-get install mono-complete mono-xsp4 asp.net-examples

* пакет mono-complete содержит все возможности Mono; mono-xsp4 предоставляет поддержку ASP.NET; asp.net-examples — содержит примеры скриптов ASP и скрипт для автоматической конфигурации веб-приложения.

Разрешаем автозапуск и стартуем сервис:

systemctl enable mono-xsp4

systemctl start mono-xsp4

Если мы используем брандмауэр, добавим правило:

iptables -I INPUT 1 -p tcp -m tcp —dport 8084 -j ACCEPT

* где 8084 — порт, по умолчанию для mono-xsp4.

Сохраняем правила iptables любым способом, например:

* если данная команда вернет ошибку, устанавливаем iptables-persistent командой apt-get install iptables-persistent.

Для проверки работы сервиса открываем браузер и переходим по адресу http:// :8084/samples/ — мы должны увидеть страницу «Welcome to Mono XSP»:

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

Совместное использование с веб-сервером

Рассмотрим процесс настройки mono с веб-серверами NGINX и Apache2 путем проксирования запросов.

NGINX

Открываем файл настройки виртуального домена по умолчанию:

Находим опцию location / и приводим ее к виду:

location / <
proxy_pass http://127.0.0.1:8084/;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
>

* где proxy_pass перенаправляет все запросы на внутренний сервер mono-xsp4.

Проверяем корректность настроек:

. и перезапускаем nginx:

systemctl restart nginx

Теперь открываем браузер и заходим по адресу http:// /samples/ (без указания порта). Мы должны увидеть веб-приложение, настроенное на mono.

Apache

Включаем модули для проксирования:

a2enmod proxy proxy_http

* где proxy — главный модель для перенаправления запросов; proxy_http — проксирование HTTP.

Настраиваем виртуальный домен с сайтом — в данном примере для сайта по умолчанию:

Добавляем строки внутри VirtualHost:

.
ProxyPreserveHost On
ProxyPass / http://127.0.0.1:8084/
ProxyPassReverse / http://127.0.0.1:8084/
.

* где опция ProxyPreserveHost включаем проксирование для виртуального домена; ProxyPass позволяет перенаправить все запросы на данный сервер (в данном примере, на локальный mono-xsp4); ProxyPassReverse задает правило для возврата ответа — при такой настройке ответ будет возвращаться обратно веб-серверу.

Проверяем корректность настроек:

. и перезапускаем веб-сервер:

systemctl restart apache2

Теперь открываем браузер и переходим по адресу без указания порта — http:// /samples/. Мы должны увидеть веб-приложение, настроенное на mono.

Дополнительные настройки

Разберем некоторые настройки, которые могут пригодится при конфигурировании сервера.

Добавить веб-приложение

Открываем файл webapp:

• web-application — секция с настройками приложения.
• name — имя приложения.
• vpath — путь URL, при обращении по которому приложение доступно.
• path — путь на сервере, где находятся скрипты приложения.

. также можно использовать дополнительные опции:

• vhost — имя виртуального хоста, если будем его применять.
• vport — номер сетевого порта, на котором слушает приложение.
• enabled — принимает значение true или false. Позволяет включить или отключить приложение.

systemctl restart mono-xsp4

Смена порта сервера

Открываем настройки mono-xsp4:

Ищем опцию port= и меняем ее значение на порт, на котором должен работать сервис:

Источник

Размещение ASP.NET Core в операционной системе Linux с Apache

Из этого руководства вы узнаете, как настроить Apache в качестве обратного прокси-сервера в CentOS 7, чтобы перенаправлять трафик HTTP в веб-приложение ASP.NET Core, работающее на сервере Kestrel. Расширение mod_proxy и связанные с ним модули создают обратный прокси-сервер.

Предварительные требования

• Сервер под управлением CentOS 7 и учетная запись обычного пользователя с правами sudo.
• Установите среду выполнения .NET Core на сервере.
  1. Перейдите на страницу скачивания .NET Core.
  2. Выберите последнюю не предварительную версию .NET Core.
  3. Скачайте последнюю не предварительную версию среды выполнения из таблицы под заголовком Run apps — Runtime (Выполнение приложений — среда выполнения).
  4. Щелкните ссылку Package manager instructions (Инструкции диспетчера пакетов) для Linux и выполните инструкции для CentOS.
• Существующее приложение ASP.NET Core.

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

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

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

• Настройка приложения для обработки безопасных локальных подключений. Дополнительные сведения см. в разделе Конфигурация HTTPS.
• Удалите https://localhost:5001 (при его наличии) из свойства applicationUrl в файле Properties/launchSettings.json.

Запустите dotnet publish в среде разработки, чтобы упаковать приложение в каталог (например, bin/Release/ /publish), который может выполняться на сервере:

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

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

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

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

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

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

Так как запросы перенаправляются обратным прокси-сервером, используйте ПО промежуточного слоя перенаправления заголовков, которое входит в пакет 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 :

Установка Apache

Обновите пакеты CentOS до последних стабильных версий:

Установите веб-сервер Apache на CentOS, выполнив одну команду yum :

Пример выходных данных этой команды:

В нашем примере выходные данные содержат строку httpd.86_64, так как используется 64-разрядная версия CentOS 7. Чтобы проверить, где установлен Apache, выполните whereis httpd из командной строки.

Настройка Apache

Файлы конфигурации для Apache находятся в каталоге /etc/httpd/conf.d/ . В алфавитном порядке обрабатываются все файлы с расширением .conf, а также файлы конфигурации модуля из папки /etc/httpd/conf.modules.d/ , где содержатся файлы конфигурации, необходимые для загрузки модулей.

Создайте для приложения файл конфигурации с именем helloapp.conf:

Блок VirtualHost может встречаться несколько раз в одном или нескольких файлах на сервере. С представленным выше файлом конфигурации Apache принимает трафик от любого источника через порт 80. Он обслуживает домен www.example.com , а псевдоним *.example.com указывает на тот же веб-сайт. Дополнительные сведения см. в статье о поддержке виртуальных узлов на основе имен. Запросы к корневому каталогу перенаправляются на порт 5000 того же сервера по адресу 127.0.0.1. Для двусторонней связи требуются ProxyPass и ProxyPassReverse . Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.

Блок VirtualHost может встречаться несколько раз в одном или нескольких файлах на сервере. С представленным выше файлом конфигурации Apache принимает трафик от любого источника через порт 80. Он обслуживает домен www.example.com , а псевдоним *.example.com указывает на тот же веб-сайт. Дополнительные сведения см. в статье о поддержке виртуальных узлов на основе имен. Запросы к корневому каталогу перенаправляются на порт 5000 того же сервера по адресу 127.0.0.1. Для двусторонней связи требуются ProxyPass и ProxyPassReverse . Сведения о том, как изменить IP-адрес и порт Kestrel, см. в разделе о настройке конечных точек Kestrel.

Если не удастся указать правильную директиву ServerName в блоке VirtualHost, приложение будет иметь значительные уязвимости. Привязки с подстановочными знаками на уровне дочерних доменов (например, *.example.com ) не создают таких угроз безопасности, если вы полностью контролируете родительский домен (в отличие от варианта *.com , создающего уязвимость). Дополнительные сведения см. в документе rfc7230, раздел 5.4.

Ведение журнала можно настроить отдельно для каждого VirtualHost с помощью директив ErrorLog и CustomLog . Журналы ошибок сохраняются в расположение ErrorLog , а параметр CustomLog задает имя и формат для файла журнала. В нашем примере здесь фиксируются сведения о запросах. Для каждого запроса создается одна строка.

Сохраните файл и протестируйте конфигурацию. Если проверка выполнена успешно, ответ должен быть Syntax [OK] .

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

Настройка Apache на переадресацию запросов к порту http://localhost:80 в приложение ASP.NET Core, работающее на базе Kestrel по адресу http://127.0.0.1:5000 , теперь завершена. Однако в Apache не настроено управление процессом Kestrel. Для запуска и мониторинга базового веб-приложения используйте systemd и создайте файл службы. systemd — это система инициализации, предоставляющая различные функции для запуска и остановки процессов, а также управления ими.

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

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

Пример файла службы для приложения:

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

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

Некоторые значения (например, строки подключения 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 — просмотреть записи за предыдущий час. Дополнительные сведения см. на странице руководства о команде journalctl.

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

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

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

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

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

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

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

Firewalld — это динамическая управляющая программа брандмауэра, которая поддерживает зоны сети. Фильтрацию портов и пакетов можно по-прежнему осуществлять через iptables. Firewalld обычно устанавливается в системе по умолчанию. yum позволяет установить этот пакет или убедиться, что он установлен.

С помощью firewalld вы можете открыть только те порты, которые необходимые для работы приложения. В этом случае используются порты 80 и 443. Следующие команды назначают порты 80 и 443 постоянно открытыми.

Обновите параметры брандмауэра. Проверьте, что доступные службы и порты находятся в зоне по умолчанию. Эти параметры можно просмотреть с помощью firewall-cmd -h .

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

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

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

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

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

Конфигурация безопасности в этом разделе представляет собой общую конфигурацию, которая будет использоваться в качестве отправной точки для дальнейшей настройки. Мы не можем обеспечить поддержку инструментов, серверов и операционных систем сторонних производителей. Ответственность за использование конфигурации в этом разделе лежит на пользователе. Дополнительные сведения см. в следующих ресурсах:

Apache для HTTPS настраивается с помощью модуля mod_ssl. При установке модуля httpd автоматически добавляется и модуль mod_ssl. Если он по каким-то причинам отсутствует, добавьте его в систему с помощью yum .

Чтобы принудительно использовать HTTPS, установите модуль mod_rewrite для перезаписи URL-адресов:

Измените файл helloapp.conf, чтобы разрешить безопасный обмен данными через порт 443.

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

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

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

В этом примере используется локально созданный сертификат. В SSLCertificateFile должен быть указан основной файл сертификата для доменного имени. В SSLCertificateKeyFile должен быть указан файл ключа, сформированный при создании CSR. В SSLCertificateChainFile должен быть указан файл промежуточного сертификата (если он существует), предоставленный центром сертификации.

Для работы с веб-сервером TLS 1.3 с OpenSSL 1.1.1 требуется сервер Apache HTTP Apache 2.4.43 или более поздней версии.

В предыдущем примере ассоциация протокола OCSP отключена. Дополнительные сведения и рекомендации по включению OCSP см. в разделе об ассоциации OCSP (документация по Apache).

Сохраните файл и протестируйте конфигурацию.

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

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

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

Дополнительные заголовки

Для защиты от вредоносных атак следует изменить или добавить несколько заголовков. Убедитесь, что модуль mod_headers установлен.

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

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

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

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

Добавьте строку Header append X-FRAME-OPTIONS «SAMEORIGIN» .

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

Заголовок X-Content-Type-Options защищает Internet Explorer от сканирования MIME (определения Content-Type для файла по его содержимому). Если сервер задает заголовок Content-Type со значением text/html , и при этом установлен параметр nosniff , Internet Explorer отображает содержимое как text/html независимо от содержимого файла.

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

Добавьте строку Header set X-Content-Type-Options «nosniff» . Сохраните файл. Перезапустите Apache.

Балансировка нагрузки

В этом примере показано, как установить и настроить Apache в CentOS 7 и Kestrel на одном компьютере. Чтобы устранить единую точку отказа, воспользуйтесь mod_proxy_balancer и измените значение VirtualHost для управления несколькими экземплярами веб-приложений за прокси-сервером Apache.

В представленном ниже файле конфигурации настроен дополнительный экземпляр helloapp , работающий на порте 5001. В разделе Proxy настраивается конфигурация подсистемы балансировки нагрузки с двумя членами для распределения нагрузки методом byrequests.

Ограничения скорости

С помощью элемента mod_ratelimit, который входит в модуль httpd, можно ограничить пропускную способность для клиентов:

В примере файла пропускная способность составляет 600 Кбит/с в корневой папке.

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

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

Не увеличивайте значение LimitRequestFieldSize по умолчанию, если это не требуется. Увеличение значения повышает риск переполнения буфера и атак типа «отказ в обслуживании» (DoS) со стороны злоумышленников.

Источник