Что такое код iis шифрование


Что такое код iis шифрование

Обновлен: Ноябрь 2007

Предоставляет пошаговые инструкции для шифрования разделов файла конфигурации для приложения ASP.NET.

Функция защищенной конфигурации помогает улучшить безопасность приложения путем шифрования конфиденциальной информации, хранящейся в файле Web.config. Для шифрования разделов файла Web.config и управления ключами шифрования можно использовать программу aspnet_regiis.exe. ASP.NET расшифровывает файл конфигурации при его обработке. Таким образом, расшифровка не требует дополнительного кода. Дополнительные сведения о функции защищенной конфигурации см. в разделе Шифрование сведений о конфигурации с помощью функции защищенной конфигурации .

В данном пошаговом руководстве рассматривается выполнение следующих действий.

Шифрование разделов файла Web.config с помощью поставщика защищенной конфигурации по умолчанию.

Доступ к расшифрованной информации на странице ASP.NET.

Для выполнения инструкций данного пошагового руководства необходимы следующие компоненты.

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

Подробные сведения об установке и настройке IIS содержатся в справке IIS, включенной в состав установки, или в электронной документации IIS Internet Information Services 6.0 Technical Resources.

Если веб-узел уже существует, его можно использовать. В противном случае дополнительные сведения о способах создания виртуального каталога или веб-узла см. в разделе Практическое руководство. Создание и настройка виртуальных каталогов в IIS 5.0 и 6.0 .

Перед тем как ASP.NET расшифрует зашифрованную информацию в файле Web.config, идентификация приложения ASP.NET должна иметь доступ к считыванию зашифрованного ключа, используемого для зашифровки и расшифровки данных конфигурации. В данном руководстве используется поставщик по умолчанию RsaProtectedConfigurationProvider , предоставленный в файле Machine.config file и имеющий имя «RsaProtectedConfigurationProvider» . Используемый поставщиком по умолчанию RsaProtectedConfigurationProvider контейнер ключа RSA называется «NetFrameworkConfigurationKey» .

Чтобы предоставить идентификации ASP.NET доступ на чтение к контейнеру ключа RSA по умолчанию

Откройте текстовый редактор и скопируйте следующий код в новый файл.

Сохраните этот файл в каталоге приложения как identity.aspx .

Чтобы определить идентификацию приложения ASP.NET, откройте файл identity.aspx в обозревателе.

Олицетворенная идентификация приложения ASP.NET выводится в обозревателе.

Так как для данного пошагового руководства используется IIS, не следует использовать олицетворение для проверки подлинности на узле. Для данного руководства необходимо использовать только анонимную проверку подлинности в качестве идентификации приложения ASP.NET. Если идентификацией приложения является идентификатор пользователя, под учетной записью которого выполнен вход в систему, например DOMAIN\ myuserid , то в файле Web.config следует отключить олицетворение. Чтобы отключить олицетворение в файле Web.config, откройте файл Web.config и удалите элемент . После удаления элемента обновите файл identity.aspx в обозревателе для отображения измененной идентификации приложения.

В командной строке выполните файл aspnet_regiis.exe со следующими параметрами:

Параметр -pa, за которым следует имя контейнера ключа RSA для поставщика по умолчанию RsaProtectedConfigurationProvider .

Идентификация приложения ASP.Net, как указано на предыдущем этапе.

Например, следующая команда предоставляет учетной записи NETWORK SERVICE доступ к контейнеру ключа RSA «NetFrameworkConfigurationKey» на уровне компьютера.

Примечание.

На компьютере под управлением Windows Server 2003 с олицетворением для приложения ASP.NET, отключенного в файле Web.config, идентификацией приложения является идентификация пула приложений. По умолчанию ею является учетная запись NETWORK SERVICE (в более ранних версиях Windows идентификацией являлась учетная запись ASPNET).

aspnet_regiis -pa «NetFrameworkConfigurationKey» «NT AUTHORITY\NETWORK SERVICE»

Не закрывайте окно командной строки.

После того как идентификация приложения ASP.NET получила доступ на чтение к контейнеру ключа RSA для объекта по умолчанию RsaProtectedConfigurationProvider , разделы файла Web.config приложения ASP.NET можно зашифровать с помощью этого контейнера. Затем ASP.NET расшифровывает разделы при обработке файла Web.config.

Чтобы зашифровать разделы файла Web.config и

Откройте файл Web.config для приложения в текстовом редакторе.

Если файл Web.config для приложения ASP.NET не существует, откройте текстовый редактор, скопируйте пример конфигурации в новый файл и сохраните его в каталоге приложения ASP.NET под именем web.config .

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

Закройте файл Web.config.

В командной строке измените каталог на каталог платформы .NET Framework версии 2.0, введя следующую команду:

cd \WINDOWS\Microsoft.Net\Framework\v2.0.*

В командной строке выполните файл aspnet_regiis.exe со следующими параметрами:

Параметр -pe и строка «connectionStrings» для шифрования элемента connectionStrings файла приложения Web.config.

Параметр -app и имя приложения.

Например, следующая команда шифрует раздел файла Web.config для приложения под именем MyApplication .

aspnet_regiis -pe «connectionStrings» -app «/MyApplication»

Повторите предыдущий шаг для дочернего элемента элемента , как показано в следующем примере:

aspnet_regiis -pe «system.web/machineKey» -app «/MyApplication»

Не закрывайте окно командной строки.

Откройте файл Web.config и просмотрите зашифрованное содержимое.

Содержимое будет выглядеть как в следующем примере файла Web.config.

Закройте файл Web.config file.

ASP.автоматически NET расшифровывает содержимое файла Web.config при его обработке. Таким образом, пользователю не требуется предпринимать дополнительных действий для расшифровки зашифрованных параметров конфигурации, их использования в функциях ASP.NET или доступа к ним в коде. Однако если требуется просмотреть расшифрованные параметры, следует выполнить указанные ниже действия.

Чтобы просмотреть расшифрованные параметры конфигурации

Откройте текстовый редактор и скопируйте следующий код ASP.NET в новый файл.

Сохраните файл под именем walkthrough.aspx, и затем просмотрите его в обозревателе.

На странице отобразятся расшифрованные значения из зашифрованного файла Web.config.

Чтобы защитить конфиденциальную информацию веб-узла, удалите файл walkthrough.aspx после завершения выполнения шагов данного пошагового руководства.

