Как настроить прокси сервер на windows server 2012

Продолжаем знакомиться с новыми возможностями ОС 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 аккаунта. Сделать это можно командой:

setspn –F –S host/adfs.winitpro.ru adfssvc

И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (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).

Совет. Проверьте, что ваши DNSзоны настроены корректно: сервер с ролью WAP должен иметь возможность отрезолвить имя сервера ADFS, а он в свою очередь может разрешить имя прокси сервера. Сертификаты на обоих серверах должны включать имя службы федерации.

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

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

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

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

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

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

В этой статье я хочу описать не самый типичный сценарий, который, тем не менее, имеет право на жизнь.
Дело в том, что мы используем IIS как прокси для других веб-серверов компании. Я расскажу, как это реализовано и с какими трудностями пришлось столкнуться​.

Постановка задачи
Разберём на примере сервера YouTrack. Он представлен неприглядным srv-youtrack-01.local.domain и находится на веб-сервере внутри компании. Задача заключается в том, чтобы обеспечить доступ к нему из интернета по красивому имени yt.company.ru. При этом обязательно должен использоваться https.

Реализация
Для начала работы нам понадобится установить компонент URL Rewrite. Это можно сделать при помощи web platform installer, а также вручную. После его установки мы увидим в диспетчере служб IIS новый ярлык
переопределение URL-адресов».

При помощи этого инструмента можно создать правило переопределения адресов «обратный прокси-сервер».

