Создает ли отключение анонимного доступа в IIS угрозу безопасности? - PullRequest
7 голосов
/ 23 марта 2009

Если я сниму флажок , установите флажок «Включить анонимный доступ» в IIS, чтобы защитить сайт паролем, т. Е. Путем ограничения доступа для чтения к назначенным учетным записям Windows, будет ли получающийся диалог пароля, который затем представлен все анонимные http-запросы представляют угрозу безопасности в том смысле, что они (казалось бы) предлагают все и каждый раз неограниченное количество попыток угадать пароль любой учетной записи Windows?

EDIT: Ладно, пока я не рад этому, так что я присваиваю награду. Просто 50 баллов извините, я человек скромных средств. Чтобы прояснить, что мне нужно: предлагает ли отключение анонимного доступа в IIS общественности возможность угадать пароль, которой раньше не было, или это случай, когда диалог учетных данных пользователя в браузере можно смоделировать, включив имя пользователя и пароль в HTTP запрос напрямую, и что ответ будет указывать, была ли комбинация правильной, даже если страница была открыта для анонимных пользователей в любом случае? Кроме того, неверные попытки ввода пароля, отправленные через http, подчиняются той же политике блокировки, применяемой для внутренних входов в систему, и если это так, это представляет собой очень простую возможность преднамеренно заблокировать известные имена пользователей, или, в качестве альтернативы, если нет, есть ли что-либо, что можно сделать чтобы смягчить эту неограниченную возможность подбора пароля?

Ответы [ 4 ]

3 голосов
/ 27 марта 2009

Короткий ответ на ваш вопрос - да. Каждый раз, когда вы предоставляете какой-либо удаленный доступ к любому ресурсу в вашей сети, это представляет угрозу безопасности. Лучше всего будет следовать рекомендациям IIS , а затем принять некоторые собственные меры предосторожности. Переименуйте свой встроенный аккаунт администратора . Применяйте политики надежных паролей. Изменить заголовок сервера . Удаление анонимного доступа, несмотря на риск угадывания пароля, является очень управляемым, если используется с надлежащей многоуровневой моделью безопасности.

2 голосов
/ 31 марта 2009

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

Например, если у вас есть локальная учетная запись «FRED», а политика блокировки учетной записи настроена на 5 недопустимых попыток в течение 30 минут, то это эффективно предотвращает угадывание пароля учетной записи, что может привести к атаке типа «отказ в обслуживании». Однако установка значения окна сброса (15 минут?) Эффективно ограничивает DOS.

  • Базовая аутентификация не рекомендуется для соединений без SSL, так как пароль будет отображаться в виде простого текста.

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

  • Встроенная проверка подлинности Windows включает в себя NTLM и Kerberos.

    • Сервер IIS должен быть настроен с помощью параметров групповой политики или локальной безопасности для отключения аутентификации LM (Сетевая безопасность: для уровня проверки подлинности LAN Manager установлено значение «Отправлять только NTLMv2-ответ» или выше, предпочтительным является «Отправлять только NTLMv2-ответ \» отказаться от LM & NTLM "), чтобы предотвратить тривиальные взломы LM и предотвратить атаки NTLM man in middle proxy.

    • Можно использовать Kerberos, однако он работает только в том случае, если обе машины являются членами одного домена и могут быть доступны DC. Поскольку это обычно не происходит в Интернете, вы можете игнорировать Kerberos.

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

2 голосов
/ 24 марта 2009

Вы должны прочитать о доступных механизмах аутентификации Differentnet: Basic, Digest, NTLM, сертификаты и т. Д. IETF скомпилировал документ , в котором изложены плюсы и минусы некоторых из них (NTLM - собственный протокол MS) ,

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

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

1 голос
/ 27 марта 2009

Я знаю, что я имею в виду гуру хостинга, и я думаю, что есть способы и способы сделать это, но я лично считаю, что то, о чем вы говорите, является вызывающим и ненужным риском для безопасности. Если этот сайт должен быть доступен в Интернете, т. Е. Он будет иметь публичный доступ, то вы, вероятно, не хотите отключать анонимный доступ в IIS.

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...