Зашифрованное содержимое файла Web.config можно при необходимости расшифровать, запустив программу aspnet_regiis.exe с параметром -pd. Синтаксис команды совпадает с синтаксисом шифрования содержимого файла Web.config при использовании параметра -pe. Отличие состоит в том, что поставщик защищенной конфигурации не указывается. Соответствующий поставщик определяется при помощи элемента configProtectionProvider для раздела protected . Например, следующие команды расшифровывают элемент и дочерний элемент элемента в файле Web.config для приложения ASP.NET с именем MyApplication .

aspnet_regiis -pd «connectionStrings» -app «/MyApplication»

Что такое код iis шифрование

Здравствуйте! Установлен Exchange 2013

Заметил в настройках IIS метод шифрования SHA1 можно ли и стоит ли сменить его на TripleDES или MDA? хотелось бы повысить безопасность передаваемого трафика

Ответы

Поскольку CA «свой» — нужно, чтобы CA выдавал такие сертификаты. Например, вот так:

  • Предложено в качестве ответа Avksentyev Sergey 19 июня 2015 г. 11:26
  • Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 6 июля 2015 г. 11:38
  • Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 6 июля 2015 г. 11:38

Все ответы

Если говорить о реализациях хэш-функций — SHA1 предпочтительнее.

(TripleDES — это не реализация хэш-функции.)

У меня свой центр сертификации сертификаты сервера и клиентов выданы им цепочки сертификатов прописаны

Подскажите тогда почему когда я через гугл захожу в owa (входит в перечень имен сертификата) он говорит На этом сайте используется устаревшие параметры безопасности?

Дальше пишет что используется TLS 1.2, для аутентификации сообщений AES_256_CBS c SHA1, для обмена ключами ECDHE_RSA это правильно ?

Поскольку CA «свой» — нужно, чтобы CA выдавал такие сертификаты. Например, вот так:

  • Предложено в качестве ответа Avksentyev Sergey 19 июня 2015 г. 11:26
  • Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 6 июля 2015 г. 11:38

Просто сделайте так, чтоы Ваш СА умел такие сертификаты выдавать, сделайте новый запрос и выдайте ему новый сертификат. и будет у Вас как хочется.. Но на самом деле это не критично сейчас. Это Хром и в частности Гугл считаю что она устарела эта технология.

Кстати, у меня SHA256 сертификат и последняя версия Хрома тоже считает устаревшей технологией. теперь в оппозиции и RSA

Зы.. Даже этот сайт зашифрован с помощью устаревшей технологии )))

Что такое код iis шифрование

В соответствии с Payment Card Industry Data Security Standard (PCI DSS), предприятия, использующие данные кредитных карт обязаны использовать устойчивые криптографические алгоритмы и протоколы, такие как- SSL/TLS или IPSEC, для защиты личных данных о держателях карт при их передаче по открытым общедоступным сетям.

Что это значит? Для того, чтобы соответствовать PCI DSS в этой области, Вы должны убедиться, что Ваши соответствующие серверы, связанные с PCI настроены на запрет Secure Sockets Layer (SSL) версии 2 и «слабого» кодирования. Вы также должны поддерживать ежеквартальное PCI сканирование на наличие уязвимости безопасности. Без отключения SSLv2 Вы почти гарантированно не пройдете это сканирование. В свою очередь это приведет к не соответствию PCI DSS вместе с вытекающими последствиями и рисками.

Поддерживает ли Ваш сервер SSLv2?

У Вас должно быть установлено OpenSSL, чтобы Вы могли провести тестирование. После установки используйте следующую команду для тестирования Вашего сервера (предполагая, что https соединение используется на порте 443):

# openssl s_client -ssl2 -connect SERVERNAME:443

# openssl s_client -ssl2 -connect SERVERNAME:443
CONNECTED(00000003)
458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:

Как настроить Apache v2 на запрет SSLv2 соединений:


Вам нужно будет изменить директиву SSLCipherSuite в файле httpd.conf или ssl.conf.
Примером может служить редактирование следующих строк на:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
«Enabled»=dword:00000000

Перезапустите систему и убедитесь, что сервер функционирует. Также повторно проведите тестирование с использованием OpenSSL, чтобы убедиться, что SSLv2 больше не принимаются.

Слабое SSL кодирование

Поддерживает ли Ваш сервер слабое SSL кодирование
Как узнать:

У Вас должно быть установлено OpenSSL, чтобы Вы могли провести тестирование. После установки используйте следующую команду для тестирования Вашего сервера (предполагая, что https соединение используется на порте 443):

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP

# openssl s_client -connect SERVERNAME:443 -cipher LOW:EXP
CONNECTED(00000003)
461:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226:

Перезапустите систему и убедитесь, что сервер функционирует. Также повторно проведите тестирование с использованием OpenSSL, чтобы убедиться, что слабое кодирование больше не принимается.



Как настроить Microsoft IIS на запрет слабого SSL кодирования:
Вам нужно будет изменить реестр системы.
Соедините следующие ключи в реестре Windows:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]
«Enabled»=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
«Enabled»=dword:00000000

Перезапустите систему и убедитесь, что сервер функционирует. Также повторно проведите тестирование с использованием OpenSSL, чтобы убедиться, что слабое кодирование больше не принимается..

Если Вы произвели указанные выше изменения, то при ASV(Approved Scanning Vendor) сканировании не выявятся следующие уязвимости:

  • SSL сервер поддерживает слабое кодирование
  • SSL сервер разрешает Cleartext кодирование
  • SSL сервер может быть вынужден использовать слабое кодирование
  • SSL сервер разрешает анонимную аутентификацию

Шифрование

Тем не менее, положение дел меняется при использовании кредитной карточки в интернете, или если вы являетесь принимающей стороной транзакции кредитной карты. В этих случаях одна лишь анонимность не обеспечит должного уровня безопасности. Более того, при получении секретного документа вы на сто процентов уверены в том, что его отправил именно тот человек, за которого себя выдает реальный отправитель? Что между отправкой и получением этот документ не был каким-то образом изменен? Что делать для защиты секретных данных на сайте или при передаче пользователю? Как реализовать более надежную аутентификацию пользователя?

О цифровых сертификатах

IIS использует цифровые сертификаты для реализации должного уровня защиты и поддерживает метод SSL -шифрования/аутентификации на веб-сайтах.

