Какая лучшая контрмера для распределенной грубой силы?

152

Во-первых, немного предыстории: не секрет, что я внедряю систему аутентификации + аутентификации для CodeIgniter, и пока я побеждаю (так сказать). Но я столкнулся с довольно нетривиальной задачей (которую большинство библиотек авторизации пропускают полностью, но я настаиваю на правильной ее обработке): как разумно бороться с крупномасштабными, распределенными атаками с переменным именем пользователя методом перебора .

Я знаю все обычные трюки:

  1. Ограничение количества неудачных попыток для каждого IP / хоста и запрет доступа нарушителей (например, Fail2Ban) - что больше не работает, так как ботнеты стали умнее
  2. Комбинируя вышесказанное с черным списком известных «плохих» IP / хостов (например, DenyHosts), который опирается на ботнеты, попавшие на первое место, чего они все чаще не делают
  3. Белые списки IP / хостов в сочетании с традиционной аутентификацией (к сожалению, бесполезны для динамических пользователей IP и большого оттока на большинстве веб-сайтов)
  4. Установка ограничения по количеству неудачных попыток в течение N минут / часов и регулирование (приостановка) всех попыток входа в систему после этого в течение нескольких минут / часов (с проблемой, что атака DoS становится игрой ботнета)
  5. Обязательные цифровые подписи (сертификаты с открытым ключом) или аппаратные токены RSA для всех пользователей без опции логин / пароль (без сомнения, надежное решение, но практично только для закрытых выделенных сервисов)
  6. Принудительные схемы сверхсильных паролей (например,> 25 бессмысленных символов с символами - опять же, слишком непрактично для обычных пользователей)
  7. И, наконец, CAPTCHA (которые могут работать в большинстве случаев, но раздражают пользователей и практически бесполезны против решительного, находчивого злоумышленника )

Теперь это только теоретически осуществимые идеи. Существует множество идей по взлому, которые взрывают сайт широко (например, для обычных DoS-атак). То, что я хочу, это что-то лучше. И под лучшими я имею в виду:

  • Он должен быть защищен (+) от DoS-атак и атак методом перебора, и не должен содержать каких-либо новых уязвимостей, которые могли бы позволить немного хитрому боту продолжить работу под радаром.

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

  • Это должно быть осуществимо для широкого использования в Интернете (т. Е. Высокий отток, большой объем и открытая регистрация, которую могут выполнять непрограммисты)

  • Это не может помешать работе пользователя до такой степени, что случайные пользователи будут раздражены или разочарованы (и потенциально могут покинуть сайт)

  • Это не может включать котят, если они действительно не очень безопасные котята

(+) Под «безопасным» я подразумеваю, по крайней мере, такую ​​же безопасность, как способность параноидального пользователя хранить свой пароль в секрете.

Итак - давайте послушаем это! Как бы вы это сделали ? Знаете ли вы о лучшем опыте, о котором я не упомянул (о, пожалуйста, говорите)? Я признаю, что у меня есть собственная идея (объединяющая идеи из 3 и 4), но я позволю истинным экспертам говорить, прежде чем смущать себя ;-)

Дженс Роланд
источник

Ответы:

69

Ладно, хватит тормозить; вот что я придумала до сих пор

(извините, длинный пост вперед. Будь смелым, друг, путешествие того стоит)

Объединение методов 3 и 4 из исходного поста в своего рода «нечеткий» или динамический белый список, а затем - и вот в чем хитрость - не блокирование IP-адресов, не занесенных в белый список, а просто удушение их в ад и обратно .

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

Предположения о сценарии атаки

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

Поэтому нам нужно сделать что-то еще.

Первая часть контрмеры: Белый список

В чем мы можем быть абсолютно уверены, так это в том, что злоумышленник не может обнаружить и динамически подделать IP-адреса нескольких тысяч наших пользователей (+). Что делает белый список осуществимым. Другими словами: для каждого пользователя мы храним список (хэшированных) IP-адресов, с которых пользователь ранее (недавно) вошел в систему.

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

(+) если злоумышленник не «владеет» ни сервером, ни всеми ящиками наших пользователей, ни самим соединением - и в этих случаях у нас больше не возникает проблема «аутентификации», у нас есть подлинный размер франшизы. Ситуация FUBAR

