Несколько областей и несколько TGTs под MIT Kerberos для Windows
Автор той статьи делает огромное предположение о количестве запросов, что "нормальные" веб-приложения могут обработать. Если Ваш сайт находится на выделенном сервере с правильно написанным кодом, он может смочь обработать 1 000 запросов в секунду без потения. Более старый сервер без любого вида оптимизации может только смочь обработать 10 запросов в секунду, прежде чем это начнет прекращать работу. Автор должен был выбрать число для базирования его вычислений на, и 100 походит на разумное место для запуска.
При попытке защитить от или атак с подбором по словарю "в лоб", можно использовать множество методов, таких как точечная коррозия tar, как TessellatingHeckler упомянул, или помещение временных блокировок на учетной записи, как предложено статьей. Я даже видел системы, которые просто проигнорируют запросы от любого IP, который это видит, отправляют запросы выше определенного уровня.
Относительно исходного вопроса, взломщик захочет смочь попробовать как можно больше паролей, не снижая сервер, поэтому не то, чтобы необходимо смочь "защитить от" конкретного количества запросов в секунду, поскольку взломщик будет ограничение скорости их собственные инструменты, если они будут видеть, что он вызывает замедление на сервере, потому что это находится в их интересах не привлечь внимание себе. Просто разработайте свое приложение, чтобы смочь обработать Вашу ожидаемую нормальную нагрузку плюс некоторое разумное поле для роста и случайного скачка в трафике.
Если Вы волнуетесь по поводу универсальных DDos-атак, который является другим разговором полностью и не имеет никакого отношения к запросам в секунду на попытки пароля.
Хорошо, я придумал рабочее решение, которое требует дополнительной доработки, поэтому может работать не во всех средах.
Это работает с:
- MIT Kerberos для Windows 4.0.1 с инструментами поддержки Windows (KSETUP.EXE, KTPASS.EXE)
- PuTTY 0,63
- Windows 7 SP1
Я искал исходный код MIT Kerberos и наткнулся на README для Windows . Особый интерес вызвали различные значения для Credentials Cache . Он поддерживает значение по умолчанию API: , но я неожиданно обнаружил, что мой реестр использует вместо этого MSLSA: .
Я играл с разными значениями ccname под HKEY_CURRENT_USER \ Software \ MIT \ Kerberos5 . Сначала я попробовал MEMORY: , что привело к интересному поведению. При открытии сеанса PuTTY мое окно MIT Kerberos Ticket Manager восстанавливается и выходит на передний план, предлагая мне ввести учетные данные. Вау! Такого никогда не было раньше, но, увы, PuTTY отвергнет это. Значение, которое помогло мне, было FILE: C: \ Some \ Full \ File \ Path . Я не совсем уверен, как защитить доступ к указанному файлу, поэтому оставлю это в качестве упражнения для читателя. У меня было такое же поведение окна на передний план, но на этот раз понравилось только PuTTY. В окне диспетчера билетов также, наконец, были отображены билеты LR и FR. Было доказано, что билеты могут быть переадресованы и выдержат несколько блокировок / разблокировок Windows. ПРИМЕЧАНИЕ: обязательно полностью закройте и перезапустите Ticket Manager между изменениями реестра. Я еще не пробовал ccname из API: .
Я не знаю, имеет ли это значение или нет, но я также поигрался с KSETUP , прежде чем это начало работать. Сначала KSETUP без параметров просто показывал бы мне информацию о LR. Я добавил некоторую информацию о FR на своей локальной рабочей станции.
ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported
Ну, я не скажу, что это НЕ МОЖЕТ быть сделано с Windows, но я скажу, что ограничение зависит от сеанса. Проблема в том, что для каждого сеанса Windows кэширует один билет. Когда вы блокируете свой компьютер, а затем разблокируете его, инициируется другой сеанс, и от KDC запрашивается новый ключ. То же самое происходит, когда вы выйдете из системы, а затем снова войдете в нее. Фактически, этот метод определяет права пользователей и для сеансов сервера, означает, что ключ / билет можно кэшировать, так что каждый инициируемый вами серверный ресурс или сеанс не должен запрашивать ваш пароль, но я никогда не слышал / не читал / не исследовал возможности кэшировать более одного.
Теперь вы, вероятно, уже знаете, что, учитывая ваши знания, что вы ' ve отображается в вашем вопросе, поэтому я скажу, что, исходя из того факта, что Windows хранит ключ, который вы получаете при выдаче TGT, и основан на сеансе, я не думаю, что это возможно с ТОЛЬКО Windows. MIT Kerberos для Windows может иметь способ инициировать два сеанса под одним пользователем, но даже в этом случае я не уверен, как ресурсы, к которым вы обращаетесь, будут знать, какую пару билет / ключ использовать. Имеет ли это смысл?
Пожалуйста, смотрите здесь описание того, как Windows хранит TGT / пары ключей.
Кстати, очень хороший вопрос.
Я не уверен, как ресурсы, к которым вы обращаетесь, будут знать, какую пару билет / ключ использовать. Имеет ли это смысл?Пожалуйста, смотрите здесь описание того, как Windows хранит TGT / пары ключей.
Кстати, очень хороший вопрос.
Я не уверен, как ресурсы, к которым вы обращаетесь, будут знать, какую пару билет / ключ использовать. Имеет ли это смысл?Пожалуйста, посмотрите здесь описание того, как Windows хранит TGT / пары ключей.
Кстати, очень хороший вопрос.
Для меня это выглядит так, как будто на самом деле есть ошибка в Kerberos для Windows.
Я нашел следующее:
Если я использую опцию "получить билет" в окне KfW 4.0.1, это просто работает(TM); я могу нажать кнопку "получить билет" и приобрести дополнительные билеты к оригинальным билетам, которые я получил при входе в систему.
Если я нажму на опцию "сделать билет по умолчанию" в окне KfW, то с этого момента каждый раз, когда я нажимаю "получить билет", новый билет будет заменять любой билет по умолчанию, вместо того, чтобы добавлять еще одну запись в список известных билетов. Проверка реестра в этот момент покажет, что была добавлена запись ccname (как в ответе Тоддиуса). Удаление этой записи, на удивление, восстановит прежнее поведение разрешения нескольких билетов.
После ответа Тоддиуса у меня есть коллега в похожей ситуации (Windows 7 Enterprise 64-bit, присоединен к домену AD, также запущен MIT Kerberos для Windows 4.0.1): Его копия диспетчера Kerberos Ticket Manager позволит ему иметь только один основной/один TGT. Всякий раз, когда он использовал кнопку "Получить Ticket" для получения TGT для другого директора, предыдущий директор исчезал.
Я просмотрел README, и большинство ключей реестра были установлены, как и ожидалось, за исключением для ключа ccname на пути HKEY_CURRENT_USER\Software\MIT\Kerberos5. Этот ключ был установлен на значение MSLSA:. Наше исправление заключалось в изменении этого значения на API:. Точнее, шагом было:
- Выход из Kerberos Ticket Manager вместе со всеми остальными приложениями (так как вы будете перезагружаться).
- На пути реестра
HKEY_CURRENT_USER\Software\MIT\Kerberos5, изменить ccname ключ кAPI:(A-P-I, то двоеточие). - Выход regedit, и перезагрузить.
- После обратного входа в систему запустите Kerberos Ticket Manager и воспользуйтесь кнопкой Get Ticket, чтобы получить TGT вашего не-AD принципала.
С приведенными выше шагами все сработало, и мой коллега теперь может видеть несколько принципов/TGT одновременно.
Кстати, MIT Kerberos для Windows приносит свой собственный набор программ командной строки (например, klist), и эти программы поддерживают несколько кэш-памяти учетных записей. На моей 64-битной системе, когда я запускаю "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A" после получения нескольких TGT, я вижу в MSLSA кэше мою директорию Active Directory principal, а затем у меня есть по одному кэшу API на каждую дополнительную директорию.
P.S. Это моя первая запись на этом сайте, так что я не смог добавить ее в качестве комментария к ответу Тоддиуса. Прошу прощения!