Используются три типа сертификатов.

  • Сертификаты сервера. Обеспечивают метод шифрования данных, передаваемых через сеть (посредством SSL), и методы идентификации для сервера. Эти методы дают клиенту уверенность в том, что сайт, который он посетил, является именно тем сайтом, за который он себя выдает.
  • Сертификаты клиента. Обеспечивают идентификацию клиента на сервере, что позволяет серверу определить, кем на самом деле является клиент. Это более мощная аутентификация по сравнению с базовой. Сертификаты клиентов не поддерживают шифрование данных.
  • Сертификаты подписывания кода. Обеспечивают метод цифрового «подписывания» приложения посредством цифрового идентификатора, созданного на основе содержимого приложения. Если в приложении происходят какие-либо изменения, то цифровой идентификатор становится не соответствующим этому приложению, о чем пользователь получает уведомление. Сертификаты подписывания кода не поддерживают шифрование приложения.

Ключи сертификатов

Цифровые сертификаты используют ключи при шифровании данных. Чтобы понять, каким образом работают цифровые сертификаты, необходимо знать, что такое ключи и для чего они предназначены.

Примечание. Ключ – это фрагмент данных, используемый шифром для преобразования открытого текста в шифрованный текст. Шифром является математический алгоритм, выполняющий шифрование или дешифрование данных.

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

  • Шифрование на симметричном ключе. Для шифрования и расшифровки данных используется один и тот же ключ. Эта форма шифрования более эффективна с точки зрения скорости. При этом обеспечивается некоторый уровень безопасности, поскольку принимающая сторона должна знать ключ для расшифровки информации. Главным недостатком шифрования на симметричном ключе является то, что при вскрытии ключа злоумышленник сможет расшифровать данные. Он даже сможет зашифровать их и отправить принимающей стороне, выдав себя за легитимного отправителя.
  • Шифрование на открытом ключе. Более сложный процесс с точки зрения использования ключей. IIS предоставляет на выбор два алгоритма шифрования на открытом ключе – DH (Diffie-Hellman) и RSA (сокр. от имен разработчиков Ron Rivest, Adi Shamir и Leonard Adleman). RSA используется чаще всего, поэтому в данной лекции мы рассмотрим именно этот алгоритм. При шифровании на открытом ключе создается пара ключей – открытый ключ и секретный ключ.

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

Секретный ключ, разумеется, необходимо содержать в секрете. Его можно использовать для подписывания данных с целью подтверждения подлинности. Открытый ключ используется для проверки подлинности подписи и установления возможных искажений данных. Если данные зашифрованы при помощи секретного ключа, то без открытого ключа их не сможет расшифровать даже тот человек, который их зашифровал. Опять-таки, поскольку секретный ключ находится только у владельца, то данные являются подлинными. В противном случае, только владелец секретного ключа может просмотреть данные.

По сравнению с шифрованием на симметричном ключе шифрование на открытом ключе требует выполнения большего объема работы и является не столь эффективным. При шифровании больших объемов данных использование этого метода отрицательно сказывается на производительности. Тем не менее, можно использовать шифрование на открытом ключе для зашифровки симметричного ключа, после чего применить более эффективное симметричное шифрование для зашифровки остальных данных. Именно этот процесс лежит в основе функционирования SSL.

Мощность шифрования

Мощность шифрования зависит от длины ключа и типа шифра, используемого для шифрования. Сообщения, созданные при помощи 128-битного ключа, взломать в 3х10 26 раз сложнее, чем сообщения, созданные при помощи 40-битного ключа. Это в некоторой степени объясняет то, почему правительство США раньше не разрешало экспортировать технологию, поддерживающую ключи длиной более 40 бит. В целях безопасности, правительство США отталкивалось от того факта, что оно сможет дешифровать перехваченные зашифрованные данные. Это гораздо сложнее сделать при использовании 128-битных ключей! Многое зависит и от того, какой именно шифр используется при шифровании данных. Например, данные, зашифрованные при помощи симметричного шифра (например, шифра DES – Data Encryption Standard ) с применением 64-битного ключа, сопоставимы по уровню защищенности с сообщением, зашифрованным при помощи RSA на ключе длиной в 512 бит.

Примечание. В настоящее время правительство США разрешает экспорт 128-битных шифров во все страны, на которые не наложено соответствующее эмбарго.

Цифровые подписи

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

Односторонний хэш. Односторонний хэш (иногда называется анализом сообщения) представляет собой набор данных для проверки полученного документа на предмет того, что он не был изменен с момента создания хэша. Алгоритм одностороннего хэша создает для документа набор уникальных данных. Документ отправляется вместе с созданным односторонним хэшем. При получении документ повторно обрабатывается алгоритмом хеширования . Новый хэш сопоставляется с хэшем, полученным вместе с документом. Если выявляются различия, то это означает, что документ был искажен. Добавление в документ одного-единственного символа или пробела основательно изменит результирующий хэш. Не существует способа восстановления документа только из одного хэша, по этой причине хэш и называется односторонним. Наиболее распространенными алгоритмами одностороннего хэширования являются алгоритм обработки сообщений MD5, созданный профессором института MIT Роном Ривестом (соавтором алгоритма шифрования RSA), и алгоритм безопасного хэширования SHA , разработанный Национальным институтом стандартов и технологий США ( NIST ) и Управлением национальной безопасности США ( NSA ). Алгоритм MD5 генерирует 128-битное значение, а алгоритм SHA – 160-битное.

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

При шифровании одностороннего хэша, уникального для отправляемых данных, на секретном ключе создается цифровая подпись. Ее расшифровывают для подтверждения подлинности вашей личности, а односторонний хэш сопоставляют со своим экземпляром для подтверждения целостности данных. Таким образом, при помощи цифровых подписей, мы «убиваем сразу двух зайцев».

Бюро сертификатов и доверие. Как убедиться в том, что открытый ключ, используемый для шифрования отправляемых данных, заслуживает доверия? Когда пользователь создает пару ключей открытый/секретный для использования на веб-сайте, он, по существу, запрашивает сертификат SSL x.509 (x.509 является стандартом, определенный в RFC 2459) у бюро сертификатов (т.е. у сервера, выпускающего сертификаты). Бюро сертификатов может авторизовать (уполномочить) любое количество подчиненных бюро сертификатов, те, в свою очередь, – другие бюро сертификатов и т.д. Первое бюро сертификатов в этой цепочке называется корневым бюро сертификатов. Возможно наличие только одного корневого бюро сертификатов в цепочке. При выпуске сертификата SSL создающее его бюро сертификатов проверяет корректность информации, отправленной запрашивающей стороной. Подробности этой проверки индивидуальны для каждого бюро сертификатов.