Вторая часть контрмеры: общесистемное регулирование непризнанных IP-адресов

Для того чтобы белый список работал для веб-службы с открытой регистрацией, где пользователи часто переключают компьютеры и / или подключаются с динамических IP-адресов, нам нужно держать «дверь в кошку» открытой для пользователей, подключающихся с нераспознанных IP-адресов. Хитрость заключается в том, чтобы спроектировать эту дверь так, чтобы ботнеты застревали и таким образом, чтобы законные пользователи беспокоились как можно меньше .

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

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

Что я надеюсь достичь с помощью этого механизма регулирования, так это то, что, если максимальный предел достигнут, наша «кошачья дверь» на некоторое время захлопывается, но наша входная дверь остается открытой для законных пользователей, подключающихся обычными способами:

  • Либо путем подключения с одного из их распознанных IP-адресов
  • Или с помощью постоянного файла cookie для входа (из любого места)

Единственные законные пользователи, которые будут затронуты во время атаки - т.е. в то время как регулирование было активировано - это будут пользователи без постоянных файлов cookie для входа, которые входили в систему из неизвестного местоположения или с динамическим IP-адресом. Эти пользователи не смогут войти в систему, пока не прекратится регулирование (что может занять некоторое время, если злоумышленник продолжит работу ботнета, несмотря на регулирование).

Чтобы позволить этой небольшой группе пользователей протиснуться через запечатанную в противном случае дверь кошки, даже если боты все еще били ее, я бы использовал «резервную» форму входа в систему с CAPTCHA. Чтобы при отображении сообщения «Извините, но вы не можете войти с этого IP-адреса в данный момент», добавьте ссылку « Безопасный резервный вход в систему - ТОЛЬКО ЧЕЛОВЕК ( боты: не лгите ) ». Помимо шутки, когда они щелкают по этой ссылке, дают им аутентифицированную reCAPTCHA форму входа в систему, которая обходит регулирование всего сайта. Таким образом, если они люди и знают правильный логин + пароль (и могут читать CAPTCHA), им никогда не будет отказано в обслуживании, даже если они подключаются с неизвестного хоста и не используют cookie-файл автологина.

Да, и просто для пояснения: поскольку я считаю, что CAPTCHA, как правило, являются злыми, опция входа в систему «резервного копирования» будет появляться только при активном регулировании .

Нет никаких сомнений в том, что подобная устойчивая атака все равно будет представлять собой форму DoS-атаки, но при наличии описанной системы она повлияет только на то, что, как я подозреваю, будет крошечной группой пользователей, а именно на людей, которые не используют cookie «Помни меня» И случается, что он входит в систему во время атаки, И не входит ни с одного из своих обычных IP-адресов И не может читать CAPTCHA. Только те, кто может сказать «нет» ВСЕМ из этих критериев - особенно боты и действительно несчастные люди с ограниченными возможностями - будут отвергнуты во время атаки ботов.

РЕДАКТИРОВАТЬ: На самом деле, я подумал о том, чтобы позволить даже пользователям с CAPTCHA проходить через «блокировку»: вместо или в качестве дополнения к резервному входу в CAPTCHA, пользователь может выбрать одноразовое использование. пользовательский код блокировки, отправленный на его электронную почту, который он затем может использовать для обхода регулирования. Это определенно пересекает мой порог «раздражения», но так как он используется только в качестве крайней меры для небольшого подмножества пользователей, и поскольку он все еще превосходит блокировку вашей учетной записи, это будет приемлемо.

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


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

