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

Question

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

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

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