Использование бюро сертификатов на компьютере клиента

Предположим, на компьютере клиента установлен набор сертификатов по умолчанию; выпустившие их бюро сертификатов являются доверенными. Набор установленных сертификатов зависит от используемого программного обеспечения (например, Internet Explorer или Netscape). При представлении клиенту сертификата SSL клиент выяснит, имеется ли в его кэше соответствующий сертификат. При наличии сертификата клиент проверит подпись бюро сертификатов при помощи открытого ключа, находящегося в кэше, осуществив таким образом аутентификацию веб-сервера. Если сертификат в кэше отсутствует, клиент запросит сертификат, после чего повторит проверку сертификата рассматриваемого бюро. Если сертификат не пройдет аутентификацию в корневом бюро сертификатов, будет сгенерировано предупреждение о том, что проверить сертификат SSL не удалось и принимать его не следует. В любом случае, если будет найдено бюро сертификатов, сертификат которого содержится в вашем кэше, сертификат SSL будет принят.

Проверка списка бюро сертификатов браузера. Можно просмотреть список бюро сертификатов, являющихся доверенными для браузера. Рассмотрим на примере Internet Explorer 6. Выполните следующие действия.

  1. В Internet Explorer выберите Tools\Internet Options (Сервис\Свойства браузера).
  2. Откройте вкладку Content (Содержание).
  3. В области Certificates (Сертификаты) нажмите на кнопку Certificates (Сертификаты).
  4. В окне Certificates (Сертификаты) (см. рис. 10.1) откройте вкладку Trusted Root Certification Authorities (Доверенные корневые бюро сертификатов); здесь присутствует перечень доверенных корневых бюро сертификатов.

Добавление бюро сертификатов в список доверия браузера. При посещении сайта, использующего сертификат бюро сертификатов, которое не пользуется доверием вашего браузера, отобразится соответствующее сообщение. Можно принять сертификат и продолжить работу через безопасное соединение. Продолжая шифровать данные, вы в этом случае проигнорируете одну из главных функций сертификатов – аутентификацию. При принятии сертификата от бюро сертификатов, не пользующимся доверием, скорее всего, для вас не имеет значения это бюро сертификатов и вы просто хотите выполнить транзакцию. При наличии других методов проверки бюро сертификатов этот подход приемлем. Если вы доверяете бюро сертификатов, отсутствующему в списке доверия браузера (например, бюро сертификатов компании, в которой вы работаете), то доверенный сертификат можно добавить в браузер. В следующий раз предупреждения отображаться уже не будут.

Для добавления доверенного корневого бюро сертификатов в Internet Explorer выполните следующие действия.

Что такое код iis шифрование

1 xx — оповещение

Перечисленные ниже коды состояния обозначают предварительный ответ. Перед получением окончательного ответа клиент может получить один или несколько ответов с кодами состояния 1xx.

  • 100 — продолжение.
  • 101 — смена протоколов.

2 xx — запрос принят

Коды этой категории показывают, что сервер успешно принял запрос клиента.

  • 200 — ОК. Запрос клиента выполнен успешно.
  • 201 — создано.
  • 202 — принято.
  • 203 — неавторизованные сведения.
  • 204 — содержимое отсутствует.
  • 205 — сброс содержимого.
  • 206 — частичное содержимое.
  • 207 — Множественное состояние (WebDav).

3 xx — перенаправление

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

  • 301 — перемещено навсегда
  • 302 — объект перемещен.
  • 304 — объект не изменялся.
  • 307 — временное перенаправление.

4 xx — ошибка клиента

Данные коды показывают, что возникла ошибка по вине клиента. Например, клиент мог запросить отсутствующую страницу или не предоставить сведения для проверки подлинности.

  • 400 — неверный запрос.
  • 401 — доступ запрещен. Если возникает ошибка с кодом 401, то службы IIS возвращают расширенный код, указывающий причину ошибки. Эти коды ошибок отображаются на экране браузера, но не регистрируются в журнале служб IIS.
    • 401.1 — ошибка входа.
    • 401.2 — вход не выполнен из-за настройки сервера.
    • 401.3 — доступ запрещен списком управления доступом к ресурсу.
    • 401.4 — доступ запрещен фильтром.
    • 401.5 — авторизация не выполнена из-за приложения ISAPI/CGI.
    • 401.7 — доступ запрещен политикой авторизации URL-адресов на веб-сервере. Данный код поддерживается только службами IIS 6.0.
  • 403 — запрет. Если возникает ошибка с кодом 403, то службы IIS возвращают расширенный код, указывающий причину ошибки.
    • 403.1 — доступ на выполнение запрещен.
    • 403.2 — доступ на чтение запрещен.
    • 403.3 — доступ на запись запрещен.
    • 403.4 — требуется SSL.
    • 403.5 — требуется SSL 128.
    • 403.6 — IP-адрес отклонен.
    • 403.7 — требуется сертификат клиента.
    • 403.8 — отказ в доступе к сайту.
    • 403.9 — подключено слишком много пользователей.
    • 403.10 — недопустимая конфигурация.
    • 403.11 — необходим другой пароль.
    • 403.12 — отказ доступа от программы сопоставления.
    • 403.13 — сертификат клиента отозван.
    • 403.14 — вывод каталогов запрещен.
    • 403.15 — достигнуто максимальное число разрешенных одновременных подключений.
    • 403.16 — сертификат клиента поврежден или ненадежен.
    • 403.17 — сертификата клиента недействителен или просрочен.
    • 403.18 — запрос указанного URL-адреса не может быть выполнен в текущем пуле приложений. Данный код поддерживается только службами IIS 6.0.
    • 403.19 — невозможно выполнять приложения CGI для этого клиента в данном пуле приложений. Данный код поддерживается только службами IIS 6.0.
    • 403.20 — вход в систему с помощью служб Passport не выполнен. Данный код поддерживается только службами IIS 6.0.
  • 404 — объект не найден.
    • 404.0 — (отсутствует) — файл или каталог не найден.
    • 404.1 — веб-сайт не доступен по запрошенному порту.
    • 404.2 — запрос отклонен политикой закрытия расширений веб-служб.
    • 404.3 — запрос отклонен политикой сопоставления MIME.
  • 405 — для доступа к странице используется недопустимый метод HTTP (недопустимый метод).
  • 406 — браузер клиента не принимает тип MIME запрашиваемой страницы.
  • 407 — требуется проверка подлинности через прокси-сервер.
  • 412 — необходимое условие не выполнено.
  • 413 — размер запроса слишком велик.
  • 414 — слишком длинный запрос URI.
  • 415 — неподдерживаемый тип носителя.
  • 416 — значение за пределами диапазона.
  • 417 — ошибка при выполнении.
  • 423 — ошибка блокировки.