Дженс Роланд
источник
1
Может быть, вы могли бы сгенерировать «специальный» пароль для каждого пользователя, который мог бы использовать его в режиме блокировки (и они подключаются с нового IP-адреса и т. Д.), Причем этот специальный пароль был достаточно сложным, и его невозможно было взломать?
Дуглас Лидер
1
Это может сработать, но только в том случае, если пользователи запомнят эти пароли, даже если они не использовали их ранее (эти типы атак не являются обычным делом, и ни один ботмастер, достойный его соли, не потрудился бы поддерживать его в течение длительного времени после того, как его удушили). Риск слишком велик, чтобы они просто не могли вспомнить.
Дженс Роланд
1
Тем не менее, один из методов, который может сработать, - предоставить этим пользователям ссылку «отправить мне код блокировки», что позволит им получить электронное письмо, содержащее одноразовый токен пользователя, который позволит им войти в систему, минуя дросселирование.
Дженс Роланд
1
@Abtin: Хорошая идея, за исключением того, что это будет «вступление в гонку вооружений» - т.е. начинать «кто кого может перехитрить» с людьми, которые создают списки паролей для атак по словарю. Я думаю, что лучше всего было бы обеспечить соблюдение строгой политики паролей , так что не нет слабых паролей
Jens Roland
1
@OrestisP .: Вам не хватает точки распределенной атаки - число недопустимых попыток с каждого IP-адреса минимально, поэтому блокировка для каждого IP-адреса не может работать. Кроме того, этот вопрос конкретно описывает автоматизированную атаку грубой силой, поэтому 1) злоумышленник не человек, а ботнет зомби-машин (которые не могут использовать логин с помощью капчи); и 2) атака методом "грубой силы" требует очень большого числа попыток входа в систему, чтобы обеспечить успех, что означает, что вывозить капчу с целью решения проблемы в потовом магазине где-то невозможно (хотя это возможно, если злоумышленник хорошо финансируется и решителен). достаточно).
Дженс Роланд,
17

Несколько простых шагов:

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

Убедитесь, что любой, кто имеет реальную власть на сайте, имеет безопасный пароль. Требовать от администраторов / модераторов иметь более длинные пароли с сочетанием букв, цифр и символов. Отклоните тривиально простые пароли от обычных пользователей с объяснениями.

Одна из самых простых вещей, которую вы можете сделать, это сообщить людям, когда кто-то пытался войти в их учетную запись, и дать им ссылку, чтобы сообщить об инциденте, если это не они. Простое сообщение, когда они входят в систему: «Кто-то пытался войти в вашу учетную запись в 4:20 утра среды бла-бла. Нажмите здесь, если это был не вы». Это позволяет вам вести статистику атак. Вы можете усилить меры контроля и безопасности, если увидите, что количество мошеннических обращений резко возросло.

patros
источник
Прекрасные мысли. Я определенно планировал реализовать автоматическую политику паролей, которая динамически меняется в зависимости от уровня привилегий пользователя. Идея «приманки» может работать для некоторых типов атак, но если атака распределена, блокировка IP-адресов, попадающих под нее, не будет эффективной.
Дженс Роланд
Что касается «времени последней попытки входа в систему», это хорошая стратегия для опытных пользователей (я уверен, что именно поэтому SO это делает), но у нее есть два недостатка: (а) она не решает проблему вторжения, она только сообщает, что это могло произойти, и (б) большинство пользователей просто не помнят / не заботятся
Дженс Роланд
1
Да, honeypot и пользовательские отчеты больше о сборе информации. Они могут предоставить некоторые ценные метрики, чтобы вы знали, если / когда происходит медленная атака грубой силы.
Patros
2
Для приманки, не будет ли лучше рассматривать любое несуществующее имя пользователя как подозрительное, чем просто использовать фиксированный список известных или неправильных имен пользователей? Вы хотели бы избежать блокировки пользователей, которые неправильно набрали свое имя пользователя и не заметили опечатку при повторной попытке ввести пароль несколько раз, но я все же думаю, что есть способы, которые могут быть полезны. Вы даже можете избежать некоторых «ложных срабатываний», создав большой фильтр Блума или подобную структуру данных с вариантами допустимых имен пользователей, имен, фамилий, адресов электронной почты и т. Д. По мере добавления пользователей.
R .. GitHub ОСТАНОВИТЬ ЛЬДА
11

Если я правильно понимаю МО атак грубой силы, то одно или несколько имен пользователей будут пробоваться непрерывно.

Есть два предложения, которые я не видел здесь:

  • Я всегда думал, что стандартной практикой было иметь небольшую задержку (секунду или около того) после каждого неправильного входа в систему для каждого пользователя. Это удерживает грубую силу, но я не знаю, как долго задержка в одну секунду будет сдерживать атаку по словарю. (словарь из 10000 слов == 10000 секунд == около 3 часов. Хм. недостаточно хорошо.)
  • вместо замедления всего сайта, почему бы не использовать имя пользователя. Дроссель становится все более резким с каждой неправильной попыткой (я думаю, до предела, так что реальный пользователь все еще может войти)

