Web Application Proxy в Windows Server 2012 R2

Продолжаем знакомиться с новыми возможностями ОС Windows Server 2012 R2. Ранее мы рассказывали о корпоративном аналоге DropBox в Windows Server 2012 R2 под названием Work Folders. Сегодня речь пойдет о еще одном новшестве новой серверной платформы – функции Web Application Proxy. Web Application Proxy – это новая функция роли Remote Access в Windows 2012 R2, позволяющая публиковать HTTP/ HTTPS приложения, расположенные в периметре корпоративной сети на клиентских устройствах (в первую очередь подразумеваются мобильные устройства) за ее периметром. Благодаря возможности интеграции c AD FS (служба может выступать в качестве ADFS-прокси), возможно обеспечить аутентификацию внешних пользователей, пытающихся получить доступ к опубликованным приложениям.

Web Application Proxy предоставляет такие же возможности публикации приложений, как и Forefront Unified Access Gateway (UAG), однако данная служба также позволяет взаимодействовать с другими серверами и сервисами, обеспечивая тем самым более гибкую и рациональную конфигурацию.

Web Application Proxy по сути выполняет функцию обратного прокси сервера (HTTP reverse proxy), организуя ретрансляцию запросов клиентов из внешней сети на внутренний сервер, и является межсетевым экраном на прикладном уровне.

Сервер со службой Web Application Proxy получает внешний HTTP/HTTPS трафик и терминирует его, после чего от своего имени инициирует новое подключение ко внутреннему приложению (веб-серверу). Т.е. внешние пользователи прямого доступа к внутреннему приложению реально не получают. Любой другой трафик, получаемый Web Application Proxy, отклоняется (в том числе отклоняются HTTP/HTTPS запросы, которые могут быть использованы при DoS, SSL и 0-day атаках).

Требования к организации Web Application Proxy и ключевые особенности:

• Систему можно развернуть на серверах с ОС Windows Server 2012 R2, включенных в домен Active Directory, с ролями AD FS и Web Application Proxy. Эти роли должны быть установлены на разных серверах.
• Необходимо обновить схему Active Directory до Windows Server 2012 R2 (обновлять контроллеры домена до Windows Server 2012 R2 не нужно)
• В качестве клиентских устройств поддерживаются устройства с ОС Windows, IOS (iPad и iPhone). Работы над клиентами для Android и Windows Phone пока еще не окончены
• Аутентификация клиентов осуществляется службой Active Directory Federation Services (ADFS), которая также выполняет функции ADFS – проксирования.
• Типовая схема размещения сервера с ролью Web Application Proxy представлена на рисунке. Данный сервер располагается в выделенной DMZ зоне и отделен от внешней (Интернет) и внутренней сети (Интранет) межсетевыми экранами. В этой конфигурации для работы Web Application Proxy требует наличия двух интерфейсов – внутреннего (Intranet) и внешнего (DMZ)

Установка роли ADFS в Windows Server 2012 R2

Для обеспечения дополнительной безопасности преаутентифкация внешних клиентов выполняется на сервере ADFS, в противном случае используется pass-through аутентификация на конечном сервере приложения (что менее секьюрно). Поэтому первый шаг при настройке Web Application Proxy – установка на отдельном сервере роли Active Directory Federation Services.

При установке ADFS нужно выбрать SSL сертификат, который будет использоваться для шифрования, а также DNS имена, которые будут использоваться клиентами при подключении (соответствующие записи в DNS зоне придется создать самостоятельно).

Затем нужно указать сервисную учетную запись для службы ADFS. Необходимо учесть, что имя ADFS должно быть указано в атрибут Service Principal Name аккаунта. Сделать это можно командой:

И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (WID — Windows Internal Database) или отдельная база на выделенном SQL-сервере.

Установка службы Web Application Proxy

Следующий этап, настройка самой службы Web Application Proxy. Напомним, что служба Web Application Proxy в Windows Server 2012 R2 является частью роли “Remote Access”. Установите службу Web Application Proxy и запустите мастер ее настройки.

На первом этапе мастер предложит Вам указать имя ADFS сервера и параметры учетной записи, имеющей доступ к данной службе.

Далее нужно указать сертификат (убедитесь, что в альтернативных именах сертификата содержится имя сервера ADFS).

Публикация приложения через Web Application Proxy

После того, как установлены роли ADFS и Web Application Proxy (которая работает еще и как ADFS Proxy), можно перейти непосредственно к публикации наружу конкретного приложения. Сделать это можно с помощью консоли Remote Access Management Console.

Запустите мастер публикации и укажите, хотите ли вы использовать для преаутентификации службу ADFS (это именно наш вариант).

Затем нужно задать имя публикуемого приложения, используемый сертификат, внешний URL (имеенно его для подключения будут использовать внешние пользователи) и внутрений URL-адрес сервера, на который будут пересылаться запросы.

Backend server URL: lync.winitpro.local:4443

Завершите работу мастера, и на этом публикация приложений окончена. Теперь, если попытаться с помощью браузера зайти на опубликованный внешний URL-адрес, то браузер сначала будет перенаправлен на службу аутентификации (ADFS Proxy), а после успешной аутентификации пользователь будет отправлен непосредственно на внутренний сайт (веб приложение).