5 xx — ошибка сервера

Данные коды показывают, что сервер не может выполнить запрос, поскольку при выполнении возникла ошибка.

  • 500 — внутренняя ошибка сервера.
    • 500.12 — приложение на веб-сервере перезапускается.
    • 500.13 — веб-сервер перегружен.
    • 500.15 — запросы на файл Global.asa недопустимы.
    • 500.16 — учетные данные не позволяют выполнить проверку подлинности при подключении к адресу UNC. Данный код поддерживается только службами IIS 6.0.
    • 500.18 — не удается открыть хранилище данных авторизации URL. Данный код поддерживается только службами IIS 6.0.
    • 500.19 — данные для файла в метабазе сконфигурированы неверно.
    • 500.100 — внутренняя ошибка ASP.
  • 501 — значения, указанные в заголовке, определяют нереализованную конфигурацию.
  • 502 — веб-сервером в качестве шлюза или прокси-сервера получен недопустимый ответ.
    • 502.1 — Истекло время ожидания приложения CGI.
    • 502.2 — ошибка в приложении CGI.
  • 503 — служба недоступна. Данный код поддерживается только службами IIS 6.0.
  • 504 — превышен интервал ожидания ответа от шлюза.
  • 505 — неподдерживаемая версия HTTP.

Коды статусов протокола HTTP в IIS и их причины

  • 200 — запрос выполнен успешно. Данный код показывает, что сервер IIS успешно обработал запрос.
  • 206 — частичное содержимое. Это означает, что файл был закачан лишь частично. Можно включить продолжение прерванной загрузки или разбить закачку на несколько потоков.
  • 207 — Множественное состояние (WebDav). Это сообщение появляется перед XML-сообщением, которое содержит несколько различных кодов ответа, в зависимости от того, сколько было сделано подзапросов.
  • 301 — перемещено навсегда Этот и все последующие запросы должны быть направлены на указанный универсальный код ресурса (URI).
  • 302 — найдено. В случае авторизации на основе форм этот ответ зачастую представляется в виде кода «Объект перемещен». Запрашиваемый ресурс временно имеет другой универсальный код ресурса (URI). Поскольку перенаправление могло быть изменено временно, клиенту следует использовать для будущих запросов URI в запросе. Этот ответ снабжается кэшем только если это отмечено в заголовке поля «Cache-Control» или «Expires».
  • 304 — объект не изменялся. Клиент запросил документ, который имеется в кэше клиента и не изменялся после кэширования. Клиент использует кэшированную копию документа вместо скачивания его с сервера.
  • 401.1 и 401.2 — вход в систему не выполнен. Попытка входа оказалась неудачной, так как имя пользователя или пароль неверны или из-за проблемы с конфигурацией системы.
  • 401.3 — доступ запрещен списком управления доступом к ресурсу. Появление данного кода свидетельствует о проблеме с разрешениями NTFS. Эта ошибка возникает, даже если разрешения для открываемого файла настроены надлежащим образом. Например, она возникает, если для учетной записи IUSR не настроен доступ к каталогу C:\Winnt\System32\Inetsrv. Дополнительные сведения об устранении данной ошибки см. в следующих статьях базы знаний Майкрософт:
  • 404.1 — веб-сайт не доступен по запрошенному порту. Эта ошибка означает, что у запрашиваемого веб-сайта IP-адрес, который не принимает запросы по порту, на который пришел запрос. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

1 xx — положительный предварительный ответ

Данный код состояния говорит о том, что выполнение действия началось успешно, но перед переходом к новой команде клиент должен дождаться следующего ответа.

  • 110 Значение маркера повторного запуска.
  • 120 Служба будет готова через nnn мин.
  • 125 Соединение для передачи данных уже установлено; передача данных начата.
  • 150 Состояние файла проверено. Сервер готов к установке соединения для передачи данных.

2 xx — оповещение о выполнении команды

Действие завершилось успешно. Клиент может выполнять следующую команду.

  • 200 Команда выполнена успешно.
  • 202 Команда не реализована. На данном сайте команда не требуется.
  • 211 Состояние системы или справка по системе.
  • 212 Состояние каталога.
  • 213 Состояние файла.
  • 214 Справочное сообщение.
  • 215 ИМЯ тип системы, где ИМЯ — официальное имя системы в соответствии с документом о присвоении номеров.
  • 220 Система готова обслуживать нового пользователя.
  • 221 Служба разрывает управляющее соединение. Если необходимо, будет произведен выход из системы.
  • 225 Соединение для передачи данных установлено; передача не выполняется.
  • 226 Соединение для передачи данных разрывается. Требуемое действие выполнено (например, передача или прекращение передачи файла).
  • 227 Выполняется вход в пассивный режим (h1,h2,h3,h4,p1,p2).
  • 230 Пользователь вошел в систему. Производится обработка.
  • 250 Требуемое действие завершено успешно.
  • 257 Создана папка «ПУТЬ».

3 xx — положительный промежуточный ответ

Команда выполнена успешно, но для завершения обработки запроса серверу требуются дополнительные сведения от клиента.

  • 331 Имя пользователя получено. Необходимо ввести пароль.
  • 332 Необходима учетная запись для входа в систему.
  • 350 Для выполнения запрашиваемого действия требуются дополнительные данные.

4 xx — промежуточный отрицательный ответ

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

  • 421 Служба недоступна. Управляющее соединение разрывается. Такое сообщение может прийти в ответ на какую-либо команду, если служба должна завершить работу.
  • 425 Не удается установить соединение для передачи данных.
  • 426 Соединение разорвано; передача прекращена.
  • 450 Требуемое действие не выполнено. Файл недоступен (например, он может быть занят).
  • 451 Выполнение требуемого действия прервано. Во время выполнения возникла локальная ошибка.
  • 452 Требуемое действие не выполнено. Системе не хватает места на диске.

5 xx — окончательный отрицательный ответ