Редактировать : в ответ на комментарии к дросселю имени пользователя: это дроссель к конкретному имени пользователя без учета источника атаки.

Если имя пользователя задушено, то может быть обнаружена даже скоординированная атака по имени пользователя (мульти IP, одно предположение на IP, то же имя пользователя). Отдельные имена пользователей защищены дросселем, даже если злоумышленники могут попробовать другого пользователя / пройти в течение тайм-аута.

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

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

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

Дополнительные уточнения:

  • обнаруживать IP-адреса, которые предполагают наличие нескольких учетных записей - 408 Request Timeout
  • обнаруживать IP-адреса, которые используют один и тот же аккаунт - 408 Request Timeout после большого (скажем, 100) числа догадок.

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

  • если вы контролируете настройку пароля, то показ пользователя, насколько надежным является его пароль, побуждает его выбрать лучший.
  • если вы контролируете страницу входа в систему , то после небольшого (скажем, 10) числа предположений об одном имени пользователя предложите CAPTCHA.
jamesh
источник
Регулятор имени пользователя плюс регулятор IP отлично подходит для атак с фиксированным именем или с фиксированным IP, и они делают традиционные атаки по словарю невозможными. Но если злоумышленник постоянно меняет имена пользователей, он проскользнет мимо, не вызывая дросселя имени пользователя. Вот что я хочу противопоставить
Дженс Роланд
2
Спасибо за редактирование, джамеш. Сейчас мы говорим. Мне нравится идея 408. Однако даже при строгом регулировании имени пользователя ботнет, атакующий нескольких пользователей, все равно будет работать. И проверка топ-5000 паролей для одного пользователя МЕНЬШЕ, скорее всего, удастся, чем проверка ТОП-1 пароля на 5000 пользователей
Дженс Роланд
Ничего похожего на парадокс дня рождения. В большой группе многие будут использовать небезопасные пароли, и один, вероятно, будет использовать любой данный популярный. Также будет немало таких людей, как я, которые не будут пойманы такой атакой.
Дэвид Thornley
2
На самом деле, мне, возможно, придется перепроверить математику в моем предыдущем утверждении. Как только вы исключили N самых распространенных паролей, вероятность того, что у пользователя будет пароль # (N + 1), может увеличиться достаточно, чтобы выровнять разницу. Хотя кривая, вероятно, достаточно крутая, чтобы этого не произошло
Дженс Роланд,
9

Существует три фактора аутентификации:

  1. Пользователь что- то знает (т.е. пароль)
  2. У пользователя есть что-то (например, брелок)
  3. Пользователь - это что-то (например, сканирование сетчатки)

Как правило, веб-сайты применяют только политику № 1. Даже большинство банков применяют только политику 1. Вместо этого они полагаются на подход «знает что-то другое» к двухфакторной аутентификации. (IE: пользователь знает свой пароль и девичью фамилию своей матери.) Если вы можете, способ добавить второй фактор аутентификации не слишком сложен.

Если вы можете сгенерировать около 256 символов случайности, вы можете структурировать их в таблице 16 × 16, а затем попросить пользователя указать, например, значение в таблице ячейки A-14. Когда пользователь регистрируется или изменяет свой пароль, дайте ему таблицу и попросите его распечатать и сохранить ее.

Сложность такого подхода заключается в том, что когда пользователь забывает свой пароль, как он хочет, вы не можете просто предложить стандарт «ответьте на этот вопрос и введите новый пароль», поскольку он также уязвим для перебора. Кроме того, вы не можете сбросить его и отправить по электронной почте новый, так как их электронная почта также может быть скомпрометирована. (См .: Makeuseof.com и их украденный домен.)

Другая идея (которая включает в себя котят), это то, что BOA называет SiteKey (я полагаю, они используют торговую марку). Вкратце, у вас есть пользователь, загружающий изображение при регистрации, и когда он пытается войти в систему, попросите его выбрать свое изображение из 8 или 15 (или более) случайных. Таким образом, если пользователь загружает фотографию своего котенка, теоретически только он точно знает, какая картинка у него из всех других котят (или цветов или чего-то еще). Единственная реальная уязвимость, которой обладает этот подход, - это атака «человек посередине».

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