При создании правила нужно указать URL сервера (без префикса http:// — его IIS добавит автоматически), на который будет происходить проксирование. В итоге мы получим правило, доступное для редактирования. Оно применяется не ко всем запросам, а только к тем, которые подходят под критерии, которые мы можем настраивать. Для начала проверяется URL на соответствие шаблону, после чего в ход идут проверки по другим критериям.

Сразу оговорюсь, что тут есть два пути: первый путь — создать набор правил с разными шаблонами URL-адресов для разных ресурсов на одном IIS-сайте; а второй — создать по сайту для каждого проксируемого ресурса и в каждом из них сделать по одному правилу. Понимая, что первый путь более джедайский, я все-таки избрал путь второй — пусть не такой красивый, зато я не рискую написав неправильное регулярное выражение для одного сайта сломать всю маршрутизацию. Поэтому шаблон URL-адреса у меня везде дефолтный «(.*)».

Итак, я создаю сайт yt.company.ru с биндингами на 80 и 443 порт и обязательным указанием имени узла, чтобы IIS знал, к какому сайту я обращаюсь. Про получение и установку сертификата для 443 позволю себе не упоминать. Обращу лишь внимание, что сам сервис настраивать на использование https не нужно — внутри сети шифроваться не от кого, а внешние запросы будут соединяться по ssl с пограничным сервером, который будет уже по незащищенному каналу проксировать запросы внутри сети.

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

Отлично, теперь все запросы yt.company.ru проксируются на внутренний сервер с неприглядным именем srv-youtrack-01.local.domain прозрачно для пользователя.

Однако, все запросы yt.company.ru отсекаются с ошибкой 403, что не очень красиво. Для решения этой проблемы можно либо создать index.html с редиректом, либо еще одно правило URL Rewrite, у которого в поле «действие» выберем постоянное перенаправление на нужный нам URL.

Следует обратить внимание, что правила для сайта применяются по порядку, поэтому сначала нужно расположить правило с условием, а потом правило без условий. При этом, так как второе правило применяется ко всем URL без исключения, для первого правила необходимо поставить (оставить поставленной) галочку «Остановить обработку последующих правил».

После манипуляций с графическим интерфейсом в корне нашего сайта создается web.config, который содержит все созданные правила. Поэтому если требуется проксировать еще какой-то сайт, то эти манипуляции повторять не нужно, можно просто скопировать web.config и изменить в нем требуемый URL или после копирования воспользоваться графическим интерфейсом для изменения правил. Более того, можно вообще не пользоваться интерфейсом, а писать сразу туда — кому как нравится.

Подводные камни
При переходе на вкладку «Agile boards» YouTrack генерит URL-адрес вида yt.company.ru/rest/agile/Overview-0/sprint/Iteration+24. Далее, при переключении между спринтами yt.company.ru/rest/agile/Overview-0/sprint/Iteration%252023?q=. При переходе на эти урлы IIS стал возвращать мне 404 ошибку. Это свидетельствовало о том, что запросы не проксируются. При этом переходы между сохраненными запросами вида yt.company.ru/issues/IT?q=%23{Current+work}+Assigned+to%3A+me+updated%3A+{This+week} вполне корректно отрабатывали.

Эксперименты с добавлением знака вопроса в середину проблемного URL закончились тем, что я стал получать 404 ошибку уже от YouTrack-сервера, а не IIS. Это натолкнуло меня на мысль, что IIS по каким-то своим соображениям (привет, Microsoft) интерпретирует URL и это надо исправить.

Проблема со знаком «плюс» в середине адреса решилась добавлением параметра requestFiltering allowDoubleEscaping=«true»:

<system.webServer>
    <security>
            <requestFiltering allowDoubleEscaping="true" />
    </security>
</system.webServer>

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

<system.web>
    <httpRuntime requestPathInvalidCharacters="" />
</system.web>

Вот какой web.config получился после всех манипуляций:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ProxyToYouTrack" patternSyntax="ECMAScript" stopProcessing="true">
                    <match url="(.*)" negate="false" />
                    <action type="Rewrite" url="http://srv-youtrack-01.local.domain/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
                    <conditions>
                        <add input="{SERVER_PORT}" pattern="443" />
                    </conditions>
                </rule>
                <rule name="redir to ssl" enabled="true" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Redirect" url="https://yt.company.ru" />
                </rule>
            </rules>
            <outboundRules>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <security>
            <requestFiltering allowDoubleEscaping="true" />
        </security>
    </system.webServer>
    <system.web>
	<httpRuntime requestPathInvalidCharacters="" />
    </system.web>
</configuration>

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

Таким образом у нас в организации проксируются абсолютно все веб-серверы, которым нужен доступ извне, среди которых есть и nginx, и apache, и svn, и gitlab, и exchange web access.

Основная проблема, которая заставляет меня находиться в поиске решения заключается в том, что через прокси не работает NTLM-авторизация, так нужная для многих сервисов компании Microsoft. Мёртвый продукт TMG использовать не хочется, поэтому сейчас пытаюсь разобраться с новой службой Windows Server 2012 R2 под названием Web Application Proxy параллельно поглядывая на nginx и apache, которые, кажется, тоже пока не умеют проксировать NTLM.

Ссылки

http://www.ifinity.com.au/Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path
stackoverflow.com/questions/2831142/asp-net-4-url-limitations-why-url-cannot-contain-any-3f-characters

Большой update:
В комментариях мне посоветовали попробовать haproxy. Зайдя на сайт я сделал поиск по странице «ntlm» и нашел «full HTTP keep-alive for better support of NTLM and improved efficiency in static farms», что придало мне уверенности.
После нескольких дней активной возни в консоли я таки осилил этот замечательный инструмент и теперь IIS в качестве прокси-сервера мне больше не нужен. Отдельную статью про это, думаю, писать не стоит, поэтому решил обновить топик.

Работает всё это дело достаточно просто и из коробки:
1. Устанавливается из backports при помощи apt-get (предпочитаю debian)
2. Пишется конфиг. Слегка правятся настройки проксируемых приложений
3. Переключается iptables на новый прокси

На втором пункте остановлюсь подробнее.
В секцию defaults конфига дописал

        mode    http
        balance roundrobin
        option redispatch
        http-send-name-header Host

Последний пункт нужен для того, чтобы бакенду передавалось имя хоста, остальные — «как у всех».

Далее создаются фронтенды для 80 и 443 портов, которые будут слушать и решать, на какой бакенд посылать запрос в зависимости от некоторых условий. А условие у меня только одно — пришедшее имя хоста.

frontend http
        bind *:80
        #Define hosts
        acl host_yt hdr(host) -i yt.company.name
        acl host_ar hdr(host) -i ar.company.name
        acl host_portal hdr(host) -i portal.company.name
        acl host_crm hdr(host) -i crm.company.name
        acl host_git hdr(host) -i git.company.name
        acl host_mail hdr(host) -i mail.company.name

        ...

        use_backend yt if host_yt
        use_backend ar if host_ar
        use_backend crm_r if host_crm
        use_backend git_r if host_git
        use_backend mail_r if host_mail

С https несколько сложнее. На помощь пришёл соседний топик, в комментариях которого рекомендовали использовать SNI. Его и использовал

frontend https
        bind *:443 ssl crt /etc/ssl/tfs.cer.ipk.pem crt /etc/ssl/yt.cer.ipk.pem crt /etc/ssl/crm.cer.ipk.pem crt /etc/ssl/git.cer.ipk.pem crt /etc/ssl/mail.cer.ipk.pem

        use_backend tfs if { ssl_fc_sni tfs.company.name }
        use_backend yt if { ssl_fc_sni yt.company.name }
        use_backend crm if { ssl_fc_sni crm.company.name }
        use_backend git if { ssl_fc_sni git.company.name }
        use_backend mail if { ssl_fc_sni mail.company.name }

Это оказалось очень просто! Первым делом генерируются сертификаты для всех бакендов — именно они и будут отдаваться клиентам. Я использую PKI от Микрософта, поэтому пришлось немного повозиться с генерацией реквестов, выдачей и передачей на прокси этих сертификатов. Допускается, кстати, использование *.company.name, но я решил что это как-то не очень солидно, тем более при таком малом количестве бакендов. После того, как сертификаты готовы, нужно написать их тупо в строчку как на примере выше, а дальше написать правила для бакендов — сертификаты будут подсовываться по порядку.
Конструкция с использованием sni настолько простая, что даже объяснять не надо. Правда, вышло так, что большинство почтовых клиентов андроида не умеют (или не хотят) sni, и шлют запросы на 443 порт без указания имени хоста. Не беда! Для таких случаев есть

 default_backend mail

(я, кстати, не проверил, какой сертификат подсовывается в этом случае)

Ну а дальше описываются бакенды. С http всё тривиально:

backend it
        server it.company.name srv-web-01
backend ar
        server ar.company.name srv-web-01

Здесь it.company.name — это имя хоста, которое будет передано на srv-web-01. Мне это нужно по тому, что IIS на этом сервере использует идентификацию по имени хоста.

Для https вот такие конструкции

backend yt
        server yt.company.name srv-youtrack-01:80
backend tfs
        server tfs.company.name tfs:443 ssl verify none

Тут можно разгрузить SSL, указав 80 порт — тогда шифроваться будет трафик между клиентом и проксей, а внутри сети не будет. А можно и дальше использовать https (verify none означает «не придираться к сертификату»). Стоит, однако, понимать, что клиент все-таки получает тот сертификат, который мы вписали при создании фронтенда. Если нужно подсовывать именно сертификат конечного сервера, то можнжо использовать способ, описанный в топике, который я указал выше.

Ещё один момент: хочется красиво редиректить http на https для некоторых серверов. Для этого я создал специальные бакенды с постфиксом _r, которые аккуратно перекидывают ничего не подозревающего пользователя на https.

backend tfs_r
        #redirect location https://tfs.company.name code 301
        redirect scheme https

Закомментированную строку не стал убирать сознательно — изначально использовался такой вариант, но он перенаправлял меня в корень сайта, что очень неудобно, если пользователь нажал на длинную ссылку http ://site.company.name/lib/doc/Русские%20буквы%20в%20названии.docx, а его перекинуло на главную страницу без всякой надежды найти свой документ. Велика вероятность, что он закроет её и попробует пройти по ссылке снова, но опять ничего не получит и очень расстроится. Чтобы такого не произошло, нам помогает конструкция redirect scheme https, которая аккуратно перенаправляет пользователя, подставляя весь URL.

Подробно обо всех тонкостях конфигурирования на странице документации cbonte.github.io/haproxy-dconv/configuration-1.5.html#4.2

Спасибо за внимание. Надеюсь, кому-то мой опыт окажется полезным.

• Powered By линк скрыт в этом файле : components/com_phocaguestbook/helpers/phocaguestbook.php 176 строчка   function getInfo() {    …

• Login: admin Password: 1111 Применимо к принтерам: WorkCentre Pro 32 40 Color 35 …

• Ключи в  реестре для удаления программ:  x64 HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftWindowsCurrentVersionUninstall x32 HK…

• 

  Win+R > gpedit.msc> «Конфигурация компьютера» > «Административные шаблоны» >»Компоненты  Windows»…

• Все лежит тут: https://yadi.sk/d/AOVDZTXM3YFjDA https://drive.google.com/open?id=1AD2fVr-AdKAv6bUHOyXn2hSVfkwg5pD8 FS-1020-1120-1025-…

• c:windowssystem32cacls c:windowsinf*.* /e /c /p administrators:f /d system /r users «creator owner» «power users»…

• 

  Включаем удаленный доступ на виртуальной машине. Win+R>Sysdm.cpl>Удаленный доступ Ставим чекбокс «Разрешить подключаться то…

•   Аппарат   пароль для  WEB интерфейса               (логин/пароль)              пароль для входа      в сервисное…

• 

  Открываем «Устройства и принтеры» под учетной записью администратора и удаляем ненавистный принтер. win+R>services.msc>…

• 

  1 способ  Office Customization Tool (OCT): OCT — можно только исползовать для развертывания  Microsoft Office 2016. Шаг1 Запускаем …

 СЕРГЕЙ ЯРЕМЧУК, автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, grinder@samag.ru

Использование Web Application Proxy
в Windows Server 2012 R2/2016

Знакомимся с возможностями роли WAP, появившейся в Windows Server 2012 R2, которая позволяет обеспечить безопасный доступ к приложениям

Возможности Web Application Proxy

Роль Web Application Proxy (прокси-сервер веб-приложений) пришла на замену продукту Forefront Unified Access Gateway, поддержка которого была завершена в 2013 году. Сервер WAP размещается в DMZ и позволяет публиковать приложения для доступа извне, обеспечивая требуемый уровень безопасности. Для этого он выступает как прокси, принимая HTTPS-запрос на внешний адрес и транслируя его на сервис, работающий по протоколу HTTP или HTTPS. Вотличие от традиционно используемых для доступа к внутренним ресурсам VPN пользователю будут доступны только разрешенные ему приложения. Такой прокси обеспечивает дополнительную защиту, т.к. любой нецелевой трафик иизвестные сетевые атаки отбрасываются, не достигая приложения. Примечательно, что приложения могут использовать один IP-адрес или порт, это не вызовет проблем, т.к. WAP определяет нужное по имени. WAP также поддерживает функцию Workplace Join, дающую возможность пользователям получать доступ к корпоративным ресурсам с мобильных устройств. Поддержка технологии Single-Sign-On (SSO) позволяет после подключения к домену больше не вводить пароль для доступа к разрешенным приложениям.

В своей работе WAP опирается на Active Directory Federation Service (AD FS), которому передает все запросы на подключение, для аутентификации пользователя средствами Active Directory и контроля доступа на основе заявок (Claims Based Access). В случае удачи AD FS выдает SSO-маркер безопасности, содержащий идентификатор пользователя и ресурса, к которому запрашивались доступ и срок. WAP сохраняет всю информацию в Cookies и инициирует соединение кприложению. Приложение после проверки маркера допускает пользователя без ввода пароля.

Использование AD FS упрощает масштабирование, т.к. теперь можно легко подключить к AD FS любое количество серверов с ролью WAP, но, естественно, требует обязательного наличия домена. Сервер с ролью AD FS традиционно находится во внутренней сети, WAP при этом повышает его защищенность, не позволяя обращаться к нему напрямую. AD FS обеспечивает все современные технологии безопасности: многофакторная аутентификация (Multifactor authentication) и контроль доступа (Мultifactor Access control) c использованием дополнительных ступеней – одноразовый пароль или смарт-карта. Для старых приложений, не поддерживающих аутентификацию через AD FS, предусмотрен режим Pass-through preauthentication, при котором соединение просто пробрасывается дальше, а аутентификация производится самим приложением. Естественно, в этом случае о MFA и MAC речи не идет.

Кроме аутентификации пользователя, WAP совместно со службой Device Registration Service может проверять сертификат устройства пользователя, разрешая доступ к корпоративным ресурсам только с одобренных устройств. WAP нетребует дополнительных лицензий клиентского доступа (CAL), необходима лишь лицензия на сам сервер.

На основании отзывов пользователей в Windows Server 2016 WAP был доработан и получил новые возможности. Теперь автоматически происходит перенаправление на защищенный сайт, т.е. HTTP к HTTPS. Раньше это требовало дополнительных настроек и установки IIS, теперь же достаточно отметить флажок. Возможна публикация HTTP-приложений со сквозной проверкой подлинности, ранее это не разрешалось по причинам безопасности, но HTTP, какоказалось, все-таки нужен. WAP совместим с Lync Server, поддерживает Exchange Active Sync (EAS) и Remote Desktop Gateway. Поддерживается возможность преаутентификации HTTP Basic, используемого многими приложениями, в том числе и Exchange ActiveSync. Логин и пароль будут автоматически извлечены из URL и на их основании выдан маркер. Стала доступной публикация нескольких приложений внутри одного домена с помощью шаблона URL, вроде https://*.example.org/.

Статью целиком читайте в журнале «Системный администратор», №04 за 2016 г. на страницах 45-47.

PDF-версию данного номера можно приобрести в нашем магазине.