Рекомендации по развертыванию RPC через HTTP

В этом разделе описаны рекомендации и рекомендуемые конфигурации развертывания для достижения максимальной безопасности и производительности при использовании RPC через HTTP. Различные конфигурации, найденные здесь, применяются к разным организациям в зависимости от размера, бюджета и требований к безопасности. Каждая конфигурация также содержит рекомендации по развертыванию, полезные для определения того, какой из них лучше всего подходит для конкретного сценария.

Сведения о сценариях RPC через HTTP с большим объемом см. в статье Балансировка нагрузки Microsoft RPC.

Следующие рекомендации применяются ко всем конфигурациям.

• Используйте версии Windows, поддерживающие RPC через HTTP версии 2.
• Переместите СЛУЖБЫ IIS на компьютер, на котором выполняется прокси-сервер RPC в режиме IIS 6.0.
• Запретить анонимный доступ к виртуальному каталогу прокси-сервера RPC.
• Никогда не включайте раздел реестра AllowAnonymous.
• Убедитесь, что клиенты RPC через HTTP используют CertificateSubjectField (дополнительные сведения см. в разделе RpcBindingSetAuthInfoEx ), чтобы убедиться, что прокси-сервер RPC, к которому вы подключены, является ожидаемым прокси-сервером RPC.
• Настройте раздел реестра ValidPorts так, чтобы он содержал только компьютеры, к которым будут подключаться клиенты RPC через HTTP.
• Не используйте подстановочные знаки в ключе ValidPorts ; это может сэкономить время, но подстановочный знак может также подойти для совершенно неожиданного компьютера.
• Используйте SSL в RPC через HTTP-клиенты. При соблюдении рекомендаций, изложенных в этих разделах, клиент RPC через HTTP не сможет подключиться без использования SSL.
• Настройте клиенты RPC через HTTP для использования шифрования RPC в дополнение к использованию SSL. Если клиент RPC через HTTP не может связаться с KDC, он может использовать только Negotiate и NTLM.
• Настройте клиентские компьютеры для использования NTLMv2. Задайте для раздела реестра LMCompatibilityLevel значение 2 или выше. Дополнительные сведения о ключе LMCompatibilityLevel см. в msdn.microsoft.com.
• Запустите веб-ферму прокси-компьютеров RPC с конфигурацией, описанной выше.
• Разверните брандмауэр между Интернетом и прокси-сервером RPC.
• Чтобы обеспечить оптимальную производительность, настройте iis для отправки короткого ответа на коды ошибок, не являющихся успешными. Так как потребитель ответа IIS является автоматизированным процессом, клиенту не нужно отправлять понятные объяснения. Они будут просто игнорироваться клиентом RPC через HTTP.

Ниже приведены основные цели прокси-сервера RPC с точки зрения безопасности, производительности и управляемости.