Редактировать, Новая идея:

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

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

davethegr8
источник
Я уверен, что это еще не все, но если идея SiteKey именно то, что вы упомянули, злоумышленник не должен быть MITM, он может просто выполнить две или три попытки входа в систему для этого пользователя и выбрать изображение, которое повторяется среди случайных. Даже если набор из 8-15 картинок статичен для пользователя X,
Дженс Роланд,
(продолжение), вероятно, не будет слишком сложно выбрать правильный, так как люди склонны выбирать предсказуемые типы изображений (даже изображения из их собственных альбомов Flickr!)
Дженс Роланд
2
Да, я подумал о том, что ты поднял вчера вечером после того, как я пошел домой. Я думаю, что способ исправить это: когда пользователь входит в систему и вводит правильный пароль, отображает его изображение и некоторое количество других случайных. Когда они не предоставляют правильный пароль, покажите некоторое количество случайных чисел
davethegr8
1
изображения + 1, которые могут включать или не включать их собственное изображение. Кроме того, у меня была другая идея, см. Редактирование в посте. Но да, эти идеи довольно сложны.
davethegr8
1
Это могло бы сработать, но я вижу пару проблем. Что произойдет, если владелец фотографии удалит изображение? Как вы можете быть уверены, что возвращенные изображения не будут оскорбительными для вашего пользователя? Как пользователь помнит, где он нажал? (Кажется, трудно забыть)
davethegr8
7

Ранее я отвечал на очень похожий вопрос в разделе Как я могу ограничить попытки входа пользователя в PHP . Я повторю предложенное решение здесь, так как я полагаю, что многие из вас найдут его информационным и полезным, чтобы увидеть какой-то реальный код. Пожалуйста, помните, что использование CAPTCHA может быть не лучшим решением из-за все более точных алгоритмов, используемых в настоящее время в бастерах CAPTCHA:

Вы не можете просто предотвратить DoS-атаки, связав регулирование до одного IP-адреса или имени пользователя. Черт, вы даже не можете предотвратить попытки быстрого входа в систему с помощью этого метода.

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

Я уже писал в другом месте, что в идеале вы должны отслеживать все неудачные попытки входа на сайт и связывать их с меткой времени, возможно:

CREATE TABLE failed_logins(
    id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(16) NOT NULL,
    ip_address INT(11) UNSIGNED NOT NULL,
    attempted DATETIME NOT NULL
) engine=InnoDB charset=UTF8;

Определите определенные задержки на основе общего количества неудачных входов в систему за определенный промежуток времени. Вы должны основывать это на статистических данных, извлеченных из вашей failed_loginsтаблицы, так как они будут меняться с течением времени в зависимости от количества пользователей и от того, сколько из них могут вспомнить (и ввести) свой пароль.


10 failed attempts = 1 second
20 failed attempts = 2 seconds
30 failed attempts = reCaptcha

Запросите таблицу при каждой неудачной попытке входа в систему, чтобы найти количество неудачных попыток входа в систему за указанный период времени, скажем, 15 минут:


SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute);

Если количество попыток за указанный период времени превышает ваш лимит, либо принудите регулирование, либо заставьте всех пользователей использовать капчу (т.е. reCaptcha) до тех пор, пока количество неудачных попыток за данный период времени не станет меньше порогового значения.

// array of throttling
$throttle = array(10 => 1, 20 => 2, 30 => 'recaptcha');

// assume query result of $sql is stored in $row
$sql = 'SELECT MAX(attempted) AS attempted FROM failed_logins';
$latest_attempt = (int) date('U', strtotime($row['attempted']));
// get the number of failed attempts
$sql = 'SELECT COUNT(1) AS failed FROM failed_logins WHERE attempted > DATE_SUB(NOW(), INTERVAL 15 minute)';
// assume the number of failed attempts was stored in $failed_attempts
krsort($throttle);
foreach ($throttle as $attempts => $delay) {
    if ($failed_attempts > $attempts) {
        // we need to throttle based on delay
        if (is_numeric($delay)) {
            $remaining_delay = time() - $latest_attempt - $delay;
            // output remaining delay
            echo 'You must wait ' . $remaining_delay . ' seconds before your next login attempt';
        } else {
            // code to display recaptcha on login form goes here
        }
        break;
    }
}