При выполнении команды возникла ошибка. Она носит постоянный характер. Если клиент повторит команду, при ее выполнении возникнет такая же ошибка.

  • 500 Синтаксическая ошибка. Команда не распознана. Одной из ее причин может быть использование слишком длинных команд.
  • 501 Синтаксическая ошибка в аргументах или параметрах.
  • 502 Команда не реализована.
  • 503 Ошибочная последовательность команд.
  • 504 Для данного параметра команда не реализована.
  • 530 Не выполнен вход в систему.
  • 532 Необходима учетная запись для сохранения файлов.
  • 550 Требуемое действие не выполнено. Файл недоступен (например, не найден или к нему нет доступа).
  • 551 Выполнение требуемого действия прервано. Неизвестный тип страницы.
  • 552 Выполнение требуемого действия прервано. Превышен максимально допустимый объем места на диске (в текущем каталоге или наборе данных).
  • 553 Требуемое действие не выполнено. Недопустимое имя файла.

Основные коды состояния FTP и их описание

  • 150 — протокол FTP использует два порта: порт 21 для передачи команд и 20 — для передачи данных. Код состояния 150 показывает, что сервер подключится к порту 20 для передачи данных.
  • 226 — команда используется для подключения к порту 20, чтобы выполнить какие-либо действия (например, передать файл). Данное действие завершено успешно. Подключение для передачи данных разорвано.
  • 230 — сообщение с этим кодом появляется после отправки клиентом правильного пароля. Данный код состояния показывает, что пользователь вошел в систему.
  • 331 — сообщение с этим кодом появляется после отправки клиентом имени пользователя. Это сообщение появляется независимо от того, присутствует ли в системе указанное имя пользователя.
  • 426 — команда используется для подключения к порту 20, чтобы выполнить какое-либо действие, однако действие отменено, а подключение для передачи данных — разорвано.
  • 530 — этот код состояния показывает, что пользователь не может войти в систему, так как введена ошибочная комбинация имени пользователя и пароля. Если для входа в систему используется учетная запись пользователя, то такое сообщение может появляться, если имя пользователя или пароль введены неправильно или если в систему могут входить только анонимные пользователи. Если для входа в систему используется анонимная учетная запись, сообщение может появляться, когда службы IIS настроены на отклонение анонимных пользователей.
  • 550 — команда не выполнена, поскольку требуемый файл недоступен. Это сообщение может появляться при попытке получить отсутствующий файл с помощью команды GET или при использовании команды PUT для сохранения файла в каталоге, для которого отсутствует доступ на запись.

1xx: Informational (Информационные).
100 Continue (Продолжать).
101 Switching Protocols (Переключение протоколов).
102 Processing (Идёт обработка).

2xx: Success (Успешно).
200 OK (Хорошо).
201 Created (Создано).
202 Accepted (Принято).
203 Non-Authoritative Information (Информация не авторитетна).
204 No Content (Нет содержимого).
205 Reset Content (Сбросить содержимое).
206 Partial Content (Частичное содержимое).
207 Multi-Status (Многостатусный).
226 IM Used (IM использовано).

3xx: Redirection (Перенаправление).
300 Multiple Choices (Множество выборов).
301 Moved Permanently (Перемещено окончательно).
302 Found (Найдено).
303 See Other (Смотреть другое).
304 Not Modified (Не изменялось).
305 Use Proxy (Использовать прокси).
306 (зарезервировано).
307 Temporary Redirect (Временное перенаправление).

4xx: Client Error (Ошибка клиента).
400 Bad Request (Плохой запрос).
401 Unauthorized (Неавторизован).
402 Payment Required (Необходима оплата).
403 Forb /> 404 Not Found (Не найдено).
405 Method Not Allowed (Метод не поддерживается).
406 Not Acceptable (Не приемлемо).
407 Proxy Authentication Required (Необходима аутентификация прокси).
408 Request Timeout (Время ожидания истекло).
409 Conflict (Конфликт).
410 Gone (Удалён).
411 Length Required (Необходима длина).
412 Precondition Failed (Условие «ложно»).
413 Request Entity Too Large (Размер запроса слишком велик).
414 Request-URI Too Long (Запрашиваемый URI слишком длинный).
415 Unsupported Media Type (Неподдерживаемый тип данных).
416 Requested Range Not Satisfiable (Запрашиваемый диапазон не достижим).
417 Expectation Failed (Ожидаемое не приемлемо).
418 I’m a teapot (Я — чайник).
422 Unprocessable Entity (Необрабатываемый экземпляр).
423 Locked (Заблокировано).
424 Failed Dependency (Невыполненная зависимость).
425 Unordered Collection (Неупорядоченный набор).
426 Upgrade Required (Необходимо обновление).
449 Retry With (Повторить с. ).
456 Unrecoverable Error (Некорректируемая ошибка. ).

5xx: Server Error (Ошибка сервера).
500 Internal Server Error (Внутренняя ошибка сервера).
501 Not Implemented

Удалённое исполнение кода в IIS под Windows через HTTP-запрос

Xakep #246. Учиться, учиться, учиться!

В сетевом стеке HTTP.sys для серверных Windows обнаружена критичная уязвимость, из-за которой HTTP.sys неправильно обрабатывает специальным образом составленные HTTP-запросы, вызывая DoS или удалённое исполнение кода.

Microsoft выпустила справочный бюллетень MS15-034, в котором присвоила уязвимости самый высокий уровень опасности и перечисляет подверженные ей операционные системы: Windows 7, Windows Server 2008 R2, Windows 8 и Windows 8.1, Windows Server 2012 и Windows Server 2012 R2,

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

При получении такого запроса Windows выводит сообщение об ошибке, а компьютер прекращает работу со странным сообщением.

Независимые исследователи приводят код эксплоита. Он осуществляет сканирование системы, чтобы вызвать переполнение буфера и проверить, уязвима система или нет.

Это можно заменить командой curl.

Вероятно, грамотная эксплуатация позволит запускать на уязвимой системе произвольный код. Этот факт упоминается и в бюллетене безопасности Microsoft.

Уязвимости присвоен классификатор CVE-2015-1635.

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

Одним из элементов безопасности современного предприятия является использование защищенных каналов связи. Защищенные каналы связи позволяют предотвратить несанкционированный просмотр и изменение данных. Одним из наиболее популярных протоколов, реализующих защищенный канал, является протокол SSL . Данная статья описывает, как можно использовать протокол SSL при работе с web -сервисами «1С:Предприятия».