• Укажите единую точку входа для трафика RPC через HTTP в сеть сервера. Наличие единой точки входа для трафика RPC через HTTP в серверной сети имеет два преимущества main. Во-первых, так как прокси-сервер RPC подключен к Интернету, большинство организаций изолируют такие компьютеры в специальной сети, называемой ненадежной сетью периметра, которая отделена от обычной организационной сети. Серверы в ненадежной сети периметра очень тщательно управляются, настраиваются и отслеживаются, чтобы они могли противостоять атакам из Интернета. Чем меньше компьютеров в ненадежной сети периметра, тем проще настроить, контролировать и обеспечивать их безопасность, а также управлять ими. Во-вторых, так как одна веб-ферма с установленными прокси-серверами RPC может обслуживать любое количество RPC-серверов через HTTP, размещенных в корпоративной сети, имеет смысл отделить прокси-сервер RPC от RPC через HTTP-сервер и размещать прокси-сервер RPC в ненадежной сети периметра. Если бы прокси-сервер RPC находился на том же компьютере, что и сервер RPC через HTTP, организации были бы вынуждены поместить все серверные серверы в недоверенную сеть периметра, что значительно усложнит защиту ненадежной сети периметра. Разделение роли прокси-сервера RPC и сервера RPC через HTTP помогает организациям поддерживать управляемое и, следовательно, более безопасное количество компьютеров в ненадежной сети периметра.
• Служат предохранителем безопасности для серверной сети. Прокси-сервер RPC предназначен как расходный предохранитель для серверной сети. Если что-то пойдет не так на прокси-сервере RPC, он просто выходит из строя и таким образом защищает реальный сервер RPC через HTTP. Если до сих пор соблюдаются рекомендации, описанные в этом разделе, трафик RPC через HTTP шифруется с помощью шифрования RPC в дополнение к SSL. Само шифрование RPC находится между клиентом и сервером, а не между клиентом и прокси-сервером. Это означает, что прокси-сервер не понимает и не может расшифровать получаемый трафик RPC. Он распознает только некоторые последовательности элементов управления, отправленные ему клиентом, которые имеют дело с установлением подключения, управлением потоком и другими сведениями о туннелированиях. Он не имеет доступа к данным, которые клиент RPC через HTTP отправляет на сервер. Кроме того, клиент RPC через HTTP должен независимо проходить проверку подлинности как на прокси-сервере RPC, так и на сервере RPC через HTTP. Это обеспечивает глубинную защиту. Если прокси-компьютер RPC скомпрометирован из-за какой-либо ошибки конфигурации или нарушения безопасности, данные, которые проходят через него, по-прежнему будут защищены от незаконного изменения. Злоумышленник, который получит контроль над прокси-сервером RPC, может прервать трафик, но не прочитать его или изменить его. Именно здесь вступает в игру роль предохранителя прокси-сервера RPC— она расходуется без компрометации безопасности трафика RPC через HTTP.
• Распределите некоторые проверки доступа и расшифровку между несколькими компьютерами, на которых запущен прокси-сервер RPC в веб-ферме. Благодаря правильной работе в веб-ферме прокси-сервер RPC позволяет организациям разгружать расшифровку SSL и некоторые проверки доступа, тем самым освобождая большую емкость внутреннего сервера для обработки. Использование веб-фермы прокси-компьютеров RPC также позволяет организации повысить свою способность противостоять атакам типа "отказ в обслуживании" (DoS), увеличивая емкость на внешних серверах.

В соответствии с руководящими принципами, изложенными до сих пор, у организаций по-прежнему есть выбор. У каждой организации есть варианты и компромиссы между неудобствами пользователей, безопасностью и затратами:

• Использовать обычную проверку подлинности или встроенную проверку подлинности Windows для проверки подлинности на прокси-сервере RPC? В настоящее время RPC через HTTP поддерживает только NTLM— он не поддерживает Kerberos. Кроме того, при наличии прокси-сервера HTTP или брандмауэра между клиентом RPC через HTTP и прокси-сервером RPC, который вставляет через pragma в заголовок HTTP, проверка подлинности NTLM не будет работать. Если это не так, организации могут выбирать между обычной проверкой подлинности и проверкой подлинности NTLM. Преимущество обычной проверки подлинности заключается в том, что она выполняется быстрее и проще и, следовательно, дает меньше возможностей для атак типа "отказ в обслуживании". Но NTLM является более безопасным. В зависимости от приоритетов организации она может выбрать базовый, NTLM или разрешить пользователям выбирать между ними. Если выбран только один из них, лучше отключить другой из виртуального каталога прокси-сервера RPC, чтобы снизить риск атаки.
• Использовать один и тот же набор учетных данных для прокси-сервера RPC и RPC через HTTP-сервер или использовать разные учетные данные для каждого из них? Компромиссом для этого решения является удобство и безопасность пользователя. Немногие пользователи любят вводить несколько учетных данных. Однако в случае нарушения безопасности в недоверенной сети периметра наличие отдельных наборов учетных данных для прокси-сервера RPC и сервера RPC через HTTP обеспечивает дополнительную защиту. Обратите внимание, что если используются отдельные учетные данные и один набор учетных данных является учетными данными домена пользователя, рекомендуется использовать учетные данные домена пользователя для сервера RPC через HTTP, а не для прокси-сервера RPC.