Использование reCaptcha при определенном пороге гарантирует, что атака с нескольких фронтов будет сведена к минимуму, и обычные пользователи сайта не будут испытывать значительную задержку для законных неудачных попыток входа в систему. Я не могу гарантировать гарантию, так как это уже было расширено на то, что CAPTCHA могут быть уничтожены. Существуют альтернативные решения, возможно, вариант «Назови это животное», который вполне может подойти в качестве замены.

Кори Баллу
источник
6

Я должен спросить, провели ли вы анализ затрат и выгод по этой проблеме; Похоже, вы пытаетесь защитить себя от злоумышленника, у которого достаточно присутствия в сети, чтобы угадать количество паролей, отправляя, возможно, 3-5 запросов на IP (так как вы отклонили регулирование IP). Сколько (примерно) будет стоить такая атака? Это дороже, чем стоимость счетов, которые вы пытаетесь защитить? Сколько гигантских ботнетов хочет то, что у тебя есть?

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

ojrac
источник
(Вы хотите сказать, если ответ «нет», т. Е. Затраты на атаку ботнета НЕ слишком велики по отношению к учетным записям)
Дженс Роланд,
Но в любом случае вы затронули важный момент. Что касается моего собственного использования, я не ожидаю, что какой-либо оператор ботнета будет заботиться в меньшей степени, но я выпускаю исходный код для всех, кто хотел бы обеспечить достойную защиту для своего веб-приложения, и я не могу знать, что другие могут пытаться защитить, или кто их враги
Дженс Роланд
Это не будет охранять национальные секреты, несмотря ни на что (официальные системы нуждаются в специальной сертификации, и я совершенно уверен, что ничто, построенное на PHP, не может быть квалифицировано), но все веб-приложения нуждаются в безопасной аутентификации, поэтому, если я выпускаю это, это ' было бы невероятно безответственно не использовать лучшие практики везде, где я могу
Дженс Роланд
1
Итак, мой короткий ответ: я создаю это потому, что 99,9% веб-сайтов и приложений имеют ужасную безопасность (даже в высшей лиге: AOL, Twitter, Myspace и раньше были скомпрометированы), и в большинстве случаев потому, что они используя дрянные библиотеки авторизации.
Дженс Роланд
Также прочитайте статью «Чтобы поймать хищника» Niels Provos et al. из материалов USENIX 2008 года (ссылка: usenix.org/events/sec08/tech/small.html ). Это откровение: 2 месяца, один honeypot: 368 000 атак с почти 30 000 различных IP-адресов, из более чем 5 600 ботнетов!
Дженс Роланд
5