SSL ( Secure Socket Layer ) — протокол, использующийся для обеспечения защищенного взаимодействия между клиентом и сервером. SSL базируется:

· на в заимной аутентификации клиента и сервера для того, чтобы и клиент, и сервер были уверены в том, что они те, за кого себя выдают;

· цифровых подписях, для обеспечения целостности данных (защиты данных от несанкционированного изменения);

· шифровании, для обеспечения конфиденциальности данных (защиты данных от несанкционированного просмотра).

SSL — протокол поддерживает различные варианты шифров, цифровых подписей, сертификатов и т. д. для того, чтобы наиболее адекватно обеспечить защищенный канал требуемой стойкости.

SSL — протокол использует SSL — сессию для установки защищенного соединения между клиентом и сервером. Сессия устанавливается путем обмена между клиентом и сервером последовательностью сообщений. При установке сессии могут выполняться такие действия, как:

· у становка алгоритмов шифрования, которые будут использоваться для шифрования и цифровой подписи передаваемых данных;

· установка сессионного ключа;

· аутентификация сервера на клиенте;

· аутентификация клиента на сервере.

SSL — сессия может быть переиспользована между клиентом и сервером.

Для выполнения аутентификации клиента на сервере и сервера на клиенте SSL использует сертификаты. Сертификат является документом, в котором описывается набор параметров того, для кого выполняется аутентификация. Например, сертификат может содержать имя пользователя или имя веб-сайта сервера. Сертификат также имеет цифровую подпись, которая используется для проверки его валидности. Для предотвращения возможности неконтролируемой выдачи сертификатов используются цепочки сертификатов. Началом цепочки сертификатов выступает Центр Сертификации — организация, занимающаяся выдачей сертификатов. Если определенному пользователю требуется сертификат, он посылает запрос в Центр Сертификации на выдачу сертификата. Центр Сертификации выдает готовый сертификат путем подписывания запроса собственным закрытым ключом. Пользователь, которому выдан сертификат, может, в свою очередь, выступать в качестве Центра Сертификации для других пользователей. Т. е. образуется цепочка сертификатов, корнем которой является корневой Центр Сертификации, как правило, общеизвестная организация. Чтобы клиент принял данный сертификат, он должен быть в списке сертификатов, которым доверяет этот клиент. В списке может быть как сам сертификат, так и любой сертификат из цепочки сертификатов данного сертификата. Как правило, это сертификат корневого Центра Сертификации.

Одним из наиболее общеупотребимых применений протокола SSL является его использование для передачи HTTP -запросов ( HTTPS — протокол). В этом случае URL — схема адресации для таких ресурсов — https , а порт по умолчанию – 443.

Механизм web -сервисов «1С:Предприятия» позволяет как использовать, так и реализовывать https web -сервисы.

Клиентская часть механизма web -сервисов автоматически по URL -схеме ( https ) расположения web -сервиса определяет, что взаимодействие с таким web -сервисом должно вестись по защищенному каналу связи. Клиентская часть также требует, чтобы с сервером был связан валидный сертификат, выданный известным клиенту Центром Сертификации.

Сертификат сервера является валидным, если его цифровая подпись соответствует содержимому сертификата, его дата действия не просрочена и веб-сайт, на который выдан данный сертификат, соответствует веб-сайту сервера. Если сертификат не является валидным, например, веб-сайт сертификата не соответствует веб-сайту сервера, то клиент не сможет взаимодействовать по протоколу SSL с web -сервисами этого сайта.

Чтобы сертификат сервера был принят клиентом, нужно поместить его или сертификат Центра Сертификации, выдавшего данный сертификат сервера, в файл cacert . pem , который находится в каталоге bin «1С:Предприятия». В этом файле перечислены все сертификаты, которым доверяет данный клиент. Файл имеет формат PEM ( Privacy Enhanced Mail ) — текстовый формат, в котором сертификаты закодированы в base 64 последовательности.

https web -сервисы разрабатываются так же, как и обычные http web -сервисы, но требуют дополнительной настройки веб-сервера. Для IIS веб-сервера настройка заключается в привязке к веб-сайту серверного сертификата и настройке виртуальной директории web -сервиса. Серверный сертификат может быть получен от Центра Сертификации, в качестве которого может выступать любой Windows Server 2003 с установленным сервисом сертификатов. После того как сертификат связан с веб-сайтом, для виртуальной директории web -сервиса нужно указать, что доступ к ней осуществляется по защищенному каналу связи (см. документацию по IIS ).

Для Apache web -сервера также нужно указать серверный сертификат и признак работы по защищенному каналу. Сертификат может быть получен при помощи утилиты openssl (см. документацию по mod _ ssl ).

Идентификация и отключение слабых наборов шифров Сервер Windows 2008/IIS 7

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

Результат сканирования безопасности до развертывания веб-приложения на сервере Windows 2008 R2 поднял следующее сообщение:

Переконфигурируйте сервер, чтобы избежать использования слабых наборов шифров. изменения конфигурации зависят от сервера.

SSLCipherSuite HIGH: MEDIUM:! MD5! EXP:! NULL:! LOW:! ADH

Для Microsoft Windows Vista, Microsoft Windows 7 и Microsoft Windows Server 2008 удалите набор шифров, которые были идентифицированы как слабых из списка поддерживаемых шифров, следуя этим инструкции:

Я пробовал недооценивать информацию msdn, но я полностью потерялся там.

Прежде всего, я не понимаю, что это шифровой набор, который следует удалить или отключить.

а затем, как я предполагаю запустить код, приведенный в качестве примера, для удаления набора шифров?

снова извините за полное отсутствие знаний здесь!

Что такое код iis шифрование

Стандартные возможности аутентификации Internet Information Server (IIS), анонимный доступ, методы аутентификации, учетная запись IUSR_

Большая часть серверов IIS работает без требований к пользователю аутентифицироваться — то есть в режиме анонимного доступа. На самом деле такие анонимные пользователи работают от имени специальной учетной записи IUSR _имя_компьютера. Конечно же, настоятельно не рекомендуется использовать эту учетную запись для каких-то других целей, добавлять ее в другие группы (кроме группы Guests ), в которой эта учетная запись находится по умолчанию и т.п.

Однако в некоторых ситуациях анонимным доступом не обойтись. Обычно аутентификация требуется в двух случаях:

1) когда на Web -сервере находятся ресурсы, доступ к которым нужен не всем пользователям (проще говоря, чтобы задействовать систему разрешений);

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