Благодаря новой службе Web Application Proxy в Windows Server 2012 R2 возможно реализовать функционал обратного прокси сервера с целью публикации внутренних служб предприятия наружу без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront и пр.

Какое посоветуете бесплатное Reverse Proxy решение?

RazorBlade: из того, что я прочитал в вопросе, nginx может если не всё, то почти всё.
На нём можно поднять несколько SSL серверов (инстанций), на каждый из которых назначит свой ssl сертификат, клиент обращаясь к его порту, средствами расширения SNI к протоколу SSL сообщает серверу, с каким доменом он будет общатся, NGINX в этом случае отдаёт нужный сертификат сервера и процедура установления SSL сессии продолжается.
От NGINX до вашего внутреннего ресурса можно держать обычное HTTP соединение.

Этот режим работы называется обратный прокси и он очень подробно описан в тысячах документаций и работает отлично с дефолтными настройками. Требуется лишь, положить на NGINX сервер открытые и закрытые ключи и создать записи в конфигурационных файлах nginx где для каждого домена будут указаны сертификаты (и ключи) и адрес конечного сервера, на который осуществлять проксирование. Опционально можно сделать прозрачный http -> https редирект для тех пользователей, чьи браузеры идут небезопасно.

Такая конфигурация настраивается максимум за час.

RazorBlade: все ваши вопросы — это какой-то каменный век, честное слово. Видны костлявые руки мелкомягких.

Все нормальные веб-серверы (и nginx, разумеется) уже не первый десяток лет умеет SNI. И для Let`s Encrypt давно написана масса врапперов, самостоятельно обновляющих сертификаты сайтов — вам остаётся только добавить задание в планировщик.

ky0: не ругайте, да обруганы не будете. И кто никогда не юзал софт от майкрософта — пусть первый кинет в меня камень (желательно i7 и с индексом «k»).

Обычная ситуация в обычной конторе (скорее всего ГОС), закупили софт в прошлом веке, имеют большой контракт с MS, стоит TMG никого не беспокоит, но вот настало время перемен и прошлый ИТ директор ушёл (умер, на пенсии, спился, укажи свою причины).

RazorBlade:
server <
listen 443 ssl;
server_name test.com;

ssl_certificate /etc/nginx/cert/test_pub.crt;
ssl_certificate_key /etc/nginx/cert/test_priv.key;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Reverse proxy для windows

Welcome to the YARP project

YARP (which stands for «Yet Another Reverse Proxy») is a project to create a reverse proxy server. We found a bunch of internal teams at Microsoft who were either building a reverse proxy for their service or had been asking about APIs and tech for building one, so we decided to get them all together to work on a common solution, this project.

YARP is a reverse proxy toolkit for building fast proxy servers in .NET using the infrastructure from ASP.NET and .NET. The key differentiator for YARP is that it’s been designed to be easily customized and tweaked to match the specific needs of each deployment scenario.

We expect YARP to ship as a library and project template that together provide a robust, performant proxy server. Its pipeline and modules are designed so that you can then customize the functionality for your needs. For example, while YARP supports configuration files, we expect that many users will want to manage the configuration programmatically based on their own backend configuration management system, YARP will provide a configuration API to enable that customization in-proc. YARP is designed with customizability as a primary scenario, rather than requiring you to break out to script or having to rebuild from source.

For regular updates, see our releases page. Subscribe to release notifications on this repository to be notified of future updates (Watch -> Custom -> Releases).

To build the repo, you should only need to run build.cmd (on Windows) or build.sh (on Linux or macOS). The script will download the .NET SDK and build the solution.

For VS on Windows, you can run the startvs.cmd script to launch Visual Studio on Windows using the appropriate local copy of the .NET SDK.

To set up local development with Visual Studio, Visual Studio for Mac or Visual Studio Code, you need to put the local copy of the .NET SDK in your PATH environment variable. Our Restore script fetches the latest build of .NET 5 and installs it to a .dotnet directory within this repository.

We provide some scripts to set all this up for you. Just follow these steps:

1. Run the restore.cmd / restore.sh script to fetch the required .NET SDK locally (to the .dotnet directory within this repo)
2. «Dot-source» the activate script to put the local .NET SDK on the PATH
   1. For PowerShell, run: . .\activate.ps1 (note the leading . , it is required!)
   2. For Linux/macOS/WSL, run: . ./activate.sh
   3. For CMD, there is no supported script. You can manually add the .dotnet directory within this repo to your PATH . Ensure where dotnet shows a path within this repository!
3. Launch VS, VS for Mac, or VS Code!

When you’re done, you can run the deactivate function to undo the changes to your PATH .

If you’re having trouble building the project, or developing in Visual Studio, please file an issue to let us know and we’ll help out (and fix our scripts/tools as needed)!

• See our Getting Started docs.
• Try our previews.
• Try our latest daily build.

Reporting security issues and bugs

YARP is a preview project, and as such we expect all users to take responsibility for evaluating the security of their own applications.

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) at secure@microsoft.com . You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found at the Microsoft Security Response Center.

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

About

A toolkit for developing high-performance HTTP reverse proxy applications.