Чтобы обобщить схему Йенса в диаграмме / псевдо-переходе состояния:

  1. пользователь + пароль -> запись
  2. пользователь +! пароль -> отказано
  3. пользователь + known_IP (пользователь) -> входная дверь, // never throttle
  4. пользователь + unknown_IP (пользователь) -> catflap
  5. (#denied> n) через catflaps (сайт) -> дроссельная заслонка (сайт) // slow the bots
  6. catflap + throttle + password + captcha -> запись // humans still welcome
  7. catflap + газ + пароль +! капча -> отказано // a correct guess from a bot

Замечания:

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

Эти наблюдения охватывают различные типы атак, против которых вы пытаетесь противостоять.

jamesh
источник
Абсолютно учетная запись электронной почты является частью поверхности атаки. У меня есть ряд предположений, касающихся верхней границы безопасности, которую будет обеспечивать моя стратегия, а самой низкой границей является собственная безопасность электронной почты пользователя. Если злоумышленник нарушит адрес электронной почты пользователя, все ставки отключены.
Дженс Роланд
Кроме того, я думаю, что вашей диаграмме перехода состояний требуется пара деталей: № 3 и № 4 должны включать пароль; # 1 и # 2 должны включать в себя unknown_IP (пользователь), поскольку логин всегда имеет известный или неизвестный IP; и № 6 - «вход, несмотря на газ»
Дженс Роланд
4

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

Бьорн Раупах
источник
На самом деле быстрая грубая сила тоже. Я надеялся быть несколько снисходительным с грубой силой фиксированного пользователя (дросселирование всего за 20 секунд), но на сайте с 50 тысячами пользователей, что сделало бы возможным быстрое грубое насилие с переменным пользователем (предполагая 20+ секунд для циклического перемещения по пользователям). И это, как говорится, будет отстой ..
Дженс Роланд
Хорошо быстрая перебор с одного хоста использует iptables или любой другой брандмауэр, который вы используете.
Бьорн Раупах
Я имел в виду распределенную быструю грубую силу. Это редко, но потенциально очень неприятно
Дженс Роланд
3

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

Файлы cookie могут быть украдены с помощью XSS и браузера. Пользователи обычно меняют браузеры или очищают свои куки.

Исходные IP-адреса являются одновременно динамически изменяемыми и поддельными.

Капча полезна, но не аутентифицирует конкретного человека.

Можно успешно сочетать несколько методов, но хороший вкус, безусловно, в порядке.

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

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

Как вы заметили, уменьшение количества неудачных попыток входа в систему является компромиссом между предотвращением атак методом перебора и простотой DoSing учетной записи. Агрессивные политики блокировки могут отражать отсутствие доверия к энтропии паролей.

Лично я не вижу выгоды от принудительного истечения срока действия пароля на веб-сайте. Атакующий получает ваш пароль один раз, затем он может изменить его и выполнить эту политику так же легко, как и вы. Возможно, одним из преимуществ является то, что пользователь может заметить раньше, если злоумышленник изменит пароль учетной записи. Еще лучше было бы, если бы пользователь был каким-то образом уведомлен, прежде чем злоумышленник получил доступ. В этом отношении полезны сообщения типа «N неудачных попыток с момента последнего входа в систему».

Наилучшая безопасность обеспечивается вторым фактором аутентификации, который является внеполосным по сравнению с первым. Как вы сказали, аппаратные токены в «чем-то, что у вас есть» великолепны, но у многих (не всех) есть реальные накладные расходы администратора, связанные с их распространением. Я не знаю ни одного биометрического решения «что-то, что ты есть», подходящего для веб-сайтов. Некоторые двухфакторные решения работают с поставщиками openid, у некоторых есть PHP / Perl / Python SDK.

Болотный луч
источник
Все отличные моменты - я не могу не согласиться. Пункт о небезопасности файлов cookie очень верен, но без второго фактора физических токенов или одноразовых паролей (распределенных по защищенной линии) вы действительно не сможете защитить от уязвимой конечной точки. Если ящик / браузер пользователя скомпрометирован, то же самое происходит с его логинами.
Дженс Роланд
1

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

Я на самом деле поймал кого-то, кто взломал учетную запись моего брата на myspace, потому что он пытался войти в учетную запись gmail, которую я для него установил, и использовал функцию «сбросить пароль по электронной почте» ... которая зашла в мой почтовый ящик.

nvuono
источник
1
  1. Как насчет одноразового пароля перед вводом обычного пароля? Это сделает очевидным, что кто-то атаковал до того, как у него появилось много возможностей угадать основной пароль?

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

Дуглас Лидер
источник
1) Как бы вы внедрили одноразовый пароль на незащищенной линии без проверки подлинности? Другими словами, когда пользователь устанавливает эти одноразовые пароли? 2) Да, это суть №4 в моем списке, ограничение по количеству неудачных попыток. Недостатком является возможность DoS, которую он открывает.
Дженс Роланд
0

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

С моей головы:

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

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

Далее, как насчет другого рода капчи: у вас есть ряд вопросов, которые не вызовут проблем у человека. Тем не менее, они не случайны. Когда начинается атака, всем задается вопрос № 1. Через час вопрос № 1 отбрасывается, его больше никогда не использовать, и каждый получает вопрос № 2 и так далее.

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