Аутентификация в IIS , к сожалению, полностью основывается на системе безопасности Windows . Фактически мы можем предоставить доступ только тем пользователям, для которых у нас создана локальная учетная запись (или доменная учетная запись, если компьютер с IIS входит в домен). Конечно, по этой причине доступ на IIS со стандартными средствами можно предоставлять только пользователям локальной сети (или, например, очень ограниченному числу внешних партнеров). Рассчитывать на организацию системы аутентификации для пользователей из Интернета стандартными средствами не приходится (поскольку для каждого пользователя учетную запись Windows не создашь). Обычно для таких целей используются или самостоятельно созданные Web -приложения, или специальные надстройки на IIS , которые обеспечивают отдельную, независимую от Windows систему аутентификации. Ниже будет рассмотрены стандартные возможности аутентификации, а затем — дополнительные средства других производителей.

Настройку аутентификации стандартными методами предписывается производить из консоли Internet Information Services Manager -> свойства Web -сайта -> вкладка Directory Security -> кнопка Edit в группе Authentification and Access Control . При нажатии на эту кнопку открывается окно Authentification Method , в котором и производятся настройки параметров аутентификации. В этом окне вы можете:

  • разрешить или запретить анонимный доступ на Web -сайт и выбрать учетную запись, которая будет использована для этой цели;
  • выбрать методы аутентификации, которые могут быть использованы для доступа на Web -сервер.

О методах аутентификации необходимо рассказать подробнее:

  • IntegratedWindowsAuthentification — единственный метод (кроме анонимного доступа), доступный по умолчанию. При использовании этого метода используются те же хэши NTLM (или Kerberos — negotiate для Windows 2000/ XP /2003), что и при обычной аутентификации в Windows (например, при обращении к файлам на файл-сервере). Конечно, ни один броузер, кроме Internet Explorer , такой аутентификации не поддерживает. Необходимо отметить, что, если прав учетной записи IUSR недостаточно (или анонимный доступ вообще отключен) следующее, что делает Internet Explorer — отсылает NTLM -хэш (его версия зависит от версии операционной системы) текущей учетной записи на сервер IIS . Если аутентификация не прошла (или прошла, но у учетной записи не оказалось прав на Web -ресурс), то открывается всплывающее окно аутентификации, в котором пользователь имеет возможность ввести данные другой учетной записи;
  • DigestAuthentification — сравнительно новая технология (появилась только в Windows 2000/ IIS 5.0), основанная на открытых Интернет-стандартах (алгоритм хэширования MD 5 и RFC 2617). При использовании этого метода аутентификации сервер посылает специальную случайную последовательность символов — nonce — клиенту (для каждого сеанса она будет сгенерирована заново). Клиент принимает эту последовательность, на основе ее и своего пароля генерирует хэш по алгоритму MD 5 и пересылает ее серверу. Сервер, который производит такую же операцию и сравнивает полученные значения. Главной проблемой применения этого метода аутентификации является то, что IIS должен получить доступ к открытым паролям пользователей, которых по умолчанию нет и на контроллерах домена. Таким образом, чтобы этот метод аутентификации заработал, необходимо для учетных записей пользователей установить параметр » Store password using reversible encryption «, что обычно в защищенных сетях недопустимо.
  • BasicAuthentification — самый простой тип аутентификации, который поддерживается практически всеми броузерами. При этом имя пользователя и пароль посылаются почти открытым текстом (на самом деле они кодируются, во избежание попадания служебных символов, по алгоритму Base 64). Те менее, конечно, расшифровать эти данные не составит никакого труда — например, при помощи утилиты Base 64 Decoder (она умеет декодировать и некоторые другие форматы) из каталога прочее на компакт-диске. Поскольку передаются таким образом на самом деле имя и пароль учетной записи Windows , то последствия могут оказаться очень серьезными (если в сети запущен сниффер). Безопасно пользоваться этим методом аутентификации можно только при использовании SSL .
  • .NETPassportauthentification — возможность использовать для аутентификации централизованную систему . NET Passport от Microsoft . Не совсем понятно, зачем эта возможность помещена на графический интерфейс IIS Manager — использовать эту возможность могут только участники программы . NET Passport , фактически — очень ограниченный круг крупных Web -коммерсантов. Существует и множество других ограничений при использовании .NET Passport .

Есть и другие методы аутентификации, например, при помощи клиентских сертификатов (этот метод сертификации настраивается при помощи Edit в разделе Secure Certifications и о нем будет рассказано ниже), при помощи серверов RADIUS и смарт-карт, но обычно последние два способа используются в составе комплексных решений для очень защищенных Web -сайтов.

Еще несколько слов об служебных учетных записях и группах, имеющих отношение к IIS :

  • IUSR _имя_компьютера — об этой учетной записи уже говорилось, она предназначена для обеспечения анонимного доступа на сервер IIS и никаких дополнительных прав ей предоставлять не рекомендуется;
  • IWAM_имя_компьютера — еще одна гостевая учетная запись, которой не нужно давать лишние права. От имени этой учетной записи запускаются внешние процессы, порождаемые процессом INETINFO (то есть процессом Web -сервера). Иногда для работы Web 0-приложения этой учетной записи необходимо предоставить дополнительные права, например, на запись в каталог.
  • IIS _WPG — эта группа предназначена для предоставления прав в операционной системе приложениям CGI и ASP . NET , работающим на Web -сервере. Если у вас таких приложений нет, выдавать какие-либо разрешения этой группе не нужно.
  • ASPNET — как понятно из названия, эта учетная запись используется приложениями ASP . NET , работающими на сервере IIS . Если у вас не используется ASP . NET (не установлена как компонент IIS ), то этой учетной записи не будет. Этой учетной записи нужно предоставлять права, например, если приложению ASP . NET необходимо подключаться к SQL Server .

При помощи группы переключателей IP address and domain name restrictions можно также ограничить доступ к сайту по IP -адресам, целым IP -сетям или именам доменов DNS . Обычно такие возможности используются только в Интранет Web -серверах.

Какая информация используется для шифрования web.config в IIS?

Скажем, у меня есть раздел соединения в моем web.config, как это

Я следовать инструкциям здесь , чтобы зашифровать его, и он становится чем — то вроде этого

До сих пор все работает.

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

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

Илон Маск рекомендует:  Что такое код mcal_event_set_recur_monthly_mday
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Примечание.