Лорен Печтель
источник
Откровенно говоря, альтернативный экран входа в систему может смущать людей больше, чем машины. Мы, конечно, предполагаем, что злоумышленник заранее проверил бы наши меры безопасности. Он мог бы легко настроить свой скребок, чтобы найти правильно расположенные поля.
Дженс Роланд
Контрольные вопросы были сделаны ранее, и это не очень эффективно. Для оператора ботнета-человека ответ на один вопрос в час (после которого новый ответ будет распространяться на ботов) во время атаки вполне осуществим.
Дженс Роланд
Вы упускаете суть. Атакующий не может проверить заранее, потому что он показывает дополнительную защиту, только когда появляется атака.
Лорен Печтел
Конечно, человек мог видеть, что это был за вопрос - но он должен сообщить об этом всем своим ботам. Это коммуникационный путь, который облегчает работу ботнета.
Лорен Печтел
Я не думаю, что я упускаю суть. Я не имею в виду, что он бы провел атаку ранее, чтобы проверить наши меры безопасности, я имею в виду, что он прочитал бы эту ветку и проверил (открытый) исходный код, чтобы проверить слабости :)
Дженс Роланд
0

Поскольку несколько человек включили CAPTCHA в качестве резервного механизма, я добавляю более ранний вопрос и поток StackOverflow об эффективности CAPTCHA.

ReCaptcha был взломан / взломан / OCR'd / победил / сломан?

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

Мэтью Глидден
источник
0

Вы также можете регулировать скорость, основываясь на надежности пароля пользователя.

Когда пользователь регистрирует или меняет свой пароль, вы рассчитываете степень надежности его пароля, например, от 1 до 10.

Нечто подобное «паролю» присваивается 1, в то время как «c6eqapRepe7et * Awr @ ch» может набирать 9 или 10, и чем выше этот показатель, тем дольше дросселирование срабатывает.

Джозеф В.
источник
2
Я понимаю идею, но это косвенно приведет к утечке информации о пароле, сообщая злоумышленнику, стоит ли взламывать пароль или нет. Это может показаться немного теоретическим, но многие пользователи повторно используют пароли, поэтому, если я захочу взломать Strong_Throttling_Website.com, я могу просто атаковать (привилегированные) учетные записи наугад, пока не найду пользователя «Фредди», у которого слабый пароль (т.е. раннее регулирование), затем перейдите к Less_Secure_Website.edu и выполните легкую атаку по словарю на учетную запись Фредди там. Это немного сложно, но, безусловно, выполнимо на практике.
Дженс Роланд
0

Первый ответ, который я обычно слышал, задавая этот вопрос, - это изменить порты, но забудьте об этом и просто отключите IPv4. Если вы разрешаете только клиентам из сетей IPv6, вы больше не будете молиться о простом сканировании сети, и злоумышленники прибегнут к поиску DNS. Не используйте тот же адрес, что и ваш Apache (AAAA) / Sendmail (MX-> AAAA) / что вы раздали всем (AAAA). Убедитесь, что ваша зона не может быть изменена, подождите, пока вы разрешаете кому-либо загружать ее?

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

** Протестируйте ваши обратные (PTR) записи (в ip6.arpa.), Чтобы увидеть, можно ли их использовать для обнуления в / 4, в которых есть записи VS / 4, в которых нет. IE Как правило, ip6.arpa будет иметь ~ 32 "." В адресе, но попытка с последними несколькими пропущенными может ускользнуть от сетевых блоков, имеющих записи, против других, которые не имеют. Если вы продолжите в том же духе, станет возможным пропустить большие части адресного пространства.

В худшем случае пользователям придется настраивать туннель IPv6, но вряд ли им придется заходить так далеко, как VPN в DMZ ... Хотя возникает вопрос, почему это не первый вариант.

Также Kerberos это круто, но IMHO LDAP удары (Что технически не так с NISPlus? Я читал, что Sun решила, что пользователи хотят LDAP, и из-за этого они отказались от NIS +). Kerberos отлично работает без LDAP или NIS, просто нужно управлять пользователями на хосте за хостом. Использование Kerberos дает вам простую в использовании, если не автоматизированную, PKI.

Майк Местник
источник
0

Здесь немного поздно, но я подумал, предполагая сложный случай - злоумышленник использует много случайных IP-адресов, случайных имен пользователей и случайных паролей, выбранных, скажем, из списка 10 000 самых популярных.

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

Тим 333
источник